Importância da Abstração na prática

Publicado por Ricardo Ushisima
20/5/2012
Categoria:
Tags: , ,

Criar abstrações é uma prática recorrente em Engenharia de Software. Abstrações permitem aos desenvolvedores, entre outras coisas, representar o problema que uma aplicação se propõe a resolver, facilitando o entendimento e a solução do problema em questão. Abstração não é uma competência que se aprende apenas lendo livros, é necessário estudar e praticar o conhecimento. Mais sobre isso, leia o artigo Abstraction, Abstraction, Abstraction. Mas para mostrar um pouco da importância da abstração, vou estudar um caso de uma aplicação nossa onde algumas simples abstrações ajudaram a aplicação a evoluir e incorporar novas funcionalidades que nunca foram pensadas inicialmente, mas foram incorporadas na aplicação sem a necessidade de alterações drásticas na base do sistema.

O sistema estudado neste artigo é (originalmente) um sistema de cotação de preços que esta sendo ativamente desenvolvida e mantida pela ZBRA, e que vem evoluindo para incluir mais processos de negócio do cliente. O nosso sistema substitui um sistema de cotação similar desenvolvido por outra empresa e que os usuários não gostavam de usar por ser lento e de difícil manuseio, entre outros problemas.

A versão inicial da nova interface gráfica do sistema derivou de uma aplicação de prova de conceito que foi discutida com o cliente visando a melhoria na usabilidade da aplicação em relação a versão anterior. Quando o conceito foi aprovado, iniciou-se o desenvolvimento sobre o código escrito até em então. Por se tratar de uma prova de conceito, o foco foi a rapidez na produção do protótipo, não na abstração.

Interface Nova da Aplicação

A aplicação é composta de uma tela que mostra a lista de cotações do usuário e a partir dessa lista, é possivel abrir uma ou mais cotações para edição (a versão antiga permitia a visualização de apenas 1 cotação por vez) que ficam disponíveis na barra de navegação lateral do sistema. A lista de cotações e cada cotação são implementados como user controls. Até então, a implementação estava altamente acoplada com os elementos de UI usado para construir a interface principal do sistema. Por exemplo, o controle de cotação tinha acesso direto a barra de navegação lateral do sistema para conseguir colocar as ações do módulo na barra de comandos. Esse problema de acoplação foi resolvido durante a implementação da primeira versão do sistema, antes de colocar o sistema em produção. A solução é a abstração do modelo de visualização de módulos do sistema. O modelo é bem simples, mas representa bem a interface do sistema.

Modelo da Interface Gráfica

Esse modelo desacopla a implementação do formulário principal da implementação de cada módulo individual do sistema. Para o módulo, pouco importa como e onde o form principal (ModuleHost) mostra as ações do módulo ao usuário. Por experiência, sabemos que esse tipo de acoplação é ruim para o sistema e fizemos esse refactoring, mesmo que não traga grandes vantagens no momento. Tenho certeza que em muitas empresa, esse problema de falta de abstração teria sido deixado de lado. Mas essa decisão pode cobrar seu preço mais tarde, e no nosso caso, teria saído muito caro não fazê-lo.

Todo esse tempo gasto na abstração da interface e o refactoring para a sua implementação mostrou seu beneficio na implementação da versão mais recente da aplicação, quando o escopo foi ampliado para suportar mais um processo de negócio do cliente. Por questões de usabilidade, a interface gráfica do sistema passou a não ser a mais adequada.

A solução foi uma nova interface usando um Ribbon Bar para mostrar as ações dos módulos, e um Tabbed Panel para mostrar e navegar entre os módulos ativos. Para implementar essa nova interface foi necessário reimplementar apenas o ModuleHost (que é o form principal do sistema), que dita como os elementos de um módulo são mostrados. Por se tratar de uma view passiva, toda a lógica de negócio está separada em um supervising controller, o que facilitou muito a reimplementação da interface sem perder funcionalidades.

Interface Evoluída da Aplicação

Claro que essa alteração não foi totalmente indolor já que a organização das ações no ribbon é mais complexa que no navbar da versão anterior. Mas as alterações no modelo para incorporar esses elementos foram simples. Sem a abstração da interface, essa alteração teria um custo altíssimo devido ao acoplamento entre os módulos e a implementação do host de módulos. Essa evolução na interface teria sido vetada pelo cliente e o release entregue daria uma experiência ao usuário inferior à versão anterior. A adição de novos módulos ao sistema só agravaria o problema de falta de abstração, ficando cada vez mais difícil a evolução da interface. Isso em última instância provocaria uma estagnação do sistema pois a interface gráfica já não atende as necessidades do cliente. Novas aplicações teriam que ser desenvolvidas para atender aos requisitos do cliente.

A abstração é uma disciplina essencial no desenvolvimento de qualquer sistema, mesmo os mais simples; não apenas para garantir a entrega de um software bem desenvolvido, livre de erros e fácil de manter; mas também para garantir a evolução do sistema. O modelo adotado por nosso sistema é bem simples e genérico o suficiente para suportar as necessidades do nosso cliente. Lógico que essa abstração não vai resolver todos os problema da interface gráfica do sistema mas organiza o código e facilita a manutenção da interface gráfica e o desenvolvimento de novas funcionalidades.





Desenvolvido por hacklab/ com WordPress