Projeto
Identificação e Especificação de Componentes de Negócio
Como identificar e especificar componentes de negócio usando como base casos de uso e diagramas UML
Componentes partem do princípio da divisão e conquista - dividir um grande problema em partes menores e resolver essas partes menores individualmente. Ao final, o problemão terá sido resolvido, parte a parte. Pois, quando focamos o trabalho em um problema menor, podemos pensar em soluções específicas para ele.
E qual a novidade disso? Afinal, dividir para conquistar é um conceito utilizado desde que a programação estruturada foi criada.
A programação estruturada usava a idéia de dividir para conquistar na forma de decomposição funcional. Porém, os dados relacionados a essas funções não recebiam o mesmo tratamento. Eles eram mantidos em grandes bases, responsáveis por dados relacionados a diversas funcionalidades. Dessa forma o reuso e a gerência de mudanças ficavam extremamente comprometidos. Com isso, não só as funções eram bastante dependentes entre si, como os dados também.
A diferença da abordagem estruturada para a que utilizamos aqui pode ser resumida na união entre funções e dados relacionados, conceito que foi introduzido pela orientação a objetos.
A orientação a objetos tratou de minimizar o problema da dependência com a utilização de classes para unir funções e dados correlatos.
Um componente de negócio aglomera um conjunto de classes e dados altamente relacionados, em uma mesma unidade. De forma análoga à idéia de classe da orientação a objetos.
Devido a essa característica, arquiteturas baseadas em componentes de negócio oferecem uma maior capacidade de reuso, afinal, soluções baseadas em componentes geralmente são formuladas com o intuito de reutilizar código. Uma arquitetura que não se preocupa com reuso, tende a tratar o projeto de cada aplicação como algo individual e isolado. Seguindo essa linha, é enorme a possibilidade de encontrarmos funcionalidades redundantes entre as várias aplicações existentes em uma empresa, como pode ser visto na Figura 1, que demonstra um exemplo onde aplicações contêm funcionalidades redundantes entre si, caracterizando essas redundâncias na forma de porcentagem.
Figura 1. Redundancia entre aplicações.
Entretanto, o maior objetivo a ser alcançado quando se projeta um componente de negócio é atingir um alto nível de flexibilidade no gerenciamento de mudanças.
Sempre que a lógica de um determinado processo de negócio informatizado sofre uma modificação, a estrutura de software responsável por manter essa lógica deverá, por conseqüência, ser modificada também. Se toda essa lógica for projetada em forma de componentes de negócio, com suas dependências bem formuladas e delimitadas, a troca de um componente por outro ou a modificação de regras internas de um componente é de longe bem menos traumática do que a manutenção tradicional em sistemas não componentizados.
Isso só é possível porque um componente só se comunica através de suas interfaces. As interfaces de um componente representam a especificação daquilo que ele se propõe a oferecer.
O desenvolvimento baseado em componentes se destaca das outras abordagens existentes justamente por separar a interface de sua implementação.
Como os componentes só se comunicam por meio de suas interfaces, suas implementações ficam isoladas, o que reduz o grau de dependência entre classes.
A Figura 2 exemplifica uma troca de componentes. Observe que a classe ClienteExistente não precisou sofrer qualquer tipo de modificação para suportar o novo componente.
