| Opções de Representação |
Representação UML: Modelo, estereotipado como <<modelo de análise>>.
O modelo de análise pode ter as seguintes propriedades:
-
Introdução: Uma descrição textual que serve como uma introdução resumida para o modelo.
-
Pacotes de Análise: Os pacotes do modelo, representando uma hierarquia.
-
Classes: As classes do modelo, pertencentes aos pacotes.
-
Relacionamentos: Os relacionamentos do modelo, pertencentes aos pacotes.
-
Realizações de Casos de Uso: As realizações de casos de uso do modelo, pertencentes aos pacotes.
-
Diagramas : Os diagramas do modelo, pertencentes aos pacotes.
Normalmente, as "classes de análise" evoluirão diretamente para elementos do Modelo de Design: algumas se tornam
classes de design, outras se tornam subsistemas de design. A meta da Análise é identificar um mapeamento preliminar do
comportamento necessário dos elementos da modelagem no sistema. A meta do Design é transformar esse mapeamento
preliminar (e um pouco idealizado) em um conjunto de elementos de modelo que pode ser implementado. O resultado é que
há um refinamento detalhado e preciso quando alguém se move da Análise para o Design. Como resultado, as "classes de
análise" são geralmente um pouco fluidas, alteráveis e evoluem muito antes de se concretizarem nas atividades de
Design.
Pontos que devem ser considerados para decidir se um Modelo de Análise separado é necessário:
-
Um Modelo de Análise separado pode ser útil quando o sistema deve ser projetado para vários ambientes-alvo, com
arquiteturas de design separadas. O Modelo de Análise é uma abstração, ou uma generalização, do Modelo de Design.
Ele omite a maioria dos detalhes do design para fornecer uma visão geral da funcionalidade do sistema.
-
O design é tão complexo que é preciso um "design" abstrato simplificado para introduzir o design aos novos membros
da equipe. Novamente, uma arquitetura bem definida pode servir ao mesmo fim.
-
O trabalho extra necessário para garantir que os modelos de Análise e Design permaneçam consistentes deve ser
comparado com o benefício de ter uma visualização do sistema que represente apenas os detalhes mais importantes de
como o sistema funciona. Pode ser muito custoso manter um alto grau de fidelidade entre o Modelo de Análise e o
Modelo de Design. Uma abordagem menos ambiciosa pode ser manter o Modelo de Análise apenas com as classes de
domínio mais importantes e as principais abstrações no design. Conforme a complexidade do Modelo de Análise
aumenta, também aumenta o custo de mantê-la.
-
Quando o Modelo de Análise não é mais mantido, seu valor diminui rapidamente. Em algum ponto, se ele não for
mantido, deixará de ser útil quando não refletir mais com precisão o design atual do sistema. A decisão de não
manter mais o Modelo de Análise pode ser apropriada (ele pode ter atendido a seu propósito), mas a decisão deve ser
consciente.
Em algumas empresas, onde os sistemas funcionam há décadas, ou onde há muitas variantes do sistema, um modelo de
análise separado mostra-se útil.
|
