Atividade:
| |||||||||||||||||||||||||||
Finalidade
|
|
Passos
|
|
| Artefatos Informados: | Artefatos Resultantes: |
| Freqüência: Uma vez por iteração, para um conjunto de Artefato: Realizações de Casos de Uso | |
| Papel: Designer | |
| Diretrizes: | |
| Mentor de Ferramentas: | |
| Detalhamento do Fluxo de Trabalho: |
Finalidade
|
A descrição de cada caso de uso nem sempre é suficiente para localizar as classes de análise e seus objetos. Geralmente, o cliente acha desinteressantes as informações sobre o que ocorre no sistema, de forma que as descrições de casos de uso não precisam incluir esse tipo de informação. Em casos como esse, a descrição do caso de uso é lida como uma descrição em 'caixa preta', na qual detalhes internos sobre como o sistema responde às ações de um ator estão ausentes ou descritas muito resumidamente. Para encontrar os objetos que realizam o caso de uso, é preciso uma descrição em 'caixa branca' do que o sistema executa por uma perspectiva interna.
Exemplo
No caso de um Sistema de Caixa Eletrônico, o cliente do sistema pode preferir
"O Sistema de Caixa Eletrônico valida o cartão de Cliente do Banco."
Para descrever o comportamento de autenticação do usuário do sistema. Embora possa ser suficiente para o cliente, essa frase não nos oferece nenhuma idéia do que realmente ocorre no interior do Sistema de Caixa Eletrônico para validar o cartão.
Para obter uma imagem interna de como o sistema funciona, em um nível suficiente de detalhe que identifique os objetos, podem ser necessárias informações adicionais. Tomando como exemplo a atividade de validação do cartão do Sistema de Caixa Eletrônico, a descrição ampliada seria:
"O Sistema de Caixa Eletrônico envia o número da conta do cliente e o PIN para a Rede do Sistema para serem validados. A Rede do Sistema de Caixa Eletrônico informará um êxito se o número do cliente corresponder ao PIN, e o cliente será autorizado a executar transações. Caso contrário, a Rede do Sistema de Caixa Eletrônico informará uma falha."
Esse nível de detalhamento nos dá uma idéia clara das informações necessárias (número da conta e PIN) e de quem é responsável pela autenticação (a Rede do Sistema de Caixa Eletrônico, um ator no modelo de Casos de Uso). Com essas informações, podemos identificar dois possíveis objetos (um objeto Cliente, com atributos de número de conta e PIN, e uma Interface de Rede do Sistema de Caixa Eletrônico), como também suas respectivas responsabilidades.
Examine a descrição do caso de uso para verificar se o comportamento interno do sistema está claramente definido. O comportamento interno do sistema não deve ser ambíguo, para que fique bem claro o que o sistema executa. Não é necessário definir os elementos contidos no sistema (objetos) responsáveis pela execução desse comportamento - basta uma definição do que precisa ser feito.
Entre as fontes de informações para esses detalhes estão os especialistas em domínio, que podem ajudar a definir o que o sistema precisa fazer. Uma boa pergunta ao considerar determinado comportamento do sistema é "o que significa para o sistema executar tal ação?". Se o que o sistema faz para executar o comportamento não estiver bem definido para responder a essa pergunta, é provável que haja a necessidade de incluir mais informações.
Estas são alternativas para a suplementação da descrição do Fluxo de Eventos:
Finalidade
|
Encontrar essa sugestão de conjunto de classes de análise é o primeiro passo na transformação do sistema, da mera declaração do comportamento necessário à descrição de como ele funcionará. Nesse esforço, as classes de análise são usadas para representar os papéis dos elementos de modelo que oferecem o comportamento necessário para atender aos requisitos funcionais especificados pelos casos de uso e aos requisitos não-funcionais especificados pelos requisitos suplementares. À medida que a ênfase do projeto se desloca para o design, esses papéis desenvolvem um conjunto de elementos de design que realizam os casos de uso.
Os papéis identificados na Análise de Caso de Uso expressam principalmente o comportamento das camadas superiores do sistema - comportamento específico do aplicativo e comportamento específico do domínio. As classes de fronteira e as classes de controle normalmente evoluem para elementos de design da camada de aplicativo, enquanto as classes de entidade evoluem para elementos de design específicos do domínio. Em geral, os elementos de design de camadas inferiores evoluem a partir dos mecanismos de análise usados pelas classes de análise aqui identificadas.
A técnica descrita aqui utiliza três perspectivas distintas do sistema para orientar a identificação de sugestões de classes. As três perspectivas são a fronteira entre o sistema e seus atores, as informações que o sistema usa e a lógica de controle do sistema. Os estereótipos de classe, fronteira, entidade e controle, são conveniências usadas durante a Análise que desaparecem no Design.
A identificação de classes significa que: elas devem ser identificadas, nomeadas e descritas em poucas palavras.
Para obter mais informações sobre as classes de análise, consulte Diretrizes: Classe de Análise. Para obter mais informações sobre realizações de casos de uso, consulte Diretrizes: Realização de Casos de Uso.
Finalidade
|
| Diretrizes: Realizações de Casos de Uso, Diagramas de Colaboração |
Para cada subfluxo independente (cenário):
Um diagrama de colaboração para o caso de uso Receber Item de Depósito.
Finalidade
|
| Mentor de Ferramentas: Documentação de Responsabilidades de Classe com o Rational Rose |
Responsabilidade é a informação de algo que um objeto pode ser solicitado a fornecer. As responsabilidades se transformam em uma (normalmente mais de uma) operação em classes de design. Elas podem ser caracterizadas como:
Cada classe de análise deve ter várias responsabilidades. Uma classe com apenas uma responsabilidade é, provavelmente, muito simples, enquanto uma outra com uma dúzia ou mais de responsabilidades ultrapassa o limite do bom senso e deve poder ser dividida em várias outras classes.
Não é preciso dizer que todos os objetos podem ser criados e excluídos. Não redefina o óbvio, a menos que o objeto desempenhe algum comportamento especial quando criado ou excluído. (Alguns objetos não poderão ser removidos se certos relacionamentos existirem.)
As responsabilidades derivam-se de mensagens nos diagramas de colaboração. Em cada mensagem, verifique a classe do objeto para a qual a mensagem foi enviada. Se a responsabilidade ainda não existir, crie uma nova que forneça o comportamento solicitado.
Outras responsabilidades se originarão dos requisitos não-funcionais. Quando criar uma nova responsabilidade, verifique nos requisitos não-funcionais se há requisitos relacionados aplicáveis. Amplie a descrição da responsabilidade ou crie uma nova responsabilidade que reflita essa situação.
As responsabilidades devem ser documentadas com um nome curto (de poucas palavras) e uma descrição resumida (com algumas frases). A descrição define o que o objeto faz para cumprir a responsabilidade e qual é o resultado retornado quando a responsabilidade é disparada.
Finalidade
|
Para cumprir suas responsabilidades, as classes freqüentemente dependem de outras classes para fornecer o comportamento necessário. As associações documentam os relacionamentos entre as classes e ajudam a compreender o acoplamento de classes e a redução de acoplamentos, quando possível. Além disso, ajudam a criar sistemas melhores e mais resistentes.
Os seguintes passos definem os atributos de classes e as associações entre classes:
Os atributos são usados para armazenar informações de uma classe. Especificamente, os atributos são usados quando as informações:
Se, por outro lado, as informações apresentarem um comportamento complexo, se forem compartilhadas por dois objetos ou mais, ou se forem passadas "por referência" entre dois objetos ou mais, elas deverão ser modeladas como uma classe separada.
O nome do atributo deve ser um substantivo que defina claramente que informações o atributo contém.
A descrição deve incluir as informações que serão armazenadas no atributo. Esse é um procedimento opcional caso as informações armazenadas possam ser obviamente deduzidas a partir do nome do atributo.
O tipo de atributo é o tipo de dados simples do atributo. Como por exemplo, seqüência de caracteres, inteiro, número.
Comece a analisar os vínculos dos diagramas de colaboração produzidos em Distribuir Comportamento para as Classes de Análise. Os vínculos entre as classes indicam que os objetos das duas classes precisam se comunicar entre si para realizarem o Caso de Uso. Depois que começamos o design do sistema, esses vínculos podem ser executados de várias maneiras:
Nesse momento inicial da "vida" da classe, é muito precipitado tomar esse tipo de decisão: ainda não temos informações suficientes para tomar decisões bem formadas. Como conseqüência, durante a análise, criamos associações e agregações para representar (e "transportar") mensagens que devem ser enviadas entre os objetos de duas classes. (A agregação, uma forma especial de associação, indica que os objetos participam de um relacionamento "todo/parte" (consulte Diretrizes: Associação e Diretrizes: Agregação)).
Essas associações e agregações serão refinadas em Atividade: Design da Classe.
Para cada classe, elabore um diagrama de classes que mostre as associações com outras classes:
Exemplo de diagrama de classes de análise para parte de um Sistema de Entrada de Pedidos
Concentre-se apenas nas associações necessárias para a realização dos casos de uso. Não inclua associações que "talvez" existam, a não ser que elas sejam necessárias, de acordo com os diagramas de colaboração.
Dê às associações nomes e multiplicidades de papéis.
Redija uma breve descrição da associação para indicar como a associação é usada ou que relacionamentos são representados pela associação.
Algumas vezes, os objetos precisam saber quando ocorre um evento em um objeto-"alvo", sem que o "alvo" tenha que saber quais são os objetos que precisam de notificação da ocorrência do evento. Para mostrar essa dependência de notificação de evento, uma associação de assinatura permite expressar essa dependência de maneira compacta e concisa.
Uma associação de assinatura entre dois objetos indica que o objeto assinante será informado quando determinado evento ocorrer no objeto assinado. Uma associação de assinatura tem uma condição definidora do evento que faz o assinante ser notificado. Para obter mais informações, consulte Diretrizes: Associação de Assinatura
As condições de associação de assinatura devem ser expressas em termos de características abstratas, e não em termos de suas operações ou seus atributos específicos. Dessa forma, o objeto associativo é mantido independente do conteúdo do objeto de entidade associado, que pode ser mudado.
Uma associação de assinatura é necessária:
Os objetos 'assinados' são geralmente objetos de entidade. Os objetos de entidade normalmente são armazenamentos passivos de informações, com um comportamento que, em geral, relaciona-se às suas respectivas responsabilidades de armazenamento de informações. Com freqüência, muitos outros objetos precisam saber quando os objetos da entidade mudam. A associação de assinatura evita que o objeto de entidade tenha que ter informações sobre todos esses outros objetos - eles apenas 'demonstram' interesse no objeto de entidade e são notificados quando esse objeto muda.
Tudo isso passa a ser um 'truque de análise': durante o design, temos que definir como essa notificação realmente funciona. É possível adquirir um framework de notificação ou projetar e criar um próprio. Contudo, no momento, a observação de que a notificação existe já é suficiente.
Observe que a direção da associação mostra que somente o objeto assinante está ciente da relação entre os dois objetos. A descrição da assinatura está inteiramente no objeto assinante. O objeto de entidade associado, por sua vez, é definido de forma usual sem considerar que outros objetos possam estar interessados em sua atividade. Isso também implica que um objeto assinante pode ser adicionado ao modelo, ou removido, sem mudar o outro objeto da assinatura.
Finalidade
|
Se a classe de análise usa um ou mais mecanismos, as informações adicionais capturadas nesse momento ajudarão o arquiteto e os designers de software a determinarem os recursos necessários dos mecanismos de design de arquitetura. O número de instâncias da classe de análise, seu tamanho, sua freqüência de acesso e seu tempo de vida esperado estão entre as propriedades importantes que podem auxiliar os designers na seleção de mecanismos adequados.
Para cada mecanismo de análise usado pela classe de análise, qualifique as características relevantes que precisam ser consideradas durante a seleção apropriada dos mecanismos de design e implementação. Elas variam de acordo com o tipo de mecanismo. Defina tipos de mecanismos quando apropriado ou quando ainda houver um alto grau de incerteza. Mecanismos de arquitetura distintos têm características distintas, de forma que essas informações são meramente descritivas e só precisam ser estruturadas o necessário para capturar e conter as informações. Durante a análise, essas informações são geralmente bastante especulativas, mas sua captura é vantajosa, pois as estimativas conjeturais podem ser revisadas à medida que mais informações são obtidas.
Os mecanismos de análise usados por uma classe e sua respectiva característica não precisam ser capturados de maneira formal. Uma anotação incluída em um diagrama ou em uma extensão da descrição da classe bastam para conter as informações. As informações sobre características nesse ponto de evolução da classe é fluido e especulativo, de forma que a ênfase recai sobre a captura de valores esperados, e não sobre a formalização da definição dos mecanismos.
Exemplo
As características do mecanismo de persistência usadas por uma classe Vôo podem ser classificadas como:
Granularidade: 2 a 24 Kbytes por vôo
Volume: Até 100.000
Freqüência de acesso:
- Criação/exclusão: 100 por hora
- Atualização: 3.000 atualizações por hora
- Leitura: 9.000 acessos por hora
Exemplo
As características do mecanismo de persistência usadas por uma classe Missão podem ser classificadas como:
Granularidade: 2 a 3 Mbytes por missão
Volume: 4
Freqüência de acesso:
- Criação/exclusão: 1 por dia
- Atualização: 10 por dia
- Leitura: 100 por hora
Finalidade
|
Faça uma revisão informal no fim do workshop, como um ponto de sincronização, e na conclusão de Atividade: Análise de Caso de Uso.
Consulte Pontos de Verificação para as Realizações de Casos de Uso e Pontos de Verificação: Classe de Análise.
|
Rational Unified Process
|
