Artefato:
|
![]() |
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: |
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.
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. | -" - |
O Modelo de Análise é criado na fase de Elaboração e atualizado na Fase de Construção, conforme a estrutura do modelo é atualizada.
O arquiteto de software é responsável pela integridade do Modelo de Análise, garantindo que:
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:
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
|