1. 2 3 4 agregação: empresa departamento 1 todo parte

1

V. AGREGAÇÃO E COMPOSIÇÃO

Utilizamos a agregação quando temos umrelacionamento entre duas classes do tipo todo/ partede tal f orma que um objeto-parte pode pertencer amais de um objeto-todo.

A composição é uma variação da agregação onde háeste relacionamento todo/ parte mas cada objeto-parte pertence a um único objeto-todo e os objetos-parte desaparecem quando o objeto-todo ao qualpertencem é apagado. As partes podem ser criadasapós o surgimento do todo assim como seremremovidas antes que o todo seja apagado.

3

A agregação na UML é representada por um losango e acomposição por um losango cheio, ambos posicionados naextremidade ref erente ao todo. Na composição amultiplicidade na extremidade do todo é no máximo umenquanto na agregação pode ser maior que um.

4

Agregação: Empresa

Departamento

1

TODO

Parte

5

Podemos dizer que temos uma composição porque temos umrelacionamento todo/ parte e um determinado item pedidopertence a um único pedido.

Composição: Pedido

numPedidodataEmissão

nomePresenteado [0..1]endereçoEntregadataCancelamento [0..1]

status

Item pedido

quantidadePedidapreçoCobrado

1..*

8

VI . RESTRI ÇÕES

Restrição: é utilizada quando não podemos modelar umainformação importante com as notações já existentes.

A restrição é representada através uma cadeia decaracteres entre chaves que é colocada ao lado doelemento ao qual f az ref erência. É portanto um mecanismode extensibilidade da linguagem.

9

Venda

idforma pagamentodata

Produto

iddescriçãopreço custopreço vendacomissão

Item

quant

1..*

0..1

0..*Serviço

iddescriçãopreço0..10..*

{ou}0..*

0..* 0..1

0..1

1..*

Exemplo de restrição ou:

10

Pessoa Departamento1..* *

membro

1..* *

1*gerente1*

gerencia ->

trabalha ->

{subconjunto}

Exemplo de restrição subconjunto:

11

Exemplo de restrição relacionada a associações:

Item faturadoquantFaturada Livro

isbntítulodescriçãoquantEstoquepreço

prazoMédioEntrega

Item pedidoquantidadePedidapreçoCobrado

1

0..*

1

0..*

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

PedidonumPedidodataEmissão

nomePresenteado [0..1]endereçoEntregadataCancelamento [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 }

12

VI I . ELABORANDO O DIAGRAMA

1. A elaboração da primeira versão do diagrama de classe com uma perspectiva conceitual pode ser realizada em paralelo à leitura dos casos de uso. Na descrição de cada caso de uso há uma série de informações, conceitos, nomes de atributos, etc, que serão úteis para descobrir as classes, associações e atributos. Uma estratégia é elaborar este diagrama incluindo somente as

classes persistentes, ou seja, aquelas cujos objetos são preservados após serem criados ou modificados por uma aplicação. Estes objetos podem ser armazenados em um banco de dados de f orma a serem recuperados mais adiante.

Outras classes, não-persistentes, serão incluídas no diagrama de classes elaborado com a perspectiva de implementação.

13

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.

14

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çõesfiquem descritas de f orma mais clara.

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

Veremos em Classes: 2ª ParteVeremos em

Classes: 2ª Parte

15

Exemplo:

Elaborando o diagrama de classes doSistema de controle de pedidos, com uma perspectiva conceitual, a partir da descriçãodos casos de uso.

16

Diagrama de casos de uso:

Gerente

Funcionário

Comunica atraso

Valida pedido

Solicita cancelamento de fatura

Paga fatura

Comunica atraso no pagamento

Avalia cancelamento de fatura

Fatura pedido

(verificação de itens pendentes)

<<extend>>

Diminui quantidade de um item do

pedido

<<include>>

Solicita cancelamento de pedido<<include>>Faz pedido

Cliente

Faz pedido para presentear

17

Faz pedidoCenário principal: Venda realizada com sucesso por umnovo cliente1. Cliente informa dados pessoais (cpf , nome, endereço,

telefone e e-mail) e endereço de entrega2. Cliente informa a lista dos livros desejados e

respectivas quantidades3. Sistema armazena além dos dados f ornecidos pelo

cliente, a data de emissão do pedido e o preço cobradopor cada livro, já que pode ser dado algum desconto eo valor cobrado não será o de tabela

4. Sistema envia ao cliente a confirmação da venda com onúmero de seu pedido, seu código, a lista dos itenspedidos com quantidade e preço de cada item e o preçototal do pedido.

18

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

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


endereçoEntrega

1..*1..*


1

0..*0..*

1

LivroisbntítulodescriçãoquantEstoquepreçoprazoMédioEntrega

Obs: A classe livro faz parte de outro subsistema.

19

Faz pedido para presentear

1. Cliente informa dados pessoais (cpf , nome,endereço, telefone e e-mail)

Cliente informa dados do presenteado:nome e endereço de entrega

Continua a partir do passo 2.

20

Pedido


nomePresenteado [0..1]endereçoEntrega

21

Fatura pedidoCenário principal: f aturamento de pelo menos um item do pedido

1. Funcionário seleciona um pedido que não tenha sido integralmenteatendido (f aturado)

2. Sistema verifica a quantidade pendente (quantidadePedida -quantidadeAtendidaTotal) de cada item(Extend – Comunicaatraso)

3. Sistema cria uma fatura com o número da f atura, a data deemissão, a data limite de pagamento e a quantidade de cada item.4. Sistema emite a f atura que deverá ser encaminhada ao cliente

juntamente com os livros. A f atura deverá conter:- Número da f atura- Número do pedido- Data de emissão- Data de vencimento- Para cada item: a quantidade e o preço unitário cobrado

- Preço total

22

Obs: A quantidade f aturada de cada item (livro) está

limitada ao que há em estoque. Caso não possa ser f eitoum atendimento completo neste momento, maisadiante, logo que haja o item em estoque, será criadauma nova f atura.

Uma f atura f az ref erência a um e apenas um pedido.No entanto ela pode estar atendendo apenasparcialmente àquele pedido.

23

Item faturadoquantFaturada Livro

isbntítulodescriçãoquantEstoquepreçoprazoMédioEntrega

ClientecódigoCPFnomeendereçotelefoneeMail


1

0..*

1

0..*

FaturanumFaturadataEmissãodataVencimento

status

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


nomePresenteado [0..1]endereçoEntrega

status

1..*1..*

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

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 }

24

Comunica atraso

Sistema verifica que um ou mais itens pedidosnão poderão ser entregues e que não há previsãode entrega.

Sistema comunica ao cliente o atrasodescrevendo o número do pedido e os itens paraos quais não há previsão de entrega.

25

Diminui quantidade de um item do pedidoCenário principal: Quantidade diminuida

1. Cliente informa seu código2. Sistema valida código3. Cliente informa número do pedido4. Sistema valida número do pedido (include – Valida

pedido)5. Cliente informa o item a ser reduzido6. Sistema apresenta ao cliente a quantidade pendente

(quantidade pedida – quantidade f aturada)7. Cliente informa a nova quantidade (no máximo a

quantidade pendente)8. Sistema armazena a nova quantidade9. Sistema envia ao cliente a confi rmação da alteração

realizada

26

Diminui quantidade de um item do pedidoCenário alternativo: Pedido de redução de item érecusado por já ter sido totalmente f aturado

6. Sistema comunica ao cliente: o item não pode ser reduzido por ter sido

completamente f aturado caso deseje realmente esta redução o cliente

deverá solicitar o cancelamento parcial ou totalda f atura. Esse pedido será avaliado pelogerente.

Os passos seguintes não são realizados

27

Solicita cancelamento de pedidoCenário principal: Pedido cancelado por não haver f atura emitida

1. Cliente informa seu código2. Sistema valida código3. Cliente informa número do pedido4. Sistema valida número do pedido (include – Valida pedido)5. Sistema cancela o pedido (não há nenhuma fatura emitida para

ele) e armazena a data de cancelamento

6. Sistema envia ao cliente a confirmação do cancelamentosolicitado.

28

Pedido


nomePresenteado [0..1]endereçoEntregadataCancelamento [0..1]status

29

Solicita cancelamento de pedidoCenário alternativo: Pedido não pode ser cancelado por já tersido emitida pelo menos uma f atura

5. Sistema comunica ao cliente: o pedido não pode ser cancelado por já ter sido emitida

pelo menos uma f atura. o cliente deverá solicitar o cancelamento das f aturas já

emitidas caso deseje cancelar o pedido.

Os passos seguintes não são realizados

30

Valida pedido

1. Sistema verifica a existência do número do pedido2. Sistema envia ao cliente os dados relativos a seu

pedido: a lista dos itens pedidos com quantidade e preço

unitário de cada item e o preço total do pedido a lista das f aturas emitidas contendo para cada

fatura:- Número da f atura- Número do pedido- Data de emissão- Data de vencimento- Para cada item: a quantidade e o preço unitário

- Preço total

31

Solicita cancelamento de f aturaCenário principal: Solicitação de cancelamento integral da f aturarealizada com sucesso

1. Cliente informa seu código2. Sistema valida código3. Cliente informa número da f atura4. Sistema verifica a existência deste número5. Sistema envia ao cliente os dados da f atura, contendo: a data de

emissão, o preço total e para cada item: a quantidade e o preçounitário

6. Cliente solicita o cancelamento integral da f atura

7. Sistema armazena a solicitação de cancelamento da f atura e adata da solicitação

8. Sistema envia ao cliente a confirmação do cadastramento desua solicitação e a informação de que o seu pedido só seráanalisado quando a Empresa receber os livros relativos à f atura.

32


dataPedidoCancelamento [0,1]

status

33

Paga f aturaCenário principal: Pagamento da última f atura de umpedido

1. Cliente paga a f atura2. Sistema armazena o número da f atura, o valor pago e

a data de pagamento.3. Sistema f echa o pedido relacionado à f atura (f oi paga

a última f atura de um pedido)4. Sistema envia ao cliente a confirmação de pagamento

da fatura

34


valorPago [0..1]dataPagamento [0..1]dataPedidoCancelamento [0..1]

status

35

Avalia cancelamento de f aturaCenário principal: Gerente cancela a f atura e automaticamente écancelado o pedido

1. Gerente analisa o pedido de solicitação de cancelamento deuma f atura

2. Gerente cancela a f atura3. Sistema armazena a data de cancelamento e atualiza o estoque,

considerando a devolução dos livros4. Sistema cancela o pedido (todas as f aturas de um pedido

foram canceladas)5. Sistema envia ao cliente notificação do cancelamento da

fatura e do pedido

36


valorPago [0..1]dataPagamento [0..1]dataPedidoCancelamento [0..1]dataCancelamento [0..1]

status

37

Usar classes e associações para definir o glossário do sistema “Jogo de Futebol” descrito de seguida: “O jogo de futebol é realizado por duas equipes de jogadores. Cada equipe é composta por 11 jogadores, com diferentes funções: o goleiro, zagueiros, médios, atacantes, e pontas de lança. O ponta de lança é um atacante especial por ter especiais características de goleador... O jogo é realizado num campo com medidas regulamentares (em comprimento e largura), tem duas balizas, cada qual em extremos opostos do campo. Ganha o jogo a equipe que marcar mais gols (i.e., colocar a bola) na baliza do adversário. No jogo apenas existe uma única bola, que apresenta características (peso, diâmetro, …) regulamentares... O jogo de futebol é mediado por uma equipe de 3 árbitros, em que um é o árbitro principal, e os outros dois são árbitros auxiliares…”

Exercicio 2: Modele os Relacionamentos

38

Exercicio: Acrescente relacionamentos ao sistema da Petrobrás

1. 2 3 4 agregação: empresa departamento 1 todo parte

Documents