Análise e Projeto de Sistemas
Introdução ao Projeto Orientado a
Objeto com UML
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
1/58
Objetivos
Revisar os princípios do paradigma de
orientação a objetos
 Apresentar os conceitos de orientação a
objetos com a notação UML
correspondente
 Foco em aspectos estruturais: diagramas
de classes

CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
2/58
Características do projeto OO




A funcionalidade do sistema é expressa em termos de
serviços de objetos (agrupados em classes)
Áreas de dados compartilhadas são eliminadas. Objetos
se comunicam através de passagem de mensagens
Pela própria natureza, objetos podem ser distribuídos
Potencialmente, embutem características como
abstração, encapsulamento, information hiding,
modularidade e extensibilidade
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
3/58
Desenvolvimento orientado a objeto




Análise, projeto e programação orientados a objeto são
relacionados, mas são distintos
Análise orientada a objeto trata do desenvolvimento de
um modelo orientado a objeto do domínio da aplicação
(independente da implementação)
Projeto orientado a objeto trata do desenvolvimento de
um modelo orientado a objeto voltado para a
implementação dos requisitos
Programação orientada a objeto trata da realização de um
projeto orientado a objeto usando uma linguagem de
programação OO, como Java ou C++
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
4/58
Objeto

Modelo de um objeto real
 entidade
física, conceitual ou de software
Possui comportamento, estado e
identidade
 Exemplo: conta, funcionario, livro,
ponto de venda, ...

donut
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
5/58
Objetos em UML
: Conta
Apenas o nome da classe
contaSaque
contaSaque :
Conta
Apenas o nome do objeto
Nome da classe e do objeto
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
6/58
Classe


Descrições de objetos com
propriedades e comportamento
comuns
Abstração que




enfatiza o que é relevante
suprime o que não interessa
Classes são fábricas de objetos
Objetos são agrupados em
classes
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
7/58
Classes de Objetos

Quantas classes temos aqui?
Fonte: Rational
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
8/58
Classe em UML
Conta
Nome da Classe
Atributos
Operações
Conta
numero
saldo
credito()
debito()
getSaldo()
estrutura
comportamento
getNumero()
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
9/58
Classes: mais exemplos
Indivíduo
Indivíduo
código : long
sexo : char
nome : String
CIn-UFPE
Indivíduo
incluir()
atualizar()
Indivíduo
código : long
sexo : char
nome : String
incluir()
atualizar()
©2003, Alexandre Vasconcelos & Augusto Sampaio
10/58
Classes: atributos



Um atributo representa alguma propriedade que é
compartilhada por todos os objetos da classe
Os atributos descrevem os dados contidos nas instâncias
de uma classe
Em um dado momento, um objeto de uma classe conterá
valores para todos os atributos descritos na sua classe
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
11/58
Atributos: notação

Atributos podem ser identificados apenas com nomes
Conta
numero: integer
Saldo: real

Atributos podem ter seus tipos (ou classes) especificados e terem
valores padrão definidos
Parede
altura : real
largura : real
espessura : real
viga : boolean = false
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
12/58
Objetos com atributos valorados
Objeto
Valor do Atributo
Conta
: Conta
numero = 21.342-7
saldo = 875,32
numero
saldo
: Conta
numero = 23.025-1
saldo = 500,00
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
13/58
Classes: operações


Uma operação é uma abstração de algum serviço que se
pode requisitar a um objeto e que é compartilhado por
todos os objetos da classe
Um classe pode ter qualquer número de operações,
inclusive nenhuma
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
14/58
Operações: notação

Como para os atributos, pode-se especificar uma
operação apenas com seu nome
Especificação
das operações
Conta
credito()
debito()
getSaldo()
getNumero()

Pode-se também especificar a assinatura da operação:
seus parâmetros, o tipo desses parâmetros e o tipo de
retorno
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
15/58
Classes: visibilidade

+
#
-
Marcações de acesso podem ser usadas para especificar
o tipo de acesso permitido aos atributos e operações
público: todos os objetos do sistema podem usar
protegido: qualquer descendente
da classe pode usar
privado: somente a própria classe pode usar
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
16/58
Visibilidade no Rose
público
privado
protegido
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
17/58
Comunicação entre objetos


Conceitualmente, objetos se comunicam através da troca
de mensagens.
Componentes de uma mensagem



Nome do serviço requisitado pelo objeto que está fazendo a
chamada.
Informação requerida para executar o serviço e o nome de um
proprietário para o resultado do serviço.
Na prática, mensagens são normalmente implementadas
através de chamadas de procedimentos (operações)


Nome = nome do procedimento.
Informação = lista de parâmetros para o procedimento.
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
18/58
Exemplos de mensagem
// Chama um método associado a um objeto buffer que
// retorna o próximo valor no buffer
v = circularBuffer.Get () ;
// Chama o método associado ao objeto termostato
// que define a temperatura a ser mantida
thermostat.setTemp (20) ;
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
19/58
Componente
Parte não trivial, quase independente,
substituível de um sistema, que provê a
realização de (uma/um conjunto de)
interface(s)
 Exemplos

 um
código fonte
 um componente executáve
 tabelas de bancos de dados
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
20/58
Componentes em UML
Arquivo fonte
CIn-UFPE
<<EXE>>
Arquivo
executável
©2003, Alexandre Vasconcelos & Augusto Sampaio
21/58
Pacote




Mecanismo para organizar elementos em grupos
Facilita entendimento do sistema
Favorece modularidade e reuso em larga escala
Essencial para estruturar sistemas complexos
nome do
pacote
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
22/58
Subsistema

União de
 pacote
(agrupa outros elementos)
 classe (comportamento)
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
23/58
Subsistema em UML
<<subsystem>>
Nome do subsistema
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
24/58
Relacionamentos


Objetos e classes de objetos participam de
relacionamentos com outros objetos e classes de objetos
Tipos de relacionamento
 Associação
simples
agregação
composição
 Dependência
 Generalização
 Realização
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
25/58
Navegabilidade de um relacionamento


Em geral a navegação entre as classes de um
relacionamento é bi-direcional
Porém é possível limitá-la a apenas uma direção
Usuário
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
Senha
26/58
Multiplicidade de um relacionamento

Define quantos objetos participam do
relacionamento
O
número de instâncias de uma classe relacionada
a uma instância de outra classe
 Especificado
em cada uma das pontas do
relacionamento
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
27/58
Tipos de multiplicidade

Não especificada

Exatamente um

Zero ou mais

Muitos (mesmo que 0..*)

Um ou mais

Zero ou um
1..*

Intervalo determinado
0..1

Valores múltiplos
2..4
1
0..*
*
2, 4..6
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
28/58
Associação simples

Relação estrutural entre classes
Companhia
*
contrata
1..*
Empregado
0..*
1
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
29/58
Associação unária

Quando há um relacionamento de uma classe consigo
própria
Funcionário
1..*
1
gerencia
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
30/58
Relacionamentos e papéis

Nome de papéis são úteis para distinguir relacionamentos
entre o mesmo par de classes
Companhia
*
contrata
1..*
Empregado
+empregador
+subordinado
0..*
+chefe 1
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
31/58
Relacionamentos com atributos



Modela as propriedades associadas com um
relacionamento
Para indicar os atributos de um relacionamento, usamos
uma linha tracejada para unir o relacionamento às suas
propriedades
As propriedades devem ser representadas por uma
classe
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
32/58
Exemplo de relacionamento com atributo
Companhia
*
1..*
Empregado
+empregador
Trabalho
descrição
salário
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
33/58
Agregação

Uma forma especial de associação entre o todo e suas
partes, no qual o todo é composto das partes
Todo
Parte
Empresa
Departamento
Agregação
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
34/58
Composição




Uma forma mais forte de agregação
Há uma coincidência da vida das partes
Uma vez criada a parte ela irá viver e morrer com o todo
O “Todo” é responsável pelo gerenciamento da criação e
destruição das partes
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
35/58
Exemplo de Composição
Pedido
-codigo: Integer
-dataRecebido
-total: Currency
+confirmar()
+cancelar()
-calcularTotal():Currency
gerarNovoCodigo: String
*
Item de Pedido
-quantidade: Integer
-preco: Currency
*
Produto
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
36/58
Exemplo de diagrama de classe: Escola
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
37/58
Associação x Agregação x Composição

Composição ou agregação?
 Na

dúvida, use agregação!
Agregação ou associação?
 Na
CIn-UFPE
dúvida, use associação!
©2003, Alexandre Vasconcelos & Augusto Sampaio
38/58
Dependência

Dependências são relações de uso



mais fraco que associação
Uma dependência indica que mudanças em um
elemento (o “servidor”) podem afetar outro elemento (o
“cliente”)
Uma dependência entre classes indica que os objetos
de uma classe usam serviços dos objetos de outra
classe
Cliente
CIn-UFPE
Servidor
©2003, Alexandre Vasconcelos & Augusto Sampaio
39/58
Dependência

Pode existir relacionamento de dependência entre
vários elementos de UML
Classe
Cliente
Fornecedor
Cliente
Pacote
PacoteCliente
Componente
PacoteFornecedor
Fornecedor
Dependência
Fonte: Rational
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
40/58
Generalização (ou herança)



Uma generalização (também conhecida como herança) é
um relacionamento entre um elemento mais geral
(chamado de superclasse ou pai) e um mais específico
(chamado de subclasse ou filho)
Classes são organizadas numa hierarquia onde uma
super classe é uma generalização de uma ou mais sub
classes
Uma sub classe herda os atributos e operações de sua
super classe e pode adicionar seus próprios métodos ou
atributos
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
41/58
Herança simples

Classes herdando de apenas uma outra classe
Figura
cor
largura da linha
desenhar()
girar(graus)
selecionar()
Superclasse
(pai)
Subclasses
Círculo
raio
centro
desenhar()
Relacionamento
de Generalização
Retângulo
vertices
desenhar()
diagonal()
Quadrado
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
42/58
Herança múltipla

Classes herdando de mais de uma classe
Mamífero
AnimalVoador
Herança
múltipla
Cachorro
CIn-UFPE
Gato
Morcego
Passarinho
©2003, Alexandre Vasconcelos & Augusto Sampaio
Gaviao
43/58
Vantagens da herança


É um mecanismo de abstração que pode ser usado para
classificar entidades
É um mecanismo de reuso tanto em nível de projeto
como em nível de programação
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
44/58
Problemas com a herança



Classes de objeto não são auto-contidas. Elas não podem
ser entendidas sem a referência a suas super classes
Herança introduz complexidade e isso é indesejável,
especialmente em sistemas críticos
Herança múltipla: conflito de nomes
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
45/58
Realização e Interfaces


Realização é uma relação pela qual um
elemento especifica o contrato que outro
elemento deve implementar
A realização é um relacionamento entre uma
especificação de interface e sua implementação
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
46/58
Interface




Interfaces definem um tipo especificando apenas
a assinatura de seus métodos
Interfaces não possuem atributos e seus métodos
não têm corpo
Diferentemente das classes, as interfaces não
especificam nenhuma estrutura
Classes implementam interfaces

provêem implementação para os métodos especificados em uma
interface
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
47/58
Realização: notação
Realização
<<interface>>
Empregado
Empregado_Impl
verificarFicha()
calcularSalário()
Classe
Subsistema
Componente
Realização
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
48/58
Realização: outro exemplo
<<interface>>
ChaveKit
Apertar
Afrouxar
Porca8mm
Porca6mm
Porca4mm
Relacionamentos de realização
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
49/58
Realização: outro exemplo
Porca8mm
Porca6mm
ChaveKit
Porca4mm
Relacionamentos
de realização
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
50/58
Subsistemas x Componentes



Ambos encapsulam um
comportamento modelado por
interfaces
Subsistemas representam
componentes no modelo de projeto
Componentes são a realização
física dos subsistemas
Projeto
<<subsystem>>
Nome do
subsistema
Implementação
Nome do
componente
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
51/58
Classe abstrata
Classe abstrata é aquela que não possui
instância
 Em geral, possui pelo menos um método
abstrato
 Métodos abstratos não têm corpo

 subclasses
não abstratas são obrigadas a fornecer
uma implementação para eles
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
52/58
Classes, Interfaces e Classes Abstratas
Interfaces
• Assinaturas dos métodos
Classes
• Atributos
• Métodos
CIn-UFPE
Classes Abstratas
• Atributos
• Métodos
• Assinatura de Métodos
©2003, Alexandre Vasconcelos & Augusto Sampaio
53/58
Classes abstratas x Interfaces




Herança de tipos x herança de código
Classes descrevem propriedades fundamentais
de um objeto
Interfaces descrevem papéis desempenhados
por um objeto em determinadas situações
Interfaces são úteis para implementar herança
múltipla
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
54/58
Mecanismos adicionais de UML
Estereótipos
 Notas
 Propriedades (Tagged values)
 Restrições

CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
55/58
Estereótipos



Mecanismo utilizado para estender os
elementos de UML
Define um novo modelo de elemento em
termos de outro já existente
Como


criando um novo ícone
utilizando a notação <<novo_elemento>>
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
56/58
Estereótipos: exemplo

Classes de fronteira:
<<boundary>>
ClasseFronteira
ClasseFronteira
CIn-UFPE
©2003, Alexandre Vasconcelos & Augusto Sampaio
57/58
Notas

Anotação utilizada para adicionar informação a
diagramas


Pode ser afixada a qualquer elemento de UML
Pode ser ligada a um elemento com uma linha tracejada
Exemplo:
LeitoraCartao
CIn-UFPE
Esta classe é uma abstração do
dispositivo de hardware que
será usado para ler
efetivamente as informações do
cartão magnético.
©2003, Alexandre Vasconcelos & Augusto Sampaio
58/58
Propriedades (Tagged Values)


Servem para estender elementos UML, adicionando
informações sobre eles
Exemplos já definidos em UML:



Persistence (valores: persistent, transient)
Location (ex. de valores: client, server)
Você pode criar suas próprias propriedades
Cliente
{persistence=persistent}
CIn-UFPE
: LeitoraCartao
{location=server}
©2003, Alexandre Vasconcelos & Augusto Sampaio
59/58
Restrições


Usadas para criação de novas regras sobre
elementos do modelo
Ou modificação de regras existentes
Funcionário
Pessoa
1..*
Diretor
3
CIn-UFPE
1
Empresa
{subset}
1
©2003, Alexandre Vasconcelos & Augusto Sampaio
60/58