Artefato:  Modelo de Análise

Modelo de Análise	Um modelo de objeto que descreve a realização dos 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. O Modelo de Análise é um artefato opcional (consulte Adaptação).
Representação em UML:	Modelo, estereotipado como "modelo de análise".
Papel:	Arquiteto de Software
Possibilidade de Opção:	O modelo de análise é opcional.
Exemplos:	Modelo de Análise, do Sistema de Matrícula de Curso
Mais informações:	Diretrizes: Modelo de Design Diretrizes: Classe de Análise
Finalidade Propriedades Ocorrência Responsabilidade Adaptação

Entrada para Atividades: Análise de Caso de Uso

Saída de Atividades: Definir Requisitos de Automatização Análise de Caso de Uso

Finalidade

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

Ocorrência

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

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

Normalmente, "as classes de análise" evoluirão diretamente para elementos no Modelo do Design: algumas tornam-se 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 permanecem consistentes deve ser comparado com o benefício de ter uma visão do sistema que representa 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.

Copyright  (c) 1987 - 2001 Rational Software Corporation

Rational Unified Process