Artigo Engenharia de Software 3 - Identificação e Especificação de Componentes de Negócio

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." [...] continue lendo...