Artefato:
| |||||||||||||||||||||||||||||||||||||||||||||||
 Classe de Análise |
As classes de análise representam um primeiro modelo conceitual para "elementos no sistema que possuam responsabilidades e comportamento". |
| Representação em UML: | Classe, estereotipada como "fronteira", "entidade" ou "controle". |
| Papel: | Designer |
| Mais informações: | |
| Entrada para Atividades: | Saída de Atividades: |
Classes de análise usadas 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 | atributo |
| descrição | uma breve descrição do papel da classe no sistema | atributo |
| responsabilidades | uma lista das responsabilidades da classe | atributo |
| atributos | os atributos da classe | atributo |
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 abaixo, são suficientes (com base 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 abaixo:
| 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 | Descrição | Tipo |
| Título do Curso | O nome do curso | seqüência de caracteres |
| Descrição | Uma breve descrição do curso | seqüência de caracteres |
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
|
