UML - Unified Modeling
Language
Álvaro Vinícius de Souza Coêlho
[email protected]
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
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
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
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
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
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çalho
Seqüê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çalho
Caso de Uso:
Atores:
Finalidade:
Visão Geral:
Tipo:
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)
3. Comportamento do Sistema
Seqüência Típica de Eventos
1.
2.
3.
Este caso de Uso começa
quando o usuário solicita
uma reserva
O usuário se identifica
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)
Dados da Reserva
Confirmação
Usuário
Reservar Livro
3. Comportamento do Sistema
• Associação
– Pode ser detalhada
Dados da Reserva
Confirmação
Usuário
Reservar Livro
Disponibilidade
do Livro
Verificar
Disponibilidade
Dados
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 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
3. Comportamento do Sistema
Seqüência Típica de Eventos
1.
2.
3.
Este caso de Uso começa
quando o usuário solicita
uma reserva
O usuário se identifica
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 - 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
3. Comportamento do Sistema
Seqüência Típica de Eventos
1.
2.
Este caso de Uso começa
quando o usuário solicita
uma reserva
O usuário passa o cartão 3.
e digita a senha
4.
O sistema consulta sua
situação no Banco de
Dados
O sistema mostra um
Menu
3. Comportamento do Sistema
Seqüência Típica de Eventos
5. O usuário
6. O sistema pede
solicita a opção
que ele indique
Reserva no
ou autor, ou
Menu
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 vaise 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
Reserva
-Nome
-Privilégio
-Status
-DataInício
-DataFim
-Data
Métodos
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
Reserva
-Nome
-Privilégio
-Status
-DataInício
-DataFim
-Data
Métodos
Métodos
Livro
-Título
-Ano
Métodos
4. Objetos e Classes
• Atributos de Classes
• E as novas:
Assunto
Autor
-Descrição
-Nome
-Nacionalidade
-DataNasc
Métodos
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
Autor
Livro
-Nome
-Nacionalidade
-DataNasc
-Título
-Editora
-Ano
Métodos
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
Autor
-Nome
-Nacionalidade
-DataNasc
Métodos
Escreve
-Título
-Editora
-Ano
Métodos
5. Associações entre Classes
• Podem haver (embora mais raras)
associações entre mais de duas classes
Cliente
-CPF
-Nome
Conta
Possui
Métodos
-Número
-Saldo
Métodos
Agência
-Nome
-Endereço
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
ReNaVaM
1
Possui
1
Métodos
Funcionário
-Nome
-Sexo
-DataAdmissão
Métodos
-Codigo
-EstadoOrigem
Métodos
Conjuge
1
Casado Com
1
-Nome
-Idade
Métodos
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
ReNaVaM
1
Métodos
Funcionário
-Nome
-Sexo
-DataAdmissão
Métodos
Possui
1
-Codigo
-EstadoOrigem
Métodos
Conjuge
1
Casado Com 0..1 -Nome
-Idade
Métodos
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
Trabalhador
0..1
Contrata
Métodos
Museu
-Nome
-Endereço
Métodos
*
-Matrícula
-Nome
Métodos
Quadros
0..1 Possui
0..* -Nome
-Autor
-Data
Métodos
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
Ag_Publicidade
*
Contrata
Métodos
Fornecedor
-Nome
-Endereço
Métodos
*
-Nome
-Telefone
Métodos
Peças
*
Dispõe de
0..* -Nome
-Autor
-Data
Métodos
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étodos
*
* Contrata
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 TodoParte 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
• Exemplo
Empresa
-Nome
-CNPJ
Setor
1..*
Métodos
Métodos
Passageiro
Vôo
-Empresa
-Distância
-Duração
Métodos
-Nome
-Ramal
*
-Nome
-CPF
Métodos
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 metaclasse).
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
Livro
-ISBN
-Encadernação
Volume
Métodos
-Localização
-Título
Periódico
Métodos
-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ãose também com os métodos
• Métodos definidos nas super-classes são
compartilhados entre todos os objetos das subclasses
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 superclasse
• 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
Disciplina
*
Cursou
*
-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
*
*
Cursou
-Nome
-Ementa
Métodos
1
Métodos
Disciplina
* Matriculou
-Período
-Nota
Métodos
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 ClassesEntidade
• 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ário
Usuário
Reserva
Reservar()
VerificaStatus(Usuário)
StatusUsuário
VerificaAcervo(Livro)
SituaçãoLivroAcervo
RespReserva
Publicação
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
Status=VerificaStatus(Usuário)
Usuário
Reservar(Publ)
RespReserva
Usuário
Reserva
Disponibilidade =
VerificaAcervo(Publ)
Publicação
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
Classe1
Classe1
Mensagem()
Classe2
Mensagem(Param1:tipo)
Classe2
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
Classe1
Ret=Mensagem(Param1:tipo)
Classe2
6. Interação entre Objetos
• Mensagens para a própria Classe (Self ou This
em Linguagens de Programação
Classe1
Msg()
Reservar(Publ)
RespReserva
Usuário
Reserva
Criar()
6. Interação entre Objetos
• Iteração: Usa-se um *. Possivelmente uma
cláusula de teste
Msg1()
Classe1
*(i=1..10) R=Mensagem()
Classe2
6. Interação entre Objetos
• Caso hajam múltiplas mensagens dentro da
mesma cláusula repete-se a cláusula de Iteração
Msg1()
Classe1
*(i=1..10) R1=MensagemA()
*(i=1..10) R2=MensagemB()
Classe2
Classe3
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
-Status
VerificaStatus()
Reserva
-DataInício
-DataFim
-Data
Reservar()
Publicação
-Título
-Autor
-Assunto
-Editora
-Ano
VerificaAcervo()
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
Num_Exemplares >= 0
Publicação
Disponível
Num_Exemplares = 0
Publicação não
Disponível
7. Transição de Estados
• Estados e Associações
• Estados também podem ser distinguidos pela
existência de certas associações
Professor
1
0..*
Curso
• Professor pode estar Ensinando (há associação)
ou Licensiado(não há)
7. Transição de Estados
• 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
Curso Aberto
Adicionar Aluno
Registro fechado
Curso Completado
8. Conclusão
•
•
•
•
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...
FIM!
Escher
“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