A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Abr-17 Analisar Caso de Uso Analisar caso de uso.

Apresentações semelhantes


Apresentação em tema: "Abr-17 Analisar Caso de Uso Analisar caso de uso."— Transcrição da apresentação:

1 abr-17 Analisar Caso de Uso Analisar caso de uso

2 Objetivos deste módulo
abr-17 Objetivos deste módulo Apresentar os passos necessários para realizar a atividade analisar casos de uso e discutir seus artefatos Apresentar os diagramas de seqüência, colaboração e classes de UML Analisar caso de uso

3 Fluxo de análise e projeto
abr-17 Analisar Serviços Arquiteto de Software Projetar Serviços Projetar Arquitetura Revisor de projeto Prototipar Interface gráfica Arquiteto de Informação Analisar Casos de Uso Projetar Casos de Uso Projetar Subsistemas/ componentes Analista de Sistemas Revisar Projeto Projetar classes Projetar Base de Dados Projetista de Banco de Dados Fluxo de análise e projeto

4 Fluxo de análise e projeto
abr-17 Analisar Serviços Arquiteto de Software Projetar Serviços Projetar Arquitetura Revisor de projeto Prototipar Interface gráfica Arquiteto de Informação Analisar Casos de Uso Projetar Casos de Uso Projetar Subsistemas componentes Analista de Sistemas Revisar Projeto Projetar classes Projetar Base de Dados Projetista de Banco de Dados Fluxo de análise e projeto

5 Objetivos desta atividade
abr-17 Objetivos desta atividade Encontrar as classes iniciais do sistema (classes de análise) e distribuir comportamento dos casos de uso entre elas Para cada classe, descrever as responsabilidades, atributos e associações Esta atividade é realizada para cada caso de uso! Esta atividade é realizada uma vez para cada caso de uso a ser desenvolvido na iteração, isto é, o foco da atividade é em um caso de uso específico. Analisar caso de uso

6 Visão geral dos artefatos
abr-17 Modelo de Casos de Uso Documento de Requisitos Glossário Documento da Arquitetura Realização de Caso de Uso Analisar Caso de Uso Analista de Sistemas Os elementos chave desenvolvidos nesta atividade são as classes de análise e as primeiras versões das realizações dos casos de uso, que fazem parte do Modelo de Análise e Projeto. Diagrama de Colaboração Diagrama de Classes Diagrama de Seqüência Analisar caso de uso

7 Passos para Analisar Casos de Uso
abr-17 Para cada caso de uso: 1. Encontrar classes de análise 2. Identificar persistência Para cada classe: 3. Distribuir comportamento entre as classes 4. Descrever responsabilidades 5. Descrever atributos e associações 6. Revisar os Resultados Durante a realização dos passos, usa-se bastante a descrição do caso de uso, particularmente de seu fluxo de eventos. Às vezes, a descrição do fluxo é feita em um nível de abstração elevado e, eventualmente, pode ser preciso detalhar mais alguma parte específica do fluxo de eventos. Neste caso, é preciso entrar em contato com o especificador de requisitos para esclarecer quaisquer dúvidas e/ou propor alguma mudança no Documento de Requisitos. Aspectos não-funcionais a nível de análise já devem ser identificados nesta atividade. Aqui, o foco é em persistência, mas deve-se atentar para outros aspectos como segurança. Analisar caso de uso

8 Passo 1. Encontrar classes de análise
abr-17 O comportamento do caso de uso é distribuído em classes de análise dos seguintes tipos (estereótipos) fronteira controle entidade Estes estereótipos são uma conveniência de análise que desaparecem no projeto As classes de análise constituem a primeira tentativa de modelar como o sistema irá realizar o caso de uso. Elas são ainda bastante abstratas, e, durante a etapa de projeto, poderão ser divididas em outras classes ou até mesmo transformadas em subsistemas. A idéia é que elas aglutinem os conceitos e responsabilidades necessários para a realização dos casos de uso; os detalhes e pormenores das classes são tratados posteriormente. As classes de análise podem ser de três tipos: fronteira, entidade e controle. Veremos neste passo como identificar as classes usando três diferentes perspectivas do sistema: classes de fronteira (entre os atores e os casos de uso), classes de controle (controlam a lógica do caso de uso) e classes de entidade (armazenam a informação que o sistema utiliza). Identificar as classes por tipo facilita a análise do sistema porque cada estereótipo direciona algumas características das classes. Por exemplo, classes de fronteira são mais propensas a mudanças e classes de entidade são, na sua maioria, persistentes. Analisar caso de uso

9 Classes de análise: um primeiro passo em direção ao executável
abr-17 Classes de análise: um primeiro passo em direção ao executável Classes de Análise Modelo de Casos de Uso Elementos de Projeto Códigos Fonte As classes de análise constituem a primeira tentativa de modelar como o sistema irá realizar o caso de uso. Elas são ainda bastante abstratas, e, durante a etapa de projeto, poderão ser divididas em outras classes ou até mesmo transformadas em subsistemas. A idéia é que elas aglutinem os conceitos e responsabilidades necessários para a realização dos casos de uso; os detalhes e pormenores das classes são tratados posteriormente, durante as atividades de projeto. Executável Analisar caso de uso

10 QIB - Diagrama de Casos de Uso
abr-17 Usaremos o QIB como exemplo A descoberta de classes de análise será ilustrada com exemplos do Qualiti Internet Banking. Analisar caso de uso

11 Classes de Fronteira (boundary classes)
abr-17 Isolam o sistema de mudanças no ambiente externo Atores devem se comunicar apenas com classes de fronteira Exemplos de classes fronteira GUI Interface com outros sistemas Interface com dispositivos Notação em UML As classes de fronteira fazem a interface do sistema com qualquer entidade externa a ele, como os seus usuários, outras aplicações ou mesmo dispositivos com os quais o sistema precise interagir. Elas isolam o núcleo do sistema do mundo exterior, evitando que mudanças na interface com o mundo exterior afetem outras classes do sistema. As classes de fronteira são identificadas com o estereótipo <<boundary>>. Modelam a interação entre o sistema e seu ambiente <<boundary>> Analisar caso de uso

12 QIB – Efetuar Login abr-17 Regra geral para encontrar classes de fronteira: uma classe por cada par ator/caso de uso Efetuar Login ClienteAtor Para encontrar classes de fronteira, basta olhar o modelo de casos de uso – em geral existe uma classe de fronteira para cada par ator-caso de uso. Analisar caso de uso

13 QIB – Efetuar Pagamento do Qualiti Card
abr-17 Descobrindo classes de fronteira Efetuar Pagamento do Qualiti Card ClienteAtor Operadora de Cartão de Crédito Analisar caso de uso

14 Descrevendo Classes de Fronteira
abr-17 Descrevendo Classes de Fronteira GUI Concentre-se nas informações que serão apresentadas, não em um projeto gráfico Interface com outros sistemas ou dispositivos Concentre-se em quais protocolos devem ser definidos, não como serão implementados Concentre-se nas responsabilidades, não nos detalhes! Analisar caso de uso

15 Classes de Entidade (entity classes)
abr-17 Abstrações e conceitos chaves dos casos de uso Fontes: Conhecimento do negócio Glossário Modelo de negócios Documento de requisitos Especificação do Caso de uso Notação em UML As classes de entidade representam os conceitos principais do sistema, as fontes de informação que o sistema manipula. Elas geralmente são persistentes e sua principal função é armazenar e gerenciar informação. As classes de entidade são identificadas com o estereótipo <<entity>>. Armazenam e controlam informação no sistema <<entity>> Analisar caso de uso

16 QIB – Efetuar Login Observe o fluxo de eventos do Efetuar Login
abr-17 Observe o fluxo de eventos do Efetuar Login Este caso de uso é responsável por autenticar um usuário do sistema. Pré-condição: nenhuma Pós-condição: um usuário válido é logado e sua sessão é registrada no sistema. Fluxo de eventos principal 1. O cliente informa login e senha. 2. O sistema verifica se o login e a senha são válidos (verifica-se se o login e senha pertencem a uma conta). 3. O sistema registra o início de uma sessão de uso. Fluxos secundários - No passo 2, se o login ou a senha forem inválidos, o sistema exibe uma mensagem e volta ao passo 1. Analisar caso de uso

17 Orientações para encontrar Classes de Entidade
abr-17 Usando a descrição do caso de uso, use a abordagem tradicional de filtrar substantivos identifique substantivos no fluxo de eventos remova candidatos redundantes e vagos remova atores que apenas interagem com o sistema mas não fazem parte da modelagem remova atributos (serão usados mais tarde) e operações Para encontrar classes de entidade observe o glossário e o fluxo de eventos do caso de uso. Os substantivos encontrados são candidatos naturais a classes de entidade. Se tiver sido realizada a modelagem do negócio, o modelo do negócio também é uma boa fonte para encontrar essas classes. Durante a realização deste passo é natural tentar identificar hierarquias de classes, porém, devem ser identificadas apenas hierarquias que sejam explícitas no caso de uso, isto é, que sejam inerentes a natureza da aplicação. A decisão de usar ou não herança deve ser postergada sempre que possível para as atividades de projeto. Analisar caso de uso

18 QIB – Efetuar Login Classes de entidade
abr-17 Classes de entidade A classe Conta é uma classe que armazena o login e senha de um cliente. Algumas classes levantadas podem ser eliminadas e novas serão adicionadas Este primeiro levantamento de classes de entidade pode revelar classes que não serão realmente utilizadas no caso de uso e serão eliminadas. As atividades seguintes indicarão mais claramente que classes realmente são utilizadas. Analisar caso de uso

19 QIB – Efetuar Pagamento do Qualiti Card
abr-17 Descrição inicial Este caso de uso é responsável por realizar o pagamento do Qualiti Card com a operadora de cartão de crédito. Cada cliente possui apenas um cartão como titular, estando vinculado a apenas uma operadora. Pré-condição: O cliente deve estar conectado ao sistema (ter efetuado o login). Pós-condição: O valor do pagamento é debitado da conta do cliente, o pagamento é enviado à operadora do cartão de crédito e a transação é registrada no sistema. Analisar caso de uso

20 QIB – Efetuar Pagamento do Qualiti Card
abr-17 Fluxo de eventos principal 1. O cliente informa os dados necessários para efetuar o pagamento do cartão: - O código de barras da fatura que deseja efetuar o pagamento. - O valor que deseja pagar. 2. O sistema recupera a conta bancária do cliente logado. 3. O sistema verifica se o saldo da conta do cliente é suficiente para realizar o pagamento. 4. O sistema debita da conta do cliente. 5. O sistema envia o pagamento à operadora de cartão de crédito. 6. O sistema registra a transação de pagamento e emite um comprovante da mesma para o usuário. A transação registrada contém os dados da conta do cliente, o código de barras da fatura, data, hora e valor do pagamento. Analisar caso de uso

21 QIB – Efetuar Pagamento do Qualiti Card
abr-17 Fluxo de eventos secundários Fluxo Principal O cliente informa os dados necessários para efetuar o pagamento do cartão: - O código de barras da fatura que deseja efetuar o pagamento. - O valor que deseja pagar. O sistema recupera a conta bancária do cliente logado 3. O sistema verifica se o saldo da conta do cliente é suficiente para realizar o pagamento. 4. O sistema debita da conta do cliente. 5. O sistema envia o pagamento à operadora de cartão de crédito. 6. O sistema registra a transação de pagamento e emite um comprovante da mesma para o usuário. A transação registrada contém os dados da conta do cliente, o código de barras da fatura, data, hora e valor do pagamento. Fluxo secundário - No passo 3, se o saldo disponível na conta do cliente for menor que o valor do pagamento, o sistema informa que o saldo é insuficiente e retorna para o passo 1. - No passo 5, se a operadora de cartão de crédito estiver inativa, o sistema exibe uma mensagem e cancela a operação. - Em qualquer momento o usuário pode cancelar a operação. Analisar caso de uso

22 QIB – Efetuar Pagamento do Qualiti Card
abr-17 Classes de entidade Este primeiro levantamento de classes de entidade pode revelar classes que não serão realmente utilizadas no caso de uso e serão eliminadas. As atividades seguintes indicarão mais claramente que classes realmente são utilizadas. Analisar caso de uso

23 Classes de Controle (control classes)
abr-17 Coordenam o comportamento (lógica de controle) do caso de uso Interface entre fronteira e entidade Dependente do caso de uso, independente do ambiente Permitem separação entre o uso da entidade (específico do sistema) do comportamento inerente à entidade Notação em UML Coordena o comportamento do caso de uso. Uma classe controle pode ter referência a vários objetos entidade. As classes de controle coordenam a realização do caso de uso, deixando as classes de entidade mais reusáveis, uma vez que elas ficam isoladas de comportamento específico do sistema. Alguns exemplos de classes de controle são classes fachada (que implementam o padrão de projeto Facade). As classes de controle são identificadas com o estereótipo <<control>>. <<control>> Analisar caso de uso

24 Orientações para encontrar Classes de Controle
abr-17 Usualmente, uma classe de controle por caso de uso Eventualmente mais de uma (comportamento complexo) ou nenhuma (manipulação simples de informações armazenadas) Geralmente, é definida uma classe controle para cada caso de uso. Porém, casos de uso com fluxos simples podem ser realizados sem classes de controle, com as classes de fronteira trocando informação diretamente com as classes de entidade. Já casos de uso com fluxos mais complexos geralmente precisam de uma ou mais classes de controle para coordenar a ação de outros objetos do sistema. Analisar caso de uso

25 QIB – Efetuar Login Encontrando classes de controle Efetuar Login
abr-17 Encontrando classes de controle Efetuar Login ClienteAtor Analisar caso de uso

26 QIB – Efetuar Pagamento do Qualiti Card
abr-17 Encontrando classes de controle Efetuar Pagamento do Qualiti Card ClienteAtor Operadora de Cartão de Crédito Analisar caso de uso

27 QIB – Efetuar Login Classes de análise descobertas até o momento
abr-17 Classes de análise descobertas até o momento Analisar caso de uso

28 QIB – Efetuar Pagamento do Qualiti Card
abr-17 Classes de análise descobertas até o momento Analisar caso de uso

29 Exercício – Qualiti Internet Banking
abr-17 Exercício – Qualiti Internet Banking Dado: Artefatos de requisitos do Qualiti Internet Banking, especialmente o fluxo de eventos do caso de uso RealizarDoc (ver próximos slides) Produzir: Identificação das classes de análise, com seus estereótipos e breve descrição Analisar caso de uso

30 QIB – Realizar Doc Descrição inicial
abr-17 Descrição inicial Este caso de uso é responsável por realizar a transferência de valores entre uma conta deste banco para uma conta de um outro banco. A transferência pode ocorrer entre contas com mesmo CPF ou CPFs distintos. Pré-condição: o cliente deve estar conectado ao sistema (ter efetuado o login). Pós-condição: o valor da transferência foi debitado da conta do cliente, o DOC foi enviado à operadora de DOC e a transação foi registrada. Analisar caso de uso

31 QIB – Realizar Doc Fluxo de eventos principal
abr-17 Fluxo de eventos principal 1. O cliente informa os dados necessários para a realização do DOC: - Banco, agência e conta destino; - CPF do favorecido; - Valor do DOC. 2. O sistema recupera a conta bancária do cliente logado. 3. O sistema verifica se o saldo da conta do cliente é suficiente para a realização do DOC. 4. O sistema envia o DOC à operadora. 5. Debita-se o valor da conta. 6. O QIB registra a ocorrência desta transação (um DOC). 7. Emite-se um comprovante da mesma para o usuário, contendo os dados da conta de origem e destino, assim como a data e valor do DOC. Analisar caso de uso

32 QIB – Realizar Doc Fluxo de eventos secundários Fluxo secundário
abr-17 Fluxo de eventos secundários Fluxo Principal 1. O cliente informa os dados necessários para a realização do DOC: - Banco, agência e conta destino; - CPF do favorecido; - Valor do DOC. 2. O sistema recupera a conta bancária do cliente logado. 3. O sistema verifica se o saldo da conta do cliente é suficiente para a realização do DOC. 4. O sistema envia o DOC à operadora. 5. Debita-se o valor da conta. 6. O QIB registra a ocorrência desta transação (um DOC). 7. Emite-se um comprovante da mesma para o usuário, contendo os dados da conta de origem e destino, assim como a data e valor do DOC. Fluxo secundário No passo 3, se o saldo disponível na conta do usuário for menor que o valor do DOC, o sistema informa que o saldo é insuficiente e retorna ao passo 1 do fluxo principal de eventos. No passo 4, se a operadora de DOC estiver inativa ou se ocorrer algum erro de comunicação que impeça a efetivação da transação, o sistema emite uma mensagem para o cliente e aborta a transação. Em qualquer momento o usuário pode cancelar a operação. Analisar caso de uso

33 Passo 2. Identificar persistência
abr-17 Passo 2. Identificar persistência Identificar que classes de análise deverão ser persistentes Criar, para cada classe persistente, uma classe de cadastro com estereótipo <<entity collection>> As classes persistentes são classes cujos atributos devem ser armazenados pelo sistema de forma não volátil (em um SGBD, por exemplo). Elas devem ser identificadas porque serão tratadas de maneira especial durante a etapa de projeto, para que se possa implementar sua persistência. Atributos complexos de classes persistentes, que não sejam considerados persistentes individualmente, não devem ser marcados como tal. Por exemplo, considere as classes Cliente e Endereço, com Endereço sendo um dos atributos de Cliente. A classe Cliente deve ser identificada como persistente, mas Endereço não, uma vez que os dados relativos ao endereço do cliente só são armazenados juntamente com os dados do respectivo cliente. As classes de cadastro são responsáveis por manter uma coleção de objetos. Por exemplo, um objeto da classe de entidade Conta representa uma única conta de do sistema. Um objeto da classe CadastroContas é responsável por todas as contas do sistema e oferece métodos típicos de acesso a base de dados (inserir, remover, atualizar, consultar, etc). Analisar caso de uso

34 QIB – Efetuar Login abr-17 Classes persistentes Analisar caso de uso

35 QIB – Efetuar Pagamento do Qualiti Card
abr-17 Classes persistentes Analisar caso de uso

36 Exercício – Qualiti Internet Banking
abr-17 Dado Artefatos de requisitos do caso de uso realizar doc Classes de entidade Produzir Identificação das classes que deverão ser persistentes Analisar caso de uso

37 abr-17 Contexto Encontradas as classes de análise e identificadas as classes persistentes, vamos agora descrever o seu comportamento. Lembrando que estas atividades são realizadas para cada caso de uso Analisar caso de uso

38 Passo 3. Distribuir comportamento entre as classes
abr-17 Passo 3. Distribuir comportamento entre as classes Para cada fluxo de eventos alocar responsabilidades do caso de uso às classes de análise modelar interações entre as classes através dos diagramas de interação Neste passo, deve-se modelar os casos de uso (fluxo de eventos) usando os diagramas de interação (seqüência ou colaboração). Analisar caso de uso

39 Distribuindo comportamento entre as classes
abr-17 Diagrama de Seqüência Diagrama de Colaboração Classes de Análise Caso de Uso Classes de Análise (com responsabilidades) Analisar caso de uso

40 Alocando responsabilidades
abr-17 Alocando responsabilidades Use estereótipos de análise como guia Classes de fronteira comportamento que envolve comunicação com um ator Classes de entidade comportamento que envolve informação encapsulada na abstração Classes de controle comportamento específico ao caso de uso (lógica de controle do caso de uso) As responsabilidades de uma classe são os serviços que os objetos da classe devem prover para os outros objetos. Durante a etapa de projeto, cada responsabilidade evolui para um ou mais métodos da classe. Analisar caso de uso

41 Alocando responsabilidades
abr-17 Alocando responsabilidades Identificar que classe tem a informação necessária para realizar a responsabilidade isso pode envolver apenas uma classe, pode ser preciso criar nova classe ou relacionamento entre classes Analisar caso de uso

42 abr-17 Modelando interações Diagramas de interação (colaboração e seqüência) modelam interações do sistema com seus atores A interação é iniciada por um ator e envolve instâncias (objetos) das classes Diagramas de interação capturam a semântica do fluxo de eventos do caso de uso Auxiliam a identificar classes, responsabilidades e relacionamentos Diagramas de interação são usados para descrever a interação entre as classes (troca de mensagens) necessárias para realizar o fluxo de eventos do caso de uso. Eles são úteis na hora de identificar as responsabilidades de cada classe (operações que são implementadas pela classe). As classes de análise encontradas no passo anterior são o ponto de partida para a elaboração dos diagramas de interação. Analisar caso de uso

43 Forma Geral dos Diagramas de Seqüência
abr-17 Objeto cliente Objeto fornecedor :Cliente :Fornecedor Mensagem reflexiva 1: Realize responsabilidade 1.1: Realize outra responsabilidade Mensagem Numeração hierárquica para as mensagens Foco de controle Analisar caso de uso

44 abr-17 QIB – Efetuar Login O método existeConta() procura no cadastro de contas a existência de uma Conta que armazene o login e senha digitados. Este cenário assume que a procura é bem sucedida (cliente válido, com o método retornando true). Apesar de o cadastro ser consultado, o objeto Conta não é recuperado por este caso de uso. Note que as classes Usuario e Mensagem (identificadas inicialmente como classes de análise) não são usadas aqui, pois Usuario é o ClienteAtor e Mensagem não é utilizada neste cenário (fluxo principal). Ao final de um login bem sucedido, a TelaLogin armazena o identificador do cliente (login) enquanto o mesmo estiver usando o sistema (controla esta sessão de uso). Analisar caso de uso

45 Forma Geral de Diagramas de Colaboração
abr-17 Objeto cliente Mensagem reflexiva Link 1.1: Realize outra responsabilidade :Cliente :Fornecedor 1: Realize responsabilidade Mensagem Objeto fornecedor Analisar caso de uso

46 QIB - Efetuar Login abr-17 Analisar caso de uso

47 QIB – Efetuar Pagamento do Qualiti Card
abr-17 QIB – Efetuar Pagamento do Qualiti Card Exercício: diagramas de seqüência e colaboração do caso de uso Efetuar Pagamento do Qualiti Card Analisar caso de uso

48 Quantos diagramas de interação fazer?
abr-17 Quantos forem necessários para modelar o comportamento do caso de uso! Pelo menos o fluxo principal deveria ser modelado Não é necessário modelar todos os fluxos Os fluxos secundários geralmente não acrescentam muito à modelagem do principal O importante é exemplificar o uso de todas as responsabilidades Normalmente, são feitos diagramas de interação apenas para o fluxo de eventos principal do caso de uso. Porém, se o caso de uso apresentar fluxos secundários complexos, deve-se elaborar diagramas de interação para eles também. Analisar caso de uso

49 Que diagramas de interação fazer?
abr-17 Diagramas de colaboração x diagramas de seqüência Colaboração Melhores para visualizar os relacionamentos e responsabilidades de um dado objeto Mais fáceis de desenhar - úteis em sessões de brainstorm Seqüência Melhores para visualizar a seqüência do fluxo no tempo Melhores para visualizar o fluxo completo Mais adequados para cenários complexos Normalmente, são feitos diagramas de interação apenas para o fluxo de eventos principal do caso de uso. Porém, se o caso de uso apresentar fluxos secundários complexos, deve-se elaborar diagramas de interação para eles também. Use o que gostar mais!! Analisar caso de uso

50 Contexto Para cada caso de uso encontramos as classes de análise
abr-17 Contexto Para cada caso de uso encontramos as classes de análise identificamos classes persistentes descrevemos o seu comportamento através de diagramas de interação Agora, para cada classe vamos descrever suas responsabilidades Analisar caso de uso

51 Passo 4. Descrever Responsabilidades
abr-17 Responsabilidades identificadas nos fluxos de eventos são refletidas em diagramas de interação Mensagens nestes diagramas resultam em responsabilidades nas classes receptoras diagrama de interação :Cliente :Fornecedor // Realizar responsabilidade As mensagens enviadas para objetos de uma determinada classe representam requisições de serviços que devem ser realizados pelos objetos. Assim, os diagramas de interação são uma boa fonte para encontrar responsabilidades. Para cada mensagem presente no diagrama, examine a classe do objeto para o qual a mensagem foi enviada. Se na classe ainda não existir uma responsabilidade capaz de atender ao que foi requisitado na mensagem, crie a responsabilidade correspondente. Se não houver diagramas disponíveis, examine o fluxo de eventos do caso de uso para identificar as responsabilidades de cada classe. diagrama de classes Fornecedor // Realizar responsabilidade Analisar caso de uso

52 QIB – Efetuar Login Classes com responsabilidades abr-17
Analisar caso de uso

53 QIB – Efetuar Pagamento do Qualiti Card
abr-17 QIB – Efetuar Pagamento do Qualiti Card Classes com responsabilidades Analisar caso de uso

54 abr-17 Analisando o Modelo Classes com responsabilidades similares são candidatas a serem combinadas Uma classe com responsabilidades disjuntas é candidata a ser dividida Classes sem (ou com apenas uma responsabilidade) e classes que interagem com muitas classes são candidatas a serem reexaminadas Isso poderá resultar em uma alteração dos diagramas de interação Você deve analisar as classes identificadas levando em consideração os itens listados acima. Este processo pode resultar em uma alteração dos diagramas de interação para uma melhor distribuição de comportamento. Deve ser realizado também no final da análise de cada caso de uso. Analisar caso de uso

55 Exercício – Qualiti Internet Banking
abr-17 Exercício – Qualiti Internet Banking Dado: Artefatos de requisitos do QIB, especialmente o fluxo de eventos do caso de uso Realizar DOC As classes de análise identificadas no exercício anterior Produzir: Diagrama de interação para o caso de uso VOPC com responsabilidades * VOPC: View of Participating Classes Analisar caso de uso

56 Passo 5. Descrever atributos e associações
abr-17 Passo 5. Descrever atributos e associações Detalhando mais as classes definir atributos estabelecer associações necessárias entre as classes O propósito deste passo é identificar outras classes que sejam necessárias, definir que informações as classes de análise são responsáveis por manter e identificar os relacionamentos entre essas classes. Analisar caso de uso

57 Encontrando Atributos
abr-17 Encontrando Atributos Possíveis fontes: conhecimento do negócio, requisitos, glossário, modelo do negócio, etc. São propriedades/características das classes identificadas informação cujo valor é o aspecto crucial informação de propriedade exclusiva do objeto informação que pode ser lida ou escrita por operações, mas sem outro comportamento a não ser fornecer um valor Se a informação tem comportamento complexo ou é compartilhada, deve gerar uma classe Analisar caso de uso

58 Encontrando Relacionamentos
abr-17 Encontrando Relacionamentos Links entre objetos em diagramas de colaboração indicam a necessidade de relacionamento entre as respectivas classes Links reflexivos só geram relacionamentos reflexivos quando dois objetos da classe precisam se comunicar (mas não quando um objeto envia mensagens para si próprio) A navegabilidade do relacionamento deve estar de acordo com a direção da mensagem Inclua também o papel (role) e a multiplicidade dos relacionamentos Associações são relacionamentos estruturais entre classes, representando ligações que devem ser mantidas entre os objetos das classes associadas. Os diagramas de interação são, novamente, boas fontes para se identificar associações entre classes, pois a comunicação (troca de mensagens) entre objetos significa que pelo menos um deles deve conhecer o outro, podendo representar a necessidade de uma associação entre os objetos. Identifique as associações existentes entre as classes do caso de uso e documente- as no diagrama de classes elaborado anteriormente. Caso você identifique dependências, agregações e composições, pode documentá-las também. Todavia, se estiver em dúvida sobre a natureza de uma determinada associação (associação simples, agregação ou composição), represente-a como uma associação simples – você poderá substituí-la depois, se desejar. Analisar caso de uso

59 Encontrando Relacionamentos
abr-17 Encontrando Relacionamentos 1: Realizar responsabilidade Diagrama de Colaboração :Cliente :Fornecedor Link Cliente Fornecedor Cliente Fornecedor Diagrama de classe Analise os diagramas de interação para encontrar os relacionamentos. Se uma classe se comunica com outra, então esta classe provavelmente recebe um objeto desta outra como parâmetro ou possui uma associação. Neste passo, mantenha o foco nas associações necessárias para realizar o caso de uso, não crie associação que você acha que pode ser necessária. Não esqueça de colocar nomes dos papéis (omita se for muito óbvio) e indicar multiplicidade. Realizar responsabilidade Associação Fonte: Rational Um relacionamento para cada link Analisar caso de uso

60 abr-17 QIB – Efetuar Login Diagrama de classes com relacionamentos e atributos Analisar caso de uso

61 QIB – Efetuar Pagamento do Qualiti Card
abr-17 QIB – Efetuar Pagamento do Qualiti Card Diagrama de classes com relacionamentos e atributos Conta numero saldo getSaldo() debitar() <<entity>> Comprovante pagamentoCartao PagamentoCartao numeroFatura data hora valor contaBancaria TelaPagamentoQualitiCard efetuarPagamentoQualitiCard() <<boundary>> CadastroContas consultarConta() atualizar() <<entity collection>> 0..n CadastroPagamentos Cartao inserir() ComunicacaoOperadoraCartao enviar() ControladorPagamentoQualitiCard verificarSaldo() <<control>> 1 Analisar caso de uso

62 Exercício – Qualiti Internet Banking
abr-17 Exercício – Qualiti Internet Banking Dado: Classes de análise do caso de uso Realizar DOC com estereótipos e responsabilidades Diagramas de interação do caso de uso VOPCs desenvolvidos no exercício anterior Produzir: VOPCs com relacionamentos e atributos. Incluir multiplicidade e navegabilidade dos relacionamentos Analisar caso de uso

63 Passo 6. Revisar Resultados
abr-17 Passo 6. Revisar Resultados Verificar se as classes de análise satisfazem os requisitos funcionais Unificar as classes de análise Verificar se todo o modelo está consistente entre si e com os requisitos Ao terminar a análise, é importante verificar se todo o comportamento do caso de uso pode realmente ser realizado com as classes e responsabilidades que foram encontradas. Além disso, as classes envolvidas na realização do caso de uso devem estar definidas de forma consistente e coesa. Em particular, deve-se considerar os pontos listados a seguir. Todos os fluxos de eventos, inclusive os fluxos secundários do caso de uso, podem ser realizados com as classes que foram encontradas? As classes representam abstrações simples e bem definidas? Observe as responsabilidades de cada classe – uma classe com muitas responsabilidades talvez deva ser dividida em classes menores e mais coesas. Existe alguma classe sem responsabilidades ou com apenas uma responsabilidade? A falta de responsabilidades pode ser um indício de que a classe é supérflua. Existem classes diferentes que apresentam comportamento semelhante ou que representam o mesmo conceito no sistema? Em caso positivo, elas devem ser unificadas em uma única classe. Analisar caso de uso

64 Revisando: Passos realizados nesta atividade
abr-17 Para cada caso de uso: 1. Encontrar classes de análise 2. Identificar persistência Para cada classe: 3. Distribuir comportamento entre as classes 4. Descrever responsabilidades 5. Descrever atributos e associações 6. Revisar os Resultados Analisar caso de uso


Carregar ppt "Abr-17 Analisar Caso de Uso Analisar caso de uso."

Apresentações semelhantes


Anúncios Google