Diagrama de Classes

Objetivos

Prover respostas para as seguintes

perguntas:

Em um nvel alto de abstrao, que

objetos constituem o sistema em
questo?

uais so as classes candidatas?

Como as classes do sistema esto

relacionadas entre si?

uais so as responsabilidades de cada

classe?
!odelo de Classes de "n#lise
$"n#lise do Domnio%

&epresenta termos do domnio do

neg'cio(

)d*ias, coisas, e conceitos no mundo

real(

Descreve o problema representado

pelo sistema a ser desenvolvido, sem
considerar caractersticas da soluo
a ser utilizada.
Classes

+ma classe descreve seus objetos

atrav*s de atributos e operaes.

"tributos correspondem ,s
in-orma.es que um objeto arma/ena(

Opera.es correspondem ,s a.es

que um objeto sabe reali/ar(

Detal0amento utili/ado depende do

est#gio de desenvolvimento e do nvel
de abstrao desejado(
E1emplo
"ssocia.es

Para representar o -ato de que objetos

podem se relacionar uns com os outros,
utili/amos associa.es(

+ma associao representa relacionamentos

que so -ormados entre objetos durante a
e1ecuo do sistema(

Embora as associa.es sejam representadas

entre classes do diagrama, tais associa.es
representam liga.es possveis entre os
objetos das classes envolvidas(
2otao para associa.es

2a +!3 associa.es so
representadas por uma lin0a que
liga as classes cujos objetos se
relacionam(
Participao

+ma caracterstica de uma associao

que indica a necessidade $ou no% da
e1ist4ncia desta associao entre
objetos(

" participao pode ser obrigatria ou

opcional.

5e o valor mnimo da multiplicidade de uma

associao * igual a 6 $um%, signi7ca que a
participao * obrigat'ria

Caso contr#rio, a participao * opcional(

"cess'rios para associa.es

" +!3 de7ne tr4s recursos de notao para

associa.es:
Nome da associao: fornece algum signifcado
semntico a mesma.
Direo de leitura: indica como a associao deve
ser lida
Papel: para representar um papel especfco em
uma associao.
Classe associativa

Classe que est# ligada a uma associao,

em ve/ de estar ligada a outras classes(

+sada quando duas ou mais classes esto

associadas, e * necess#rio manter
in-orma.es sobre esta associao(

5in8nimo: classe de associao

"ssocia.es n9#rias

De7ne9se o grau de uma associao como a

quantidade de classes envolvidas na
mesma.

2a notao da +!3, as lin0as de uma

associao n!ria se interceptam em um
losango.

2a grande maioria dos casos pr#ticos de

modelagem, as associa.es normalmente so
bin!rias.

uando o grau de uma associao * igual a

tr4s, di/emos que a mesma * tern!ria.
E1emplo de associao
tern#ria

2a notao da +!3, as lin0as de uma

associao n9#ria se interceptam em
um losango nomeado(
"ssocia.es re:e1ivas

"ssociao que representa liga.es entre objetos

que pertencem a uma mesma classe(

No indica que um objeto se associa a ele

prprio.

" de7nio de pap*is * importante para evitar

ambig;idades na leitura da associao(

Cada objeto tem um papel distinto na

associao(
"grega.es e Composi.es
5o assim*tricas, no sentido de que, se um objeto " *
parte de um objeto <, o objeto < no pode ser parte do
objeto "
Propagam comportamento, no sentido de que um
comportamento que se aplica a um todo automaticamente
se aplica ,s suas partes(

"s partes so normalmente criadas e destrudas pelo todo(

5e uma das perguntas a seguir -or respondida com um
sim, provavelmente 0# uma agregao onde = * todo e >
* parte(

X tem um ou mais Y?
Y parte de X?
E1emplo
"grega.es e composi.es 9
di-erenas

Destruio de objetos

2a agregao, a destruio de um objeto

todo no implica necessariamente na
destruio do objeto parte(

Pertin4ncia

2a composio, os objetos parte pertencem

a um ?nico todo(

Em uma agregao, pode ser que um

mesmo objeto participe como componente
de v#rios outros objetos(
"gregao e "ssociao

E1iste pouca di-erena sem@ntica

entre agregao e associao(

2a pr#tica, agregao * usada

raramente(
&estri.es sobre
associa.es
Aenerali/ao e
Especiali/ao

&elacionamentos entre classes(

Esses denotam rela.es de generalidade

ou especi7cidade entre as classes
envolvidas(

O conceito mam!ero mais genrico que o

conceito ser "umano.

O conceito carro mais espec#co que o

conceito veculo.

Esse * o c0amado relacionamento de

"erana.
Berminologia

subclasse X superclasse .

classe base X classe "erdeira .

classe de especializao X classe de

generalizao .

2otao de7nida pela +!3

Cerana de associa.es

2o somente atributos e opera.es, mas

tamb*m associa.es so 0erdadas pelas
subclasses(

2o e1emplo abai1o, cada subclasse est#

associada a Pedido, por 0erana(
Propriedade da Cerana

#ransitividade: uma classe em uma

"ierarquia "erda propriedades e
relacionamentos de todos os seus ancestrais.
" 0erana pode ser aplicada em v#rios nveis, dando
origem a "ierarquia de generalizao.
+ma classe que 0erda propriedades de uma outra
classe pode ela pr'pria servir como superclasse(

$ssimetria: dadas duas classes $ e %& se $

for uma generali'ao de %& ento % no
pode ser uma generali'ao de $.
Ou seja, no pode "aver ciclos em uma "ierarquia de
generalizao.
E1emplo de 0erana
Classes "bstratas

+sualmente, a e1ist4ncia de uma

classe se justi7ca pelo -ato de 0aver
a possibilidade de gerar inst@ncias
da mesma

Essas so as classes concretas.

2o entanto, podem e1istir classes

que no geram inst@ncias diretas(

Essas so as classes abstratas.

Classes "bstratas

Classes abstratas so utili/adas para

organi/ar e simpli7car uma 0ierarquia de
generali/ao(

Propriedades comuns podem ser

organi/adas e de7nidas em uma classe
abstrata a partir da qual as primeiras
0erdam(

5ubclasses de uma classe abstrata tamb*m

podem ser abstratas, mas a 0ierarquia deve
terminar em uma ou mais classes concretas(
2otao para classes
abstratas

2a +!3, uma classe abstrata *

representada com o seu nome em it$lico.

2o e1emplo a seguir, Conta<anc#ria *

uma classe abstrata(
Diagrama de Objetos

" +!3 de7ne um segundo tipo de

diagrama estrutural, o diagrama de
objetos(

Pode ser visto com uma inst@ncia de

diagramas de classes

&epresenta uma D-otogra7aE do sistema

em um certo momento(

e1ibe as liga.es -ormadas entre objetos

con-orme estes interagem e os valores dos
seus atributos(
E1emplo F Diagrama de
Objetos
P e d i d o
I t e m P e d i d o P r o d u t o
n o m e G H C a d e r n o ! H
d e s c r i o G H C a d e r n o e m e s p i r a l t a m a n 0 o m * d i o H
p r e o + n i t # r i o G I , J K
d e s c o n t o G 6 J
p r o d u t o L K : P r o d u t o
n o m e G H C a n e t a E 5 M H
d e s c r i o G H C a n e t a e s - e r o g r # 7 c a J m m H
p r e o + n i t # r i o G 6 , L K
d e s c o n t o G L
p r o d u t o 6 L : P r o d u t o
n o m e G H E s q u a d r o H
d e s c r i o G H E s q u a d r o d e a c r l i c o L K c m H
p r e o + n i t # r i o G L , N J
d e s c o n t o G 6 K
p r o d u t o K O : P r o d u t o
q u a n t i d a d e G L K
i t e m L : ) t e m P e d i d o
q u a n t i d a d e G P
i t e m 6 : ) t e m P e d i d o
q u a n t i d a d e G 6
i t e m N : ) t e m P e d i d o
d a t a G 6 N Q K R Q L K K L
0 o r a G 6 K : K K a m
P e d i d o 6 : P e d i d o
B*cnicas de )denti7cao de Objetos,
"tributos e !*todos

E1istem t*cnicas $de uso no

e1clusivo% usadas para identi7car
classes:

Categorias de Conceitos

"n#lise Be1tual de "bbott $%bbot &e'tual

%nal(sis)

"n#lise de Casos de +so

Categorias de Conceitos

Conceitos concretos: edi-cios, carros, salas de aula(

Papis desempen0ados por seres 0umanos:

pro-essores, alunos, empregados, clientes(

Eventos, ou seja, ocorr4ncias em uma data e em uma

0ora particulares: reuni.es, pedidos, aterrisagens,
aulas(

Lugares: #reas reservadas para pessoas ou coisas:

escrit'rios, 7liais, locais de pouso, salas de aula(

Organizaes: cole.es de pessoas ou de recursos:

departamentos, projetos, campan0as, turmas(

Conceitos abstratos: princpios ou id*ias no

tangveis: reservas, vendas, inscri.es, boleto(
"n#lise Be1tual de "bbott

)denti7car termos da narrativa de casos de

uso e documento de requisitos que podem
sugerir classes, atributos, opera.es(

Montes de in-ormao: documento de

requisitos, modelos do neg'cio, gloss#rios,
con0ecimento sobre o domnio(

2omes $substantivos e adjetivos% que

aparecem no mesmo so destacados(

"p's isso, os sin8nimos so removidos(

"n#lise Be1tual de "bbott
$cont(%

Cada termo remanescente se

encai1a em uma das situa.es a
seguir:

O termo se torna uma classeS

O termo se torna um atributoS

O termo no tem relev@ncia alguma

com o 5T(
"n#lise Be1tual de "bbott
$cont(%

B*cnica de identi7cao de opera.es e de

associa.es: destacar verbos no te1to(

Uerbos de ao $calcular, con7rmar, cancelar,

comprar, -ec0ar, estimar, depositar, sacar%
so opera.es em potencial(

Uerbos com sentido de DterE so potenciais

agrega.es ou composi.es(

Uerbos com sentido de DserE so

generali/a.es em potencial(

Demais verbos so associa.es em potencial(

"n#lise Be1tual de "bbott
$cont(%

O resultado $as classes candidatas% depende de

os documentos utili/ados como -onte serem
completos(

" t*cnica pode levar , identi7cao de diversas

classes candidatas que no geraro classes(

" an#lise do te1to de um documento pode no

identi7car uma classe importante(

Em linguagem natural, as varia.es ling;sticas

e as -ormas de e1pressar uma mesma id*ia so
bastante numerosas(
"n#lise de Casos de +so

Caso particular da "B"(

B*cnica preconi/ada pelo &+P(

Casos de uso como ponto de partida(

" reali/ao de um caso de uso *

responsabilidade de um conjunto de objetos que
devem colaborar para produ/ir o resultado
daquele caso de uso(

"plica9se a t*cnica para identi7car as classes

necess#rias , produo do comportamento que
est# documentado na descrio do caso de uso(
"n#lise de Casos de +so

Procedimento de aplicao:

Estudar a descrio te1tual de cada caso de uso

para identi7car classes candidatas(

Para cada caso de uso, o te1to $:u1os principal,

alternativos e de e1ceo, p's9condi.es e pr*9
condi.es% * analisado(

)denti7car classes que possam -ornecer o

comportamento do mesmo(

2a medida em que os casos de uso so

analisados, as classes so identi7cadas(

Pode9se categorizar as classes.

Categori/ao de Classes

Objetos de entidade : usualmente objetos

do domnio do problema

Objetos de -ronteira : atores interagem

com esses objetos

Objetos de controle : servem como

intermedi#rios entre objetos de -ronteira e
de entidade, de7nindo o comportamento
de um caso de uso espec7co(
Categori/ao de Classes

Categori/ao proposta por

Vacobson(

Possui correspond4ncia $mas no

equival4nciaW% com o padro de
arquitetura model*vie+*controller ,-./)

Estere'tipos na +!3: XboundarYZ,

XentitYZ, XcontrolZ
Objetos de Entidade

&eposit'rio para informaes e as regras de

neg(cio manipuladas pelo sistema.

&epresentam conceitos do domnio do neg'cio(

Caractersticas
2ormalmente arma/enam in-orma.es persistentes(
U#rias inst@ncias da mesma entidade e1istindo no sistema(
Participam de v#rios casos de uso(
E1emplo:
+m objeto 0edido participa dos casos de uso 1ealizar
0edido e %tualizar 2stoque.
Este objeto pode e1istir por diversos anos ou mesmo tanto
quanto o pr'prio sistema(
Objetos de Mronteira

Comunicao do sistema com os atores(

tradu/em os eventos gerados por um ator em

eventos relevantes ao sistema
tamb*m so respons#veis por apresentar os
resultados de uma interao dos objetos(

E1istem para que o sistema se comunique com

o mundo e1terior(

C# dois tipos principais de objetos de -ronteira:

Os que se comunicam com o usu#rio $atores

0umanos%: relat'rios, inter-ace gr#7ca(
Os que se comunicam com atores no90umanos
Objetos de Controle

5o a Dponte de comunicaoE entre objetos de

-ronteira e objetos de entidade(

&espons#veis por controlar a l'gica de e1ecuo

correspondente a casos de uso(

Decidem o que o sistema deve -a/er quando um

evento de sistema ocorre(

"gem como controladores dos outros objetos para a

reali/ao de um caso de uso(

Bradu/em eventos de sistema em operaes

que devem ser realizadas pelos demais
objetos.
)mport@ncia da
Categori/ao

" categori/ao <CE parte do

princpio de que cada objeto *
especialista em reali/ar um de tr4s
tipos de tare-a:

comunicar com atores $ronteira!"

manter as in-orma.es $entidade!"

coordenar a reali/ao de um caso de

uso $controle!.
)mport@ncia da
Categori/ao

" import@ncia dessa categori/ao

est# relacionada , capacidade de
adaptao a eventuais mudanas(

5e cada objeto tem atribui.es

espec7cas dentro do sistema, mudanas
podem ser menos comple1as e mais
locali/adas(

+ma modi7cao em uma parte do

sistema tem menos possibilidades de
resultar em mudanas em outras partes(
!odelo de "n#lise no Processo
)terativo e )ncremental

Em um desenvolvimento dirigido a
casos de uso, ap's a descrio dos
casos de uso, * possvel iniciar a
identi7cao de classes(

"s classes identi7cadas so re7nadas

para retirar inconsist4ncias e
redund@ncias(

"s classes so documentadas e o

diagrama de classes inicial *
construdo(
!odelo de "n#lise no Processo
)terativo e )ncremental $cont(%

"s constru.es do modelo de casos de uso

e do modelo de classes so retroativas
uma sobre a outra(

2ovos casos de uso podem ser identi7cados

Pode9se identi7car a necessidade de

modi7cao de casos de uso pree1istentes(

Depois que a primeira verso do modelo de

classes de an#lise est# completa, retornar
ao modelo de casos de uso e veri7car a
consist4ncia entre os dois modelos(
!odelo de "n#lise no Processo
)terativo e )ncremental $cont(%
Classes de Projeto

O modelo de classes de projeto

resultante de re#namentos no modelo de
classes de an$lise.

Esse modelo * construdo em paralelo com o

modelo de interaes.

" construo do modelo de interaes gera

inormaes para a transorma%o do modelo
de classes de an$lise no modelo de classes de
projeto.

O modelo de classes de projeto cont*m detal0es

?teis para a implementa%o das classes.
"spectos a considerar na -ase de projeto

"dio de novas classes ao modelo

Especi7cao de atributos,
opera.es e de associa.es

Descrever re7namentos e conceitos

relacionados , 0erana, classes
abstratas, )nter-aces, polimor7smo(
Especi7cao de classes de
-ronteira

2o atribuir a essas classes

responsabilidades relativas , l'gica do
neg'cio(

Classes de -ronteira devem apenas servir

como:

Ponto de captao ou

Ponto de apresentao de in-orma.es(

" ?nica intelig4ncia que essas classes

devem ter * a que permite a elas reali/arem
a comunicao com o ambiente do sistema(
Especi7cao de classes de
-ronteira $cont(%

C# diversas ra/.es para isso:

5e o sistema tiver que ser implantado

em outro ambiente, as modi7ca.es
resultantes sobre seu -uncionamento
seriam mnimas(

O sistema pode dar suporte a diversas

-ormas de interao com seu ambiente(

Essa separao resulta em mel0or

coeso.
Especi7cao de classes de
-ronteira $cont(%

Durante a an#lise, considera9se que

0# uma ?nica classe de -ronteira
para cada ator(

2o projeto, algumas dessas classes

podem resultar em v#rias outras(
Especi7cao de classes de
-ronteira $cont(%

Clientes TE< cl#ssicos

Classes de -ronteira so p#ginas CB!3(

Clientes stand9alone

&ecomend#vel que os desenvolvedores

pesquisem os recursos -ornecidos pelo
ambiente de programao sendo
utili/ado( E1( 5[ingQVMC
Especi7cao de classes de
-ronteira $cont(%

" maioria das classes de entidade

normalmente permanece na passagem
da an#lise ao projeto(

Classes de entidade so normalmente

as primeiras classes a serem
identi7cadas, na an#lise de domnio(

Deve9se identi7car quais delas geram

objetos que devem ser persistentes(
Especi7cao de classes de
-ronteira $cont(%

Como identi7car cada um de seus objetos

unicamente(

E1( um objeto da classe "luno * unicamente

identi7cado pelo valor de sua matrcula(

+m identifcador de implementao& que

no tem correspondente com atributo
algum do domnio& pode ser criado.

Possibilidade de manipular identi7cadores de

maneira uni-orme e e7ciente(

!aior -acilidade quando objetos devem ser

mapeados para um 5A<D&
Especi7cao de classes de
entidade

" maioria das classes de entidade

normalmente permanece na passagem
da an#lise ao projeto(

Classes de entidade so normalmente

as primeiras classes a serem
identi7cadas, na an#lise de domnio(

Deve9se identi7car quais delas geram

objetos que devem ser persistentes(
Especi7cao de classes de
entidade

Como identi7car cada um de seus

objetos unicamente(

E1( um objeto da classe "luno *

unicamente identi7cado pelo valor de sua
matrcula(

+m identifcador de
implementao& que no tem
correspondente com atributo
algum do domnio& pode ser criado.
Especi7cao de classes de controle

2ormalmente associado a um caso

de uso

O controle pode ser particionado em

duas ou mais outras classes para
controlar diversos aspectos da
soluo(

Evitar a criao de uma ?nica classe

com bai1a coeso e alto
acoplamento(
Especi7cao de classes de controle

E1emplos dos aspectos de uma

aplicao cuja coordenao * de
responsabilidade das classes de
controle:

produo de valores para

preenc0imento de controles da inter-ace
gr#7ca,

autenticao de usu#rios,

controle de acesso a -uncionalidades do

sistema
Especi7cao de classes de controle

&esponsabilidades de controlador de
caso de uso:

Coordenar a reali/ao de casos de uso(

5ervir como canal de comunicao entre

objetos de -ronteira e objetos de entidade(

Comunicar com outros controladores(

!apear a.es do usu#rio para mensagens a

serem enviadas a objetos de entidade(

!anipular e1ce.es provenientes das

classes de entidades(
Especi7cao de outras
classes

"l*m do re7namento de classes pree1istentes,

diversos outros aspectos demandam a
identi7cao de novas classes durante o projeto(

Persist4ncia de objetos
Distribuio e comunicao $&!), CO&<", DCO!%

"utenticaoQ"utori/ao

3ogging

Classes para testes $&est 3riven 3evelopment)

+so de bibliotecas" componentes e rame&or's

Concluso: a tare-a de identi7cao de classes

no termina na an#lise(
&e7namento de atributos e m*todos

Os atributos e m*todos de uma classe a

0abilitam a cumprir com suas
responsabilidades(

"tributos: permitem que uma classe

arma/ene in-orma.es necess#rias ,
reali/ao de suas tare-as(

!*todos: so -un.es que manipulam os

valores do atributos, com o objetivo de
atender ,s mensagens que o objeto
recebe(
5inta1e para atributos e
m*todos
\ o b t e r 2 o m e $ % : 5 t r i n g
\ d e 7 n i r 2 o m e $ i n u m 2 o m e : 5 t r i n g %
\ o b t e r D a t a 2 a s c i m e n t o $ % : D a t a
\ d e 7 n i r D a t a 2 a s c i m e n t o $ i n u m a D a t a : D a t a %
\ o b t e r B e l e - o n e $ % : 5 t r i n g
\ d e 7 n i r B e l e - o n e $ i n u m B e l e - o n e : 5 t r i n g %
\ o b t e r 3 i m i t e C r * d i t o $ % : ! o e d a
\ d e 7 n i r 3 i m i t e C r * d i t o $ i n u m 3 i m i t e C r * d i t o : : o a t %
\ o b t e r ) d a d e $ % : i n t
\ o b t e r u a n t i d a d e C l i e n t e s $ % : i n t
\ o b t e r ) d a d e ! * d i a $ % : : o a t
C l i e n t e
5ublin0ado: m*todoQatributo
est#tico
Q : atributo derivado
Uisibilidade

uali7cadores de visibilidade aplic#veis a

atributos tamb*m podem ser aplicados a
opera.es(

( visibilidade p)blica

* visibilidade protegida

+ visibilidade privativa

O real signi7cado depende da linguagem

de programao em questo(

O conjunto das opera.es p?blicas de uma

classe * c0amado de interace
Projeto de m*todos

!*todos de criao e destruio de

objetos

!*todos de acesso $get=Qset=%

Outros m*todos:

Ualores derivados, -ormatao,

converso,((((

"lguns m*todos devem ter uma

operao inversa 'bvia

0abilitar e desabilitarS tornarUisvel e

tornar)nvisvelS adicionar e removerS
Detal0amento de m*todos

Diagramas de interao -ornecem um

indicativo sobre como m*todos devem ser
implementados(

Como complemento, notas e1plicativas

tamb*m so ?teis no esclarecimento de
como um m*todo deve ser implementado(

O diagrama de atividades tamb*m pode

ser usado para detal0ar a l'gica de
-uncionamento de m*todos mais
comple1os(
)mplementao de
associa.es

C# tr4s casos, em -uno da

conectividade: 6:6, 6:2 e 2:!

Para uma associao 6:6 entre duas

classes " e < :

5e a navegabilidade * unidirecional no
sentido de " para <, * de7nido um atributo
do tipo < na classe "(

5e a navegabilidade * bidirecional, pode9se

aplicar o procedimento para as duas
classes(
Conectividade 6:6
Conectividades 6:2 e 2:!

Para uma associao 6:2 ou 2:! entre duas

classes " e <:

5o utili/ados atributos cujos tipos

representam cole.es de elementos(

] tamb*m comum o uso de classes

parametri/adas(
)d*ia b#sica: de7nir uma classe parametri/ada cujo
par@metro * a classe correspondente ao lado muitos
da associao.
Classe parametri/ada

+ma coleo pode ser representada

em um diagrama de classes atrav*s
uma classe parametrizada.

De-(: * uma classe utili/ada para

de7nir outras classes(

Possui opera.es ou atributos cuja

de7nio * -eita em -uno de um ou
mais par@metros(
Conectividade 6:2

Mormas alternativas para

representao de uma associao
cuja conectividade * 6:2(
Conectividade 6:2 $Cont%
Conectividade 2:!
Classes "ssociativas
Bipos de Cerana

Com relao , quantidade de

superclasses que certa classe pode
ter(

"erana m)ltipla

"erana simples
Opera.es polim'r7cas

+ma subclasse 0erda todas as propriedades de

sua superclasse que ten0am visibilidade
p?blica ou protegida(

Pode ser que o comportamento de alguma

operao 0erdada seja di-erente para a
subclasse(

2esse caso, a subclasse deve rede7nir o

comportamento da operao(

" assinatura da operao * reutili/ada(

!as, a implementao da operao $ou seja, seu

m*todo+ * diferente.
Opera.es polim'r7cas
$Cont%

Opera.es polim'r7cas so aquelas

que possuem mais de uma
implementao(

" assinatura * repetida na$s%

subclasse$s% para en-ati/ar a
rede7nio de implementao(

O objetivo de manter a assinatura *

garantir que as subclasses ten0am
uma inter-ace em comum(
Opera.es polim'r7cas
$Cont%

5e duas ou mais subclasses implementam

uma operao polim'r7ca, a mensagem
para ativar essa operao * a mesma para
todas essas classes(

2o envio da mensagem, o remetente no

precisa saber qual a verdadeira classe de
cada objeto, pois eles aceitam a mesma
mensagem(

" di-erena * que os mtodos da operao

so di!erentes em cada subclasse.
Opera.es polim'r7cas 9
e1emplo
Opera.es polim'r7cas
Opera.es polim'r7cas tamb*m podem
e1istir em classes abstratas(
Opera.es polim'r7cas
$cont%

Opera.es polim'r7cas implementam o

princ,pio do polimor#smo-

dois ou mais objetos respondem a

mesma mensagem de -ormas
di-erentes(
E1erccios

Para cada especi7cao a seguir,

projete dois diagramas de classes:

De an#lise

De projeto
Conven.es nesta disciplina

Classes de "n#lise
!*todos HsimplesH
"tributos sem tipo
"ssocia.es nomeadas
Cardinalidades de7nidas
Classes de entidade

Projeto
!*todos comple1os $relativos a duas ou mais classes%
!*todos com atributos e valores de retorno
"tributos com tipo $inclusive criados% e visibilidade
Classes de -ronteira e de controle $com m*todos%
Projetado duranteQap's os modelos din@micos

+m 7lme tem obrigatoriamente ao menos

uma c'pia, mas pode possuir diversas delas(

+ma c'pia re-ere9se e1clusivamente a um

determinado 7lme(

+m s'cio pode reali/ar muitas loca.es

enquanto permanecer s'cio da locadora, mas
uma locao re-ere9se unicamente a um
determinado s'cio

Cada locao deve obrigatoriamente

re-erenciar9se ao menos a uma c'pia de um
7lme, podendo re-erenciar9se a muitas
c'pias(

+ma c'pia pode ter sido locada diversas

ve/es, em *pocas di-erentes obviamente

!odelar a situao usando um

diagrama de classes: D+ma pessoa
ao longo da vida, tem v#rios
empregos, em empresas di-erentes(
Para a Previd4ncia, * importante
saber a data de admisso e a data
de resciso de contrato com cada
uma dessas EmpresasE
+m cliente pode possuir muitos animais, mas um animal
pertence a um ?nico cliente( " clnica precisa de in-orma.es a
respeito de cada cliente, como nome, endereo, e tele-one(
+m animal pertence a uma ?nica esp*cie, por*m podem 0aver
diversos animais cadastrados de uma determinada esp*cie(
] preciso manter in-orma.es a respeito de cada animal j#
tratado, como nome, se1o, idade e esp*cie
+m animal pode reali/ar diversos tratamentos, mas um
tratamento * reali/ado e1lusivamente por um animal(
Cada tratamento possui ao menos uma consulta, mas pode
possuir muitas consultas( +ma determinada consulta re-ere9se
e1clusivamente a um determinado tratamento( Cada consulta
deve arma/enar in-orma.es como a data em que -oi reali/ada, o
veterin#rio que atendeu o animal e o resumo da consulta(
+m veterin#rio pode reali/ar muitas consultas, por*m uma
consulta deve ser reali/ada por somente um veterin#rio
Em uma consulta podem ser marcados e1ames para o animal( O
n?mero de e1ames possveis em uma consulta * indeterminado,
mas precisa ser registrado(
+ma universidade possui dois tipos de -uncion#rios: pro-essores e
t*cnico9administrativos( uando so contratados, * necess#rio
cadastrar seu nome, tele-one, endereo, CPM $que deve ser v#lido%, e a
data de contratao $que tamb*m precisa ser validada%(
Para o pro-essor deve ser cadastrado tamb*m a titulao, #rea de
pesquisa, e o tipo de contrato $LK 0oras, IK 0oras ou Dedicao
e1clusiva%(
+m -uncion#rio possui obrigatoriamente um ?nico cargo( O cargo possui
um ttulo e um sal#rio( O sal#rio do cargo pode ser aumentado apenas
uma ve/ por ano(
+m pro-essor pode no ministrar disciplinas em um semestre, ou
ministrar at* no m#1imo N disciplinas(
" disciplina pertence a um curso, ou a v#rios cursos( Por e1emplo,
C#lculo 6 * uma disciplina ministrada em v#rios cursos di-erentes da
#rea de e1atas(
+m curso possui muitas disciplinas( Para o cadastro da disciplina, deve9
se in-ormar o nome da disciplina, a carga 0or#ria, e o tipo da disciplina(
+m curso pode ser de graduao ou de p's9graduao( O curso possui
um nome e uma #rea $e1( E1atas%( Cursos de p's9graduao podem ser
de L tipos lato ou stricto sensu(
Cursos stricto senso devem ter a nota da C"PE5 e a grande #rea a qual
pertencem(
Projetar um diagrama de classes para um sistema
simples de reserva e ocupao de quartos para um
0otel( O sistema deve arma/enar reservas -eitas por
um -uncion#rio de um ou mais quartos para um
determinado cliente( O -uncion#rio deve ser capa/
de: veri7car se um quarto est# ocupado ou no,
inserir ou alterar os dados de um cliente, reali/ar a
reserva de um quarto para um cliente( Considere os
atributos de todas as classes como privados( Cada
cliente e -uncion#rio deve possuir: nome, rg, CPM,
endereo, tele-one( Deve ser possvel identi7car a
quantidade de ocupa.es j# reali/adas pelos
clientes( +m quarto pode ser simples ou lu1o e deve
indicar o n?mero de camas e o tipo de cada uma
delas $solteiro ou casal%( Cada quarto deve ter
apenas um -rigobar, que tem um conte?do de
bebidas(