1

DIAGRAMA DE CLASSES PERSPECTIVA CONCEITUAL

2ª PARTEDICAS

DEPENDÊNCIAS AVANÇADO

AGREGAÇÃO

ATRIBUTOS E ASSOCIAÇÕES DERIVADAS

ASSOCIAÇÃO TERNÁRIA

GENERALIZAÇÃO

ORGANIZAÇÃO DAS CLASSES EM PACOTES

ELABORANDO O DIAGRAMA

ERROS COMUNS

2

DICASFoco: aspecto estático do sistemaNão prejudicar a leitura com minimalismosGeneralizações: evitar mais do que 5 níveisNome para cada diagramaEvitar linhas cruzadasElementos semânticos semelhantes próximos fisicamentePode-se usar notações visuais que chamem a atenção É possível usar mais que um relacionamento, mas tentar evitar

3

DEPENDÊNCIAS AVANÇADO

Tipos Definidos pela UMLBind: origem instancia o destinoDerive: Origem computada através do destino (ex. Idade -> Data de Nascimento)Friend: Origem recebe visibilidade especial no destino

InstanceOfInstantiatePowertypeRefineUse

4

I I . ATRI BUTOS E ASSOCI AÇÕES DERI VADAS Um elemento derivado é aquele que pode ser calculado a

partir de um ou mais elementos mas é incluído no modelo: - com o objetivo de tornar algo mais claro ou - por algum motivo de projeto. Por exemplo, para tornar uma

operação mais f ácil de ser realizada. Atributos ou associações derivadas podem ser representadas

através de uma barra (/ ) antes do nome da associação ou do atributo.

Os detalhes sobre o cálculo do elemento derivado podem ser

descritos junto a ele, através de uma nota (utilizada na UML para anexar inf ormações a um modelo)

5

Fatura

numFaturadataEmissãodataVencimentovalorPago [0..1]dataPagamento [0..1]dataPedidoCancelamento [0..1]dataCancelamento [0..1]status

1..*0..*

I tem faturado

quantFaturada

I tem pedido

quantidadePedidapreçoCobrado/ quantAtendida

quantAtendida = soma das quantidades f aturadas do item

Atributo derivado

Nota

6

PedidonumPedidodataEmissão

nomePresenteado [0..1]endereçoEntrega

dataCancelamento [0..1]status

Item pedidoquantidadePedidapreçoCobrado/ quantAtendida

1..*

1

0..*

LivroisbntítulodescriçãoquantEstoquepreçoprazoMédioEntrega

0..*

1..*

ClientecódigoCPFnomeendereçotelefone [0..1]eMail [0..1]

<- faz

1..*

1

/escolhe

Associação derivada

7

I I . ASSOCIAÇÃO TERNÁRIA

Associações podem ser binárias, ternárias ou deoutro grau.

Uma associação ternária é uma associação entretrês classes, onde uma classe pode ocorrer maisde uma vez.

8

Exemplo: Num sistema de controle de reservas deexcursões, ao ser criada uma excursão:

- são selecionados um ou mais veículos e- para cada veículo, podem ser alocados até dois

motoristas que o conduzirão nesta excursão.

1..*

1..2

1

Excursão

CódigoDataHoraValorLocalEncontro

Motorista

NomeEndereçoTelefone

Veículo

PlacaLotação

9

Neste caso não ocorre de serem selecionados veículospara a excursão e só depois serem alocados motoristas.Se f osse essa a situação não teríamos um ternárioporque a classe motorista não estaria participando dorelacionamento e num ternário as três classes têm queparticipar.

10

Para incluir a multiplicidade podemos pensar da seguintemaneira:

Analisamos excursão-veículo com relação ao motorista.Para cada veículo em uma excursão é alocado um ou nomáximo dois motoristas. Desta f orma do lado do motoristaincluímos o multiplicidade 1..2. Analisamos motorista-veículo com relação a excursão.Um motorista dirigindo um determinado veículo pode terparticipado de várias excursões. Desta f orma do lado daexcursão teríamos a multiplicidade 1..*. Analisando motorista-excursão com relação ao veículo.Um motorista numa determinada excursão só pode terdirigido um veículo. Desta f orma ao lado do veículo teríamosa multiplicidade 1.

11

I I I . GENERALIZAÇÃO

A generalização é um relacionamento entre um elementomais genérico (o pai) e um elemento mais específico (ofi lho) que é totalmente consistente com o primeiroelemento e acrescenta informações adicionais. É umrelacionamento utilizado em classes mas também emcasos de uso, atores, e outros elementos.

No diagrama de classes, a generalização é apresentadacomo uma linha da classe fi lha para a classe pai com umtriângulo ao fi m da linha onde está o pai. Representa umrelacionamento entre a superclasse e a subclasse. Asubclasse herda as propriedades do pai, como atributose operações e pode ter suas próprias propriedades.

12

À s v e z e s a d e c i s ã o p o r m o d e l a r u m ag e n e r a l i z a ç ã o c o m e ç a q u a n d o t e m o s u m a c l a s s ec o m i n f o r m a ç õ e s d e v á r i o s t i p o s .

P o r e x e m p l o , n u m c o n s u l t ó r i o m é d i c o op a g a m e n t o d e u m a c o n s u l t a p o d e s e r f e i t o a t r a v é sd e c o n v ê n i o o u p a r t i c u l a r . N e s t e ú l t i m o c a s o oc l i e n t e p o d e p a g a r c o m c h e q u e o u d i n h e i r o .

N a s o l u ç ã o a s e g u i r f o r a m i n c l u í d o s e mP a g a m e n t o a t r i b u t o s r e l a c i o n a d o s a c a d a u m d e s s e st i p o s d e p a g a m e n t o .

Convênio

nometelefonedata cobrança

Consulta

data horasintomasdiagnóticomedicamentos

Pagamento

data previstadata pagamentovalor cobradovalor pagotiponúmero chequenúmero banconúmero associado

0..10..* 0..10..*

11 11

13

Modelando com a generalização podemos ter maior clarezasobre pagamento, como podemos observar no diagrama aseguir.- Foram criadas duas subclasses, pagamento particular e

pagamento por convênio.- Em pagamento estão os atributos comuns a pagamento

particular e por convênio .- Em pagamento particular temos os atributos próprios só

deste tipo e em pagamento por convênio os atributos eassociações particulares ao pagamento por convênio.

- Como consulta está relacionada à pagamento, todas assubclasses têm este relacionamento.

14

Pagamento Particular

tipo

número cheque

número banco

Pagamento por Convênio

número associado

Convênio

nome

telefone

data cobrança

0..* 10..* 1

Pagamento

data prevista

data pagamento

valor cobrado

valor pago

Consulta

data hora

sintomas

diagnóstico

medicamentos11 11

15

Uma generalização pode ser total ou parcial,disjunta ou sobreposta.

- Total: Todas as subclasses são especifi cadas- Parcial: Nem todas as subclasses são

especificadas- Sobreposta: As classes derivadas de uma

superclasse podem ocorrer simultaneamente- Disjunta: As classes derivadas de uma

superclasse podem ocorrer de maneiramutuamente exclusivas.

Restrições, já comentadas anteriormente, podemser utilizadas para descrever o tipo da generalização.

16

Pagamento Particular

tiponúmero chequenúmero banco

Pagamento por Convênio

número associado

Convênio

nometelefonedata cobrança

0..* 10..* 1

{total, disjunta}

Pagamento

data previstadata pagamentovalor cobradovalor pago

Consulta

data horasintomasdiagnóticomedicamentos

11 11

Restrição

17

No caso anterior, as subclasses de pagamento f oramcriadas em f unção do tipo de pagamento. Pode sernecessário, no entanto, f azer várias classificações.

- Classifi cação única: No exemplo a seguir médico éclassificado somente quanto a sua especialidade.

- Classifi cação múltipla: No exemplo a seguir temos pessoaclassificada por sexo e por ocupação.

Quando temos uma classificação múltipla, discriminadoresdevem ser utilizados para dif erenciar esses tipos. Ao lado dodiscriminador podemos escrever as restrições entre chaves.

18

Pessoa

Médico Enfermeira Psicólogo

HomemMulher

Cirurgião Pediatra

sexo {total, disjunta}

ocupação {parcial,sobreposta}

especialidade{parcial,sobreposta}

Discriminador

19

Quando uma subclasse tem apenas uma classe paitemos uma herança simples. Mas é possível ocorrerde uma classe ter várias classes pai e desta f ormateremos uma herança múltipla.

20

IV. ORGANIZAÇÃO DAS CLASSES EMPACOTES

Na UML os modelos podem ser organizados empackages (ou pacotes) de f orma que possamoscompreendê-los mais f acilmente.

O package é f ormado por um grupo de elementos comum tema comum. Esses elementos podem ser classes,componentes, casos de uso e até mesmo outrospacotes.

21

Exemplo:

Poderíamos no caso exemplo, ter dois packages:Controle de pedidos e Controle de Livros

Controle de

livros

Controle de

pedidos

22

O diagrama de classes apresentado a seguirpertence ao package Controle de pedidos, quecontém as classes próprias à administração depedidos e f aturamento

Classes de outros packages podem aparecerneste diagrama, caso seja importante, como é ocaso de Livro. Ao lado do nome, no entanto, vemdiscriminado o nome do package ao qual pertence.

O package Controle de Livros contém a classelivro que pertence ao sistema de Controle deLivros

23

Item faturadoquantFaturada

Livro (from Controle de Livros)isbntítulodescriçãoquantEstoquepreçoprazoMédioEntrega

Item pedidoquantidadePedidapreçoCobrado

1

0..*

1

0..*

ClientecódigoCPFnomeendereçotelefone [0..1]eMail [0..1]

PedidonumPedidodataEmissão

nomePresenteado [0..1]endereçoEntrega

dataCancelamento [0..1]status

1..*1..*

1..*1 1..*1 faz ->

FaturanumFaturadataEmissãodataVencimentovalorPago [0..1]dataPagamento [0..1]dataPedidoCancelamento [0..1]dataCancelamento [0..1]

status

1..*0..* 1..*0..*

1

0..*

1

0..*

{ Se uma fatura atende a um pedido, necessariamente os itens pedidos ligados à fatura devem ser do pedido ao qual a fatura está relacionada }

Nomedo package

24

V. ELABORANDO O DIAGRAMA

1. A elaboração da primeira versão do diagrama de classecom uma perspectiva conceitual pode se realizada emparalelo à leitura dos casos de uso. Na descrição decada caso de uso há uma série de informações,conceitos, nomes de atributos, etc, que serão úteispara descobrir as classes, associações e atributos

25

2. Ao elaborar o diagrama de classes é possível que seconstate a f alta de informações, a existência deinconsistências e haverá necessidade então de seconsultar o cliente.

3. A elaboração de modelos é realizada através de váriasrepetições e o modelo deve ser construído emconjunto com os demais modelos, já que alterações emum modelo provocam alterações em outros.

26

4. Após a elaboração da primeira versão podemostentar refinar o modelo verifi cando a possibilidadede incluir notações como composição, generalizaçãoque permitem que as informações fi quem descritasde f orma mais clara.

5. Conforme é elaborado o diagrama pode sernecessário também organizar as classes em packages.

27

28

29

30

31

32