parte7 - diagrama de classes.pptx

8/16/2019 Parte7 - Diagrama de Classes.pptx

1/90

Diagrama de Classes


2/90

Objetivos

• Prover respostas para as seguintesperguntas: – Em um nível alto de abstração, que

objetos constituem o sistema emquestão?

– uais são as classes candidatas? –

Como as classes do sistema estãorelacionadas entre si? – uais são as responsabilidades de cada

classe?


3/90

!odelo de Classes de "n#lise$"n#lise do Domínio%

• &epresenta termos do domínio doneg'cio(

• )d*ias, coisas, e conceitos no mundoreal(

• Descreve o problema representado pelo sistema a ser desenvolvido, semconsiderar características da soluçãoa ser utilizada.


4/90

Classes•

+ma classe descreve seus objetosatrav*s de atributos e operações. – "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 nívelde abstração desejado(


5/90

E1emplo


6/90

"ssociaç.es

• Para representar o -ato de que objetospodem se relacionar uns com os outros,utili/amos associaç.es(

•

+ma associação representa relacionamentosque são -ormados entre objetos durante ae1ecução do sistema(

• Embora as associaç.es sejam representadas

entre classes do diagrama, tais associaç.esrepresentam ligaç.es possíveis entre osobjetos das classes envolvidas(


7/90

2otação para associaç.es

• 2a +!3 associaç.es sãorepresentadas por uma lin0a queliga as classes cujos objetos serelacionam(


8/90


9/90


10/90

Participação

• +ma característica de uma associaçãoque indica a necessidade $ou não% dae1ist4ncia desta associação entre

objetos(• " participação pode ser obrigatória ou

opcional. –

5e o valor mínimo da multiplicidade de umaassociação * igual a 6 $um%, signi7ca que aparticipação * obrigat'ria

– Caso contr#rio, a participação * opcional(


11/90

"cess'rios para associaç.es

• " +!3 de7ne tr4s recursos de notação paraassociaç.es: – Nome da associação: fornece algum signicado

semântico a mesma.

– Direção de leitura: indica como a associação deveser lida

– Papel: para representar um papel especíco emuma associação.


12/90

Classe associativa•

Classe que est# ligada a uma associação,em ve/ de estar ligada a outras classes(• +sada quando duas ou mais classes estão

associadas, e * necess#rio manter

in-ormaç.es sobre esta associação(• 5in8nimo: classe de associação


13/90

"ssociaç.es n9#rias

• De7ne9se o grau de uma associação como aquantidade de classes envolvidas namesma.

•

2a notação da +!3, as lin0as de umaassociação n!ria se interceptam em umlosango.

• 2a grande maioria dos casos pr#ticos demodelagem, as associaç.es normalmente sãobin!rias.

• uando o grau de uma associação * igual atr4s, di/emos que a mesma * tern!ria.


14/90

E1emplo de associaçãotern#ria

• 2a notação da +!3, as lin0as de umaassociação n9#ria se interceptam emum losango nomeado(


15/90

"ssociaç.es ree1ivas

• "ssociação que representa ligaç.es entre objetosque pertencem a uma mesma classe( – Não indica que um objeto se associa a ele

próprio.

• " de7nição de pap*is * importante para evitarambig;idades na leitura da associação( – Cada objeto tem um papel distinto na

associação(


16/90


17/90

E1emplo


18/90

"gregaç.es e composiç.es 9di-erenças

• Destruição de objetos – 2a agregação, a destruição de um objeto

todo não implica necessariamente na

destruição do objeto parte(• Pertin4ncia

– 2a composição, os objetos parte pertencema um nico todo(

– Em uma agregação, pode ser que ummesmo objeto participe como componentede v#rios outros objetos(


19/90

"gregação e "ssociação

• E1iste pouca di-erença sem@nticaentre agregação e associação(

• 2a pr#tica, agregação * usadararamente(


20/90

&estriç.es sobreassociaç.es


21/90

Aenerali/ação eEspeciali/ação

• &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 oconceito veículo.

• Esse * o c0amado relacionamento de"erança.


22/90

Berminologia• subclasse X superclasse .• classe base X classe "erdeira .

• classe de especialização X classe de

generalização .• 2otação de7nida pela +!3


23/90

erança de associaç.es•

2ão somente atributos e operaç.es, mastamb*m associaç.es são 0erdadas pelassubclasses(

• 2o e1emplo abai1o, cada subclasse est#

associada a Pedido, por 0erança(


24/90

Propriedade da erança

• #ransitividade: uma classe em uma"ierarquia "erda propriedades erelacionamentos de todos os seus ancestrais. – " 0erança pode ser aplicada em v#rios níveis, dando

origem a "ierarquia de generalização. – +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'ação de %& então % não pode ser uma generali'ação de $. – Ou seja, não pode "aver ciclos em uma "ierarquia de

generalização.


25/90

E1emplo de 0erança


26/90

Classes "bstratas

• +sualmente, a e1ist4ncia de umaclasse se justi7ca pelo -ato de 0avera possibilidade de gerar inst@ncias

da mesma – Essas são as classes concretas.

• 2o entanto, podem e1istir classes

que não geram inst@ncias diretas( – Essas são as classes abstratas.


27/90

Classes "bstratas

• Classes abstratas são utili/adas paraorgani/ar e simpli7car uma 0ierarquia degenerali/ação(

•

Propriedades comuns podem serorgani/adas e de7nidas em uma classeabstrata a partir da qual as primeiras0erdam(

• 5ubclasses de uma classe abstrata tamb*mpodem ser abstratas, mas a 0ierarquia deveterminar em uma ou mais classes concretas(


28/90

2otação para classesabstratas

• 2a +!3, uma classe abstrata *representada com o seu nome em it$lico.

• 2o e1emplo a seguir, Conta


29/90

Diagrama de Objetos

• " +!3 de7ne um segundo tipo dediagrama estrutural, o diagrama deobjetos(

• Pode ser visto com uma inst@ncia dediagramas de classes

• &epresenta uma -otogra7a do sistemaem um certo momento( – e1ibe as ligaç.es -ormadas entre objetos

con-orme estes interagem e os valores dosseus atributos(


30/90

E1emplo F Diagrama deObjetos

P e d i d oI t e m P e d i d oP r o d u t o

n o m e G H C a d e r n o ! Hd 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 Hp r e ç o + n i t # r i o G I ,J Kd 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 Hd 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 Hp r e ç o + n i t # r i o G 6 ,L Kd 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 Hp r e ç o + n i t # r i o G L ,N Jd 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

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 L0 o r a G 6 K :K K a m

P e d i d o 6 : P e d i d o


31/90

B*cnicas de )denti7cação de Objetos,"tributos e !*todos

• E1istem t*cnicas $de uso nãoe1clusivo% usadas para identi7carclasses: – Categorias de Conceitos – "n#lise Be1tual de "bbott $ %bbot &e'tual %nal(sis)

–

"n#lise de Casos de +so


32/90

Categorias de Conceitos

• Conceitos concretos: edi-ícios, carros, salas de aula(• Papéis 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(

•

Organizações: coleç.es de pessoas ou de recursos:departamentos, projetos, campan0as, turmas(• Conceitos abstratos: princípios ou id*ias não

tangíveis: reservas, vendas, inscriç.es, boleto(


33/90

"n#lise Be1tual de "bbott

• )denti7car termos da narrativa de casos deuso e documento de requisitos que podemsugerir classes, atributos, operaç.es(

•

Montes de in-ormação: documento derequisitos, modelos do neg'cio, gloss#rios,con0ecimento sobre o domínio(

• 2omes $substantivos e adjetivos% que

aparecem no mesmo são destacados(• "p's isso, os sin8nimos são removidos(


34/90

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

• Cada termo remanescente seencai1a em uma das situaç.es aseguir: – O termo se torna uma classeS – O termo se torna um atributoS – O termo não tem relev@ncia alguma

com o 5T(


35/90


• B*cnica de identi7cação de operaç.es e deassociaç.es: destacar verbos no te1to(

• Uerbos de ação $calcular, con7rmar, cancelar,

comprar, -ec0ar, estimar, depositar, sacar%são operaç.es em potencial(• Uerbos com sentido de ter são potenciais

agregaç.es ou composiç.es(

• Uerbos com sentido de ser sãogenerali/aç.es em potencial(

• Demais verbos são associaç.es em potencial(

#


36/90


• O resultado $as classes candidatas% depende deos documentos utili/ados como -onte seremcompletos(

• " t*cnica pode levar identi7cação de diversasclasses candidatas que não gerarão classes(

• " an#lise do te1to de um documento pode nãoidenti7car uma classe importante(

•

Em linguagem natural, as variaç.es ling;ísticase as -ormas de e1pressar uma mesma id*ia sãobastante numerosas(


37/90


• Caso particular da "B"(• B*cnica preconi/ada pelo &+P(• Casos de uso como ponto de partida(

– " reali/ação de um caso de uso *responsabilidade de um conjunto de objetos quedevem colaborar para produ/ir o resultadodaquele caso de uso(

–

"plica9se a t*cnica para identi7car as classesnecess#rias produção do comportamento queest# documentado na descrição do caso de uso(


38/90


• Procedimento de aplicação: – Estudar a descrição te1tual de cada caso de uso

para identi7car classes candidatas( – Para cada caso de uso, o te1to $u1os principal,

alternativos e de e1ceção, p's9condiç.es e pr*9condiç.es% * analisado(

– )denti7car classes que possam -ornecer ocomportamento do mesmo(

– 2a medida em que os casos de uso sãoanalisados, as classes são identi7cadas(

• Pode9se categorizar as classes.


39/90

Categori/ação de Classes

• Objetos de entidade : usualmente objetosdo domínio do problema

• Objetos de -ronteira : atores interagem

com esses objetos• Objetos de controle : servem como

intermedi#rios entre objetos de -ronteira ede entidade, de7nindo o comportamento

de um caso de uso especí7co(


40/90

Categori/ação de Classes

• Categori/ação proposta por Vacobson(

– Possui correspond4ncia $mas não

equival4nciaW% com o padrão dearquitetura model*vie+*controller -/)

• Estere'tipos na +!3: XboundarYZ,

XentitYZ, XcontrolZ


41/90

Objetos de Entidade

• &eposit'rio para informações e as regras deneg(cio manipuladas pelo sistema.

• &epresentam conceitos do domínio do neg'cio(• Características

– 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 1ealizar0edido e %tualizar 2stoque. – Este objeto pode e1istir por diversos anos ou mesmo tanto

quanto o pr'prio sistema(


42/90

Objetos de Mronteira

• Comunicação do sistema com os atores( – tradu/em os eventos gerados por um ator em

eventos relevantes ao sistema – tamb*m são respons#veis por apresentar os

resultados de uma interação dos objetos(• E1istem para que o sistema se comunique com

o mundo e1terior(• # dois tipos principais de objetos de -ronteira:

– Os que se comunicam com o usu#rio $atores0umanos%: relat'rios, inter-ace gr#7ca(

– Os que se comunicam com atores não90umanos


43/90

Objetos de Controle

• 5ão a ponte de comunicação entre objetos de-ronteira e objetos de entidade(

• &espons#veis por controlar a l'gica de e1ecuçãocorrespondente a casos de uso(

• Decidem o que o sistema deve -a/er quando umevento de sistema ocorre( – "gem como controladores dos outros objetos para a

reali/ação de um caso de uso(

• Bradu/em eventos de sistema em operaçõesque devem ser realizadas pelos demaisobjetos.

) t@ i d


44/90

)mport@ncia daCategori/ação

• " categori/ação


45/90

)mport@ncia daCategori/ação

• " import@ncia dessa categori/açãoest# relacionada capacidade deadaptação a eventuais mudanças( – 5e cada objeto tem atribuiç.es

especí7cas dentro do sistema, mudançaspodem ser menos comple1as e maislocali/adas(

– +ma modi7cação em uma parte dosistema tem menos possibilidades deresultar em mudanças em outras partes(


46/90


47/90

!odelo de "n#lise no Processo)terativo e )ncremental

• Em um desenvolvimento dirigido acasos de uso, ap's a descrição doscasos de uso, * possível iniciar a

identi7cação de classes(• "s classes identi7cadas são re7nadas

para retirar inconsist4ncias e

redund@ncias(• "s classes são documentadas e o

diagrama de classes inicial *

construído(


48/90

!odelo de "n#lise no Processo)terativo e )ncremental $cont(%

• "s construç.es do modelo de casos de usoe do modelo de classes são retroativasuma sobre a outra( –

2ovos casos de uso podem ser identi7cados – Pode9se identi7car a necessidade de

modi7cação de casos de uso pree1istentes(

• Depois que a primeira versão do modelo de

classes de an#lise est# completa, retornarao modelo de casos de uso e veri7car aconsist4ncia entre os dois modelos(


49/90

!odelo de "n#lise no Processo)terativo e )ncremental $cont(%


50/90

Classes de Projeto

• O modelo de classes de projeto éresultante de re#namentos no modelo declasses de an$lise.

• Esse modelo * construído em paralelo com omodelo de interações. – " construção do modelo de interações gera

inormações para a transormaç%o do modelode 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.


51/90

"spectos a considerar na -ase de projeto

• "dição de novas classes ao modelo• Especi7cação de atributos,

operaç.es e de associaç.es• Descrever re7namentos e conceitos

relacionados 0erança, classesabstratas, )nter-aces, polimor7smo(

ã


52/90

Especi7cação de classes de-ronteira

• 2ão atribuir a essas classesresponsabilidades relativas l'gica doneg'cio(

•

Classes de -ronteira devem apenas servircomo: – Ponto de captação ou – Ponto de apresentação de in-ormaç.es(

• " nica intelig4ncia que essas classesdevem ter * a que permite a elas reali/arema comunicação com o ambiente do sistema(

i7 ã d l d


53/90

Especi7cação de classes de-ronteira $cont(%

• # diversas ra/.es para isso: – 5e o sistema tiver que ser implantado

em outro ambiente, as modi7caç.es

resultantes sobre seu -uncionamentoseriam mínimas( – O sistema pode dar suporte a diversas

-ormas de interação com seu ambiente( – Essa separação resulta em mel0or

coesão.

E i7 ã d l d


54/90


• Durante a an#lise, considera9se que0# uma nica classe de -ronteirapara cada ator(

• 2o projeto, algumas dessas classespodem resultar em v#rias outras(

E i7 ã d l d


55/90


• Clientes TE< cl#ssicos – Classes de -ronteira são p#ginas B!3(

• Clientes stand9alone – &ecomend#vel que os desenvolvedores

pesquisem os recursos -ornecidos pelo

ambiente de programação sendoutili/ado( E1( 5[ingQVMC

E i7 ã d l d


56/90


• " maioria das classes de entidadenormalmente permanece na passagemda an#lise ao projeto(

• Classes de entidade são normalmenteas primeiras classes a seremidenti7cadas, na an#lise de domínio(

•

Deve9se identi7car quais delas geramobjetos que devem ser persistentes(

E i7 ã d l d


57/90


• Como identi7car cada um de seus objetosunicamente( – E1( um objeto da classe "luno * unicamente

identi7cado pelo valor de sua matrícula(

• +m identicador de implementação& quenão tem correspondente com atributoalgum do domínio& pode ser criado. – Possibilidade de manipular identi7cadores de

maneira uni-orme e e7ciente( – !aior -acilidade quando objetos devem ser

mapeados para um 5A


58/90

Especi7cação de classes deentidade

• " maioria das classes de entidadenormalmente permanece na passagemda an#lise ao projeto(

• Classes de entidade são normalmenteas primeiras classes a seremidenti7cadas, na an#lise de domínio(

•

Deve9se identi7car quais delas geramobjetos que devem ser persistentes(

E i7 ã d l d


59/90

Especi7cação de classes deentidade

• Como identi7car cada um de seusobjetos unicamente( – E1( um objeto da classe "luno *

unicamente identi7cado pelo valor de suamatrícula(

• +m identicador deimplementação& que não temcorrespondente com atributoalgum do domínio& pode ser criado.


60/90

Especi7cação de classes de controle

• 2ormalmente associado a um casode uso

• O controle pode ser particionado em

duas ou mais outras classes paracontrolar diversos aspectos dasolução(

• Evitar a criação de uma nica classecom bai1a coesão e altoacoplamento(


61/90


• E1emplos dos aspectos de umaaplicação cuja coordenação * deresponsabilidade das classes de

controle: – produção de valores para

preenc0imento de controles da inter-ace

gr#7ca, – autenticação de usu#rios, – controle de acesso a -uncionalidades do

sistema


62/90


• &esponsabilidades de controlador decaso de uso: – Coordenar a reali/ação de casos de uso( –

5ervir como canal de comunicação entreobjetos 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(

Especi7cação de outras


63/90

Especi7cação de outrasclasses

• "l*m do re7namento de classes pree1istentes,diversos outros aspectos demandam aidenti7cação de novas classes durante o projeto( – Persist4ncia de objetos – Distribuição e comunicação $&!), CO&


64/90

&e7namento de atributos e m*todos

• Os atributos e m*todos de uma classe a0abilitam a cumprir com suasresponsabilidades(

•

"tributos: permitem que uma classearma/ene in-ormaç.es necess#rias reali/ação de suas tare-as(

• !*todos: são -unç.es que manipulam os

valores do atributos, com o objetivo deatender s mensagens que o objetorecebe(


65/90


66/90

Uisibilidade

• uali7cadores de visibilidade aplic#veis aatributos tamb*m podem ser aplicados aoperaç.es( –

( visibilidade p)blica – * visibilidade protegida

– + visibilidade privativa

• O real signi7cado depende da linguagem

de programação em questão(• O conjunto das operaç.es pblicas de uma

classe * c0amado de interace


67/90

Projeto de m*todos

• !*todos de criação e destruição deobjetos

• !*todos de acesso $get=Qset=%• Outros m*todos:

– Ualores derivados, -ormatação,conversão,((((

• "lguns m*todos devem ter umaoperação inversa 'bvia – 0abilitar e desabilitarS tornarUisível e

tornar)nvisívelS adicionar e removerS


68/90

Detal0amento de m*todos

• Diagramas de interação -ornecem umindicativo sobre como m*todos devem serimplementados(

•

Como complemento, notas e1plicativastamb*m são teis no esclarecimento decomo 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 maiscomple1os(

)mplementação de


69/90

)mplementação deassociaç.es

• # tr4s casos, em -unção daconectividade: 6:6, 6:2 e 2:!

• Para uma associação 6:6 entre duas

classes " e < : – 5e a navegabilidade * unidirecional no

sentido de " para


70/90

Conectividade 6:6


71/90


72/90

Classe parametri/ada

• +ma coleção pode ser representadaem um diagrama de classes atrav*suma classe parametrizada.

• De-(: * uma classe utili/ada parade7nir outras classes(

• Possui operaç.es ou atributos cuja

de7nição * -eita em -unção de um oumais par@metros(


73/90

Conectividade 6:2

• Mormas alternativas pararepresentação de uma associaçãocuja conectividade * 6:2(


74/90

Conectividade 6:2 $Cont%


75/90

Conectividade 2:!


76/90

Classes "ssociativas

i d


77/90

Bipos de erança

• Com relação quantidade desuperclasses que certa classe podeter( – "erança m)ltipla – "erança simples

. li ' 7


78/90

Operaç.es polim'r7cas

• +ma subclasse 0erda todas as propriedades desua superclasse que ten0am visibilidadepblica ou protegida(

• Pode ser que o comportamento de algumaoperação 0erdada seja di-erente para asubclasse(

• 2esse caso, a subclasse deve rede7nir ocomportamento da operação( – " assinatura da operação * reutili/ada( – !as, a implementação da operação $ou seja, seu

m*todo+ * diferente.



79/90

Operaç.es polim'r7cas$Cont%

• Operaç.es polim'r7cas são aquelasque possuem mais de umaimplementação(

• " assinatura * repetida na$s%subclasse$s% para en-ati/ar arede7nição de implementação(

• O objetivo de manter a assinatura *garantir que as subclasses ten0amuma inter-ace em comum(



80/90

Operaç.es polim'r7cas$Cont%

• 5e duas ou mais subclasses implementamuma operação polim'r7ca, a mensagempara ativar essa operação * a mesma paratodas essas classes(

• 2o envio da mensagem, o remetente nãoprecisa saber qual a verdadeira classe decada objeto, pois eles aceitam a mesma

mensagem(• " di-erença * que os mtodos da operação

são di!erentes em cada subclasse.

Operaç.es polim'r7cas 9


81/90

Operaç.es polim'r7cas e1emplo

O . li ' 7


82/90


Operaç.es polim'r7cas tamb*m podeme1istir em classes abstratas(



83/90

Operaç.es polim'r7cas$cont%

• Operaç.es polim'r7cas implementam oprinc,pio do polimor#smo- – dois ou mais objetos respondem a

mesma mensagem de -ormas

di-erentes(

E í i


84/90

E1ercícios

• Para cada especi7cação a seguir,projete dois diagramas de classes: – De an#lise – De projeto

C . t di i li


85/90

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


86/90

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 locação re-ere9se unicamente a umdeterminado s'cio• Cada locação deve obrigatoriamente

re-erenciar9se ao menos a uma c'pia de um

7lme, podendo re-erenciar9se a muitasc'pias(

• +ma c'pia pode ter sido locada diversasve/es, em *pocas di-erentes obviamente


87/90

• !odelar a situação usando umdiagrama de classes: +ma pessoaao longo da vida, tem v#rios

empregos, em empresas di-erentes(Para a Previd4ncia, * importantesaber a data de admissão e a data

de rescisão de contrato com cadauma dessas Empresas

• +m cliente pode possuir muitos animais, mas um animalpertence a um nico cliente " clínica precisa de in-ormaç.es a


88/90

pertence a um nico cliente( " clínica precisa de in-ormaç.es arespeito de cada cliente, como nome, endereço, 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-ere9see1clusivamente a um determinado tratamento( Cada consultadeve arma/enar in-ormaç.es como a data em que -oi reali/ada, oveterin#rio que atendeu o animal e o resumo da consulta(

• +m veterin#rio pode reali/ar muitas consultas, por*m umaconsulta deve ser reali/ada por somente um veterin#rio

• Em uma consulta podem ser marcados e1ames para o animal( Onmero de e1ames possíveis em uma consulta * indeterminado,mas precisa ser registrado(

• +ma universidade possui dois tipos de -uncion#rios: pro-essores et*cnico9administrativos( uando são contratados, * necess#rio


89/90

*c co ad s a os ua do são co a ados, * ecess# ocadastrar seu nome, tele-one, endereço, CPM $que deve ser v#lido%, e adata de contratação $que tamb*m precisa ser validada%(

• Para o pro-essor deve ser cadastrado tamb*m a titulação, #rea de

pesquisa, e o tipo de contrato $LK 0oras, IK 0oras ou Dedicaçãoe1clusiva%(

• +m -uncion#rio possui obrigatoriamente um nico cargo( O cargo possuium título e um sal#rio( O sal#rio do cargo pode ser aumentado apenasuma ve/ por ano(

•

+m pro-essor pode não ministrar disciplinas em um semestre, ouministrar 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, deve9se in-ormar o nome da disciplina, a carga 0or#ria, e o tipo da disciplina(

• +m curso pode ser de graduação ou de p's9graduação( O curso possuium nome e uma #rea $e1( E1atas%( Cursos de p's9graduação podem serde 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 sistemasimples de reserva e ocupação de quartos para um


90/90

simples de reserva e ocupação de quartos para um0otel( O sistema deve arma/enar reservas -eitas porum -uncion#rio de um ou mais quartos para umdeterminado cliente( O -uncion#rio deve ser capa/de: veri7car se um quarto est# ocupado ou não,inserir ou alterar os dados de um cliente, reali/ar areserva de um quarto para um cliente( Considere os

atributos de todas as classes como privados( Cadacliente e -uncion#rio deve possuir: nome, rg, CPM,endereço, tele-one( Deve ser possível identi7car aquantidade de ocupaç.es j# reali/adas pelos

clientes( +m quarto pode ser simples ou lu1o e deveindicar o nmero de camas e o tipo de cada umadelas $solteiro ou casal%( Cada quarto deve terapenas um -rigobar que tem um contedo de

parte7 - diagrama de classes.pptx

Documents