Os Casos de Uso são o foco central de grande parte do trabalho inicial de análise e design. Para ativar a transição entre tarefas centralizadas em Requisitos e tarefas centralizadas em Análise/Design, o Produto de Trabalho: Realização de Casos de Uso serve como uma ponte, fornecendo um caminho para rastrear o comportamento nos Modelos de Análise e Design de volta ao Modelo de Casos de Uso, assim como organizar colaborações ao redor do conceito de Caso de Uso.

Se não houver uma ainda, crie uma Realização de Casos de Uso de Análise no Modelo de Análise para o Caso de Uso.  O nome da Realização de Casos de Uso de Análise deve ser igual ao do Caso de Uso associado, e uma relação de "realizações" deve ser estabelecida da realização do casos de uso de análise para seu caso de uso associado.

Para obter informações adicionais sobre realizações de casos de uso, consulte Técnica: Realização de Casos de Uso.

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. Nesses casos, a descrição do caso de uso é lida como uma 'caixa preta', na qual detalhes internos sobre o que o sistema faz em resposta às ações de um agente não estão presentes ou foram descritos de forma muito resumida. Para localizar os objetos que executam o caso de uso, é necessário ter a descrição da 'caixa branca' sobre o que o sistema faz por uma perspectiva interna.

Exemplo

No caso de um caixa eletrônico, o cliente do sistema poderá preferir dizer

Para descrever o comportamento de autenticação do usuário do sistema. Embora possa ser suficiente para o cliente, essa frase não oferece nenhuma idéia do que realmente ocorre no 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:

Esse nível de detalhe fornece uma clara idéia de quais informações são necessárias (número da conta e PIN) e quem é o responsável pela autenticação (a rede de caixas eletrônicos, um agente no modelo de Caso 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 docaso de uso para saber se o comportamento interno do sistema está definido claramente. O comportamento interno do sistema não deve ser ambíguo para que fique claro o que o sistema deve fazer. Não é necessário definir os elementos do sistema (objetos) responsáveis pela execução desse comportamento - apenas uma definição clara do que precisa ser feito.

Fontes de informações sobre esses detalhes incluem especialistas em domínio que possam 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.

As alternativas a seguir destinam-se a complementar a descrição do Fluxo de Eventos:

• Não descrever de forma alguma. Esse poderá ser o caso, se você acha que os diagramas de interação são auto-explicativos ou se o Fluxo de Eventos do caso de uso correspondente fornece uma descrição suficiente.
• Complementar a descrição existente do Fluxo de Eventos. Inclua descrições complementares no Fluxo de Eventos nas áreas onde o texto existente não é claro no que diz respeito às ações que o sistema deve tomar.
• Descrevê-lo como um fluxo de texto completo, separado da descrição "externa" do Fluxo de Eventos do Caso de Uso. Essa alternativa é adequada nos casos em que o comportamento interno do sistema demonstra pouca semelhança com o seu comportamento externo. Nesse caso, uma descrição completamente separada, associada à realização de casos de uso de análise, em vez do caso de uso, é garantida.

Descobrir 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, classes de análise são utilizadas para representar as funções dos elementos de modelo que fornecem o comportamento necessário para atender aos requisitos funcionais especificados pelos casos de uso e aos requisitos não funcionais especificados pelos requisitos complementares. À 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.

As funções identificadas na Análise de Caso de Uso expressam primeiramente o comportamento das camadas superiores do sistema ou seja os comportamentos específicos do domínio e específicos do aplicativo. 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 o limite entre o sistema e seus agentes, as informações que o sistema utiliza e sua lógica de controle. Os estereótipos de classe, fronteira, entidade e controle, são conveniências usadas durante a Análise que desaparecem no Design.

Identificação de classes significa apenas que elas devem ser identificadas, nomeadas e descritas resumidamente em poucas sentenças.

Para obter informações adicionais sobre identificação de classes de análise, consulte Técnica: Classe de Análise. Para obter informações adicionais sobre realizações de casos de uso de análise, consulte Técnica: Realização de Casos de Uso.

Se determinados mecanismos e/ou padrões de análise foram documentados nas diretrizes específicas do projeto, utilize-os como outra fonte de "inspiração" para as classes de análise.

Para cada subfluxo independente (cenário):

• Crie um ou mais diagramas de interação (comunicação ou seqüência). Pelo menos um diagrama deverá ser necessário para o fluxo principal de eventos do caso de uso, e pelo menos um diagrama para cada fluxo alternativo/excepcional. Geralmente, é preciso ter diagramas separados para os subfluxos com pontos de decisão ou questões de tempo complexos ou para simplificar os fluxos complexos que dificilmente são entendidos em apenas um diagrama.
• Identifique as classes de análise responsáveis pelo comportamento exigido, percorrendo o fluxo de eventos do cenário, assegurando-se de que todo o comportamento exigido pelo caso de uso seja fornecido pela realização dos casos de uso de análise.
• Ilustre as interações entre as classes de análise no diagrama de interação. O diagrama de interação deve mostrar também as interações do sistema com seus agentes (as interações devem começar com um agente, já que ele sempre chama o caso de uso).
• Inclua as classes que representam as classes de controle dos casos de uso utilizados. (Utilize um diagrama de interação separado para cada caso de uso de extensão, mostrando apenas o comportamento variante do caso de uso de extensão.)

Um diagrama de comunicação para o caso de uso Receber Item do Depósito.

Se determinados mecanismos e/ou padrões de análise foram documentados nas diretrizes específicas do projeto, estes deverão ser indicados na alocação de responsabilidade e nos diagramas de interação resultantes.

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:

• as ações que o objeto pode executar
• o conhecimento que o objeto mantém e fornece a outros objetos

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.

Todos os objetos podem ser criados e excluídos sem salvar; não redefina o óbvio, a menos que o objeto desempenhe um comportamento especial quando criado ou excluído. (Alguns objetos não poderão ser removidos se certos relacionamentos existirem.)

Localização de Responsabilidades

As responsabilidades derivam das mensagens nos diagramas de interaçã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.

Documentação de Responsabilidades

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.

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:

• Definir atributos
• Estabelecer associações ente classes de análise
• Descrever dependência de evento entre classes de análise

Definir Atributos

Os atributos são usados para armazenar informações de uma classe. Especificamente, os atributos são usados quando as informações:

• São referidas "por valor" , ou seja, apenas o valor da informação é importante, não seu local nem o identificador do objeto.
• São de "propriedade" exclusiva do objeto ao qual pertencem; nenhum outro objeto consulta as informações.
• São acessadas por operações que apenas obtêm, definem ou executam transformações simples nas informações; as informações não possuem um comportamento "real" que não seja o fornecimento de seu valor.

Se, por outro lado, as informações apresentarem um comportamento complexo, se forem compartilhadas por dois ou mais objetos ou se forem transmitidas "por referência" entre dois ou mais objetos, 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. Os exemplos incluem cadeia,inteiro, número.

Estabelecer Associações entre Classes de Análise

Comece a observar os links nos diagramas de interação produzidos em Distribuir Comportamento para 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. Uma vez iniciado o design do sistema, esses links poderão ser realizados de várias maneiras:

• O objeto pode ter um escopo "global", o que significa que qualquer objeto do sistema pode enviar mensagens para ele
• Um objeto pode ser transmitido para o segundo objeto como um parâmetro; depois disso, poderá enviar mensagens para o objeto que foi transmitido.
• O objeto pode ter uma associação permanente com o objeto para o qual as mensagens foram enviadas.
• O objeto pode ser criado e eliminado no escopo da operação (isto é, um objeto 'temporário') - esses objetos são considerados 'locais' à operação.

Nesse momento inicial da "vida" da classe, entretanto, é muito precipitado tomar essas decisões: não há informações suficientes ainda para uma decisão adequada. Como conseqüência, na 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 uma relação "todo/parte" (consulte Técnica: Associação e Técnica: Agregação)).

Essas associações e agregações serão refinadas na Tarefa: Design de 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 realizar os casos de uso; não inclua associações que "talvez" existam, a não ser que elas sejam necessárias, com base nos diagramas de interação.

Dê às associações nomes e multiplicidades de papéis.

• O nome da função deve ser um substantivo que indique a função do objeto associado em relação ao objeto de associação.
• Adote uma multiplicidade de 0..* (zero para muitos), a não ser que haja uma forte evidência de algo mais. Uma multiplicidade equivalente a zero sugere que a associação é opcional. Certifique-se de que é isso mesmo que você quer. Se um objeto não deve ser incluído, as operações que usam a associação terão que ser ajustadas compativelmente.
• Podem ser especificados limites menores para a multiplicidade, como 3..8.
• Dentro das faixas de multiplicidade, podem ser especificadas probabilidades. Portanto, se a multiplicidade for 0..*, espera-se que esteja entre 10 e 20 em 85% dos casos. Registre essas informações, pois elas serão de grande importância durante a fase de design. Por exemplo, se o armazenamento persistente for implementado com a utilização de um banco de dados relacional, limites menores ajudarão a organizar melhor as tabelas do banco de dados.

Redija uma breve descrição da associação para indicar como a associação é usada ou que relacionamentos são representados pela associação.

Descrever Dependências de Evento entre between Classes de Análise

Algumas vezes, os objetos precisam saber quando ocorre um evento em um objeto de "destino", sem que o "destino" tenha de saber todos os objetos que precisam de notificação quando o evento ocorre. 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 possui uma condição que define o evento que faz com que o assinante seja notificado. Para obter informações adicionais, consulte Técnica: Associação de Assinatura

As condições da associação de assinatura devem ser expressas em termos de características abstratas, e não em termos de suas operações ou 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:

• se um objeto sofre a influência de algo ocorrido em outro objeto
• se um novo objeto deve ser criado para tratar de algum evento, por exemplo, quando ocorre um erro, deve ser criada uma nova janela para notificar o usuário
• se um objeto precisa saber quando um outro objeto é instanciado, alterado ou eliminado

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 de saber sobre todos esses outros objetos - eles apenas 'demonstram' interesse no objeto de entidade e são notificados quando esse objeto é alterado.

Agora é tudo uma questão de 'habilidade manual': no design, é preciso definir como exatamente essa notificação funciona. É possível adquirir uma estrutura de notificação ou talvez seja necessário projetar e construir uma por conta própria. 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.

As realizações de casos de uso de análise foram desenvolvidas como resultado da análise de um caso de uso específico.  Agora as realizações individuais de casos de uso de análise precisam ser reconciliadas.  Examine as Classes de Análise e as associações de suporte definidas para cada realização de casos de uso de análise.  Identifique e resolva as inconsistências e remova toda duplicidade.  Por exemplo, duas realizações de casos de uso de análise diferentes poderão incluir uma classe de análise conceitualmente igual mas, como as classes de análise foram identificadas por Designers diferentes, um nome diferente foi utilizado. 
Nota: a duplicação em realizações de casos de uso de análise poderá ser reduzida significativamente se o Arquiteto de Software fizer um bom trabalho de definição de uma arquitetura inicial (consulte Tarefa: Análise Arquitetural).

Ao reconciliar os elementos de modelo, é importante levar em conta suas respectivas relações.  Se duas classes estão mescladas ou uma classe substitui outra não deixe de propagar as relações da classe original para a nova classe.

O Arquiteto de Software deve participar da reconciliação das realizações de casos de uso de análise, visto que a reconciliação exige um entendimento do contexto do negócio, bem como uma previsão da arquitetura de software e do design para que as classes de análise que melhor representam os domínios de problemas e soluções possam ser selecionadas.

Para obter informações adicionais sobre classes, consulte Técnica: Classe de Análise.

Nesta etapa, são examinados os mecanismos de análise aplicáveis a cada classe de análise identificada.

Se uma classe de análise utiliza um ou mais mecanismos de análise, as informações adicionais capturadas nesse momento ajudarão o arquiteto e os designers de software a determinar 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 utilizado por uma classe de análise, qualifique as características relevantes que precisam ser consideradas ao selecionar os mecanismos apropriados 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 conjecturais 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 utilizadas por uma classe de Vôo poderiam ser qualificadas 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 utilizadas por uma classe de Missão poderiam ser qualificadas 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

As diretrizes específicas do projeto determinam que tipo de rastreabilidade é necessária aos elementos do Modelo de Análise.

Por exemplo, se houver um modelo separado de interface com o usuário, ele poderá ser útil para rastrear telas ou outros elementos da interface com o usuário nesse modelo para classes de limite no Modelo de Análise.

Faça uma revisão informal ao final do workshop, como um ponto de sincronização, bem como uma conclusão da Tarefa: Análise de Casos de Uso.

Utilize a(s) lista(s) de verificação para saída de produtos de trabalho por esta tarefa.