Diagramas de Classes

2.
DI AGRAMAS DE CLASSES
Conceitos bsicos sobre os

diagramas de classes (os conceitos
mais avanados sero leccionados
em captulo posterior)
Bibliografia:
M. Fowler and K. Scott, UML Distilled: Applying the Standard
Object Modeling Language, Addison Wesley Longman, Inc., 1997.
P-A. Muller, Modlisation Objet avec UML, ditions Eyrolles,

Paris, 1997.
A. Dias de Figueiredo, 1997/78
Engenharia de Software, Departamento de Eng. Informtica, FCTUC
Acetato 1
OBJECTI VOS
u
Familiarizar com os aspectos mais elementares

do recurso a diagramas de classes.
Acetato 2
TPI COS COBERTOS

u
u
u
u
u
u
u
u
u
Diagramas de classes
Perspectivas dos diagramas de classes
Associaes
Atributos
Operaes
Visibilidade dos atributos e operaes
Generalizao
Restries
Quando usar os diagramas de classes
Acetato 3
1. Diagramas de classes
Os diagramas de classes decrevem:
as classes, caracterizadas pelos seus:
nome (ou identificador)

atributos
operaes
restrioes
os relacionamentos estticos entre as classes:

Associaes
Sub-tipos
Acetato 4
A classe representada no exemplo :
Rectngulo
Largura
Altura
rea ()
{rea <= 600}

identificada pelo nome

Rectngulo,
tem como atributos Largura e
Altura,
executa a operao rea (), a
partir dos atributos, e
est sujeita restrio {rea
<= 600} que restringe a 600
unidades o valor mximo das
reas a calcular.
Acetato 5
Encomenda
dataRecebida *
Prepaga
nmero: string
price: money
Despacha()
Fecha()
1
*
Linha de Encomenda
quantidade: inteiro
preo: money
estSatisfeita: Booleana
*
1
Produto
Exemplo de diagram de classes
Cliente
1
{Se Encomenda.cliente.regimeCrdito
fraco, ento Encomenda.Prepaga
tem que ser verdadeiro}
nome
endereo
regimeCrdito(): string
Cliente Institucional
Cliente Individual
nomeContacto
regimeCrdito
limiteCrdito
avisa ()
facturaParaMs (Inteiro)
*
tcnico de vendas 0..1
cartoCrdito#
{regimeCrdito()==
fraco}
Empregado
Acetato 6
2. Perspectivas dos diagramas de classes

As classes podem ser entendidas sob trs perspectivas:
Conceptual. A classe exprime um conceito abstracto no
domnio em estudo.
De especificao. A classe escrita pensando j em termos
de software, mas encarada de um ponto de vista exterior, e
no em termos de implementao (i.e., pensa-se nas
interfaces, mas no na sua caracterizao interna)
De implementao. A classe descrita pensando j na

forma como vai ser implementada.
Acetato 7
2. Perspectivas dos diagramas de classes
No caso da perspectiva conceptual, desenha-se a classe sem

pensar no tipo de implementao que vai ter (i.e., indpendente
da linguagem de programao que vai ser utilizada).
No caso da perspectiva de especificao, por vezes usado o

conceito de tipo para designar as interfaces quando ainda no se
pensou na sua forma de implementao, que pode ser variada.
De um modo geral, h vantagem em pensar mais na perspectiva

de especificao do que na perspectiva de implementao,
embora a segunda seja hoje em dia mais popular.
fundamental reconhecer sempre em que perspectiva se est a

desenhar, ou a ler, um diagrama de classes.
Acetato 8
3. Associaes
Representam relacionamentos entre instncias de
classes.
Ex.:
Professor
Disciplina
Acetato 9
3. Associaes
Na perspectiva conceptual:
h
As associaes representam relacionamentos conceptuais.
Cada associao tem dois papis (roles), que correspondem a

cada um dos dois sentidos do relacionamento.
No exemplo acima os papis so professor lecciona
disciplina e disciplina leccionada por professor
Um papel pode ser caracterizado explicitamente por uma

etiqueta que se coloca, em itlico, a meio, entre as duas classes.
Se no houver etiquetas, o papel fica caracterizado pela classe
de destino.
Acetato 10
3. Associaes
Na perspectiva conceptual (continuao):
h Um papel tem multiplicidade (ou cardinalidade).
No exemplo acima o par 1,*significa que cada professor
pode ensinar vrias diciplinas e que no h nenhuma
disciplina que possa ser ensinada por vrios professores.
As cardinalidades representam limites superiores.
h* significa qualquer valor ente zero e vrios,
h1 representa o valor 1,
h se se pretendesse dizer que possvel que alguns professores
no ensinem disciplina nenhuma, utilizava-se a notao 0..1
h outra notao possvel 1..*
Acetato 11
3. Associaes
Na perspectiva de especificao:
h
As associaes representam responsabilidades.

No diagrama da transparncia 6 isso significa, por exemplo,
que h um ou mais mtodos associados a Cliente que
definem que Encomenda(s) que um cliente fez.
Do mesmo modo, haver mtodos em Encomenda que me
informam de que Cliente fez determinada encomenda e de
que Linha(s) de Encomenda constituem uma Encomenda.
Estas responsabilidades no implicam, no entanto, estruturas de
dados. O diagrama exprime apenas as interfaces, e nada mais.
Acetato 12
3. Associaes
Na perspectiva de implementao:
h
As associaes exprimem agora a existncia de ponteiros nos

dois sentidos, entre as classes ligadas pela associao.
No diagrama da transparncia 6 isso significa, por exemplo,
que Encomenda tem um campo que uma coleco de
ponteiros para Linha(s) de Encomenda e tem um ponteiro a
apontar para Cliente.
A este nvel no se podem tirar, a partir das associaes,
quaisquer concluses acerca das interfaces. As operaes sobre
as classes que daro essa informao.
Acetato 13
3. Associaes
Navegabilidade
h
As associaes descrevem a rede de relaes estruturais que

existem entre as classes e que do origem s ligaes entre os
objectos, instncias dessas classes.
Essas ligaes podem ser vistas como canais de navegabilidade

entre objectos.
Por omisso, as associaes so navegveis nos dois sentidos,

mas em alguns casos s interessa um dos sentidos da
navegabilidade.
Acetato 14
3. Associaes
Navegabilidade (continuao)
h
Quando se pretende exprimir uma navegabilidade de um s

sentido recorre-se a uma seta colocada sobre o papel para o qual
a navegabilidade possvel.
O diagrama da transparncia 16 representa o diagrama da

transparncia 6 no qual se colocaram duas navegabilidades. A
que aponta de Encomenda para Cliente significa que
Encomenda tem a responsabilidade de dizer a que Cliente se
destina, mas Cliente no tem a responsabilidade de dizer que
Encomenda lhe corresponde.
Temos assim responsabilidades assimtricas.
Acetato 15
3. Associaes
Encomenda
dataRecebida *
Prepaga
nmero: string
price: money
Despacha()
Fecha()
1
*
Linha de Encomenda
quantidade: inteiro
preo: money
estSatisfeita: Booleana
*
1
Produto
Exemplo com navegabilidades
Cliente
1
{Se Encomenda.cliente.regimeCrdito
fraco, ento Encomenda.Prepaga
tem que ser verdadeiro}
nome
endereo
regimeCrdito(): string
Cliente Institucional
Cliente Individual
nomeContacto
regimeCrdito
limiteCrdito
avisa ()
facturaParaMs (Inteiro)
*
tcnico de vendas 0..1
cartoCrdito#
{regimeCrdito()==
fraco}
Empregado
Acetato 16
3. Associaes
h
A navegabilidade constitui um aspecto importante dos diagramas

de implementao e de especificao, mas no se pensa que
tenha qualquer interesse ao nvel conceptual.
frequente ver-se um diagrama conceptual que comea sem

navegabilidades e que depois se tranforma num diagrama de
especificao ou de implementao, pela introduo das
navegabilidades.
Tem-se uma associao unidireccional quando s h

navegabilidade num sentido e uma associao bidireccional
quando as navegabilidades so nos dois sentidos.
Acetato 17
3. Associaes
h
Uma associao sem setas entendida como uma associao

bidireccional, ou ento como uma associao cujas
navegabilidades ainda no foram definidas (no seio de um grupo
de trabalho deve-se decidir de antemo qual destas interpretaes
se adopta; para o caso dos diagrams de especificao e de
implentao mais frequente adoptar-se a segunda).
Se uma associao bidireccional, isso significa que os dois

papis so inversos um do outro (tal como numa funo inversa,
em Matemtica). Esta propriedade vlida nas trs perspectivas
(conceptual, de especificao e de implementao).
Acetato 18
3. Associaes
Nomeao
h
Podemos atribur nomes , ou etiquetas, s associaes.
Os analistas tradicionais preferem usar nomes expressos por

formas verbais, quer activas (lecciona), quer passivas (
leccionada). Os analistas OO preferem usar substantivos, por
entenderem que exprimem melhor as responsabilidades e
operaes
Alguns analistas do nomes a todas as associaes. Outros

preferem s atribur nomes s associaes que tenham a ganhar,
em clareza, pela atribuio de um nome.
Acetato 19
4. Atributos
h
No caso mais geral, a notao para um atributo especifica o seu

nome (name), tipo (type) e valor por omisso (default value),
bem como a sua visibilidade (visibility). A sintaxe UML :
visibility name: type = defaultValue
O conceito de visibilidade que aqui se aplica o mesmo que

para as operaes (ver transparncias seguintes).
Os atributos tm sempre um valor nico de cada vez.
Em geral os diagramas no indicam se um atributo opcional

ou obrigatrio (embora, em rigr, devessem faz-lo).
Acetato 20
5. Operaes
h
As operaes correspondem aos mtodos da classe. A sintaxe

UML completa de uma operao a seguinte:
visibility name(parameter list): type =
return-type-expression {property-string}
onde:
h visibilidade tem o significado descrito nas transparncia seguintes,
h name uma cadeia de caracteres,
h parameter-list contm argumentos (opcionais) cuja sintaxe a mesma
dos atributos,
h return-type-expression uma especificao opcional,
h property-string indica valores de uma propriedade que se aplica
operao.
Acetato 21
5. Operaes
h
til distinguir entre operaes que alteram, e no alteram, o

estado de uma classe.
Uma interrogao (query) uma operao que obtem o
valor de uma classe sem alterar o seu estado observvel. As
operaes que alteram o estado observvel de uma classe so
denominadas modificadores.
As interrogaes podem ser executadas por qualquer ordem,
mas os modificadores exigem cuidados com a sua
sequenciao. O melhor no procurar obter valores a partir de
modificadores.
Acetato 22
5. Operaes
h
Outra designao frequente a de mtodos de obteno

(getting methods), que devolvem o valor de um campo (e no
fazem nada mais), e mtodos de fixao (setting methods),
que colocam um valor num campo (e no fazem nada mais).
Tambm se deve reconhecer a distino entre operao e
mtodo. Uma operao algo que se evoca sobre um objecto (a
chamada do procedimento), enquanto que um mtodo o corpo
do procedimento. frequente confundirem-se os dois, mas
importa notar que a operao no mais do que a chamada do
mtodo. Havendo polimorfismo, operao e mtodo so
distintos.
As linguagens de programao tendem a complicar mais a
distino: Em C++ as operaes so chamadas funes
membro, enquanto que em Smalltalk so chamadas mtodos.
Acetato 23
6. Visibilidade dos atributos e operaes

h
A UML define trs tipos de visibilidade para os atributos e

operaes:
h
pblica, (simbolizada pelo caracter +), que torna o

elemento visvel a todos os clientes da classe,
h protegida, (simbolizada pelo caracter #), que torna o
elemento visvel s sub-classes da classe,
h privada, (simbolizada pelo caracter -), que torna o
elemento visvel apenas prpria classe.
h
Embora nem sempre figure de maneira explcita nos diagramas

de classes, isso no significa que a visibilidade no seja definida
no modelo.
Acetato 24
7. Generalizao e sub-tipos
h
Em UML preferiu-se utilizar o termo generalizao em vez do

termo herana, j nosso conhecido. As classes obtidas por
herana so denominadas sub-tipos (excepto no caso dos
diagramas de implementao, em que so designadas por subclasses).
No diagrama da transparncia 6, distinguem-se os clientes
institucionais e os clientes individuais, que, tendo algumas
diferenas entre si, tm tambm algumas semelhanas. Essas
semelhanas podem ser colocadas na classe cliente (o
super-tipo) ficando as outras classes (os sub-tipos) com as
caractersticas que so diferentes.
Acetato 25
Tambm aqui se podem considerar trs perspectivas:
h
Na perspectiva conceptual podemos dizer, por exemplo, que

cliente institucional um sub-tipo de cliente se todas as
instncias de cliente institucional forem tambm, por
definio, instncias de cliente. A ideia chave que tudo o
que estabelecermos para cliente (associaes, atributos,
operaes) tambm vlido para cliente institucional.
Na perspectiva de especificao, a generalizao significa que a

interface do sub-tipo tem que incluir todos os elementos da
interface do super-tipo. Diz-se que a interface do sub-tipo est
conforme com a interface do super-tipo.
Acetato 26
h
Na perspectiva de implementao, a generalizao est

associada com o fenmeno da herana nas linguagens de
programao orientadas para objectos. Fala-se aqui de subclasses, e no de sub-tipos, e considera-se que a sub-classe
herda todos os mtodos e todos os campos da super-classe,
podendo os mtodos da sub-classe sobrepor-se aos mtodos
herdados.
Acetato 27
8. Restries
h
O prprio facto de se desenhar um diagrama de classes significa

que se esto a respeitar restries. Os conceitos de associao,
de atributo ou de generalizao so, afinal, formas de
especificar restries. No entanto, os conceitos chave dos
diagramas de classe no permitem exprimir todas as restries.
H restries que tm que ser expressas de forma explcita

porque no caem em nenhuma das categorias previstas nos
diagramas de classes. A sintaxe UML para exprimir restries
limita-se a indicar que devem ser colocadas entre {}. Tudo o
resto livre, podendo ser expressas numa pseudo-linguagem,
para enfatizar a legibilidade, ou ser traduzidas por instrues
em cdigo de programao.
Acetato 28
9. Quando usar os diagramas de classes

Os diagramas de classes so a espinha dorsal de praticamente todos
os mtodos orientados para objectos, e so por isso os mais usados.
So, no entanto, os mais ricos e complexos, pelo que se recomenda
o seu uso com alguns cuidados:
h No tentar usar todas as notaes disponves. Usar as mais
complexas (do captulo seguinte) apenas quando for
indispensvel.
h Adequar a perspectiva que se est a usar fase em que o
projecto se encontra (fazer diagramas conceptuais se se est a
fazer a anlise; de especificao se comea a pensar em
software; e de implementao apenas quando se quer ilustrar
uma soluo de implementao mais particular).
Acetato 29
9. Quando usar os diagramas de classes

h No desenhar modelos para tudo; prefervel concentrarmonos nas reas chave. melhor ter poucos diagramas que se
vo actualizando quando necessrio do que ter muitos
diagramas que se vo tornando obsoletos por falta de
actualizao.
h Evitar a todo o custo comear a pensar nos promenores de
implementao demasiado cedo. Para o conseguir, procurar
concentrar a ateno nas perspectivas de concepo e de
especificao.
Acetato 30

Diagramas de Classes

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Diagramas de Classes

Enviado por

Direitos autorais:

Formatos disponíveis

2.

Conceitos bsicos sobre os

P-A. Muller, Modlisation Objet avec UML, ditions Eyrolles,

A. Dias de Figueiredo, 1997/78

Engenharia de Software, Departamento de Eng. Informtica, FCTUC

Familiarizar com os aspectos mais elementares

A. Dias de Figueiredo, 1997/78

Engenharia de Software, Departamento de Eng. Informtica, FCTUC

TPI COS COBERTOS

A. Dias de Figueiredo, 1997/78

Engenharia de Software, Departamento de Eng. Informtica, FCTUC

nome (ou identificador)

os relacionamentos estticos entre as classes:

Engenharia de Software, Departamento de Eng. Informtica, FCTUC

{rea <= 600}

identificada pelo nome

Engenharia de Software, Departamento de Eng. Informtica, FCTUC

Exemplo de diagram de classes

A. Dias de Figueiredo, 1997/78

Engenharia de Software, Departamento de Eng. Informtica, FCTUC

2. Perspectivas dos diagramas de classes

De implementao. A classe descrita pensando j na

A. Dias de Figueiredo, 1997/78

Engenharia de Software, Departamento de Eng. Informtica, FCTUC

2. Perspectivas dos diagramas de classes

No caso da perspectiva conceptual, desenha-se a classe sem

No caso da perspectiva de especificao, por vezes usado o

De um modo geral, h vantagem em pensar mais na perspectiva

fundamental reconhecer sempre em que perspectiva se est a

Engenharia de Software, Departamento de Eng. Informtica, FCTUC

A. Dias de Figueiredo, 1997/78

Engenharia de Software, Departamento de Eng. Informtica, FCTUC

As associaes representam relacionamentos conceptuais.

Cada associao tem dois papis (roles), que correspondem a

Um papel pode ser caracterizado explicitamente por uma

A. Dias de Figueiredo, 1997/78

Engenharia de Software, Departamento de Eng. Informtica, FCTUC

Engenharia de Software, Departamento de Eng. Informtica, FCTUC

As associaes representam responsabilidades.

A. Dias de Figueiredo, 1997/78

Engenharia de Software, Departamento de Eng. Informtica, FCTUC

As associaes exprimem agora a existncia de ponteiros nos

A. Dias de Figueiredo, 1997/78

Engenharia de Software, Departamento de Eng. Informtica, FCTUC

As associaes descrevem a rede de relaes estruturais que

Essas ligaes podem ser vistas como canais de navegabilidade

Por omisso, as associaes so navegveis nos dois sentidos,

A. Dias de Figueiredo, 1997/78

Engenharia de Software, Departamento de Eng. Informtica, FCTUC

Quando se pretende exprimir uma navegabilidade de um s

O diagrama da transparncia 16 representa o diagrama da

Temos assim responsabilidades assimtricas.

A. Dias de Figueiredo, 1997/78

Engenharia de Software, Departamento de Eng. Informtica, FCTUC

Exemplo com navegabilidades

A. Dias de Figueiredo, 1997/78

Engenharia de Software, Departamento de Eng. Informtica, FCTUC

A navegabilidade constitui um aspecto importante dos diagramas

frequente ver-se um diagrama conceptual que comea sem

Tem-se uma associao unidireccional quando s h

A. Dias de Figueiredo, 1997/78

Engenharia de Software, Departamento de Eng. Informtica, FCTUC

Uma associao sem setas entendida como uma associao

Se uma associao bidireccional, isso significa que os dois