PRDS - Programa de Residência em Desenvolvimento de Software

Transcrição

1 PRDS - Programa de Residência em Desenvolvimento de Software Laboratório de Engenharia de Software (LES) da PUC-Rio Carlos Lucena lucena@inf.puc-rio.br Rodrigo Paes rbp@les.inf.puc-rio.br Gustavo Carvalho guga@les.inf.puc-rio.br Cidiane Lobato cidiane@inf.puc-rio.br

2 Conteúdo Módulo : Java I 4 horas Sintaxe IDE Eclipse Módulo 2: Orientação a Objetos com Java I 4 horas Herança Polimorfismo Associação Delegação Collections Módulo 3: Java II 8 horas Manipulação de arquivos Persistência JDBC Sockets Módulo 4: UML 4 horas Casos de Uso Classes Seqüência Módulo 5: Qualidade de Software I 4 horas Teste Assertiva de execução Módulo 6: Orientação a objetos com Java II 8 horas Padrões de projeto Frameworks 2

3 Conteúdo Módulo 7: Java III 2 horas Mapeamento OO --> ER Persistência Hibernate Módulo 8: Desenvolvimento WEB I 6 horas Servlets, JSP, Desenvolvimento de taglibs Arquitetura 3 camadas MVC básico Módulo 9: Desenvolvimento WEB II 20 horas MVC Struts Internacionalização Módulo 0: Desenvolvimento WEB III 28 horas MVC Spring Testes na camada WEB Appfuse 3

4 Introdução à UML

5 O que é um modelo? Um modelo é uma simplificação da realidade. Um modelo pode ser estrutural ou comportamental. Construímos modelos para compreender melhor o sistema que estamos desenvolvendo. 5

6 Por que modelar? Ajuda a visualizar o sistema como desejamos que ele seja. Permite especificar estrutura e comportamento do sistema. Proporciona um guia para a construção do sistema. Documenta as decisões tomadas. 6

7 Princípios da Modelagem A experiência com modelagem em todas as disciplinas de engenharia sugere quatro princípios básicos:. Os melhores modelos estão relacionados à realidade. 2. Um modelo pode ser expresso em diferentes níveis de precisão. 3. A escolha dos modelos a serem criados tem profunda influência sobre a maneira como um determinado problema é atacado e como uma solução é definida. 4. Nenhum modelo único é suficiente. Qualquer sistema não trivial será melhor investigado por meio de um conjunto de modelos quase independentes. 7

8 O que é a UML? A Unified Modeling Language (UML) é uma linguagem gráfica para visualizar, especificar, construir e documentar os artefatos de um sistema de software. É o resultado da unificação das notações utilizadas nos métodos Booch, OMT (Object Modeling Technique) e OOSE (Object-Oriented Software Engineering). Adotada por grande parte da indústria de software e por fornecedores de ferramentas CASE como linguagem padrão de modelagem. 8

9 UML é uma Linguagem Uma linguagem de modelagem é uma linguagem cujo vocabulário e regras têm seu foco voltado para a representação conceitual e física de um sistema. Uma linguagem fornece um vocabulário e as regras para combinação de palavras desse vocabulário, com o objetivo de comunicar algo. O vocabulário e as regras indicam como criar e ler modelos bem formados, mas não apontam quais modelos devem ser criados e nem em que seqüência. 9

10 UML é uma Linguagem para Visualização No processo de desenvolvimento de sistemas de software, é quase impossível a visualização de toda a estrutura de um sistema sem o uso de modelos que a represente. A UML fornece os símbolos gráficos para a representação de artefatos de software. Por trás de cada símbolo empregado, existe uma sintaxe e uma semântica bem-definidas. Dessa maneira, um desenvolvedor poderá usar a UML para escrever seu modelo e qualquer outro será capaz de interpretá-lo sem ambigüidades. 0

11 UML é uma Linguagem para Especificação Especificar significa construir modelos precisos, completos e sem ambigüidades. A UML atende a todas as decisões importantes em termos de análise, projeto e implementação que devem ser tomadas para desenvolvimento e implantação de sistemas.

12 UML é uma Linguagem para Construção Os modelos de UML podem ser diretamente traduzidos para várias linguagens de programação tais como, Java, C++ e Visual Basic. Esse mapeamento permite realizar uma engenharia de produção: geração de código a partir de um modelo UML. O processo inverso, a engenharia reversa, também é possível, com a reconstrução de um modelo UML a partir do código que o implementa. 2

13 UML é uma Linguagem para Documentação Além dos modelos que descrevem o projeto, outros documentos, que fornecem informações importante sobre o sistema, também podem ser expressos com UML: os requisitos do sistema, a arquitetura do sistema e todos os seus detalhes, as atividades de planejamento do projeto, as atividades de realização de testes, o gerenciamento de versões. 3

14 Diagramas da Linguagem UML Diagramas de Seqüência Diagrama de Casos de Uso Diagramas de Classe Diagramas de Objetos Diagramas de Componentes Diagrama de Deployment Modelos Diagramas de Colaboração Diagramas de Estado Diagramas de Atividade Ponto de Vista Dinâmico Ponto de Vista Estático 4

15 Vantagens de Utilização da UML Padrão aberto e não proprietário. Integração das melhores práticas de modelagem. Independência do processo de desenvolvimento. Aplicável a todas as fases do ciclo de desenvolvimento. Independência de linguagem de implementação. Suporte a conceitos de alto nível. É uma linguagem extensível. 5

16 Breve Histórico da UML Versão mais recente UML 2.0 Setembro/200 UML.4... Junho/999 UML.3 Outras empresas se juntam ao Consórcio UML. Primeira submissão à OMG Jan/997 Consórcio Parceiros UML UML.0 Junho/996 UML 0.9 OOPSLA Unified Method 0.8 Outros métodos Método de Booch OMT (Rumbaugh) OOSE (Jacobson) 994 6

17 Contribuições para a Criação da UML Grady Booch and Jim Rumbaugh: unificaram os métodos Booch e OMT (Object Modeling Technique); Ivar Jacobson: casos de uso; Meyer: pré e pós-condições; Harel: statecharts; Gamma et al.: frameworks e padrões; Shlaer-Mellor: ciclo de vida de objetos; Odell: classificação; Wirfs-Brock: responsabilidades; Embley: classes singleton e visão de alto-nível; Fusion: descrição de operações e numeração de mensagens. 7

18 Principais Parceiros na Submissão da UML ObjecTime Oracle Platinum Technology Taskon Texas Instruments/Sterling Software Unisys Microsoft Rational Software Corporation Hewlett-Packard I-Logix IBM ICON Computing Intellicorp MCI Systemhouse 8

19 Diagrama de Casos de Uso

20 Diagrama de Casos de Uso: Introdução É um dos cincos diagramas UML que possibilitam a modelagem dos aspectos dinâmicos de um (sub)sistema. O diagrama de casos de uso identifica: quem interage com um sistema (atores) e o que o sistema deve fazer (casos de uso). O diagrama de casos de uso não identifica: como um sistema deve realizar as suas tarefas (casos de uso). Portanto, a principal característica é que o diagrama produz uma visão externa de como um sistema pode ser utilizado. 20

21 Diagrama de Casos de Uso: Introdução Baseado no conceito de casos de uso proposto em 992 por Jacobson em Object-Oriented Software Engineering: A Use case Driven Approach. Caso de uso: é um conjunto de ações em seqüência, feitas por um sistema, que produzem um resultado de valor observável para um determinado ator. 2

22 Diagrama de Casos de Uso: Introdução Como exemplo, o caso de uso vender itens :. O Cliente navega no catálogo de itens e adiciona itens desejados à sua cesta de compras. 2. Quando o cliente deseja pagar, informa o endereço de entrega, os dados do cartão de crédito e confirma a venda. 3. O sistema verifica a autorização do cartão de crédito, confirma a venda e envia um . O diagrama de casos de uso descreve requisitos funcionais em termos de casos de uso. Entretanto, outros diagramas - seqüência, atividades e estados - também especificam requisitos a partir de casos de uso, mas em outra perspectiva. 22

23 Diagrama de Casos de Uso: Introdução Segue a lista de quem usa o diagrama de casos de uso:. Cliente: validação das expectativas do cliente; 2. Arquiteto: identificar as funcionalidades arquiteturais; 3. Designer: obter uma visão geral do sistema; 4. Testador: planejar testes e validar requisitos; 5. Manutenção: compreender funções do sistema existente; 6. Gerência: visão geral do sistema, planejar atividades da equipe e acompanhar o projeto; 7. Documentação: base para manual do usuário. Portanto, o modelo de casos de uso permite verificar se: todos os requisitos foram capturados; a equipe de desenvolvimento compreendeu os requisitos; o resultado corresponde ao propósito e à expectativa. 23

24 Diagrama de Casos de Uso: Visão Geral Associações Sistema Ator Casos de Uso Fronteira 24

25 Diagrama de Casos de Uso: Visão Geral Nome Atores Precondições Descrição do Fluxo Normal 25

26 Diagrama de Casos de Uso: Visão Geral Descrição dos Fluxos Alternativos 26

27 Diagrama de Casos de Uso: Visão Geral Nome Atores Precondições Descrição do Fluxo Normal 27

28 Diagrama de Casos de Uso: Visão Geral Nome Atores Precondições Descrição do Fluxo Normal 28

29 Diagrama de Casos de Uso: Visão Geral Nome Atores Precondições Descrição do Fluxo Normal 29

30 Diagrama de Casos de Uso: Casos de Uso Existem três tipos de relacionamento entre casos de uso:. Generalização (semelhante à generalização entre classes): Símbolo: Filho herda comportamento e significado do pai. Pode acrescentar ou sobrescrever características. Validando usuario Validando senha Validando retina 30

31 Diagrama de Casos de Uso: Casos de Uso 2. Inclusão: Símbolo: <<include>> Função: evita repetição, colocando em evidência uma atividade comum a dois ou mais casos de uso. O caso de uso incluído nunca existe sozinho; ele é sempre parte de um caso de uso base e sempre é executado. Enviando pedido <<include>> Caso de Uso Acompanhando pedido Ator Primário: Cliente <<include>> Validando usuario Precondições: Nenhuma Cliente Acompanhando pedido Validando senha Validando retina Fluxo Normal incluir (Validando usuário) 2 Cliente solicita informações de pedido. 3

32 Diagrama de Casos de Uso: Casos de Uso 3. Extensão: Símbolo: <<extend>> Semelhante à generalização, mas especifica com rigor os pontos de extensão para representar uma variação/extensão do caso de uso base. O caso de extensão só é executado sob certas circunstâncias; é parte opcional de um caso base. Caso de Uso Enviando pedido Cliente Enviando pedido <<extend>> Acompanhando pedido Enviado pedido urgente (informar prioridade) <<include>> <<include>> Validando usuario Ator Primário: Cliente Precondições: Nenhuma Pontos de Extensão: informar prioridade Fluxo Normal incluir (Validando usuário) 2 Cliente solicita informações de pedido. 3 (informar prioridade) 4 Sistema envia pedido para processamento. 32

33 Diagrama de Casos de Uso: Casos de Uso Sistema de Pedido Enviando pedido <<extend>> Enviado pedido urgente (informar prioridade) <<include>> Cliente Acompanhando pedido <<include>> Validando usuario Validando senha Validando retina 33

34 Diagrama de Casos de Uso: Atores Representam um conjunto coerente de papéis que usuários exercem quando interagem com casos de uso. Representam papéis que humanos, dispositivos ou outros sistemas exercem no sistema. Um ator pode ter relação com outros atores (generalização) e participar em um ou mais casos de uso (associações). 34

35 Diagrama de Casos de Uso: Atores Generalização: Relacionamento entre dois atores com a mesma semântica da generalização entre classes. Um ator-filho pode se comunicar com todos os casos de uso com que o ator-pai se comunica. Sistema Investidor OnLine Cliente 02 - Preenchendo ficha cadastral 04 - Validando dados cadastrais Pessoa Física Pessoa Jurídica 35

36 Diagrama de Casos de Uso: Atores Associação: Indica que existe comunicação entre caso de uso e ator. NÃO representa um fluxo de informação, mas apenas que o ator está envolvido com um caso de uso. Inclusive, pode haver informação fluindo nos dois sentidos. associações Sistema Investidor OnLine Cliente 02 - Preenchendo ficha cadastral 04 - Validando dados cadastrais Pessoa Física Pessoa Jurídica 36

37 Diagrama de Casos de Uso: Atores Há três possibilidades de atores X associações:. todos os atores que participam do caso de uso; Sistema Investidor OnLine 02 - Preenchendo ficha cadastral 03 - Recebendo documentação Assistente de Cadastro Cliente 05 - Atualizando dados cadastrais Sistema de Carteiras 04 - Validando dados cadastrais Gerente de Cadastro 37

38 Diagrama de Casos de Uso: Atores 2. o ator ativador do caso de uso; 3. o ator básico (o que obtém o valor do caso de uso). Sistema Investidor OnLine 02 - Preenchendo ficha cadastral Cliente 05 - Atualizando dados cadastrais Assistente de Cadastro 03 - Recebendo documentação 04 - Validando dados cadastrais Gerente de Cadastro 38

39 Diagrama de Casos de Uso: Especificação Níveis de detalhamento da especificação de casos de uso: 02 - Preenchendo ficha cadastral Sistema Investidor OnLine Cliente 05 - Atualizando dados cadastrais Assistente de Cadastro 03 - Recebendo documentação <<include>> 04 - Validando dados cadastrais <<include>> 06 - Localizando cliente Gerente de Cadastro 07 - Localizando cliente por estado 08 - Localizando cliente por nome 09 - Localizando cliente por CPF 39

40 Diagrama de Casos de Uso: Especificação. Descrição Textual Informal Caso de Uso 0 Cadastrando Cliente (descrição informal) O Cliente inicia o cadastro preenchendo a ficha cadastral e enviando a documentação necessária para o Departamento de Cadastro. O Assistente de Cadastro examina a documentação. Estando a documentação em ordem, o Gerente de Cadastro valida os dados da ficha cadastral e marca o Cliente como aprovado. Se houverem problemas com os documentos enviados, o Assistente de Cadastro informa documentação irregular. O Cliente envia a documentação regularizada para o Assistente de Cadastro. Se houverem problemas com os dados da ficha cadastral, o Gerente de Cadastro informa irregularidade nos dados cadastrais. O Cliente corrige os dados cadastrais. 40

41 Diagrama de Casos de Uso: Especificação 2. Descrição Textual Típica Caso de Uso 0 Cadastrando cliente (descrição típica) Ator Primário: Cliente Precondições: Nenhuma Fluxo Normal Cliente preenche ficha cadastral. 2 Assistente de Cadastro informa recebimento de documentação cadastral. 3 Gerente de Cadastro informa aprovação do Cliente. Fluxo Alternativo: documentação incompleta ou com erro 2a Assistente de Cadastro informa documentação irregular. 2b Cliente envia documentação corrigida para cadastro. 2c Retorna ao passo 2. Fluxo Alternativo: irregularidade nos dados cadastrais 3a Gerente de Cadastro informa irregularidade nos dados cadastrais. 3b Cliente atualiza dados cadastrais. 3c Retorna ao passo 3. 4

42 Diagrama de Casos de Uso: Especificação 3. Descrição Textual Detalhada Caso de Uso 0 Cadastrando cliente (descrição detalhada) Ator Primário: Cliente Objetivo: Este caso de uso tem por objetivo controlar o processo de cadastro de um novo cliente no Investidor OnLine. Ao final desse caso de uso, o cliente estará cadastrado no Sistema de Carteiras, sua documentação estará completa e estará aprovado para operar. Precondições: Nenhuma Condição de disparo (Trigger): Cliente decide operar através do Investido OnLine

43 Diagrama de Casos de Uso: Especificação 3. Descrição Textual Detalhada Fluxo Normal Cliente inicia o cadastro preenchendo a ficha cadastral e enviando documentação para Assistente de Cadastro. 2 Assistente de Cadastro recebe documentação do Cliente e informa recebimento de documentação cadastral. 3 Gerente de Cadastro valida os dados da ficha cadastral e informa aprovação do Cliente. Sistema emite relação de clientes pendentes de documentação para Assistente de Cadastro. Sistema envia aviso de documentação pendente para Cliente. Sistema emite relação de clientes pendentes de aprovação para Gerente de Cadastro. Sistema envia aviso de documentação recebida para Gerente de Cadastro. Sistema gera Número da conta. Sistema envia pedido de criação de conta para o Cliente no Sistema de Carteiras. Sistema emite relação de clientes aprovados para Gerente de Cadastro. Sistema envia aviso de aprovação de cadastro para Cliente. 43

44 Diagrama de Casos de Uso: Especificação 3. Descrição Textual Detalhada Fluxo Alternativo: documentação incompleta ou com erro 2a Assistente de Cadastro informa documentação irregular. Sistema emite relação de clientes com documentação irregular para Assistente de Cadastro. Sistema envia aviso de documentação irregular para Cliente. 2b Cliente envia documentação corrigida para cadastro. 2c Retorna ao passo 2. 44

45 Diagrama de Casos de Uso: Especificação 3. Descrição Textual Detalhada Fluxo Alternativo: irregularidade nos dados cadastrais 3a Gerente de Cadastro identifica e informa irregularidade nos dados cadastrais. 3b Cliente atualiza dados cadastrais. Sistema emite relação de clientes com cadastro irregular para Gerente de Cadastro. Sistema envia aviso de irregularidade nos dados cadastrais para Cliente. Sistema emite relação de clientes pendentes de aprovação para Gerente de Cadastro. Sistema envia aviso de alteração de dados para Gerente de Cadastro. 3c - Retorna ao passo 3. 45

46 Diagrama de Casos de Uso: Especificação 3. Descrição Textual Detalhada Prioridade: - Versão: - Tempo de Resposta: - Freqüência de Uso: 0/dia Canal para Ator Primário: navegador de internet, sistema de ou equivalente. Atores secundários: Assistente de Cadastro, Gerente de Cadastro, Sistema de Carteiras. Canal para Atores Secundários: navegador de internet, sistema de ou equivalente, servidor de fila de mensagens. Questões em aberto: - 46

47 Casos de Uso e Diagramas UML Especificação dos Casos de Uso: Descrição Textual UML não especifica padrão. São possíveis diversos níveis de detalhamento. Diagrama de seqüência Representação gráfica de cenários. Diagrama de atividades Ajuda a responder à questão todos os cenários foram pensados?. Outros artefatos: Diagrama de Estados Não especifica um caso de uso, mas ajuda na verificação da consistência dos cenários. 47

48 Casos de Uso e Diagrama de Seqüência Cliente Investidor OnLine Sistema de Carteiras Assistente de Cadastro Gerente de Cadastro : preenche ficha cadastral.2: envia aviso de documentação pendente.: emite relação de clientes pendentes de documentação 2: informa recebimento documentação cadastral 2.: emite relação de clientes pendentes de aprovação 2.2: envia aviso de documentação recebida 3: informa aprovação de Cliente 3.: envia pedido de criação de conta 3.3: envia aviso de aprovação de cadastro 3.2: emite relação de clientes aprovados 48

49 Casos de Uso e Diagrama de atividades Preenchendo ficha cadastral Recebendo documentação [irregularidade documentação] [documentação ok] Validando dados cadastrais Atualizando dados cadastrais [irregularidade dados cadastrais] [dados cadastrais ok] 49

50 Casos de Uso e Diagrama de Estados Cliente preenche ficha cadastral documentação pendente Assistente de Cadastro informa documentação irregular documentação irregular Assistente de Cadastro informa recebimento documentação aprovação pendente Cliente atualiza dados cadastrais cadastro irregular Gerente de Cadastro informa irregularidade dados cadastrais Gerente de Cadastro informa aprovação de Cliente 50

51 Modelagem de Casos de Uso: Loja de CDs Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade ilimitada de discos; para isto, ele deve se dirigir à loja. A loja possui um funcionário cuja função é atender os clientes durante a venda dos discos. A loja também possui um gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao atendente, ou seja, ele também atende os clientes durante a venda dos discos.. Quais são os atores? 2. Quais são os casos de uso? 3. Quais as associações? 4. Quais as generalizações? 5. Quais as inclusões e extensões? 5

52 Loja de CDs: Identificando os atores Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um funcionário cuja função é atender os clientes durante a venda dos discos. A loja também possui um gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao atendente, ou seja, ele também atende os clientes durante a venda dos discos. Atendente Gerente E o Cliente?! Ele não interage com o sistema! 52

53 Loja de CDs: Identificando os casos de uso Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um funcionário cuja função é atender os clientes durante a venda dos discos. A loja também possui um gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao atendente, ou seja, ele também atende os clientes durante a venda dos discos. Vender CD Administrar estoque 53

54 Loja de CDs: Identificando associações Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um funcionário cuja função é atender os clientes durante a venda dos discos. A loja também possui um gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao atendente, ou seja, ele também atende os clientes durante a venda dos discos. Atendente Vender CD Gerente Administrar estoque 54

55 Loja de CDs: Identificando generalizações Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um funcionário cuja função é atender os clientes durante a venda dos discos. A loja também possui um gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao atendente, ou seja, ele também atende os clientes durante a venda dos discos. Atendente X Vender CD Gerente também atende! Gerente Administrar estoque 55

56 Loja de CDs: Novos requisitos Depois de mostrar o último diagrama para o dono da lojas de CDs, ele se lembrou de um requisito importante que vamos considerar daqui em diante: As vendas podem ser à vista ou a prazo. Em ambos os casos, o estoque é atualizado e uma nota fiscal é entregue ao consumidor. No caso de uma venda a prazo, ela pode ser parcelada em 2 pagamentos com um acréscimo de 0%. Para as vendas a prazo são gerados boletos bancários que são entregues ao cliente e armazenados no sistema para lançamento posterior no caixa. Quais os atores, casos de uso e relacionamentos? 56

57 Loja de CDs: Identificando casos de uso As vendas podem ser à vista ou a prazo. Em ambos os casos o estoque é atualizado e uma nota fiscal é entregue ao consumidor. No caso de uma venda a prazo, ela pode ser parcelada em 2 pagamentos com um acréscimo de 0%. Para as vendas a prazo são gerados boletos bancários que são entregues ao cliente e armazenados no sistema para lançamento posterior no caixa. Atendente Vender CD Vender CD a prazo Vender CD à vista Administrar estoque Gerente 57

58 Loja de CDs: Identificando casos de uso O caso de uso Vender CD pode ser modelado como dois casos de uso especializados, pois os casos de uso herdeiros embora descrevam uma lógica de negócio similar, são diferentes. Assim, nos casos de uso especializados, o fluxo normal de execução ou os fluxos alternativos são diferentes e, portanto, totalmente reescritos. Generalização de casos de uso deve ser aplicada quando uma condição, no nosso caso, se a venda é à vista ou a prazo, resultaria na definição de diversos fluxos alternativos. Sem a generalização, por exemplo, seria necessário criar fluxos alternativos para a criação dos boletos e o não lançamento do pagamento do CDs no caixa. 58

59 Loja de CDs: Novos requisitos Clientes cadastrados na loja e que compram mais de 5 CDs de uma só vez à vista ganham um desconto de % para cada ano de cadastro. Quais atores, casos de uso e relacionamentos? 59

60 Loja de CDs: Identificando casos de uso Clientes cadastrados na loja e que compram mais de 5 CDs de uma só vez à vista ganham um desconto de % para cada ano de cadastro. Atendente Vender CD Vender CD a prazo Vender CD à vista <<extends>> Vender CD à vista com desconto Administrar estoque Gerente 60

61 Loja de CDs: Novos requisitos Para efetuar toda venda ou administração do estoque, atendentes e gerentes terão que validar suas respectivas senhas de acesso ao sistema. Quais os atores, casos de uso e relacionamentos? 6

62 Loja de CDs: Identificando casos de uso Para efetuar toda venda ou administração do estoque, atendentes e gerentes terão que validar suas respectivas senhas de acesso ao sistema. Atendente Vender CD Validar senha Vender CD a prazo Vender CD àvista <<extends>> Vender CD à vista com desconto Administrar estoque Gerente 62

63 Loja de CDs: Verificando diagrama... OK! Como todos os atores, casos e relacionamentos foram modelados, agora é só acrescentar a fronteira do sistema! Atendente Vender CD Validar senha Vender CD a prazo Vender CD àvista <<extends>> Vender CD à vista com desconto Administrar estoque Gerente 63

64 Diagrama de Classes

65 Diagrama de Classes: Introdução É o diagrama central da modelagem orientada a objetos; possibilita modelar os aspectos estáticos de um sistema. O diagrama de classes identifica: classes e relacionamentos de um sistema. O diagrama de classes não identifica: seqüência de interações entre objetos de um sistema. 65

66 Diagrama de Classes: Introdução Como exemplo, um esboço de diagrama de classes: Aluno nome: Texto matrícula: Inteiro está-matriculado-em definirnome(nome) obternome() definirmatricula(matricula) obtermatricula Turma código: Texto sala: Texto horario: Horario estaaberta() definirprofessor(professor) incluiraluno(aluno) é-ministrada-por Professor nome: Texto titulação: Texto definirnome(nome) obternome() definirtitulacao(titulo) obtertitulacao 66

67 Diagrama de Classes: Visão Geral SistemaDAR criauniversidade() : Universidade getnome() está-matriculado-em Universidade leciona 0..n Universidade() * getdepartamentos() Disciplina getalunos() codigo : String getalunosmatriculados() nome : String getdisciplinas() reqcreditos : short getdepartamento(nome: String) nocreditos : short getaluno(matricula : String) oferecida : boolean getdisciplinasoferecidas(departamento: Departamento) obrigatoriedade : boolean 0..n 0..* getdisciplinasoferecidas getoferecida() cursou PorSecretaria(departamento : Departamento) getalunosmatriculados() 0..* getdisciplina(codigo: String) getdisciplinasondeerequisito() emitepauta(disciplina: Disciplina) é-pré-requisito getreqdisciplinas() getdepartamento(aluno: Aluno) emitepauta() processamatricula(aluno: Aluno, disciplina: Disciplina) Disciplina() getprofessor() emitecomprovante(aluno: Aluno) 0..n getcurso() processamatricula(aluno : Aluno) SecretariaGraduacao..* * Departamento getcursosgraduacao() possui getdisciplinas() nome : String getdisciplinasoferecidas() getsecretarias() getalunos() getdisciplinas() getalunosmatriculados() oferece getdisciplinasoferecidasporsecretaria() SecretariaGraduacao(departamento getalunos() Departamento)..* getalunosmatriculados() getdisciplina(codigo: String) Departamento() getaluno(matricula: String) CursoGraduacao getdisciplina(codigo: String) getaluno(matricula: String) CursoGraduacao() possui getsecretariagraduacao() SecretariaPosGraduacao..2 getdepartamento() <<abstract>> Secretaria getcursosposgraduacao() getdisciplinas() getdisciplinasoferecidas() getalunos() : Collection Professor nome : String getdisciplinas() Professor(nome: String) getdisciplinas() getdisciplinasoferecidas() getalunos() : Collection getalunosmatriculados() getalunosmatriculados() SecretariaPosGraduacao(departamento: Secretaria(departamento : Departamento) Departamento) getaluno(matricula: String) getdisciplina(codigo: String) getdisciplina(codigo: String) getaluno(matricula: String) getdepartamento() Relacionamento oferece..* CursoPosGraduacao CursoPosGraduacao() getsecretariaposgraduacao() getdepartamento() 0..n Aluno matricula : String nome : String creditosobrigatorios : short creditoseletivos : short emitecomprovante() Aluno() getcurso() : Curso getdepartamento() processamatricula(disciplina * : Discipl <<abstract>> Curso nome : String getdisciplinas() getalunos() getdisciplinasoferecidas() getalunosmatriculados() getdepartamento() : Departamento getaluno(matricula: String) getdisciplina(codigo: String) * Classe está-vinculado-a 67

68 Diagrama de Classes: Classes São representadas por retângulos, geralmente incluindo seu nome, atributos e métodos. nome_da_classe atributo atributo2... metodo metodo2 metodo3... Devem receber nomes de acordo com o vocabulário do domínio do problema. É comum adotar padrões: Por exemplo, todos os nomes de classes são substantivos singulares com a primeira letra maiúscula. 68

69 Diagrama de Classes: Relacionamentos São basicamente estes os relacionamentos em um diagrama de classes UML: Associação; Agregação; Composição; Generalização; Dependência. 69

70 Relacionamentos: Associação Associação: relacionamento que indica que os objetos de uma classe estão vinculados a objetos de outra classe. Uma associação é representada por uma linha sólida conectando duas classes. Pessoa Empresa associação 70

71 Relacionamentos: Associação Uma associação pode ter um nome, a fim de tornar mais clara a natureza do relacionamento. Para evitar ambigüidades, pode-se incluir um triângulo para indicar a direção de leitura do nome. direção do nome nome Empresa trabalha para Pessoa associação 7

72 Relacionamentos: Associação 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. associação Pessoa empregado empregador Empresa nome do papel 72

73 Relacionamentos: Associação Multiplicidade é o número de instâncias de uma classe que se relacionam com uma instância de outra classe. multiplicidade Pessoa..* trabalha para * Empresa associação 73

74 Relacionamentos: Associação Indicadores de multiplicidade mais comuns: Exatamente um..* Um ou mais 0..* Zero ou mais (muitos) * Zero ou mais (muitos) 0.. Zero ou um m..n Faixa de valores (por exemplo: 4..7) multiplicidade Pessoa..* trabalha para * Empresa associação 74

75 Relacionamentos: Associação Exemplo de multiplicidade m..n: 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 aluno. Um aluno pode cursar de 0 até 8 disciplinas. Equipe de Futebol compete..22 time jogador Estudante..* participa 0..8 aluno disciplina Equipe de Futebol 75

76 Relacionamentos: Associação Em geral, as associações são bidirecionais, mas 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. navegabilidade Cliente reside * Endereço Um cliente sabe quais são os seus endereços, mas o endereço não sabe qual é o seu cliente. 76

77 Relacionamentos: Agregação Agregação: tipo de associação utilizada para indicar um relacionamento todo-parte ; um objeto parte pode fazer parte de vários objetos todo. Uma associação é representada por uma linha sólida com um losango vazado na extremidade referente ao todo. todo parte Pedido..* Item agregação O significado da agregação é inteiramente conceitual: o losango simplesmente diferencia o todo da parte. 77

78 Relacionamentos: Composição Composição: é uma variante semanticamente mais forte da agregação em que objetos parte só pertencem a um único todo e têm o tempo de vida coincidente com o dele. É representada por uma linha contínua com um losango cheio na extremidade referente ao todo. todo Notebook Window 0..* Teclado Frame parte..* 0..* errado Quando o todo morre todas as suas partes também morrem. Apenas o todo pode criar e destruir as partes. 78

79 Relacionamentos: Composição Janela Scroll Título Corpo 0.. Empresa..* Departamento *..* Escritório 79

80 Relacionamentos: Generalização Generalização: relacionamento entre itens gerais (superclasse) e itens mais específicos (subclasses). É representada por uma linha sólida com um triângulo vazado apontando para o item mais geral. superclasse Veículo Terrestre subclasse é um é um tipo de Automóvel Caminhão 80

81 Relacionamentos: Dependência Dependência: 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. cliente fornecedor A classe cliente depende de algum serviço da classe fornecedor. A mudança de estado do fornecedor afeta o objeto cliente que o utiliza. A classe cliente não declara nos seus atributos um objeto do tipo fornecedor. Fornecedor é recebido por parâmetro de método. 8

82 Relacionamentos: Dependência Applet HelloWorld Graphics paint(graphics g) import java.awt.graphics; class HelloWorld extends java.applet.applet { public void paint (Graphics g) g.drawstring( Hello, world!, 0, 0); } 82

83 Classes de associação Usada quando uma associação entre duas classes contiver atributos da associação: atributos farão parte da classe de associação; C existe para todo relacionamento de A com B. A B C possui referência para A e para B C Não existem dois objetos C e C que referenciam a mesma tupla A,B, isto é, não existem c(a,b,x) e c (a,b,x ), onde a e b são objetos de A e B, respectivamente, e x e x são valores de um atributo de C. d(a,b,x) e d(a,b,x ) existem: A D B 83

84 Classes de associação Empresa 0..* trabalha..* Pessoa Não existe uma pessoa com dois empregos na mesma empresa Emprego descrição salário atributos do relacionamento Uma pessoa pode fazer mais de um pedido na mesma empresa Empresa 0..* pertence Pedido itempedido 0..* faz Pessoa 84

85 Diagramas UML: Blog Um blog tem um título e uma data de criação e, além disso, é um conjunto de conteúdos. Estes conteúdos (mensagens) podem ser notas ou comentários sobre as notas. Tanto notas quanto comentários têm características comuns como o texto e a data de sua criação. 85

86 Blog: Análise de Requisitos. Permitir a criação de blogs. 2. Permitir a utilização de blogs. a. Qualquer usuário pode ler conteúdos: para ler o conteúdo de um blog, o usuário pede ao blog para mostrar suas notas, escolhe uma nota e a visualiza. Caso seja de seu interesse, ele pede a nota que mostre os seus comentários. Ele escolhe o comentário e pede que ele mostre o seu conteúdo. b. Somente o dono do blog pode criar notas. c. Qualquer usuário pode criar comentários. d. Somente o dono do blog pode remover conteúdos: para remover um conteúdo ele precisará ler o conteúdo. Caso ele remova um comentário, o autor do comentário deve ser notificado por . Todo usuário possui (deve ser único, ou seja, não há mais de um usuário com o mesmo ). 86

87 Blog: Diagrama de Casos de Uso BlogSystem Criar blog Criar comentário <<include>> Ler conteúdo Ler nota Usuario Ler comentário <<include>> <<include>> Remover comentário Remover conteudo Remover nota Dono do blog Criar nota 87

88 Blog: Diagrama de Classes 0..* Blog -dtcriacao:date -titulo:string -dono:usuario -conteudos:vector dono Usuario - string +notificarexclusao:void autor 0..* usa usuario +criarnota:void +exibirconteudo:void +comentar:void +lercomentarios:vector +removerconteudo:void +lernotas:vector +Blog 0..* 0..* Conteudo -dtcriacao:date -texto:string -autor:usuario Nota +Conteudo +exibirconteudo:void -comentarios:vector -attribute:int +comentar:void +lercomentarios:vector +finalize:void 0..* Comentario +finalize:void 88

89 Diagrama de Classes: Especificação Um diagrama de classes é construído a partir de um modelo conceitual do domínio do problema. Um modelo conceitual identifica conceitos relacionados com os requisitos do sistema para melhor compreendê-lo; ou seja, analisa o problema sob uma perspectiva conceitual. Um modelo conceitual mostra: conceitos (e não classes!); atributos de conceitos; relacionamentos entre conceitos. Veja que métodos não estão incluídos em um modelo conceitual! 89

90 Diagrama de Classes: Especificação Para construir um modelo conceitual:. 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 Em modelo uma fase conceitual posterior, não uma é absolutamente limpeza no modelo correto conceitual ou errado, dá mas origem sim, mais ao diagrama ou menos de útil; ele é classes uma ferramenta propriamente de comunicação. dito! 90

91 Diagrama de Classes: Especificação Em um modelo conceitual, são candidatos a conceitos:. papéis desempenhados por pessoas; 2. objetos físicos ou tangíveis; 3. lugares; 4. descrições de coisas; 5. contêineres de alguma coisa; 6. coisas em um contêiner; 7. transações; 8. outros sistemas de computador; 9. organizações; 0.serviços;.catálogos, manuais, livros, etc. 9

92 Diagrama de Classes: Especificação Em um modelo conceitual, são candidatos a relacionamentos:. A é parte física ou lógica de B. 2. A está contido fisicamente ou logicamente em B. 3. A é uma descrição de B. 4. A é membro de B. 5. A é subunidade organizacional de B. 6. A usa ou gerencia B. 7. A se comunica/interage com B. 8. A está relacionado com uma transação B. 9. A é possuído por B. 0.A é um tipo de B. 92

93 Diagrama de Classes: Especificação Em um modelo conceitual, os atributos podem ser encontrados examinando-se as descrições dos casos de uso e também pelo conhecimento do domínio do problema. Turma Cada turma oferecida possui um código, uma sala, um horário e um número de alunos. código sala horário 93

94 Diagrama de Classes: Especificação Detalhes e elementos descobertos durante a criação dos diagramas de interação são acrescentados ao modelo conceitual para a obtenção de um diagrama de classes. Entre tais elementos, destacam-se:. os métodos, que tornam explícitas as mensagens trocadas entre objetos nos diagramas de interação; 2. os relacionamentos de generalização, associação e dependências que surgem a partir da especificação dos métodos anteriores. 94

95 Diagramas UML: Sistema de Matrícula (SM) Uma universidade requisista um sistema de matrículas:. A universidade oferece vários cursos. 2. O Coordenador de um curso define as disciplinas que serão oferecidas pelo seu curso num dado semestre. 3. Várias disciplinas são oferecidas em um curso. 4. Várias turmas podem ser abertas para uma mesma disciplina. 5. Estudantes selecionam 4 disciplinas preferenciais e 2 alternativas. 6. Quando um estudante matricula-se para um semestre, o Sistema de Registro Acadêmico é notificado. 7. Após a matrícula, os estudantes podem, por um certo prazo, utilizar o sistema para adicionar ou remover disciplinas. 8. Professores usam o sistema para obter a lista de alunos matriculados em suas disciplinas. 9. Todos os usuários do sistema devem ser validados. 95

96 SM: Identificando os atores Uma universidade requisista um sistema de matrículas:. A universidade oferece vários cursos. 2. O Coordenador de um curso define as disciplinas que serão oferecidas pelo seu curso num dado semestre. 3. Várias disciplinas são oferecidas em um curso. 4. Várias turmas podem ser abertas para uma mesma disciplina. 5. Estudantes selecionam 4 disciplinas preferenciais e 2 alternativas. 6. Quando um estudante matricula-se para um semestre, o Sistema de Registro Acadêmico é notificado. 7. Após a matrícula, os estudantes podem, por um certo prazo, utilizar o sistema para adicionar ou remover disciplinas. 8. Professores usam o sistema para obter a lista de alunos matriculados em suas disciplinas. 9. Todos os usuários do sistema devem ser validados. 96

97 SM: Identificando os casos de uso Uma universidade requisista um sistema de matrículas:. A universidade oferece vários cursos. 2. O Coordenador de um curso define as disciplinas que serão oferecidas pelo seu curso num dado semestre. 3. Várias disciplinas são oferecidas em um curso. 4. Várias turmas podem ser abertas para uma mesma disciplina. 5. Estudantes selecionam 4 disciplinas preferenciais e 2 alternativas. 6. Quando um estudante matricula-se para um semestre, o Sistema de Registro Acadêmico é notificado. 7. Após a matrícula, os estudantes podem, por um certo prazo, utilizar o sistema para adicionar ou remover disciplinas. 8. Professores usam o sistema para obter a lista de alunos matriculados em suas disciplinas. 9. Todos os usuários do sistema devem ser validados. 97

98 SM: Obtendo o Diagrama de Casos de Uso Sistema de Registro Acadêmico Listar alunos Professor Matricular em disciplinas Estudante Coodenador Definir disciplinas Sistema de Registro Acadêmico 98

99 SM: Especificando os casos de uso Caso de Uso Matricular em disciplinas (descrição detalhada) Ator Primário: Estudante Objetivo: Este caso de uso tem por objetivo processar a matrícula semestral de alunos de uma universidade. Precondições: Estudante deve possuir uma credencial no sistema. Condição de disparo: Cliente decide efetuar matricular em disciplinas. Fluxo Normal Estudante inicia a matrícula semestral, fornecendo sua credencial no sistema. 2 Estudante preenche um formulário eletrônico de matrícula e o submete para uma análise de consistência. Sistema verifica se a credencial do aluno é válida. Sistema solicita que o estudante realize sua matrícula, selecionando 4 disciplinas preferenciais e 2 alternativas. Sistema analisa as informações contidas no formulário. Estudante é incluído em turmas abertas de 4 disciplinas, iniciando pelas preferenciais. Sistema de Registro Acadêmico é notificado. 99

100 SM: Especificando os casos de uso Fluxo Alternativo: credencial inválida a Estudante fornece credencial inválida. Sistema notifica que credencial é inválida e solicita que Estudante forneça uma nova credencial. b Retorna ao passo. Fluxo Alternativo: credencial inválida 2a Estudante especifica matrículas em disciplinas com turmas fechadas ou nãodisponíveis. Sistema notifica que matrículas especificadas não estão disponíveis para ele. 2b Retorna ao passo 2. Prioridade, Versão, Tempo de Resposta, Freqüência de Uso: - Canal para Ator Primário: navegador de internet, sistema de ou equivalente. Atores secundários, Canal para Atores Secundários: - Questões em aberto: - 00

101 SM: Especificando o Modelo Conceitual Uma universidade requisista um sistema de matrículas:. A universidade oferece vários cursos. 2. O Coordenador de um curso define as disciplinas que serão oferecidas pelo seu curso num dado semestre. 3. Várias disciplinas são oferecidas em um curso. 4. Várias turmas podem ser abertas para uma mesma disciplina. 5. Estudantes especificam um formulário com 4 disciplinas preferenciais e 2 alternativas. 6. Quando um estudante matricula-se para um semestre, o Sistema de Registro Acadêmico (SRA) é notificado. 7. Após a matrícula, os estudantes podem, por um certo prazo, utilizar o sistema para adicionar ou remover disciplinas. 8. Professores usam o sistema para obter a lista de alunos matriculados em suas disciplinas. 9. Todos os usuários do sistema devem ser validados. 0

102 SM: Listando os candidatos a conceitos. Listar os candidatos a conceitos, identificando substantivos nos casos de uso e a partir do conhecimento do domínio: Professor Coordenador Estudante Universidade Disciplina Turma Curso FormularioMatricula AnalisadorMatricula SistemaRegistroAcademico ListaAlunos 02

103 SM: Acrescentando os relacionamentos 2. Desenhar os conceitos em um modelo, acrescentando os relacionamentos: Universidade..* FormularioMatricula 0..* é-processado-por AnalisadorMatricula Curso gerencia oferece coordena é-preenchido-por 0..*..* Disciplina..* é-definida-por Coordenador aluno Estudante está-matriculado-em * é-ministrada-por Turma 0..3 Professor 03

104 SM: Acrescentando os atributos 3. Acrescentar os atributos no modelo: Universidade FormularioMatricula é-processado-por 0..* é-preenchido-por AnalisadorMatricula gerencia 0..* Disciplina nome numcréditos..*..* oferece é-definida-por..* Curso coordena Coordenador aluno Estudante nome matricula está-matriculado-em * Turma código sala horário é-ministrada-por 0..3 Professor nome titulação 04

105 SM: Obtendo o Modelo Conceitual Universidade FormularioMatricula é-processado-por 0..* é-preenchido-por AnalisadorMatricula gerencia 0..* Disciplina nome numcréditos..*..* oferece é-definida-por..* Curso coordena Coordenador aluno Estudante nome matricula está-matriculado-em * Turma código sala horário é-ministrada-por 0..3 Professor nome titulação 05

106 SM: Acrescentando classes e métodos. Acrescentando elementos ao modelo a partir de diagramas de interação a fim de obter o diagrama de classes: :Formulario Matricula :Sistema Matricula :Analisador Matricula AnalisadorMatricula adicionar(aluno,disciplina) : submeter Formulario(f) 2: adicionar(a,d ) SistemaMatricula submeterformulario(formulario) Caso de Uso Matricular em disciplinas FormularioMatricula 06

107 SM: Obtendo o Diagrama de Classes SistemeRegistro Acadêmico Há algo a adicionar Por enquanto é só!!! ou alterar? 0..* FormularioMatricula é notificado por SistemaMatricula é-processado-por 0..* é-processado-por X submeterformulario (FormularioMatricula) gerencia AnalisadorMatricula adicionar(estudante, Disciplina) Universidade..* Curso é-preenchido-por gerencia oferece 0..*..* Disciplina é-definida-por nome numcréditos..* coordena Coordenador aluno Estudante nome matricula está-matriculado-em Turma código sala horário..* é-ministrada-por 0..3 Professor nome titulação 07

108 SM: Acrescentando navegabilidade 2. Acrescentando detalhes de navegabilidade: Disciplina gerencia 0..* AnalisadorMatricula public class AnalisadorMatricula { private Disciplina disciplinas[]; public AnalisadorMatricula() { } } public class Disciplina { // AnalisadorMatricula não aparece como atributo! public Disciplina() { } } 08

109 SM: Acrescentando dependências 3. Acrescentando dependências: Disciplina nome : Texto numcreditos: Inteiro definirnome(nome) obternome() definirnumcreditos(inteiro) obternumcreditos() AnalisadorMatricula adicionar(estudante, Disciplina) Estudante nome : Texto matricula : Inteiro definirnome(nome) obternome() definirmatricula(matricula) obtermatricula() Lembre-se: Existe relacionamento de dependência entre duas classes: - quando uma classe utiliza outra somente como parâmetro de entrada na assinatura de ao menos uma de suas operações; - quando uma classe utiliza outra somente como variável local de ao menos um de seus métodos. 09

110 SM: Acrescentando generalizações 4. Acrescentando generalizações: Usuario nome : Texto definirnome(nome) obternome() Estudante matricula : Inteiro definirmatricula(matricula) obtermatricula() Professor titulacao : Texto definirtitulacao(titulacao) obtertitulacao() Lembre-se: Atributos, operações e/ou relacionamentos comuns podem ser movidos para uma classe mais geral! 0

111 SM: Obtendo o Diagrama de Classes SistemeRegistro Acadêmico 0..* FormularioMatricula é notificado por SistemaMatricula é-processado-por submeterformulario (FormularioMatricula) gerencia AnalisadorMatricula Universidade..* Curso obterestudante(string) obterdisciplina(integer) aluno Estudante matricula: Inteiro obtermatricula() definirmatricula (Inteiro) Usuario nome: String obternome() definirnome (String) é-preenchido-por 3..0 adicionar(estudante, Disciplina) gerencia 0..*..* Disciplina nome: Texto numcréditos: Inteiro estacompleta() adicionar(estudante) está-matriculado-em..* 4 Turma código: Texto sala: Texto horário: Horario numalunos: Inteiro completa: Booleano estacompleta(): Boolean é-definida-por..* é-ministrada-por 0..3 oferece coordena Coordenador Professor titulação obtertitulacao() definirtitulacao (String)

112 Diagramas de Interação

113 Diagramas de Interação: Introdução É um termo genérico que se aplica a três tipos de diagramas que enfatizam interações entre objetos: seqüência: foco no na seqüência temporal das mensagens; colaboração: foco no relacionamento entre os objetos que trocam mensagens; atividade: visualizar o comportamento através de muitos casos de uso ou de muitas threads. Os objetivos de um diagrama de interação são: visualizar comportamento de vários objetos dentro de um único caso de uso, a partir das mensagens passadas entre eles; definir um contexto de caso de uso, estabelecer os objetos que interagem e seus relacionamentos. 3

114 Diagramas de Interação: Introdução Diagrama de seqüência: Interação enfatizando o tempo de seqüência. Mostra os objetos participando em interações de acordo com suas linhas de vida e as mensagens que trocam. Diagrama de colaboração: Interação enfatizando o relacionamento entre os objetos. Expressam informações bastante similares, mas de maneira diferente. Nosso foco é o diagrama de seqüência. 4

115 Diagramas de Seqüência: Introdução Como construir um diagrama de seqüência?. Escolher um caso de uso. 2. Identificar os objetos que fazem parte da interação. 3. Identificar o objeto que começa a interação. 4. Identificar as mensagens trocadas entre os objetos. 5. Identificar a sequência destas mensagens. 5

116 Diagramas de Seqüência: Visão Geral Os principais conceitos são: objetos, linhas de vida, mensagens e focos de controle. Tempo (top-down) ObjetoA condição de guarda mensagem síncrona [se novo] <<create>> ObjetoB objeto mensagem (caixa de) ativação valor de retorno <<destroy>> mensagem (auto delegação) símbolo de execução linha de vida 6

117 Diagramas de Seqüência: Objetos São apresentados na dimensão horizontal do diagrama. A ordem dos objetos não é considerada; ou seja, pode-se dispô-los de forma a tornar o diagrama mais legível. Objetos tem nomes na forma objeto:classe; por exemplo: joão:dentista :Floricultor (objeto floricultor não identificado). 7

118 Diagramas de Seqüência: Objetos joao:dentista jose Floricultor central Central Floricultura floricultor Petropolis Floricultor : enviarflores("rosas","maria","petropolis","rua x, 9"):boolean.: atendecidade("petropolis"):boolean.2:[se nao na cid...] getfloricultornacidade("petropolis"):floricultor.3: aceitaencomenda("rosas", "Rua X,9"):boolean 8

119 Diagramas de Seqüência: Linhas de Vida São apresentados na dimensão vertical do diagrama. Apresentam o tempo de vida dos objetos. Podem apresentar a ativação e desativação dos objetos, ou seja, se os objetos estão executando algo. Caixas de ativação podem ser empilhadas indicando chamadas recursivas (ver objeto jose no slide anterior) Podem representar a criação e a destruição de objetos. 9