UML - Unified Modeling Language
Álvaro Vinícius de Souza Coê[email protected]
Roteiro
Histórico da ModelagemDecomposição FuncionalAnálise EstruturadaEngenharia de InformaçãoAnálise Estruturada ModernaAbismo Análise / ProjetoOrientação a Objetos
Roteiro
UMLDesenvolvimento em EspiralAcrescentando-se novas características a cada giroO Projeto
Comportamento do SistemaCasos de UsoCasos de Uso EssenciaisCasos de Uso Reais
Roteiro
Objetos e ClassesComo descobrir as ClassesAnálise dos Casos de UsoClasses EntidadesClasses FronteiriçasClasses de ControleAtributos das Classes
RoteiroAssociações entre Classes
AssociaçãoCardinalidade e OpcionalidadeAssociação ReflexivaAgregaçãoGeneralizaçãoHerança SimplesHerança MúltiplaClasse Associativa
Roteiro
Interação entre ObjetosDiagrama de SeqüênciaDiagrama de ColaboraçãoMétodos e Mensagens
Transição de EstadosEstadoEventoTransição
Conclusão
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.
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
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
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
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)
1. Histórico da Modelagem
• Análise Estruturada– Princípios Observados:
• Abstração• Escala• Comportamento
1. Histórico da Modelagem
• Engenharia de Informação– Enfoque: Informações– Entidades– Associações entre Entidades: Relacionamentos– Organização de Informações
1. Histórico da Modelagem
• Engenharia de Informação– Entidades Associativas– Supertipos e Subtipos– Atributos– MER – Poderosa ferramenta de Organização de
Informações
1. Histórico da Modelagem
• Engenharia de Informação– Princípios Observados
• Abstração• Herança• Associação• Métodos de organização• Escala
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
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
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 (??)
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?
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
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
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
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
2. UML
• Desenvolvimento em Espiral– Concepção– Elaboração– Construção– Transição
• Para cada fase, diferentes artefatos
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
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
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
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
3. Comportamento do Sistema
• Descrição de um Caso de Uso• Mostrar sua seqüência típica de eventos
CabeçalhoSeqüência Típica de Eventos
1. Este caso de Uso começa...
2. Ação do Ator 3. Resposta do Sistema
3. Comportamento do Sistema
• CabeçalhoCaso de Uso:Atores:Finalidade:Visão Geral:Tipo:
3. Comportamento do Sistema
• ExemploCaso de Uso: Reservar Livro na BibliotecaAtores: UsuárioFinalidade: Reservar um tomo para uma pessoaVisão Geral: Um usuário solicita a reserva de um
livro, que é feita em caso ded disponibilidadeTipo: (a se ver adiante)
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
3. Comportamento do Sistema
• Diagrama de Casos de Uso
Ator Caso de Uso
3. Comportamento do Sistema• Ator:
– Interage com o Sistema– Tem uma identificação (um nome)
Cliente
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
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
3. Comportamento do Sistema• Exemplos
3. Comportamento do Sistema
• Associação– Conexão dinâmica entre Casos de Uso e atores– Unidirecionais (segue o fluxo)
Usuário
Reservar LivroDados da Reserva
Confirmação
3. Comportamento do Sistema
• Associação– Pode ser detalhada
Usuário
Reservar LivroDados da Reserva
Confirmação
Verificar Disponibilidade
Dados do Livro
Disponibilidade do Livro
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)
3. Comportamento do Sistema
• Casos de Uso Essenciais• Expressam a essência do comportamento
(similar à análise essencial)• Independente de tecnologia
3. Comportamento do Sistema
• O mesmo ExemploCaso de Uso: Reservar Livro na BibliotecaAtores: UsuárioFinalidade: Reservar um tomo para uma pessoaVisão Geral: Um usuário solicita a reserva de um
livro, que é feita em caso ded disponibilidadeTipo: Essencial
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
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
3. Comportamento do Sistema
• O Exemplo - RealCaso de Uso: Reservar Livro na BibliotecaAtores: UsuárioFinalidade: Reservar um tomo para uma pessoaVisão Geral: Um usuário solicita a reserva de um
livro, que é feita em caso ded disponibilidadeTipo: Real
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
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
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
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
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
4. Objetos e Classes
• Classes– Exemplos
• Alunos• Automóveis• Aviões• Janelas de Interface• Botões
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)
4. Objetos e Classes
• Em UML:
Classe
Atributos
Métodos
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?
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)
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
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?
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.
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
4. Objetos e Classes
• Classes Entidade– Modela objetos de caráter geralmente
persistente– As entidades essenciais– Livro, Autor, Reserva, Empréstimo
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.
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.
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?
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
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
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
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
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
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
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.
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
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
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
PossuiConta
-Número-Saldo
Métodos
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
5. Associações entre Classes
• Exemplos:
Veículo-Descrição-Ano Fabricação
Métodos
PossuiReNaVaM
-Codigo-EstadoOrigem
Métodos
11
Funcionário-Nome-Sexo-DataAdmissão
Métodos
Casado ComConjuge
-Nome-Idade
Métodos
11
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.
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?
5. Associações entre Classes
• O mesmo exemplo:
Veículo-Descrição-Ano Fabricação
Métodos
PossuiReNaVaM
-Codigo-EstadoOrigem
Métodos
11
Funcionário-Nome-Sexo-DataAdmissão
Métodos
Casado ComConjuge
-Nome-Idade
Métodos
0..11
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)
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
5. Associações entre Classes
• Exemplos
Empresa-Nome-CNPJ
Métodos
ContrataTrabalhador
-Matrícula-Nome
Métodos
*0..1
Museu-Nome-Endereço
Métodos
PossuiQuadros
-Nome-Autor-Data
Métodos
0..*0..1
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...)
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
5. Associações entre Classes
• Exemplos
Empresa-Nome-CNPJ
Métodos
ContrataAg_Publicidade
-Nome-Telefone
Métodos
**
Fornecedor-Nome-Endereço
Métodos
Dispõe dePeças
-Nome-Autor-Data
Métodos
0..**
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.
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.
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.
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).
5. Associações entre Classes
• Fica assim:
Empresa-Nome-Área-CNPJ-Endereço
MétodosContrata
*
*
5. Associações entre Classes
• Um exemplo interessante:• Desta estrutura, qualquer grau de parentesco
carnal pode ser derivado
Pessoa-Nome-Sexo
Métodos Progenitor
*
*
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
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
5. Associações entre Classes
• ExemploEmpresa
-Nome-CNPJ
Métodos
Setor-Nome-Ramal
Métodos
Vôo-Empresa-Distância-Duração
Métodos
Passageiro-Nome-CPF
Métodos
*
1..*
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
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
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).
5. Associações entre Classes• É uma modelagem de um aspecto comum na natureza:• Vários exemplos
– Mamífero• Canino
– Cão– Lobo
• Equino– Cavalo
– ...
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...
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
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
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
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
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
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
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
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
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)
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!
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
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
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)
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
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
5. Associações entre Classes
• Originalmente é:
Aluno-Nome-Matrícula
Métodos
CursouDisciplina
-Nome-Ementa
Métodos
**
5. Associações entre Classes
• Pode ser:
Aluno-Nome-Matrícula
Métodos
Disciplina-Nome-Ementa
Métodos
**
Cursou-Período-Nota
Métodos
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étodosMatriculou
-Período-Nota
Métodos
1 *
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
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.
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
6. Interação entre Objetos• Diagrama de Sequencia
UsuárioUsuário PublicaçãoReserva
Reservar()VerificaStatus(Usuário)
StatusUsuário
VerificaAcervo(Livro)
SituaçãoLivroAcervo
RespReserva
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
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
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
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
6. Interação entre Objetos
• Diagramas de Colaboração
Usuário
Usuário
Publicação
ReservaReservar(Publ)
Status=VerificaStatus(Usuário)
Disponibilidade =VerificaAcervo(Publ)
RespReserva
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
6. Interação entre Objetos
• Mensagens e Parâmetros
Classe2Classe1Mensagem()
Classe2Classe1Mensagem(Param1:tipo)
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
Classe2Classe1Ret=Mensagem(Param1:tipo)
6. Interação entre Objetos
• Mensagens para a própria Classe (Self ou This em Linguagens de Programação
Classe1Msg()
ReservaCriar()
Usuário
Reservar(Publ)RespReserva
6. Interação entre Objetos
• Iteração: Usa-se um *. Possivelmente uma cláusula de teste
Classe2Classe1*(i=1..10) R=Mensagem()
Msg1()
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()
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!!!!!
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-StatusVerificaStatus()
Reserva-DataInício-DataFim-DataReservar()
Publicação-Título-Autor-Assunto-Editora-AnoVerificaAcervo()
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
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
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
7. Transição de Estados
• Um Estado
Nome do Estado
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
• 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..*1Professor Curso
• Estados Especiais:– Inicial
• Único• Obrigatório
– Final• Múltiplos (possivelmente)• Opcional
7. Transição de Estados
• 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
• 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
• Exemplo
7. Transição de Estados
Curso AbertoCurso Completado
Adicionar Aluno
Registro fechado
• 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
• 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
• A última palavra ainda não foi dada...
8. Conclusão
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 ToynbeeEscher