UML - Unified Modeling Language Álvaro Vinícius de Souza Coêlho

Apresentação em tema: "UML - Unified Modeling Language Álvaro Vinícius de Souza Coêlho"— Transcrição da apresentação:

1 UML - Unified Modeling Language Álvaro Vinícius de Souza Coêlho degas@uesc.br

2 Roteiro Histórico da Modelagem Decomposição Funcional Análise Estruturada Engenharia de Informação Análise Estruturada Moderna Abismo Análise / Projeto Orientação a Objetos

3 Roteiro UML Desenvolvimento em Espiral Acrescentando-se novas características a cada giro O Projeto Comportamento do Sistema Casos de Uso Casos de Uso Essenciais Casos de Uso Reais

4 Roteiro Objetos e Classes Como descobrir as Classes Análise dos Casos de Uso Classes Entidades Classes Fronteiriças Classes de Controle Atributos das Classes

5 Roteiro Associações entre Classes Associação Cardinalidade e Opcionalidade Associação Reflexiva Agregação Generalização Herança Simples Herança Múltipla Classe Associativa

6 Roteiro Interação entre Objetos Diagrama de Seqüência Diagrama de Colaboração Métodos e Mensagens Transição de Estados Estado Evento Transição Conclusão

7 1. Histórico da Modelagem Um dia alguém quis fazer um programa (provavelmente no ENIAC ou no UNIVAC) e não conseguiu terminá-lo. Era o problema da Administração da Complexidade Percebeu-se a necessidade de se fazer um estudo preliminar antes de qualquer ação.

8 1. Histórico da Modelagem À medida que se caminhou, os princípios de administração da complexidade foram sendo descobertos. Metodologias e Técnicas foram sendo desenvolvidas para atender a esses princípios

9 1. Histórico da Modelagem Decomposição Funcional –Um Sistema é uma Função –Composto de Funções –Sucessivamente até que a função seja de implementação básica ou trivial –Princípios Observados: Abstração Escala

10 1. Histórico da Modelagem Decomposição Funcional –Abordagem extremamente inteligente –Empírica – Aprende-se logo que se começa a programar –Reflete um importante aspecto da organização geral dos Sistemas Interfaces Processos Dados

11 1. Histórico da Modelagem Análise Estruturada –Enfoque no Fluxo de Dados –Científico: Ferramentas de Administração e de Desenvolvimento –DFD –Especificação de Processos –Transformação de Dados (Estados)

12 1. Histórico da Modelagem Análise Estruturada –Princípios Observados: Abstração Escala Comportamento

13 1. Histórico da Modelagem Engenharia de Informação –Enfoque: Informações –Entidades –Associações entre Entidades: Relacionamentos –Organização de Informações

14 1. Histórico da Modelagem Engenharia de Informação –Entidades Associativas –Supertipos e Subtipos –Atributos –MER – Poderosa ferramenta de Organização de Informações

15 1. Histórico da Modelagem Engenharia de Informação –Princípios Observados Abstração Herança Associação Métodos de organização Escala

16 1. Histórico da Modelagem Análise Estruturada Moderna –Incorporação da Engenharia de Informação na Análise Estruturada –DFD –MER –Referência Cruzada –Modelo de Dados e de Processos

17 1. Histórico da Modelagem Análise Estruturada Moderna –Princípios Observados: Abstração (de dados e de procedimentos) Herança Associação Métodos de Organização Escala Comportamento

18 1. Histórico da Modelagem Análise Estruturada Moderna –Problemas: Alguns princípios não observados O que modelar primeiro, Dados ou Processos? O projeto (??)

19 1. Histórico da Modelagem O Abismo Análise / Projeto –DFD, MER, Evento-Resposta, Diagrama de Contexto, Diagrama de Transição de Estados, Especificação de Processos – Tudo reflete O QUE –Objetivo, afinal, da Análise –Mas e o COMO?

20 1. Histórico da Modelagem O Abismo Análise / Projeto –Novas ferramentas. Abordagem distinta. –Mais um problema a ser Administrado? –Soluções: Mecanismos automáticos de construção dos artefatos de projeto Desenvolvimento de ferramentas aplicáveis tanto à Análise quanto ao Projeto

21 1. Histórico da Modelagem Orientação a Objetos –Aborda um Conceito – Composto de Informações conhecidas (atributos) e funções (métodos) Não há mais a necessidade de discutir o que se estuda antes, se Dados ou Processos –Os conceitos são Coisas do Domínio do Problema Recursos Computacionais Aplicável à Análise e ao Projeto

22 1. Histórico da Modelagem Orientação a Objetos –Implementa os princípios: Abstração Encapsulamento Herança Associação Comunicação com Mensagens Métodos de Organização Escala Comportamento

23 2. UML Não é um método. É uma linguagem. Modelo = Linguagem + Método Histórico –Início dos anos 90: Métodos Orientados a Objeto (Rumbaugh, Coad, Jacobson, etc.) –OMG (Object Management Group) Inicia um trabalho de Unificação –1997: UML vira padrão OMG

24 2. UML Desenvolvimento em Espiral –Concepção –Elaboração –Construção –Transição Para cada fase, diferentes artefatos

25 2. UML A cada volta –Novas características concebidas –Elaboração destas e correção das anteriores –Construção das partes novas/modificadas –Liberação de protótipos ou versões alfa e beta

26 2. UML O Projeto –Nas metodologias estruturadas: “Abismo” entre Análise e Projeto Diferentes artefatos Diferentes compromissos –Nas metodologias OO: Mesmos artefatos, acrescentados de objetos de projeto –Redução (supressão) do abismo

27 3. Comportamento do Sistema Visão das coisas que o sistema deve fazer Inicialmente uma visão superficial e simplificada A cada iteração deve ser ampliada e aprofundada

28 3. Comportamento do Sistema Casos de Uso (Use Cases) São descrições de eventos que ocorrem no sistema Um Ator interage com um sistema (ação e resposta) Pode ser descrito e/ou diagramado

29 3. Comportamento do Sistema Descrição de um Caso de Uso Mostrar sua seqüência típica de eventos Cabeçalho Seqüência Típica de Eventos 1.Este caso de Uso começa... 2.Ação do Ator3.Resposta do Sistema

30 3. Comportamento do Sistema Cabeçalho Caso de Uso: Atores: Finalidade: Visão Geral: Tipo:

31 3. Comportamento do Sistema Exemplo Caso de Uso: Reservar Livro na Biblioteca Atores: Usuário Finalidade: Reservar um tomo para uma pessoa Visão Geral: Um usuário solicita a reserva de um livro, que é feita em caso ded disponibilidade Tipo: (a se ver adiante)

32 3. Comportamento do Sistema Seqüência Típica de Eventos 1.Este caso de Uso começa quando o usuário solicita uma reserva 2.O usuário se identifica 3.O usuário aponta um tomo a ser reservado 4.O sistema verifica a disponibilidade e faz a reserva

33 3. Comportamento do Sistema Diagrama de Casos de Uso Ator Caso de Uso

34 3. Comportamento do Sistema Ator: –Interage com o Sistema –Tem uma identificação (um nome) Cliente

35 3. Comportamento do Sistema Ator: –Não é parte do sistema (entidade externa) –Interage com o sistema –Recebe informações do sistema –Ser humano, máquina, sensor, outro sistema

36 3. Comportamento do Sistema Caso de Uso –Sequencia de ações que o sistema executa –Padrão de comportamento –Acionado por um ator (evento) –Modela o diálogo: Atores-Sistema e Casos de Uso entre si –Invocado por um ator ou por outro caso de uso –Fluxo de eventos completo e consistente –Conjunto dos Casos de Uso = Situações possíveis de funcionamento do sistema

37 3. Comportamento do Sistema Exemplos

38 3. Comportamento do Sistema Associação –Conexão dinâmica entre Casos de Uso e atores –Unidirecionais (segue o fluxo) Usuário Reservar Livro Dados da Reserva Confirmação

39 3. Comportamento do Sistema Associação –Pode ser detalhada Usuário Reservar Livro Dados da Reserva Confirmação Verificar Disponibilidade Dados do Livro Disponibilidade do Livro

40 3. Comportamento do Sistema Associação –Qualquer semelhança com Diagrama de Contexto DFD (e as explosões das bolhas) –NÃO é mera coincidência –Ambas as ferramentas expressam processos e fluxo de informações (comportamento)

41 3. Comportamento do Sistema Casos de Uso Essenciais Expressam a essência do comportamento (similar à análise essencial) Independente de tecnologia

42 3. Comportamento do Sistema O mesmo Exemplo Caso de Uso: Reservar Livro na Biblioteca Atores: Usuário Finalidade: Reservar um tomo para uma pessoa Visão Geral: Um usuário solicita a reserva de um livro, que é feita em caso ded disponibilidade Tipo: Essencial

43 3. Comportamento do Sistema Seqüência Típica de Eventos 1.Este caso de Uso começa quando o usuário solicita uma reserva 2.O usuário se identifica 3.O usuário aponta um tomo a ser reservado 4.O sistema verifica a disponibilidade e faz a reserva

44 3. Comportamento do Sistema Casos de Uso Reais Expressam a implementação do comportamento (a encarnação em análise essencial) Visão da tecnologia

45 3. Comportamento do Sistema O Exemplo - Real Caso de Uso: Reservar Livro na Biblioteca Atores: Usuário Finalidade: Reservar um tomo para uma pessoa Visão Geral: Um usuário solicita a reserva de um livro, que é feita em caso ded disponibilidade Tipo: Real

46 3. Comportamento do Sistema Seqüência Típica de Eventos 1.Este caso de Uso começa quando o usuário solicita uma reserva 2.O usuário passa o cartão e digita a senha 3.O sistema consulta sua situação no Banco de Dados 4.O sistema mostra um Menu

47 3. Comportamento do Sistema Seqüência Típica de Eventos 5.O usuário solicita a opção Reserva no Menu 6.O sistema pede que ele indique ou autor, ou título ou assunto E a descrição segue como se pode imaginar

48 4. Objetos e Classes Objetos –Coisas que existem, e que são importantes para o domínio e as responsabilidades que se está considerando –À medida que os ciclos se fazem e a amplitude e profundidade das considerações aumentam, mais objetos são considerados

49 4. Objetos e Classes Objetos –Exemplos: O aluno José, ou João, ou Antônio O automóvel Monza placa MMX 1280 O avião Boeing 737-700 com 115 assentos e autonomia de 5000 nm A janela principal de um programa O botão Botão1 com os eventos associados a On Pressed

50 4. Objetos e Classes Classes –Descrição de objetos –Fôrma de se fazer um objeto –Visão geral dos aspectos dos objetos em intenção –Aumentam também de quantidade a cada ciclo

51 4. Objetos e Classes Classes –Exemplos Alunos Automóveis Aviões Janelas de Interface Botões

52 4. Objetos e Classes Representação –Uma classe possui um nome –Possui um conjunto de atributos (que terão valores específicos para cada objeto) –Possui um conjunto de métodos (que definem seu comportamento – independente da instância)

53 4. Objetos e Classes Em UML: Classe Atributos Métodos

54 4. Objetos e Classes Como descobrir as Classes As classes devem ser percebidas –Em entrevistas –Em descrições do domínio –Na observação –Enfim, nos processos Quem modela os processos?

55 4. Objetos e Classes Análise dos casos de uso Para sua descrição, os casos de uso se referem a “coisas” –Externas ao sistema – Os atores –Internas a ele – As classes (e os atributos)

56 4. Objetos e Classes Da descrição de um caso de uso tome os nomes das coisas (normalmente substantivos) –Exclua as referências a atores –O restante são candidatos a ser referências a classes e seus atributos

57 4. Objetos e Classes No Exemplo: –Um usuário solicita a reserva de um livro, que é feita em caso de disponibilidade Substantivos – Usuário, Reserva, Livro, Disponibilidade Tudo isso é Classe?

58 4. Objetos e Classes Usuário, Reserva e Livro parecem realmente ser. A Disponibilidade, a depender de como vai- se verificar se um livro possui ou não disponibilidade.

59 4. Objetos e Classes Duas opções –A classe Livro se refere a cada título, e Disponibilidade tem a ver com o número de volumes disponíveis – nesse caso é um atributo –A classe Livro se refere a cada volume, e Disponibilidade passa a ser a verificação (processo) de quantos estão disponíveis. E escolha depende das responsabilidades do Sistema

60 4. Objetos e Classes Classes Entidade –Modela objetos de caráter geralmente persistente –As entidades essenciais –Livro, Autor, Reserva, Empréstimo

61 4. Objetos e Classes Classe Fronteiriça –Modela a comunicação entre a vizinhança do sistema e suas operações internas. –Objetos de Interface –Formulário de Reserva, Janela de Menu –Em geral: Janelas, Relatórios, E-Mail, etc.

62 4. Objetos e Classes Classes de Controle –Modela o comportamento de controle específico para um ou mais Caso de Uso Cria, ativa e anula objetos controlados Controla a operação de objetos controlados Controla a concorrência de pedidos de objetos controlados Em muitos casos corresponde a implementação de um objeto intangível –Gerentes, Gestores, SGBDs, SOs, etc.

63 4. Objetos e Classes Atributos de Classes Para cada classe – sem perder de vista o Domínio do Problema e as Responsabilidades do Sistema: –O que é necessário para se executar os processos? –O que é necessário vir de ou ir para os atores? Deste conjunto encontrar e suprimir –Quais podem ser derivadas a partir de outras?

64 4. Objetos e Classes Atributos de Classes No exemplo: Usuário -Nome -Privilégio -Status Métodos Reserva -DataInício -DataFim -Data Métodos Livro -Título -Autor -Assunto -Editora -Ano Métodos

65 4. Objetos e Classes Atributos de Classes –Atributos que sugerem outras classes devem ser evitados Em reserva não cabe nem Livro nem Usuário –Atributos que devem ser transformados em Classes Referidos com mais especificidade em algum caso de uso Multi-Valorados

66 4. Objetos e Classes Atributos de Classes No exemplo: Assunto e Autor: Multivalorado. Editora: Referido especificamente num caso de uso hipotético “Adquirir Volumes” Usuário -Nome -Privilégio -Status Métodos Reserva -DataInício -DataFim -Data Métodos Livro -Título -Ano Métodos

67 4. Objetos e Classes Atributos de Classes E as novas: Autor -Nome -Nacionalidade -DataNasc Métodos Assunto -Descrição Métodos Editora -Nome -Endereço -Telefone -Contato Métodos

68 5. Associações entre Classes De modo geral uma classe representa um conceito bem estabelecido O Sistema, porém, é composto ded várias delas As classes podem se associar umas às outras A Associação modela uma dependência de idéias

69 5. Associações entre Classes De modo geral pode-se observar três grandes tipos de associação entre classes: –Associação (ou Relacionamento) –Agregação –Generalização

70 5. Associações entre Classes Associação Uma associação é a idéia de que a uma classe ocorre a existência de outra Ex: Professor – Aluno, Paciente – Médico, Livro - Autor.

71 5. Associações entre Classes Em UML uma associação é representada por uma linha conectando as classes relacionadas Livro -Título -Editora -Ano Métodos Autor -Nome -Nacionalidade -DataNasc Métodos

72 5. Associações entre Classes Uma associação deverá ser identificada por um nome (normalmente uma ação que uma classe exerce sobre a outra) Livro -Título -Editora -Ano Métodos Autor -Nome -Nacionalidade -DataNasc Métodos Escreve

73 5. Associações entre Classes Podem haver (embora mais raras) associações entre mais de duas classes Agência -Nome -Endereço Métodos Cliente -CPF -Nome Métodos Possui Conta -Número -Saldo Métodos

74 5. Associações entre Classes Cardinalidade: Uma associação é representada pelas quantidades envolvidas Há 3 tipos de cardinalidade: 1 para 1 As classes se relacionam, de forma que a cada instância de uma delas corresponderá uma e somente uma instância da outra

75 5. Associações entre Classes Exemplos: Veículo -Descrição -Ano Fabricação Métodos Possui ReNaVaM -Codigo -EstadoOrigem Métodos 11 Funcionário -Nome -Sexo -DataAdmissão Métodos Casado Com Conjuge -Nome -Idade Métodos 11

76 5. Associações entre Classes Um veículo qualquer (um Corsa 1999) possui um e somente um ReNaVaM (No3042384794908 da Bahia) e a recíproca é verdadeira. Para qualquer Veículo e qualquer ReNaVaM considerado. Um funcionário (Maria) casou com um e somente um Cônjuge (José) e a recíproca é verdadeira. Válido para qualquer Funcionário e qualquer Cônjuge considerado.

77 5. Associações entre Classes Opcionalidade A associação entre as classes possui importância também a respeito da opcionalidade. Dadas as condições de cardinalidade, é obrigatório que as classes estejam associadas sempre que ocorrerem? Ou pode haver caso delas ocorrerem sozinhas?

78 5. Associações entre Classes O mesmo exemplo: Veículo -Descrição -Ano Fabricação Métodos Possui ReNaVaM -Codigo -EstadoOrigem Métodos 11 Funcionário -Nome -Sexo -DataAdmissão Métodos Casado Com Conjuge -Nome -Idade Métodos 0..11

79 5. Associações entre Classes Um veículo qualquer (um Corsa 1999) possui um e somente um ReNaVaM (No3042384794908 da Bahia) e a recíproca é verdadeira. Todo veículo possui ReNaVaM e todo ReNaVaM é de um veículo Um funcionário (Maria) casou com ninguém ou com um e somente um Cônjuge (José) mas a recíproca não é verdadeira. Todo Cônjuge, porém, é casado com um Funcionário (ou não há sentido mantê-lo)

80 5. Associações entre Classes 1 para Vários As classes se relacionam, de forma que a cada instância de uma delas (chamada Dominante) corresponde várias instâncias da outra A opcionalidade também é relevante aqui

81 5. Associações entre Classes Exemplos Empresa -Nome -CNPJ Métodos Contrata Trabalhador -Matrícula -Nome Métodos *0..1 Museu -Nome -Endereço Métodos Possui Quadros -Nome -Autor -Data Métodos 0..*0..1

82 5. Associações entre Classes Uma empresa contrata um grupo de vários trabalhadores mas cada trabalhador só pode estar contratado por uma (ou nenhuma, para seu azar) única empresa. No caso do museu, ele pode ter nenhum ou vários quadros em seu acervo, e cada quadro só pode estar em um museu, ou mesmo em nenhum (Particular, Roubado, Perdido...)

83 5. Associações entre Classes Vários para Vários As classes se relacionam, de forma que a cada instância de uma delas corresponde várias instâncias da outra e vice-versa É o tipo de associação mais complexo de ser implementado em Bancos de Dados É, porém, o mais comum. A opcionalidade é relevante aqui, mais uma vez

84 5. Associações entre Classes Exemplos Empresa -Nome -CNPJ Métodos Contrata Ag_Publicidade -Nome -Telefone Métodos ** Fornecedor -Nome -Endereço Métodos Dispõe de Peças -Nome -Autor -Data Métodos 0..**

85 5. Associações entre Classes Uma empresa pode contratar (não é obrigatório) agências de publicidade, e possivelmente mais de uma (AmBev por exemplo). As agências, por sua vez, podem servir a algumas empresas ou a nenhuma (trabalhar com o governo, ou com políticos). Um fornecedor dispõe de várias peças, embora possivelmente nenhuma no momento, e as peças são ofertadas por vários fornecedores (no mínimo um) para que numa compra seja escolhido alguém.

86 5. Associações entre Classes Associação Reflexiva Também chamado de Auto-Relacionamento Uma classe poded se relacionar com... Ela Mesma! Um exemplo: Num sistema que controle empresas que prestam serviço a outrras.

87 5. Associações entre Classes Um banco, que é uma instância da classe Empresa, contrata uma Companhia de Segurança, e uma de Limpeza, mais duas instâncias de Empresa. Cada uma delas possui conta no banco, e podem se contratar mutuamente, ou ainda contratar empresas de viagem, publicidade, etc.

88 5. Associações entre Classes E assim sucessivamente. Como modelar isso? A semântica é que há uma classe empresa, que se relaciona com ela mesma, de forma que as empresas associadas ocorram quando se olhar para uma dessas. A cada empresa, pode haver uma ou mais empresas associadas (cardinalidade).

89 5. Associações entre Classes Fica assim: Empresa -Nome -Área -CNPJ -Endereço Métodos Contrata * *

90 5. Associações entre Classes Um exemplo interessante: Desta estrutura, qualquer grau de parentesco carnal pode ser derivado Pessoa -Nome -Sexo Métodos Progenitor * *

91 5. Associações entre Classes Agregação É uma especialização da Associação propriamente dita Reflete o fato de que um objeto é parte de outro Também é referido como relacionamento Todo- Parte por alguns autores como Coad e Yourdon

92 5. Associações entre Classes Este tipo de associação, na análise estrtuturada, era modelado por um relacionamento comum Em UML ganha semântica e notação específica Um Losango indica uma relação de agregação

93 5. Associações entre Classes Exemplo Empresa -Nome -CNPJ Métodos Setor -Nome -Ramal Métodos Vôo -Empresa -Distância -Duração Métodos Passageiro -Nome -CPF Métodos * 1..*

94 5. Associações entre Classes O losango cheio indica que o objeto parte não pode existir sem o objeto todo. O losango vazio indica que, apesar de ser parte dele, o segundo objeto pode existir sem o primeiro

95 5. Associações entre Classes O primeiro exemplo indica que uma empresa possui vários setores, no mínimo 1, e que os setores não podem existir sem uma empresa. O segundo exemplo aponta o fato de que um vôo pode ter vários passageiros, ou nenhum, e que podem haver passageiros em nenhum vôo

96 5. Associações entre Classes Generalização É um dos mais poderosos recursos da Orientação a Objeto O conceito é que um ou mais objetos podem ser agrupados sob uma égide comum. Por definição, os primeiros objetos são chamados de especializações (ou sub-classe) e o segundo de generalização (ou super-classe ou ainda meta- classe).

97 5. Associações entre Classes É uma modelagem de um aspecto comum na natureza: Vários exemplos –Mamífero Canino –Cão –Lobo Equino –Cavalo –...

98 5. Associações entre Classes Em UML uma relação de Generalização é expressa com um triângulo vazio na ponta da seta que indica a relação Volume -Localização -Título Métodos Livro -ISBN -Encadernação Métodos Periódico -Data -Período Métodos...

99 5. Associações entre Classes Herança A grande vantagem da Generalização O que há na Meta-Classe (ou no Meta-Objeto, por instância) é compartilhado pelas sub-classes –Atributos –Associações –Métodos

100 5. Associações entre Classes No exemplo, os atributos Localização e Título são compartilhados pelas classes Livro e Periódico (e outras que houverem) As relações que existirem entre Periódico e outras classes também são herdadas

101 5. Associações entre Classes Isso significa que um objeto da classe Livro, por ser um Volume, possui os atributos Localização e Título Um objeto da classe Periódico possui também os mesmos atributos Mas os atributos ISBN e Encadernação são específicos dos objetos da classe Livro E os atributos Data e Período são específicos dos da classe Periódico

102 5. Associações entre Classes Herança de Métodos Não vimos os métodos com detalhes até agora Mas a herança, nas relações de generalização, dão- se também com os métodos Métodos definidos nas super-classes são compartilhados entre todos os objetos das sub- classes

103 5. Associações entre Classes Acoplamento Dinâmico e Polimorfismo Uma chamada a um método que não é encontrado num objeto leva-o a buscá-lo na super-classe a que ele pertence Caso não encontre, ele prossegue na busca indefinidamente (ou retorna um erro de chamada) A esse processo dá-se o nome de Acoplamento Dinâmico

104 5. Associações entre Classes Por exemplo, na super-classe Volume pode-se definir o método AlarmeManutenção(). –AlarmeManutenção(): Informa que a última revisão das condições gerais daquele volume já venceu, e é necessário fazer outra para corrigir possíveis estragos, desgastes, etc. Nesse momento as classes Livro e Periódico passam a compartilhar juntas este método. Opcionalmente pode-se considerar um parâmetro, o que não traria grandes modificações

105 5. Associações entre Classes Mas uma observação mais cuidadosa pode revelar diferenças: –Á exceção dos periódicos, os volumes podem ser danificados em suas encadernações, e em suas fichas catalográficas, coisa que ele não tém. Isso sugere que o método AlarmeManutenção() seja implementado de forma diferente na Classe Periódico, embora permaneça igual nas demais

106 5. Associações entre Classes Isso faz surgir o método AlarmeManutenção() em periódico, que funcionará diferente do AlarmeManutenção() de Volume (e das dedmais Sub-Classes) A este mecanismo chama-se Polimorfismo

107 5. Associações entre Classes Herança Múltipla Embora seja raro, uma classe pode herdar atributos e/ou métodos de mais de uma super- classe A esse mecanismo denomina-se Herança Múltipla No caso de Herança Múltipla, Atributos e Métodos das Super-Classes devem ser distintos (ou deve-se estabelecer um método de distinção)

108 5. Associações entre Classes Como descobrir Generalizações Observar as classes Procurar por –Atributos em comum –Associações em comum –Métodos em Comum Num mesmo contexto semântico! –Nome numa classe Cliente e numa classe Peça não justifica subcategorizá-los numa mesma generalização!

109 5. Associações entre Classes Estabelecidos padrões comuns de atributos, associações e métodos, criar uma super-classe Incluir ali o que for comum aos objetos Deixar as características específicas em cada um deles

110 5. Associações entre Classes Caso a alguma classe não reste atributo nem associação nem método, esta deve ser excluída Caso todas as sub-classes sejam excluídas, extingue-se a generalização

111 5. Associações entre Classes Classe Associativa Em alguns casos, uma associação é importante por haver a necessidade de se manter –Atributos –Novas associações –Métodos (muito raro)

112 5. Associações entre Classes Para este caso, deve-se criar uma nova classe Oriunda de uma associação, portanto denominada Classe Associativa Por Exemplo uma associação entre as classes Alunos e Disciplina num histórico acadêmico

113 5. Associações entre Classes É interessante saber: –Que nota ele obteve –Em que período cursou E no caso de várias “tentativas”, todos os resultados (similares ao anterior) devem ser mantidos. Isso justifica a criação de uma Classe Associativa

114 5. Associações entre Classes Originalmente é: Aluno -Nome -Matrícula Métodos Cursou Disciplina -Nome -Ementa Métodos **

115 5. Associações entre Classes Pode ser: Aluno -Nome -Matrícula Métodos Disciplina -Nome -Ementa Métodos ** Cursou -Período -Nota Métodos

116 5. Associações entre Classes Ou ainda (com o uso de outra classe para o histórico) Aluno -Nome -Matrícula Métodos Disciplina -Nome -Ementa Métodos ** Cursou Métodos Matriculou -Período -Nota Métodos 1 *

117 6. Interação entre Objetos É com a interação entre objetos que se constrói as funcionalidades do sistema Cada ação de um sistema é um método, solicitado a um objeto Numa modelagem acurada, os casos de uso serão representativos das ações do sistema

118 6. Interação entre Objetos Para cada caso de uso haverá um método em classes fronteiriças para atendê-lo Estas classes, provavelmente, vão solicitar serviços de outras – provavelmente as Classes- Entidade No final, se houver uma rsposta a ser dada pelo sistema, um método de alguma classe fronteiriça será mais uma vez invocado.

119 6. Interação entre Objetos Existem duas formas de se representar a interação ente objetos em UML. O Diagrama de Seqüência e o Diagrama de Colaboração. O primeiro mostra a evolução da tarefa através dos objetos ao longo do tempo. O segundo é voltado para ilustrar a dependência entre objetos para cada tarefa

120 6. Interação entre Objetos Diagrama de Sequencia Usuário PublicaçãoReserva Reservar() VerificaStatus(Usuário) StatusUsuário VerificaAcervo(Livro) SituaçãoLivroAcervo RespReserva

121 6. Interação entre Objetos Este cenário atende ao caso de uso Solicitar Reserva Naturalmente a representação é para o caso essencial, pois para o caso real haveria a necessidade de se estabelecer as classes fronteiriças

122 6. Interação entre Objetos Os métodos de cada classe começam a aparecer VerificaStatus() na classe Usuário e VerificaAcervo() na classe Livro. Além, evidentemente, de Reservar() na classe Reserva

123 6. Interação entre Objetos Alguns métodos são chamados Puros, Intrínsecos ou Imediatos: –Criar() – Cria uma nova instância de uma classe –Associar() – Associa uma classe a outra –Destruir() – Exclui uma instância ded uma classe –PegaXXX(), FazXXX() – XXX é um atributo, são métodos que acessam atributos (para Ler ou Mudar seu valor) Estes métodos intrínsecos não precisam ser modelados

124 6. Interação entre Objetos A descrição de cada método pode ser feita em pseudo-código ou especificada formalmente. Os diagramas de colaboração propõem uma alternativa muitas vezes interessante

125 6. Interação entre Objetos Diagramas de Colaboração Usuário Publicação Reserva Reservar(Publ) Status=VerificaStatus(Usuário) Disponibilidade = VerificaAcervo(Publ) RespReserva

126 6. Interação entre Objetos Os diagramas de colaboração fornecem uma série de vantagens Mas não exprimem mui fielmente as complexidades de cada método no que tange ao código em si, independente de troca de mensagens

127 6. Interação entre Objetos Mensagens e Parâmetros Classe2Classe1 Mensagem() Classe2Classe1 Mensagem(Param1:tipo)

128 6. Interação entre Objetos Valor de Retorno Sintaxe geral de uma mensagem (os tipos são opcionais em modelos essenciais): Ret = msg(param1:tipo1,...):TipoRetorno Classe2Classe1 Ret=Mensagem(Param1:tipo)

129 6. Interação entre Objetos Mensagens para a própria Classe (Self ou This em Linguagens de Programação Classe1 Msg() Reserva Criar() Usuário Reservar(Publ) RespReserva

130 6. Interação entre Objetos Iteração: Usa-se um *. Possivelmente uma cláusula de teste Classe2Classe1 *(i=1..10) R=Mensagem() Msg1()

131 6. Interação entre Objetos Caso hajam múltiplas mensagens dentro da mesma cláusula repete-se a cláusula de Iteração Classe2Classe1 *(i=1..10) R1=MensagemA() Msg1() Classe3 *(i=1..10) R2=MensagemB()

132 6. Interação entre Objetos Não seria mais simples usar Para i=1 até 10 faça { R1 = Classe2.MensagemA() R2 = Classe3.MensagemB() } ??? Parece que muitas vezes é melhor seguir pela informalidade!!!!!

133 6. Interação entre Objetos A interação entre objetos é extremamente útil para ilustrar a troca de mensagens Por conseguinte, os métodos de cada classe Usuário -Nome -Privilégio -Status VerificaStatus() Reserva -DataInício -DataFim -Data Reservar() Publicação -Título -Autor -Assunto -Editora -Ano VerificaAcervo()

134 6. Interação entre Objetos A implementação (código) de cada método, qualquer que seja a linguagem, ainda é uma tarefa de criação acima de tudo

135 7. Transição de Estados Em muitos casos é interessante ilustrar o comportamento de uma certa classe Em UML isso é feito através do Diagrama de Transição de Estados (Grande Novidade...) O DTE descreve –o ciclo de vida de uma dada classe –os eventos que causam a transição de um estado para outro –as ações resultantes da mudança de estado

136 7. Transição de Estados Estado Uma das possíveis condições na qual o objeto pode existir Compreende todas as propriedades do objetos Em UML um estado é representado por um retângulo de bordas arredondadas

137 7. Transição de Estados Um Estado Nome do Estado

138 7. Transição de Estados Estados e Atributos Estados podem ser distinguidos pelos valores assumidos por certos atributos Publicação Disponível Num_Exemplares >= 0 Publicação não Disponível Num_Exemplares = 0

139 Estados e Associações Estados também podem ser distinguidos pela existência de certas associações Professor pode estar Ensinando (há associação) ou Licensiado(não há) 7. Transição de Estados 0..* 1 ProfessorCurso

140 Estados Especiais: –Inicial Único Obrigatório –Final Múltiplos (possivelmente) Opcional 7. Transição de Estados

141 Evento Uma ocorrência que acontece em algum ponto no tempo Pode modificar o estado de um objeto Pode gerar uma resposta 7. Transição de Estados

142 Transição É a mudança do estado atual para o estado subseqüente Resultado de algum estímulo O estado subseqüente pode ser igual ao estado original Pode ocorrer em resposta a um evento As transições rotuladas com o nome dos eventos 7. Transição de Estados

143 Exemplo 7. Transição de Estados Curso Aberto Curso Completado Adicionar Aluno Registro fechado

144 UML: Uma ferramenta poderosa Orientação a Objetos: Abordagem inteligente Não é melhor, não modela mais Mas é mais fácil e mais rápido 8. Conclusão

145 Problemas com a codificação ainda não resolvidos Problemas de gestão de desenvolvimento de sistema ainda não resolvidos Problemas de métrica de custos e tempo de desenvolvimento – mal foram tocados 8. Conclusão

146 A última palavra ainda não foi dada... 8. Conclusão

147 FIM! “As perspectivas de sobrevivência da raça humana eram bem maiores quando éramos indefesos contra os tigres do que hoje, indefesos que somos contra nós mesmos” Arnold Toynbee Escher