Atividade:
|
Finalidade
|
|
Função: Designer | |
Freqüência: Uma vez por iteração, para um conjunto de casos de uso e/ou cenários de casos de uso (os que estiverem sendo desenvolvidos na iteração atual). | |
Etapas
As etapas a seguir são executadas para cada caso de uso na iteração atual:
As etapas a seguir são executadas uma vez por iteração:
Nota: As etapas anteriores são apresentadas em uma ordem lógica, mas talvez você tenha de alterná-las ou executar algumas delas em paralelo. |
|
Artefatos de Entrada: | Artefatos Resultantes: |
Mentores de Ferramentas: | |
Informações Adicionais: |
Detalhes de Workflow: |
Finalidade | Criar o elemento de modelagem utilizado para expressar o comportamento do caso de uso. |
Os Casos de Uso são o foco central de grande parte do trabalho inicial de análise e design. Para permitir a transição entre atividades centralizadas em Requisitos e em Análise/Design, o Artefato: Realização de Casos de Uso serve de ponte, fornecendo uma maneira de rastrear o comportamento nos Modelos de Análise e Design novamente no Modelo de Caso de Uso, bem como organizar as colaborações com base no 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 caso de uso de análise para seu caso de uso associado.
Para obter informações adicionais sobre realizações de casos de uso, consulte Diretrizes: Realização de Casos de Uso.
Finalidade | Capturar informações adicionais necessárias para entender o comportamento interno exigido do sistema que pode estar faltando na descrição do caso de uso elaborado para o cliente do sistema. |
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 ator 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
"O caixa eletrônico valida o cartão do 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 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:
"O caixa eletrônico envia o número da conta do cliente e o PIN para a rede de caixas eletrônicos para serem validados. A rede retornará êxito se o número do cliente conferir com o PIN e o cliente será autorizado a executar transações, caso contrário, a rede de caixas eletrônicos retornará uma falha."
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 ator 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 do caso 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:
Finalidade | Identificar uma sugestão de conjunto de elementos de modelo (classes de análise) capaz de executar o comportamento descrito em casos de uso. |
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, 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 atores, 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 Diretrizes: Classe de Análise. Para obter informações adicionais sobre realizações de casos de uso de análise, consulte Diretrizes: 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.
Finalidade | Expressar o comportamento do caso de uso em termos de classes de análise de colaboração. Determinar as responsabilidades das classes de análise. |
Para cada subfluxo independente (cenário):
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.
Finalidade | Descrever as responsabilidades de uma classe de objetos identificada no comportamento do caso de uso. |
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.
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.)
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.
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 | Definir as outras classes das quais a classe de análise depende. Definir os eventos em outras classes de análise sobre os quais a classe deve saber. Definir as informações pelas quais a classe de análise é responsável por manter. |
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 objetos, ou se forem transmitidas "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. Os exemplos incluem cadeia, inteiro, número.
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:
Nesse momento inicial da "vida" da classe, entretanto, é muito precipitado tomar esse tipo de decisão: não há informações suficientes ainda para uma decisão adequada. 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 uma relação "todo/parte" (consulte Diretrizes: Associação e Diretrizes: Agregação)).
Essas associações e agregações serão refinadas na Atividade: 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.
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 de "destino", sem que o "destino" tenha de 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 possui uma condição que define o evento que faz com que o assinante seja notificado. Para obter informações adicionais, consulte Diretrizes: 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:
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.
Finalidade | Reconciliar as realizações individuais de casos de uso de análise e identificar um conjunto de classes de análise com relações consistentes. |
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 caso 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 outro nome 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
Atividade: 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 na 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 Diretrizes: Classe de Análise.
Finalidade | Identificar mecanismos de análise (se houver) utilizados pelas classes de análise. Forneça informações adicionais sobre como as classes de análise aplicam o mecanismo 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 da seguinte forma:
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 da seguinte forma:
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 | Manter as relações de rastreabilidade entre o Modelo de Análise e outros modelos. |
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.
Finalidade | Verificar se os objetos de análise atendem aos requisitos funcionais
estabelecidos para o sistema. Verificar se os objetos de análise e as interações estão consistentes. |
Faça uma revisão informal ao final do workshop, como um ponto de sincronização, bem como uma conclusão da Atividade: Análise de Casos de Uso.
Utilize os pontos de verificação para saída de artefatos por esta atividade.
Rational Unified Process
|