UML - Requisitos 1 PESC/COPPE/UFRJ - Toacy C. de Oliveira.

Apresentação em tema: "UML - Requisitos 1 PESC/COPPE/UFRJ - Toacy C. de Oliveira."— Transcrição da apresentação:

1 UML - Requisitos 1 PESC/COPPE/UFRJ - Toacy C. de Oliveira

2 Requisitos  Qual a principal medida de sucesso de um projeto de software? “The primary measure of success of a software system is the degree to which it meets the purpose for which it was intended.” Bashar Nuseibeh, Steve Easterbrook 2

3 PESC/COPPE/UFRJ - Toacy C. de Oliveira Conceitos  Requisitos são (IEEE): 1. Uma capacidade que um usuário necessita para resolver um problema ou atingir um objetivo; 2. Uma capacidade que deve ser atendida ou possuída por um sistema ou componente de um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto; 3. O conjunto de todos os requisitos que formam a base para o desenvolvimento subseqüente de um software ou componentes de um software; 4. Nome curto utilizado para especificação de requisitos de software. 3

4 PESC/COPPE/UFRJ - Toacy C. de Oliveira Requisitos  Requisitos expressam comportamentos e propriedades que o sistema deve apresentar. Devem se compreendidos pela equipe de desenvolvimento e validados pela parte interessada e pela comunidade de usuários; Deve ser capaz de ser verificado pela equipe de teste através de casos de teste.  Categorias: Requisitos Funcionais: descrevem uma ação que o sistema deve executar, normalmente em resposta a uma entrada de dados externa. Requisitos Não-Funcionais: envolvem restrições usabilidade, desempenho, robustez/confiabilidade, segurança, hardware e implantação do sistema. 4

5 PESC/COPPE/UFRJ - Toacy C. de Oliveira Requisitos  Características de um bom documento de especificação de requisitos (SRS - Software Requirements Specification): Correto Não-ambíguo Completo Consistente Priorizado Verificável Modificável Rastreável Fonte: IEEE Std. 830-1998 5

6 PESC/COPPE/UFRJ - Toacy C. de Oliveira Modelo de Casos de Uso Diagrama de Casos de Uso 6

7 Diagramas de Caso de Uso  Permitem especificar requisitos com UML  Requisitos são representados como Casos de Uso que em última análise, são funcionalidades que o sistema deve possuir, a partir da ótica de seus usuários (e elementos que interagem com o sistema). PESC/COPPE/UFRJ - Toacy C. de Oliveira 7

8 ATOR  Um ator representa uma entidade (um humano, um dispositivo de hardware ou mesmo outro sistema) que interage com um sistema. Por interação entende-se a troca de mensagens entre um ator e o sistema. Atores estão fora do sistema, isto é, não são entidades componentes do sistema. Atores podem ser conectados aos casos de uso somente por associações. Uma associação entre um caso de uso e um ator significa um canal de comunicação entre ambos, onde cada um pode enviar ou receber mensagens, estabelecendo uma interação. 8 PESC/COPPE/UFRJ - Toacy C. de Oliveira

9 Atores  O seguinte questionário pode ser usado para identificar os atores do sistema: Quem usará as funções principais do sistema ? Quem precisará do sistema para executar suas tarefas diárias ? Quem manterá e administrará o sistema ? Quais os equipamentos que o sistema controlará ? Com quais outros sistemas o sistema precisará interagir ? Quem tem interesse nos resultados que o sistema produz ? 9 PESC/COPPE/UFRJ - Toacy C. de Oliveira

10 ATOR  Representação: Aluno Ícone Nome do Ator 10 PESC/COPPE/UFRJ - Toacy C. de Oliveira

11 Generalização de atores Generalização Relacionamento entre um ator “pai” e um ator “filho”, indicando que o primeiro representa um conceito mais geral que o segundo. Aluno Pós-GraduaçãoGraduação 11 PESC/COPPE/UFRJ - Toacy C. de Oliveira

12 Ex.: Atores de um Sistema de Vendas 12 PESC/COPPE/UFRJ - Toacy C. de Oliveira

13 CASO DE USO  Descreve uma seqüência de ações - incluindo suas variantes - que o sistema deve executar com o objetivo de produzir como resultado algo de valor para o atendimento das necessidades de um ator. Um caso de uso:  Deve ser iniciado por um ator, embora haja exceções;  Descreve uma funcionalidade completa do sistema conforme percebida por um ator;  Gera como resultado algo de valor tangível para um ator (usuário);  Expressam os requisitos do sistema. 13

14 CASO DE USO  Nome: Um caso de uso deve ter como nome uma frase representando uma ação (comportamento) significativa para o vocabulário do sistema em processo de modelagem.  Representação: Ícone Nome do UseCase Sacar dinheiro 14 PESC/COPPE/UFRJ - Toacy C. de Oliveira

15 Especificando Casos de Uso  Nomeando casos de uso: Enfatize que um caso de uso é um processo: nomeio-o iniciando por um verbo.  Descrição: A especificação de um caso de uso pode ser feita através da descrição de seqüências de eventos em formato de texto. Descreve como o ator e o caso de uso interagem. Concentra-se no comportamento externo do sistema, ignorando os procedimentos a serem executadas internamente pelo mesmo através de sua implementação. 15 PESC/COPPE/UFRJ - Toacy C. de Oliveira

16 Especificando Casos de Uso  Deve ser considerado: como e quando o caso de uso inicia e termina; quando o caso de uso interage com um ator envolvido; a seqüência padrão; as seqüências alternativas ou de exceção. 16

17 Especificando Casos de Uso  A especificação inclui: Identificação do Caso de Uso Nome do Caso de Uso Ator: ator que interage com o caso de uso Pré-condições: o estado do sistema para que o caso de uso possa iniciar Pós-condições: o estado do sistema após a execução do caso de uso Seqüência de Eventos Requisitos Não-Funcionais 17 PESC/COPPE/UFRJ - Toacy C. de Oliveira

18 Especificando Casos de Uso  Seqüência de Eventos Seqüência Típica de Eventos Ação do Ator Resposta do Sistema Ações numeradas de ator Descrição numerada das respostas do sistema Seqüências Alternativas Alternativas que podem surgir por número de linha: descrição de exceções. 18 PESC/COPPE/UFRJ - Toacy C. de Oliveira

19 Especificando Casos de Uso  Exemplo: Sacar dinheiro no caixa eletrônico 19 PESC/COPPE/UFRJ - Toacy C. de Oliveira

20 Especificando Casos de Uso Ação do ator 1. Este caso de uso começa quando o Cliente realiza a leitura do cartão do banco no caixa eletrônico 2. O Cliente informa a sua senha 4. O Cliente informa o valor do saque Resposta do sistema 3. O sistema valida a conta corrente e senha do Cliente, autorizando a operação 5. O sistema autoriza o saque e lança o débito na conta corrente do Cliente 6. O sistema libera o dinheiro Identificação: UC1 Caso de uso: Sacar dinheiro no caixa eletrônico Ator: Cliente Pré-Condições: o Cliente possui cartão do banco e senha cadastrada. Pós-Condições: lançada a transação na conta do Cliente, atualizado o saldo da conta corrente e liberado o dinheiro. Seqüência Típica de Eventos (Fluxo Básico): 20 PESC/COPPE/UFRJ - Toacy C. de Oliveira

21 Especificando Casos de Uso  Forma Alternativa de Apresentação Identificação: UC1 Caso de uso: Sacar dinheiro no caixa eletrônico Ator: Cliente Pré-Condições: o Cliente possui cartão do banco e senha cadastrada. Pós-Condições: lançada a transação na conta do Cliente, atualizado o saldo da conta corrente e liberado o dinheiro. Seqüência Típica de Eventos (Fluxo Básico): 1. Este caso de uso começa quando o Cliente realiza a leitura do cartão do banco no caixa eletrônico 2. O Cliente informa a sua senha 3. O sistema valida a conta corrente e senha do Cliente, autorizando a operação. 4. O Cliente informa o valor do saque 5. O sistema autoriza o saque e lança o débito na conta corrente do Cliente 6. O sistema libera o dinheiro 21

22 PESC/COPPE/UFRJ - Toacy C. de Oliveira Especificando Casos de Uso Seqüências Alternativas (Fluxos Alternativos): 3a. Cliente Inválido: 1. O sistema não reconhece a conta corrente e senha do Cliente como válida 2. A operação é cancelada 5a: Fundos Insuficientes: 1. O sistema não autoriza o valor solicitado para saque pelo Cliente 2. A operação é cancelada Requisitos Não-Funcionais Resposta do sistema deve ocorrer em no máximo 30 seg em 90 % dos casos 22

23 DESCOBRINDO ATORES E CASOS DE USO  Lista Ator-Objetivos AtorObjetivo Cliente Retirar dinheiro de sua conta corrente Consultar conta corrente.... Caixa Processar depósito em uma conta corrente Processar pagamento de contas Processar retirada de talões de cheque Retirar dinheiro para um cliente de sua conta corrente........ 23 PESC/COPPE/UFRJ - Toacy C. de Oliveira

24 DESCOBRINDO ATORES E CASOS DE USO  Casos de Uso: deve ser definido um caso de uso para cada objetivo de usuário de um ator. O nome do caso de uso é similar ao objetivo de usuário.  Exemplo: Ator: Cliente Objetivo: Retirar dinheiro de sua conta corrente Caso de Uso: Sacar dinheiro no caixa eletrônico Exceção: casos de uso para tratamento de informações persistentes do sistema – CRUD (create, retrieve, update, delete).  Estes casos de uso podem ser comumente identificados por Atualizar, como por exemplo o caso de uso Atualizar Conta Corrente. 24 PESC/COPPE/UFRJ - Toacy C. de Oliveira

25 Especificando Casos de Uso  Ramificações Estrutura de Notação:  Caracteriza situações em que existem duas ou mais opções de continuidade no fluxo de uma determinada seção.  Dentro da Seqüência Típica de Eventos de uma seção indique desvios para subseções;  Escreva uma subseção para cada desvio usando novamente uma Seqüência Típica de Eventos. 25

26 Especificando Casos de Uso  Generalização Expressa com Ramificações Receber Pagamento Caixa Receber pagamento em cheque Receber pagamento em dinheiro 26 PESC/COPPE/UFRJ - Toacy C. de Oliveira

27 Especificando Casos de Uso Identificação: UC5 Caso de uso: Receber Pagamento Ator: Caixa Pré-Condições: o Caixa é identificado e autenticado Pós-Condições: o pagamento recebido é registrado no sistema associado ao Caixa Seqüência Típica de Eventos: Seção Principal 1. Este caso de uso começa quando o Caixa registra o documento de cobrança bancária a ser pago 2. O sistema valida a aceitação do documento de cobrança a ser pago 3. O Caixa informa a opção desejada: 3.1. Se for pagamento em dinheiro, ver subseção Receber pagamento em dinheiro 3.2. Se for pagamento em cheque, ver subseção Receber pagamento em cheque 4. O sistema registra o pagamento 5. O sistema imprime o comprovante. Subseção: Receber pagamento em cheque 1. O Caixa recebe o cheque e o registra no sistema 2. O sistema valida os dados do cheque Subseção: Receber pagamento em dinheiro 1. O Caixa registra o valor em dinheiro recebido 2. O sistema informa o troco a ser repassado ao pagante 27 PESC/COPPE/UFRJ - Toacy C. de Oliveira

28 DEPENDÊNCIAS ENTRE CASOS DE USO -INCLUSÃO  Dependência - Inclusão Uma relação de inclusão de um caso de uso A com um caso de uso B indica que uma instância do caso de uso A deverá incluir o comportamento especificado para o caso de uso B. Validar conta Liberar talão de cheque > Estereótipo caso de uso A caso de uso B Cliente Caixa Sacar dinheiro no caixa eletrônico 28 PESC/COPPE/UFRJ - Toacy C. de Oliveira

29 Identificação: UC1 Caso de uso: Sacar dinheiro no caixa eletrônico Ator: Cliente Pré-Condições: o Cliente possui cartão do banco e senha cadastrada. Pós-Condições: lançada a transação na conta do Cliente, atualizado o saldo da conta corrente e liberado o dinheiro. Seqüência Típica de Eventos: Ação do ator 1. Este caso de uso começa quando o Cliente realiza a leitura do cartão do banco no caixa eletrônico 2. O Cliente informa a sua senha. Resposta do sistema 3. Include Validar Conta. 5. O sistema autoriza o saque e lança o débito na conta corrente do Cliente 6. O sistema libera o dinheiro Seqüência Alternativa: 5a: Fundos Insuficientes: 1. O sistema não autoriza o valor solicitado para saque pelo Cliente. 2. A operação é cancelada. DEPENDÊNCIAS ENTRE CASOS DE USO -INCLUSÃO 29 PESC/COPPE/UFRJ - Toacy C. de Oliveira

30 DEPENDÊNCIAS ENTRE CASOS DE USO INCLUSÃO Identificação: UC2 Caso de Uso: Validar conta Ator: Pré-Condições: Pós-Condições: Seqüência Típica de Eventos: Resposta do sistema 1. O sistema valida a conta corrente e senha do Cliente, autorizando a operação. Ação do ator Seqüência Alternativa: 1a. Cliente Inválido: 1. O sistema não reconhece a conta corrente e senha do Cliente como válida. 2. A operação é cancelada. 30

31 PESC/COPPE/UFRJ - Toacy C. de Oliveira DEPENDÊNCIAS ENTRE CASOS DE USO INCLUSÃO  Dica: A criação de um caso de uso para utilização em relações de dependência por inclusão somente tem sentido se:  houver a possibilidade do caso de uso ser invocado diretamente por um ator, ou  existir a necessidade de associá-lo a mais de um caso de uso. Se nenhuma das situações acima for verdadeira, incorpore a seqüência de eventos necessária na descrição do caso de uso dependente. 31

32 DEPENDÊNCIAS ENTRE CASOS DE USO EXTENSÃO  Dependência – Extensão Uma relação de extensão de um caso de uso A com um caso de uso B indica que uma instância do caso de uso A poderá incluir - sujeito a satisfação da condição expressa em um fator de extensão - o comportamento especificado para o caso de uso B. Autorizar saque Sacar dinheiro pelo caixa > (quantia elevada) Estereótipo caso de uso B caso de uso A Caixa Gerente Cliente 32 PESC/COPPE/UFRJ - Toacy C. de Oliveira

33 Identificação: UC1 Caso de uso: Sacar dinheiro pelo caixa Ator: Caixa (iniciador), Cliente Pré-Condições: o Cliente possui cartão do banco e senha cadastrada. Pós-Condições: lançada a transação na conta do Cliente, atualizado o saldo da conta corrente e liberado o dinheiro. Seqüência Típica de Eventos: Ação do ator 1. Este caso de uso começa quando o Caixa realiza a leitura do cartão do banco do Cliente 2. O Cliente informa a sua senha. 4. O Caixa informa o valor do saque; Extend (quantia elevada) Autorizar Saque 6. O Caixa libera o dinheiro para o Cliente Resposta do sistema 3. Include Validar Conta. 5. O sistema autoriza o saque e lança o débito na conta corrente do Cliente Seqüência Alternativa: 5a: Fundos Insuficientes: 1. O sistema não autoriza o valor solicitado para saque pelo Cliente. 2. A operação é cancelada. DEPENDÊNCIAS ENTRE CASOS DE USO - EXTENSÃO 33 PESC/COPPE/UFRJ - Toacy C. de Oliveira

34 DEPENDÊNCIAS ENTRE CASOS DE USO - EXTENSÃO Identificação: UC3 Caso de Uso: Autorizar saque Ator: Gerente Pré-Condições: Pós-Condições: Seqüência Típica de Eventos: Ação do ator 1. O Gerente consulta informações da conta corrente de um cliente para deliberar sobre a liberação de saque em valor elevado. 3. O Gerente autoriza o saque no valor solicitado. Resposta do sistema 2. Apresentar informações completas sobre o cliente e suas movimentações bancárias. Seqüência Alternativa: 3a: Saque não autorizado 1. O Gerente não autoriza o saque no valor solicitado. 2. A operação é cancelada. 34 PESC/COPPE/UFRJ - Toacy C. de Oliveira

35 DIAGRAMA DE CASOS DE USO  Um Diagrama de Casos de Uso apresenta um conjunto de casos de uso, atores e suas relações. Captura as funcionalidades de um sistema de acordo com a visão de seus usuários. Deve ser desenvolvido pelo analista em conjunto com especialistas no domínio da aplicação.  Um Diagrama de Casos de Uso é composto por: Casos de Uso, Atores, Relações de associação, dependência e generalização. 35 PESC/COPPE/UFRJ - Toacy C. de Oliveira

36 DIAGRAMA DE CASOS DE USO Sistema de Atendimento Bancário 36 PESC/COPPE/UFRJ - Toacy C. de Oliveira

37 DIAGRAMA DE CASOS DE USO  Os Diagramas de Casos de Uso são utilizados para modelar: O contexto de um sistema, identificando os atores e seus papéis na interação com o sistema; Os requisitos de um sistema, especificando o que o sistema deve fazer (do ponto de vista de seus usuários), sem no entanto se preocupar em como é implementado.  Os Diagramas de Casos de Uso servem para: Verificar e validar a arquitetura do sistema; Identificar e gerar casos de teste. 37 PESC/COPPE/UFRJ - Toacy C. de Oliveira

38 DIAGRAMA DE CASOS DE USO  Considerações: Cada diagrama de casos de uso representa graficamente uma visão parcial do sistema. O conjunto de diagramas de casos de uso formam a visão de casos de uso completa do sistema. Diagramas de Casos de Uso representam uma visão externa ao sistema, servindo de base para a identificação e especificação do conjunto de classes - e suas interações - necessárias para atingir os objetivos e propósitos do sistema. 38 PESC/COPPE/UFRJ - Toacy C. de Oliveira

39 Leitura Adicional  Escrevendo Casos de Uso Eficazes Alistair Cockburn Bookman 39 PESC/COPPE/UFRJ - Toacy C. de Oliveira

40 Diagrama de Atividades 40 PESC/COPPE/UFRJ - Toacy C. de Oliveira

41 DIAGRAMA DE ATIVIDADES Um Diagrama de Atividades é uma variação de uma máquina de estados, na qual os estados são as Atividades que representam a execução de operações e as Transições são disparadas pela conclusão destas operações. Um Diagrama de Atividades normalmente contém:  estados de atividades e/ou estados de ações,  transições,  objetos. Tipicamente, Diagramas de Atividades são utilizados para a modelagem dos aspectos dinâmicos de um sistema. Um Diagrama de Atividades associado a um Caso de Uso descreve as atividades realizadas pelo Ator e pelo Sistema, tendo como referencial o ponto de vista dos atores que colaboram com o sistema. 41 PESC/COPPE/UFRJ - Toacy C. de Oliveira

42 Receber o Pedido Estado de Ações e Estado de Atividades  Atividade refere-se a execução de um processamento não atômico dentro de uma máquina de estados, envolvendo uma ou mais ações.  Representação gráfica: 42 PESC/COPPE/UFRJ - Toacy C. de Oliveira

43 Estado de Ações e Estado de Atividades  Uma ação consiste em um processamento atômico que resulta em uma mudança de estado no sistema ou no retorno de um valor.  Ações abrangem: chamadas de operações, envio de sinais, criação ou destruição de um objeto, ou; algum processamento computacional puro, tal como uma avaliação de uma expressão. 43 PESC/COPPE/UFRJ - Toacy C. de Oliveira

44 Receber o Pedido Incluir Produtos no Pedido Transição  Quando uma ação ou atividade de um estado é completada, o fluxo de controle passa imediatamente para o próximo estado de ação ou atividade. Estado de Início (pseudo estado) Estado de Ação Transição Estado de Término 44 PESC/COPPE/UFRJ - Toacy C. de Oliveira

45 Condição de Guarda  Condiciona a ocorrência de uma transição para a execução de uma atividade. Representação gráfica: Separar Produtos Adquirir Produtos [produtos não disponíveis recebidos] Condição de guarda 45 PESC/COPPE/UFRJ - Toacy C. de Oliveira

46 Incluir Produtos no Pedido Separar ProdutosAdquirir Produto [algum produto não está disponível] [todos os produtos estão disponíveis] Decisão (Desvio)  Representada através de uma ramificação no Diagrama de Atividades. reúne condições que resultam em uma ramificação no Diagrama de Atividades 46 PESC/COPPE/UFRJ - Toacy C. de Oliveira

47 [condição 1] [senão] [condição 2] Desvio: Intercalação: Desvio e intercalação 47 PESC/COPPE/UFRJ - Toacy C. de Oliveira

48 Barra de Sincronização  Permite a representação de fluxos de controle concorrentes. Bifurcação (Fork)  representa a divisão de um fluxo de controle em dois ou mais fluxos de controle concorrentes e independentes  Abaixo da bifurcação, as atividades associadas com cada um dos caminhos continuam em paralelo União (Join)  representa a sincronização de dois ou mais fluxos concorrentes.  Na união, os fluxos concorrentes devem sincronizar-se, isto é, o fluxo de controle abaixo da união somente inicia após todos os fluxos de controle acima da união terem encerrado. 48 PESC/COPPE/UFRJ - Toacy C. de Oliveira

49 Bifurcação e União Embalar ProdutosSeparar ProdutosEmitir Nota Fiscal Despachar Produtos Bifurcação União 49 PESC/COPPE/UFRJ - Toacy C. de Oliveira

50 Swinlanes (Raias)  Uma swinlane especifica o responsável pela execução de um conjunto de atividades. O responsável pode ser um ator ou sistema. Quando o Diagrama de Atividades é utilizado para a modelagem de workflows, as swinlanes representam as unidades organizacionais, sendo nelas apropriada as suas respectivas atividades.  Worklows são utilizados para visualizar, especificar, construir e documentar processos do negócio atinentes ao sistema em desenvolvimento. 50 PESC/COPPE/UFRJ - Toacy C. de Oliveira

51 Exemplo de Diagrama de Atividades para um Caso de Uso Sacar dinheiro no caixa eletrônico Cliente 51

52 PESC/COPPE/UFRJ - Toacy C. de Oliveira Variação do Diagrama de Atividades para um Caso de Uso Cliente Sacar dinheiro no caixa eletrônico Validar conta 52

53 Receber o Pedido Incluir Produtos no Pedido * Emitir Nota Fiscal Separar Produtos [ todos os produtos estão disponíveis ] Embalar Produtos Despachar Produtos Adquirir Produtos [ alguns produtos não estão disponíveis ] [ produtos não disponíveis recebidos ] ComprasExpediçãoVendas Exemplo de Diagrama de Atividades para workflow 53 PESC/COPPE/UFRJ - Toacy C. de Oliveira

54 Fluxo de Objetos  Objetos podem ser envolvidos no fluxo de controle associado com um diagrama de atividades.  Um objeto pode ser conectado através de uma relação de dependência com a atividade ou transição que o cria, destrói ou modifica.  O uso de relações de dependência e objetos é chamado fluxo de objetos porque representa a participação de um objeto em um fluxo de controle. objeto : Classe [ estado ] 54 PESC/COPPE/UFRJ - Toacy C. de Oliveira

55 55 PESC/COPPE/UFRJ - Toacy C. de Oliveira

56 Diagrama de Classes 56 PESC/COPPE/UFRJ - Toacy C. de Oliveira

57 Introdução  Um modelo estrutural descreve uma visão estática de um sistema mostrando: Classes Relacionamentos entre classes Atributos de Classes Operações definidas nas classes & os objetos pertencentes ao sistema; os relacionamentos entre esses objetos; 57 PESC/COPPE/UFRJ - Toacy C. de Oliveira

58 Introdução  Existem dois tipos de diagramas para o modelo de objetos: Diagrama de Classes: é um grafo que descreve as classes seus atributos,operações e relacionamentos presentes no sistema. Diagrama de Objetos: descreve como os objetos de um determinado grupo se relacionam entre si.  Serve para documentar casos de teste (cenários) e exemplos para discussão.  Ambos os diagramas oferecem uma notação gráfica formal para a modelagem de objetos e seus relacionamentos. 58 PESC/COPPE/UFRJ - Toacy C. de Oliveira

59 Diagrama de Classes  Diagramas de Classes são utilizados para modelagem estática. A modelagem estática deve dar suporte as necessidades funcionais do sistema, isto é, os serviços que o sistema deve providenciar aos seus usuário finais.  Os Diagramas de Classes são utilizados para modelar: o vocabulário do sistema: especificação das abstrações que estão contidos dentro do domínio do sistema, identificando suas responsabilidades. colaboração: colaboração envolve trabalho conjunto entre objetos do sistema visando um comportamento cooperativo. Esta cooperação traduz-se no diagrama de classes através das relações existente entre as classes identificadas. esquema lógico do banco de dados do sistema. 59 PESC/COPPE/UFRJ - Toacy C. de Oliveira

60 Representação  Graficamente, as classes são representadas por retângulos incluindo seu nome, atributos e métodos. Nome_da_classe atributo1 atributo2... metodo1 metodo2 metodo3... F Devem receber nomes de acordo com o vocabulário do domínio do problema. F É comum adotar-se padrões para nomeá-las. F Por exemplo, todos os nomes de classes são substantivos singulares com a primeira letra maiúscula. 60 PESC/COPPE/UFRJ - Toacy C. de Oliveira

61 Nomes de Classes  O nome de uma classe distingue uma classe de outra classe. nome simples: nome sozinho nome com caminho: o nome da classe é precedido pelo nome do pacote em que a classe existe. Funcionario SistemaRH::Funcionario 61 PESC/COPPE/UFRJ - Toacy C. de Oliveira

62 Atributos de Classes Atributos de Classes  Cada objeto de uma classe possui um estado, representado pelos valores associados a cada um dos atributos definidos para a classe  Sintaxe para Atributos: [visibilidade] nome [multiplicidade] [:tipo] [= valor inicial] [{propriedades}]  atributos de classe são sublinhados  Exemplos: CPF : Inteiro {frozen} Nome: String Endereço [0..2] : String quantCorrentistas: Inteiro 62 PESC/COPPE/UFRJ - Toacy C. de Oliveira

63 Atributos de Classes Atributos de Classes  Visibilidade  público (+) : o que pode ser visto pelas operações de outras classes  protegido (#) : o que pode ser visto apenas pelas operações da própria classe e por suas classes herdeiras  privado (-) : o que pode ser visto apenas pelas operações da própria classe  Propriedades  changeable: não há restrições quanto a modificação do valor do atributo  frozen: o valor do atributo não pode ser alterado  addOnly: válida para atributos com multiplicidade superior a um, onde o valor atribuído a cada ocorrência de um atributo não pode ser alterado ou removido. 63 PESC/COPPE/UFRJ - Toacy C. de Oliveira

64 Atributos de Classes Atributos de Classes  Atributos opcionais podem indicar a necessidade de especializar-se a classe. Cliente nome telefone endereço cgc inscEstad cpf cartIdent Caracterizam a existência de Pessoa Jurídica e Pessoa Física 64 PESC/COPPE/UFRJ - Toacy C. de Oliveira

65 Sensor de Temperatura reset() setAlarm() avaliarTemperatura() - Monitorar temperatura - Disparar alarme quando a temperatura atingir valores inadequados Responsabilidades de Classes Responsabilidades de Classes  Responsabilidade de uma classe diz respeito às obrigações de sua instâncias dentro do contexto do sistema. Ao refinar o modelo, as responsabilidades de uma classe são traduzidas em um conjunto de atributos e operações que melhor atendam as suas obrigações. 65 PESC/COPPE/UFRJ - Toacy C. de Oliveira

66 Métodos  Métodos Representam o comportamento (responsabilidades) que a classe fornece. Visibilidade:  + público: visível em qualquer classe de qualquer pacote.  # protegido: vísivel somente para as sua subclasses.  - privado: visível somente dentro da classe. 66 PESC/COPPE/UFRJ - Toacy C. de Oliveira

67 Relacionamentos 67 PESC/COPPE/UFRJ - Toacy C. de Oliveira

68 Relações entre Classes  As relações determinam conexões entre os objetos.  Fornecem um caminho para a comunicação entre os objetos.  Principais tipos de relações: Associação Generalização Dependência 68 PESC/COPPE/UFRJ - Toacy C. de Oliveira

69 Associações  Uma associação é uma relação estrutural que descreve um conjunto de ligações, onde uma ligação é uma conexão entre classes / objetos.  Uma ligação permite a troca de mensagens entre objetos. ClienteConta abre 0..*1 public class Cliente { private Conta abre[ ]; } public class Conta { private Cliente abre; } 69

70 Associações  Uma associação pode ter um nome. Torna mais clara a natureza do relacionamento.  Se necessário podemos incluir um triângulo para indicar a direção de leitura do nome. Evita ambigüidades ContaCliente abre associação direção do nome nome 70 PESC/COPPE/UFRJ - Toacy C. de Oliveira

71 Multiplicidade em Associações  Multiplicidade especifica quantas instâncias de uma classe se relacionam a uma única instância da outra classe. Número: estabelece o número exato de objetos relacionados  Ex. 2 Intervalo de Valores: define a multiplicidade mínima e máxima  Ex.: 1..5 Multiplicidade Máxima Ilimitada :  Ex.: 0..* 71

72 PESC/COPPE/UFRJ - Toacy C. de Oliveira Multiplicidade em Associações  Uma pessoal trabalha em várias empresas  Uma empresa tem pelo menos 1 empregado. PessoaEmpresa 1..* associação multiplicidade * trabalha para 72

73 PESC/COPPE/UFRJ - Toacy C. de Oliveira Associações  Exemplos de Multiplicidade: (1..1): cliente tem sempre 1 (e somente 1) conta (0..1): cliente pode ter 1 (e no máximo 1) conta (1..*): cliente tem sempre 1 conta, podendo ter mais (0..*): cliente pode ter 1 conta, podendo ter mais 1 Cliente 0..1 1..* * Cliente Conta 73

74 PESC/COPPE/UFRJ - Toacy C. de Oliveira Papéis em Associações  Quando uma classe participa de uma associação, ela desempenha um papel nesse relacionamento. Evidencia a finalidade ou função de cada classe da associação. Uma mesma classe pode desempenhar vários papéis em diversas associações. PessoaEmpresa empregado nome do papel associação empregador 74

75 PESC/COPPE/UFRJ - Toacy C. de Oliveira Navegabilidade em Associações  Em geral, associações são bidirecionais. Pode ser desejável limitar sua ”navegação” em uma única direção. A navegabilidade é indicada por uma seta em uma das extremidades da associação.  Ex: Um cliente sabe quais são os seus endereços, mas o endereço não sabe qual é o seu cliente. EndereçoCliente reside 1 * navegabilidade 75

76 PESC/COPPE/UFRJ - Toacy C. de Oliveira Associações tipo OU  Indica que somente uma das associações é válida em um ponto particular no tempo. Contrato de seguro PessoaEmpresa {or} 0..* 1..* 76

77 Associação - Resumo  Um Estudante pode ser um aluno de uma Disciplina e um jogador da Equipe de Futebol  Cada Disciplina deve ser cursada por no mínimo 1 aluno  Um aluno pode cursar de 0 até 8 disciplinas 77 PESC/COPPE/UFRJ - Toacy C. de Oliveira

78 Agregação  Uma agregação é um tipo especial de associação utilizada para indicar um relacionamento ”todo- parte”.  Uma agregação é representada por uma linha sólida com um losango vazado na extremidade referente ao todo. ItemPedido 1 1..* agregação todo parte  O significado da agregação é inteiramente conceitual, o losango simplesmente diferencia o todo da parte.  Um objeto “parte” pode fazer parte de vários objetos “todo”. 78 PESC/COPPE/UFRJ - Toacy C. de Oliveira

79 Composição  Em uma composição, os objetos “parte” só podem pertencer a um único objeto “todo” e têm seu ciclo de vida coincidente com o dele. É uma variante semanticamente mais ”forte” da agregação É representada por uma linha contínua com um losango cheio na extremidade referente ao todo. TecladoNotebook FrameWindow todo parte 1 1 1 0..* 1..*0..* errado –Quando o todo “morre” todas as suas partes também “morrem” –Apenas o todo pode criar e destruir as partes 79 PESC/COPPE/UFRJ - Toacy C. de Oliveira

80 Composição Composição Janela ScrollTítuloCorpo 1 0..121 Empresa DepartamentoEscritório 1 1..* 0..1 * 80 PESC/COPPE/UFRJ - Toacy C. de Oliveira

81 Agregação x Composição 81

82 Herança É o compartilhamento de atributos e operações entre classes com base em um relacionamento hierárquico. Possibilita a derivação de tipos mais específicos a partir de um tipo mais genérico Um classe pode ser definida de forma abrangente e depois ser refinada em sucessivas subclasses. Subclasses herdam os atributos e os métodos da super-classe, permitindo ainda modificações nos mesmo. Produto id descrição quantidade unidade preço generalização Pereciveis prazoValidade dataEntrada Não-Precíveis dataValidade PESC/COPPE/UFRJ - Toacy C. de Oliveira

83 Herança Múltipla  Uma subclasse pode estar associada a mais de uma super-classe. São herdados os atributos e/ou operações de cada super-classe. Conflitos de nomes são resolvidos a nível de implementação. Veículo Terrestre Veículo Aquático CarroVeículo Anfíbio Barco 83 PESC/COPPE/UFRJ - Toacy C. de Oliveira

84 Generalização  Abstrai classes genéricas, a partir de classes com propriedades (atributos e operações) semelhantes.  Generalização e herança são abstrações que permitem modelar aspectos semelhantes entre classes, preservando suas diferenças.  Numa hierarquia de generalização, as subclasses herdam todas as propriedades de sua superclasse. 84

85 PESC/COPPE/UFRJ - Toacy C. de Oliveira Generalização – Exemplo em Java public class Conta { } public class ContaCorrente extends Conta { } public class ContaPoupanca extends Conta { } Conta ContaCorrente ContaPoupanca 85

86 Generalização - Especialização  Processo de Generalização: Identificar classes com propriedades semelhantes. Definir uma nova classe com as propriedades comuns. As classes originais tornam-se subclasses da nova classe e herdam as propriedades desta. As associações em comum passam para a superclasse e as outras continuam nas subclasses. 86 PESC/COPPE/UFRJ - Toacy C. de Oliveira

87 Processo de Generalização Carro numChassi placa cor numPas anoFabric tipoComb Caminhão numChassi placa numEixos tonelagem ano Fabricante nome paísOrigem 0..* Carroceria tipo fabricante Carroceria tipo fabricante Carro cor numPas tipoComb Caminhão numEixos tonelagem Veículo numChassi placa anoFabric 0..* Multa data local valor Fabricante nome paísOrigem 0..* Multa data local valor 87

88 Especialização - Generalização  Processo de Especialização: Definir uma ou mais subclasses a partir de uma classe existente. Adicionar propriedades e associações específicas de cada nova subclasse. Associações comuns ficam ligadas à superclasse. Pode existir mais de um tipo de especialização com base em diferentes características.  Cada hierarquia de generalização/especialização deve abranger uma única característica. 88 PESC/COPPE/UFRJ - Toacy C. de Oliveira

89 Processo de Especialização Pagamento numPedido data valor Pagamento em Dinheiro Pagamento com Cartão numParcelas Pagamento com Cheque numParcelas respAutorizacao Cartao de Crédito numCartao tipo 0..* Cheque numCheque banco valor 1..* 89 PESC/COPPE/UFRJ - Toacy C. de Oliveira

90 Dependência  Uma dependência é um relacionamento de utilização entre dois itens, no qual a alteração de um (o item independente) pode afetar o outro (o item dependente ). É representada por uma linha tracejada com uma seta apontando para o item independente. clientefornecedor F A classe cliente depende de algum serviço da classe fornecedor. F A mudança de estado do fornecedor afeta o objeto cliente que o utiliza. F A classe cliente não declara nos seus atributos um objeto do tipo fornecedor. F Fornecedor é recebido por parâmetro de método. 90 PESC/COPPE/UFRJ - Toacy C. de Oliveira

91 Exemplo de Dependência import java.awt.Graphics; class HelloWorld extends java.applet.Applet { public void paint (Graphics g) g.drawString(“Hello, world!”, 10, 10); } HelloWorldGraphics paint(Graphics g) Applet 91

92 Interface Descreve operações abstratas, que especificam o comportamento que um objeto pode escolher ou suportar. PESC/COPPE/UFRJ - Toacy C. de Oliveira

93 Relacionamento com Interfaces  É uma classe especial pois define um “protocolo de comunicação”. Não é passível de instanciação.  Classes se relacionam com interfaces para especificar a implementação do “protocolo” estabelecido por esta. A classe Pedido é “obrigada” a implementar o método Armazenar! PESC/COPPE/UFRJ - Toacy C. de Oliveira

94 Modelo Conceitual 94

95 PESC/COPPE/UFRJ - Toacy C. de Oliveira Conceito  Um conceito define algo importante no domínio da aplicação.  É fundamental na definição do vocabulário utilizado pelos desenvolvedores. Ex. Um Sistema de Vendas provavelmente fala de Preço, Item, TotalVenda, etc. 95

96 Modelo Conceitual  Objetivo: identificar conceitos relacionados com os requisitos do sistema, para melhor compreendê-lo.  Analisar o problema sob uma perspectiva conceitual.  O diagrama de classes da UML é utilizado para criar um modelo conceitual do domínio do problema.  Um modelo conceitual mostra: conceitos relacionamentos entre conceitos atributos de conceitos 96 PESC/COPPE/UFRJ - Toacy C. de Oliveira

97 Modelo Conceitual  É representado por um diagrama de classes que contêm: Conceitos representados como classes Associações entre conceitos representados como associações entre classes. Propriedades dos conceitos representados como atributos de classes.  Tipicamente NÃO possuem responsabilidades. 97

98 PESC/COPPE/UFRJ - Toacy C. de Oliveira Modelo Conceitual Para construir um modelo conceitual: 1. Liste os candidatos a conceitos, identificando substantivos nas descrições dos casos de uso e a partir do seu conhecimento do domínio do problema. 2. Desenhe-os em um modelo conceitual 3. Acrescente os relacionamentos. 4. Acrescente os atributos. Um modelo conceitual não é absolutamente correto ou errado, mas sim, mais ou menos útil; ele é uma ferramenta de comunicação. 98

99 Sistema de Matrícula (exemplo)  A Universidade XYZ deseja informatizar seu sistema de matrículas:  A universidade oferece vários cursos.  O Coordenador de um curso define as disciplinas que serão oferecidas pelo seu curso num dado semestre.  Várias disciplinas são oferecidas em um curso.  Várias turmas podem ser abertas para uma mesma disciplina.  Estudantes selecionam 4 disciplinas preferenciais e 2 alternativas.  Quando um estudante matricula-se para um semestre, o Sistema de Registro Acadêmico (SRA) é notificado.  Após a matrícula, os estudantes podem, por um certo prazo, utilizar o sistema para adicionar ou remover disciplinas.  Professores usam o sistema para obter a lista de alunos matriculados em suas disciplinas.  Todos os usuários do sistema devem ser validados. 99 PESC/COPPE/UFRJ - Toacy C. de Oliveira

100 Diag. Casos de Uso 100 PESC/COPPE/UFRJ - Toacy C. de Oliveira

101 Descrição do Caso de Uso “Matricular em Disciplina”  Esse caso de uso se inicia quando o Estudante de Curso inicia uma sessão no sistema e apresenta suas credenciais.  O sistema verifica se a credencial é válida.  O sistema solicita que o estudante realize sua matrícula, selecionando 4 disciplinas preferenciais e 2 alternativas.  O estudante preenche um formulário eletrônico de matrícula e o submete para uma análise de consistência.  O sistema analisa as informações contidas no formulário.  Se as informações são consistentes, o estudante é incluído em turmas abertas de 4 disciplinas, iniciando pelas preferenciais.  Se as informações não são consistentes, o sistema informa o motivo da inconsistência e solicita que o formulário seja alterado. 101 PESC/COPPE/UFRJ - Toacy C. de Oliveira

102 Modelo Conceitual  Alguns exemplos de candidatos a conceitos: Papéis desempenhados por pessoas Objetos físicos ou tangíveis Lugares Descrições de coisas Contêineres de alguma coisa Coisas em um contêiner Transações Outros sistemas de computador Organizações Serviços Catálogos, manuais, livros, etc. 102 PESC/COPPE/UFRJ - Toacy C. de Oliveira

103 Modelo Conceitual ProfessorCoordenadorEstudante TurmaUniversidadeDisciplina FormularioMatricula Curso AnalisadorMatricula SistemaRegistroAcademicoListaAlunos 103 PESC/COPPE/UFRJ - Toacy C. de Oliveira

104 Modelo Conceitual  Para melhor compreender o vocabulário do problema, é necessário descobrir como os conceitos se relacionam, para satisfazer os requisitos descritos nos casos de uso. 104 PESC/COPPE/UFRJ - Toacy C. de Oliveira

105 Modelo Conceitual  Exemplos de candidatos a relacionamentos: A é parte física ou lógica de B. A está contido fisicamente ou logicamente em B. A é uma descrição de B. A é membro de B. A é subunidade organizacional de B. A usa ou gerencia B. A se comunica/interage com B. A está relacionado com uma transação B. A é possuído por B. A é um tipo de B. 105 PESC/COPPE/UFRJ - Toacy C. de Oliveira

106 Modelo Conceitual Professor Coordenador EstudanteTurma Disciplina FormularioMatricula AnalisadorMatricula é-preenchido-por está-matriculado-em é-processado-por é-ministrada-por é-definida-por aluno gerencia 1 1 1 0..* 1 1 1..* 1 10..33..104 106

107 Modelo Conceitual  Atributos podem ser encontrados examinando-se as descrições dos casos de uso e também pelo conhecimento do domínio do problema. Cada turma oferecida possui um código, uma sala, um horário e um número de alunos. Turma código sala horário 107 PESC/COPPE/UFRJ - Toacy C. de Oliveira

108 Modelo Conceitual Coordenador FormularioMatricula AnalisadorMatricula é-preenchido-por está-matriculado-em é-processado-por é-ministrada-por é-definida-por aluno gerencia 1 1 1 0..* 1 11..* 1 10..33..104 Turma código sala horário Professor nome titulação Estudante nome matricula Disciplina nome numCréditos 108

109 Evitar  Usar conceitos relacionados com a implementação. BancodeDadosAluno Alunos salvar() 109 PESC/COPPE/UFRJ - Toacy C. de Oliveira

110 Modelo de Análise (Modelo Conceitual) 110 PESC/COPPE/UFRJ - Toacy C. de Oliveira

111 Classes no Modelo de Análise  Características: tem como foco a representação dos requisitos funcionais do sistema: representação de conceitos do domínio de problema raramente define sua interface em termos de suas operações e assinaturas define atributos, porém sem o compromisso com detalhamento estabelece suas relações com outras classes podem ser enquadradas em três estereótipos básicos:  entidade  fronteira  controle 111

112 Estereótipos de Classes de Análise  Classe Entidade (entity) utilizada para modelar informações que tem longa vida no sistema e que freqüentemente são persistentes; modelam informações e comportamentos associados a conceitos do sistema. Nome - atrib > 112 PESC/COPPE/UFRJ - Toacy C. de Oliveira

113  Classe Fronteira (boundary) usada para modelar a interação entre o sistema e seus atores; a interação envolve o recebimento, apresentação e requisição de informações entre o sistema e seus usuários ou sistemas externos; uma mudança em uma interface de usuário ou em uma interface de comunicação é usualmente isolada em uma ou mais classes de fronteira; cada classe de fronteira deve estar relacionada a pelo menos um ator e vice-versa. Estereótipos de Classes de Análise Nome > 113 PESC/COPPE/UFRJ - Toacy C. de Oliveira

114 Estereótipos de Classes de Análise  Classe de Controle (control) representam coordenação, sequenciamento, transações e controle de outros objetos; utilizadas para encapsular controle relacionado e a um caso de uso específico; utilizadas para representar processamento complexo (tal como cálculos envolvidos na lógica de um processo de negócio) que não seja apropriado a uma classe entidade em particular. Nome > 114 PESC/COPPE/UFRJ - Toacy C. de Oliveira

115 Realização de um Caso de Uso Interface do Caixa RetiradaLançamentos Modelo de Casos de Uso Modelo de Análise Sacar dinheiro no caixa eletrônico Sacar dinheiro no caixa eletrônico Interface do Caixa Interface do Caixa Retirada Modelo de Casos de Uso Modelo de Análise Conta 115

116 PESC/COPPE/UFRJ - Toacy C. de Oliveira Estereótipos de Classes de Análise Lançamentos Retirada ContaCorrente 0..* Caixa Interface Caixa 116

117 PESC/COPPE/UFRJ - Toacy C. de Oliveira Estereótipos de Classes de Análise Lançamentos - tipoLancamento - valor - data > Retirada > ContaCorrente - numero - nomeCorrentista - endereco - telefone - saldo > 0..* Caixa Interface Caixa > 117

118 PESC/COPPE/UFRJ - Toacy C. de Oliveira Classes de Análise Sacar dinheiro no caixa eletrônico Depositar dinheiro Transferir dinheiro Cliente Lançamentos Interface do Caixa Retirada Conta Modelo de Casos de Uso Modelo de Análise Transferência Depósito Cliente 118