Artefato:
|
![]() |
As classes de análise representam um primeiro modelo conceitual para 'itens no sistema que possuam responsabilidades e comportamento'. |
Outros Relacionamentos: |
Parte de Modelo de Análise
|
---|---|
Função: | Designer |
Opcionalidade/Ocorrência: | Opcional. Fases de Elaboração e Construção. |
Gabaritos e Relatórios: |
|
Exemplos: | |
Representação em UML: | Classe, estereotipada como <<limite>>, <<entidade>> ou <<controle>>. |
Informações Adicionais: | |
Entrada de Atividades: | Saída das Atividades: |
Classes de análise são utilizadas para capturar os principais "blocos de responsabilidade" no sistema. Elas representam as classes prototípicas do sistema e são um 'primeiro passo' nas principais abstrações que o sistema deve tratar. As classes de análise podem ser mantidas em sua própria prerrogativa, se você desejar uma visão geral do sistema de "alto nível" e conceitual. As classes de análise também geram as principais abstrações do design do sistema: as classes de design e os subsistemas do sistema.
Nome da Propriedade |
Breve Descrição |
Representação em UML |
---|---|---|
nome | o nome da classe | attribute |
descrição | uma descrição breve da função da classe no sistema | attribute |
responsabilidades | uma listagem das responsabilidades da classe | attribute |
atributos | os atributos da classe | attribute |
As classes de análise são identificadas primeiro na Fase de Elaboração, conforme os Casos de Uso são analisados. Algumas Classes de Análise podem ser identificadas tão tarde quanto a Fase de Construção, para Casos de Uso que não são analisados até a Fase de Construção.
Um designer é responsável pela integridade da classe de análise, garantindo que:
As classes de análise, consideradas como um todo, representam um modelo conceitual primitivo do sistema. Esse modelo conceitual evolui rapidamente e permanece fluido por algum tempo enquanto representações diferentes e suas implicações são exploradas. A documentação formal pode impedir esse processo; portanto, tenha cuidado com a quantidade de energia gasta mantendo esse 'modelo' em um sentido formal. Você pode perder muito tempo refinando um modelo que é altamente descartável. As classes de análise raramente sobrevivem no design inalterado. Muitas delas representam colaborações inteiras de objetos, freqüentemente encapsuladas por subsistemas.
Normalmente, cartões de nota simples, como no exemplo a seguir, são suficientes (esse é baseado na técnica conhecida de Cartão CRC} - consulte [WIR90] para obter detalhes dessa técnica. Na parte da frente do cartão, capture o nome e a descrição da classe. Um exemplo de Curso em um sistema de registro de curso é listado a seguir:
Nome da Classe | Curso | |||||||||
---|---|---|---|---|---|---|---|---|---|---|
Descrição | O Curso é responsável pela manutenção das informações sobre um conjunto de seções do curso que tenham um assunto comum, requisitos e resumo. | |||||||||
Responsabilidades | Para manter as informações sobre o curso. | |||||||||
Atributos |
|
No verso do cartão, desenhe um diagrama da classe:
Diagrama de classe do Curso
Há um cartão da classe de análise para cada classe descoberta durante o workshop de análise do caso de uso.
Rational Unified Process
|