Um modelo de objeto que descreve a realização de casos de uso e que funciona como uma abstração do Artefato: Modelo de Design. O Modelo de Análise contém os resultados da análise do caso de uso, instâncias do Artefato: Classe de Análise.
Outros Relacionamentos:  Cont‚m
Função:  Arquiteto de Software  
Opcionalidade/Ocorrência:  Opcional.  Fases de Elaboração e Construção.
Gabaritos e Relatórios: 
     
Exemplos: 
     
Representação em UML:  Modelo, estereotipado como <<modelo de análise>>. 
Informações Adicionais:   
Entrada de Atividades:    Saída das Atividades:   

Finalidade Para o início da página

O modelo de análise contém as classes de análise e qualquer artefato associado. O modelo de análise pode ser um artefato temporário, como no caso em que evolui para um modelo de design, ou pode continuar a existir através de parte ou de todo o projeto e, talvez, servindo como uma visão geral conceitual do sistema.

Propriedades Para o início da página

Nome da Propriedade 

Breve Descrição 

Representação em UML 

Introdução  É uma descrição textual que funciona como uma rápida introdução do modelo.   Valor ativado, do tipo "texto curto". 
Pacotes de Análise  Os pacotes do modelo, representando uma hierarquia.   Incluídos por meio da associação "representa" ou recursivamente por meio da agregação "possui". 
Classes  As classes do modelo, pertencentes aos pacotes.   Adquiridos recursivamente por meio da agregação "possui". 
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.   -" - 

Sincronização Para o início da página

O Modelo de Análise é criado na fase de Elaboração e atualizado na Fase de Construção, conforme a estrutura do modelo é atualizada.

Responsabilidade Para o início da página

O arquiteto de software é responsável pela integridade do Modelo de Análise, garantindo que:

  • Ele é mantido em um estado atual, refletindo uma visão geral abstraída do design.

Adaptação Para o início da página

Normalmente, as "classes de análise" evoluirão diretamente para elementos no Modelo do Design: algumas se tornam classes de design, outras 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. O resultado é que as "classes de análise" freqüentemente são 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 & 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.



Rational Unified Process   2003.06.15