Derivao de um Diagrama de Classes a partir do Modelo de Casos de Uso

CF-Rest

Vamos usar para exemplificar essa derivao o Sistema Restaurante

Dois atores: 1. Cliente 2. Gerente Funcionalidades: a) Registrar o pedido de pratos e bebidas de cada cliente. Dever tambm ser feita a emisso de um ticket de fechamento, quando o cliente solicitar a conta. b) Cancelar um pedido por solicitao do cliente. c) Registrar o pagamento ou a pendura da conta do cliente. A pendura facultada apenas aos clientes considerados habituais do restaurante. d) Emitir um relatrio detalhado do consumo dirio de pratos e bebidas, para fins de reposio de estoque. e) Emitir um relatrio detalhado da receita do restaurante, em um dado perodo, separando a receita realizada daquela realizar (pelo pagamento de contas penduradas). f) Registrar o cardpio em vigor.

ATOR: Cliente UC 1: Abrir pedido pedido = dt_pedido + id_mesa + itens_ped itens_ped = 1{id_item + quant_item} id_pedido ATOR: Cliente UC 2: Cancelar pedido cancela_ped = id_pedido ATOR: Cliente UC 3: Pedir a nota solicitacao_nota = id_pedido + [id_cliente] nota = id_pedido + nr_mesa + dt_pedido + itens_nota + vl_nota + [nome_cliente + tel_cliente] itens_nota = 1{id_item + cat_item + nome_item + p_unit + quant_item + vl_item} ATOR: Cliente UC 4: Pagar a nota pagamento = id_pedido + vl_entregue + dt_pagto troco ATOR: Cliente UC 5: Pendurar a nota pendura = id_pedido + id_cliente ATOR: Gerente UC 6: Cadastrar cliente habitual cliente = nome_cliente + tel_cliente id_cliente ATOR: Gerente UC 7: Atualizar o cardpio item_consumo = nome_item + pc_unit + cat_item + descr_item id_item ATOR: Gerente UC 8: Solicitar consumo dirio solic_consumo = dt_emissao + dt_consumo consumo_dia = dt_emissao + dt_consumo + consumo_itens consumo_itens = 0{cat_item + {id_item + nome_item + quant_item} }2 ATOR: Gerente UC 9: Solicitar receita solic_receita = dt_emissao + periodo_apur periodo_apur = dt_inicio + dt_fim receita = dt_emissao + periodo_apur + vl_consumo + receita_realiz + receita_pend + receta_txServ + receita_total ATOR: Gerente mesa = nr_mesa id_mesa UC 10: Cadastrar mesa

ATOR: Gerente UC 11: Solicitar relao de notas penduradas solic_penduras = dt_emissao + periodo_apur periodo_apur = dt_inicio + dt_fim penduras = dt_emissao + periodo_apur + {id_cliente + nome_cliente + tel_cliente + notas_pend + vl_pendCli} + vl_pend notas_pend = 1{id_pedido + dt_pedido + nr_mesa + itens_nota + vl_nota} itens_nota = 1{id_item + cat_item + nome_item + p_item + quant_item + vl_item}

MOD Regras/P.Sint

Regras de derivao
Os slides a seguir apresentam vrias regras para a derivao dos diversos elementos de um modelo de classes: classes, associaes, atributos e operaes. Algumas caractersticas das regras so: Se corretamente aplicadas, produzem um diagrama de classes consistente com o modelo de UCs; Em geral, sua aplicao no pode ser (completamente) automatizada, pois exige anlise por parte do modelador.
3

Regra R1

CLASSES DE OBJETOS

Regra R1: Cada identificador gerado durante o processamento de um UC determina uma classe de objetos aplicao, representando os objetos identificados pelo identificador. Identificador gerado: identificador em um fluxo de sada que faz referncia a um objeto criado durante o processamento do UC.

id_pedido, identificador gerado no UC 1, determina a classe Pedido; id_pedido e id_cliente presentes no UC 3 no so identificadores gerados; As demais classes determinadas por essa regra so: Cliente (id_cliente, UC 6), Item (id_item, UC 7) e Mesa (id_mesa, UC 10).

ATOR: Cliente UC 1: Abrir pedido pedido = dt_pedido + id_mesa + itens_ped ..... id_pedido

Classe Pedido

ATOR: Cliente UC 3: Pedir a nota solicitacao_nota = id_pedido + [id_cliente] nota = id_pedido + nr_mesa + dt_pedido + itens_nota + vl_nota + [nome_cliente + tel_cliente] .....

Regra R2a

ASSOCIAES ENTRE CLASSES (1)

Regra R2: As associaes entre classes , a serem includas no DC, esto entre aquelas indicadas pelos pares (no-ordenados) de identificadores distintos, presentes na interface informacional (fluxos) de cada UC (nos fluxos de sada, basta considerar os identificadores gerados).
Em cada UC, cada par (no-ordenado) de identificadores deve ser analisado pelo modelador para decidir sobre a criao ou no, no diagrama, de uma associao entre as classes nomeadas por esses identificadores.
ATOR: Cliente UC 1: Abrir pedido pedido = dt_pedido + id_mesa + itens_ped itens_ped = 1{id_item + quant_item} id_pedido

Associao Pedido-Mesa Associao Pedido-Item

ATOR: Cliente

UC 3: Pedir a nota

solicitacao_nota = id_pedido + [id_cliente]

Associao Pedido-Cliente nota = id_pedido + nr_mesa + dt_pedido + itens_nota + vl_nota + [nome_cliente + tel_cliente]
..... ATOR: Cliente

Identificador no gerado
UC 5: Pendurar a nota

pendura = id_pedido + id_cliente

Associao Pedido-Cliente

ASSOCIAES ENTRE CLASSES (2) Dois identificadores so distintos quanto no tm exatamente a mesma designao. Por exemplo, id_mesa e id_pedido so ids distintos entre si. Trs questes devem ser consideradas para se decidir pela criao ou no de uma associao : 1) A associao deve ser necessria em pelo menos dois UCs do sistema; 2) A associao no deve ser redundante (ou seja, no deve j existir no DC, ou ser derivvel a partir de outras associaes j existentes); 3) A associao deve ser relevante para a aplicao, ou seja, ter significado no domnio da aplicao.
6

ASSOCIAES ENTRE CLASSES (3) Heursticas (dicas): 1. Para uma maior eficincia na descoberta de associaes relevantes e inditas logo de incio, deve-se analisar, primeiramente, os UCs com ids em ambos os fluxos (lembre-se que, no fluxo de sada, s so considerados os ids gerados). 2. Alm disso, tambm ajuda considerar primeiramente os pares de ids contendo 2 ou 1 ids gerados, nesta ordem. 3. Outra providncia que pode ajudar: se um UC tem uma pr-condio que exige a execuo prvia de outro UC, ento ele deve ser analisado depois deste outro.
7

MULTIPLICIDADE E TIPO DAS ASSOCIAES 1. Multiplicidade: Assim que uma nova associao identificada, deve-se tambm determinar a multiplicidade em cada extremo da associao. Isso importante porque as multiplicidades de uma associao traduzem parte do seu significado, e a explicitao desse significado ajuda o analista a confirmar a corretude das respostas dadas s trs questes do slide anterior.

2. Tipo: Pelo mesmo motivo, a cada nova associao, deve-se determinar o seu tipo: associao comum, agregao, composio ou generalizao.

DETERMINAO DOS ATRIBUTOS DAS CLASSES

A determinao dos atributos feita com base na necessidade de persistir (guardar, armazenar) os valores dos itens de informao que compem a interface informacional dos UCs;
Sero atributos das classes aqueles itens de informao, presentes na interface informacional dos UCs, que tiverem de ser persistidos (armazenados) entre UCs;

DETERMINAO E ALOCAO DOS ATRIBUTOS

As trs regras seguintes ajudam a determinar que itens devem ser persistidos (e portanto, quais deles sero atributos das classes) e a escolher a classe onde cada atributo deve ficar. Trs regras: R3a, R3b e R3c.

R3a e R3b: permitem identificar, dentre os itens elementares presentes na interface informacional dos UCs, quais devem ser persistidos (ou seja, quais devem se tornar atributos de classes). R3c: orienta sobre onde (em que classe) colocar o atributo.
10

Regra R3a

Atributos Provenientes dos Fluxos de Entrada

Regra R3a:Todo item elementar no-identificador, presente no fluxo de entrada de um UC e necessrio em outro UC, precisa ser persistido; caso contrrio (se no for necessrio em outro UC), no deve ser persistido. necessrio = consultado ou utilizado para obteno do valor de outro(s) item(s).

dt_pedido um item no-identificador e de entrada; Entra no UC 1 e reutilizado nos UCs 3 e 11.

ATOR: Cliente UC 1: Abrir pedido pedido = dt_pedido + id_mesa + itens_ped ...... ATOR: Cliente UC 3: Pedir a nota solicitacao_nota = id_pedido + [id_cliente] nota = id_pedido + nr_mesa + dt_pedido + itens_nota + vl_nota + [nome_cliente + tel_cliente] ATOR: Gerente UC 11: Solicitar relao de notas penduradas solic_penduras = periodo_apur + dt_emissao ....... penduras = dt_emissao + periodo_apur + {id_cliente + nome_cliente + tel_cliente + notas_pend + vl_pendCli} + vl_pend notas_pend = 1{id_pedido + dt_pedido + nr_mesa + itens_nota + vl_nota}

Concluso: dt_pedido deve ser persistido

11

Consistncia R3a/R3b

Verificao de Consistncia Regra R3a

Todo item presente no fluxo de entrada de um UC, que no for persistido, deve ser necessrio (utilizado) no prprio UC em que ele entra. Caso contrrio, tem-se uma inconsistncia do modelo de UCs: Ou est faltando especificar a utilizao do item (no prprio UC, ou em outro UC existente ou a ser criado); Ou o item no tem mesmo utilidade no sistema (e portanto, deveria ser eliminado).
Exemplo: O item descr_item, que entra no UC 7 (Atualizar o cardpio), no utilizado l, nem em qualquer outro UC. Com isso, percebe-se que falta, no sistema, um UC para fazer uso dessa informao (que poderia ser, por exemplo, um UC para imprimir o cardpio do restaurante). Outra possibilidade para se evitar a eliminao desse item considerar a existncia de um caso de uso (implcito) Retrieve, que faria a apresentao dos dados de um item, inclundo sua descrio.
12

Regra R3a

Atributos Provenientes dos Fluxos de Sada

Regra R3b: Todo item elementar no-identificador, presente no fluxo de sada de um UC, que representar informao histrica: a) Se for item primrio, deve ser persistido; b) Se for item derivado, persistir apenas se ele no puder ser restaurado no UC (opcionalmente, pode-se persistir o(s) item(s) de entrada necessrio(s) restaurao) informao histrica = informao vigente em um estado anterior ao estado corrente do sistema.
No sistema Restaurante (vide Slide 2): o item elementar no-identificador pc_item item primrio (informado) no UC 7: Atualizar o cardpio (com o nome de pc_unit), e est presente como informao histrica no fluxo de sada do UC 11 (Solicitar relao de notas penduradas). Portanto, esse item precisa ser persistido. Ele representa informao histrica no UC 11 porque entre a abertura de um pedido (UC 1) e a consulta da respectiva nota pendurada (UC 11), um item de consumo pode ter seu preo unitrio alterado (via UC 7). No sistema Restaurante no ocorre a persistncia de itens derivados. Isso porque, embora os itens elementares no-identificadores e derivados: vl_consumo, receita_realiz, receita_pend, receita_txServ e receita_total (IC 9), vl_pendCli, vl_pend, vl_nota, e vl_item (IC 11), representem informao histrica, eles podem ser restaurados a partir de outros itens anteriormente persistidos (por exemplo, vl_item, no IC 11, pode ser restaurado a partir dos itens quant_item e pc_item persistidos com base nas regras 13 R3a e R3b, respectivamente).

Observaes sobre as Regras R3a e R3b

1. Um item elementar presente no fluxo de sada de um UC item primrio se o seu valor estabelecido (originado) por um ator, no fluxo de entrada de algum UC. Por isso, eles tambm so denominados itens informados ou de entrada. Um item primrio difere de um item (elementar) derivado, pois este ltimo tem o seu valor derivado (calculado) pelo sistema a partir de outros itens elementares (primrios ou derivados). Outra denominao para item derivado item calculado. Por exemplo, no UC 3: Pedir a nota (vide slide 2): Itens primrios presentes no fluxo de sada: nr_mesa, dt_pedido, nome_cliente, tel_cliente, cat_item, nome_item, pc_unit e quant_item. Itens derivados presentes no fluxo de sada: vl_nota e vl_item. Eles tm seu valor estabelecido pelo sistema, a partir de outros itens de informao. 2. Quando se aplica a regra R3a a um UC do tipo Create deve-se considerar a possibilidade de o item ser necessrio no UC (implcito) Retrieve correspondente; se este for o caso, o item deve ser persistido. 14

Alocao dos Atributos s Classes e Criao de Classes de Associao

Regra R3a

Regra R3c: Cada item a persistir deve ser alocado como atributo de uma das classes alcanadas pelos identificadores presentes na mesma interface. Caso nenhuma dessas classes comporte o item, ele deve ser alocado em uma nova classe de associao criada para esse fim, correspondente a uma associao existente entre as classes alcanadas.
classes alcanadas por um identificador = classe que ele identifica + classes de associao nas quais ele participa (se existir).

Itens a persistir
ATOR: Cliente UC 1: Abrir pedido pedido = dt_pedido + id_mesa + itens_ped itens_ped = 1{ id_item + quant_item } id_pedido

Classes alcanadas por: id_mesa: Mesa; id_item: Item, Pedido-Item; id_pedido: Pedido, Pedido-Item.
ATOR: Cliente troco UC 4: Pagar a nota pagamento = id_pedido + vl_entregue + dt_pagto

Classes alcanadas por: id_pedido: Pedido, Pedido-Item.

15

CLASSES ALCANADAS POR UM IDENTIFICADOR

Classes alcanadas por um identificador: A classe que ele identifica, e As classes de associao nas quais ele participa como um dos identificadores (se existir).
Mesa

Classes alcanada s

id_mesa

1..1

Pedido-Item

Classes alcanadas por:

?..? 0..* Pedido

id_mesa: Mesa;
0..* ?..?
1..* Item

id_item:

Item, Pedido-Item;

0..? 0..*

id_pedido

id_item

id_cliente: Cliente; id_pedido: Pedido, Pedido-Item.

0..1 0..?
Cliente

id_cliente 16

Regra R3d

ATRIBUTOS DE ESTADO

Atributo de estado um atributo que no provm dos itens de informao presentes na interface informacional dos UCs, mas da simples ocorrncia do evento que ativa um UC. Representa uma mudana de estado de um objeto do sistema, resultante da realizao do UC.

Duas regras, uma geral e outra restrita:

Regra R3d (atributos de estado regra geral): UCs que produzem, em um ou mais objetos do sistema, mudana de estado que no possa ser expressa atravs dos atributos j existentes nas classes dos objetos, ou atravs de novas ligaes em que os objetos participem, determinam a introduo de um atributo de estado na respectiva classe do objeto.
Regra R3e (atributos de estado regra restrita): Todo UC com interface informacional constituda de apenas fluxo de entrada contendo exclusivamente um nico identificador, determina a introduo de um atributo de estado em uma das classes alcanadas por esse identificador. A regra R3d geral porque se aplica a qualquer UC, permitindo, inclusive, a descoberta dos atributos de estado que a regra R3e capaz de determinar. Entretanto, a existncia da regra R3e se justifica pela facilidade de sua aplicao.

Regra R3d

ATRIBUTOS DE ESTADO - EXEMPLOS

Regra R3e (atributos de estado regra restrita): Todo UC com interface informacional constituda de apenas fluxo de entrada contendo exclusivamente um nico identificador, determina a introduo de um atributo de estado em uma das classes alcanadas por esse identificador.

Regra R3d (atributos de estado regra geral): UCs que produzem, em um ou mais objetos do sistema, mudana de estado que no possa ser expressa atravs dos atributos j existentes nas classes dos objetos, ou atravs de novas ligaes em que os objetos participem, determinam a introduo de um atributo de estado na respectiva classe do objeto.

ATOR: Cliente

UC 2: Cancelar pedido

cancela_ped = id_pedido ATOR: Cliente UC 4: Pagar a nota

A regra R3e aplicvel e resulta no atributo de estado cancelado, na classe Pedido.

O fluxo de entrada no contm apenas identificadores; portanto a regra R3e no aplicvel. dt_pagto capaz de traduzir a mudana de estado ; portanto, no necessrio incluir um novo atributo de estado.

pagamento = id_pedido + vl_entregue + dt_pagto troco ATOR: Cliente UC 5: Pendurar a nota

pendura = id_pedido + id_cliente

O fluxo de entrada no contm apenas um nico identificador; portanto a regra R3e no aplicvel.
18

No entanto, preciso criar o atributo de estado: pendurado

Regra R4a

OPERAES DAS CLASSES: CONSTRUTORAS

Regra R4a (operaes construtoras): Todo identificador gerado produz uma operao construtora na classe identificada por esse identificador.

Identificador gerado
ATOR: Cliente UC 1: Abrir pedido pedido = dt_pedido + id_mesa + itens_ped itens_ped = 1{id_item + quant_item} id_pedido ATOR: Gerente id_cliente ATOR: Gerente UC 7: Atualizar o cardpio item_consumo = nome_item + pc_unit + cat_item + descr_item id_item ATOR: Gerente mesa = nr_mesa id_mesa UC 10: Cadastrar mesa UC 6: Cadastrar cliente habitual cliente = nome_cliente + tel_cliente

Os argumentos provem dos itens presentes no fluxo de entrada do UC

Operao (classe Pedido): Pedido (in dtPedido:Date, in mesa: Mesa, in itensPed: Object) Operao (classe Cliente): Cliente (in nomeCli: String, in telCli: String) Operao (Classe Item): Item (in nomeItem: String, in pcUnitItem: Currency, in catItem: String , in descrItem: String)

Operao (classe Mesa): Mesa (in nrMesa: Byte)

19 O tipo dos argumentos provm do Dicionrio de Itens

OPERAES DAS CLASSES: ITENS DERIVADOS Regra R4b

Regra R4b: Todo item derivado no persistido produz uma operao para calcular o seu valor, a ser includa em uma das classes alcanadas pelos identificadores presentes na interface informacional do UC, ou na classe que representa a aplicao.
ATOR: Cliente UC 3: Pedir a nota

solicitacao_nota = id_pedido + [id_cliente] nota = id_pedido + nr_mesa + dt_pedido + itens_nota + vl_nota + [nome_cliente + tel_cliente] itens_nota = 1{id_item + cat_item + nome_item + p_unit + quant_item + vl_item} ATOR: Cliente UC4: Pagar a nota

As operaes retornam valor (so funes); Os argumentos de entrada provm de itens no fluxo de entrada do UC.

Operao (classe Pedido) : vl_nota (): Currency

Operao (classe Pedido) : troco (in vlEntregue: Currency): Currency

pagamento = id_pedido + vl_entregue + dt_pagto troco ATOR: Gerente UC 8: Solicitar consumo dirio solic_consumo = dt_emissao + dt_consumo consumo_dia = dt_emissao + dt_consumo + consumo_itens consumo_itens = 0{cat_item + {id_item + nome_item + quant_item} }2 ATOR: Gerente UC 9: Solicitar receita solic_receita = periodo_apur + dt_emissao receita = dt_emissao + periodo_apur + vl_consumo + receita_realiz + receita_pend + receita_txServ + receita_total

Operao (classe Item) : quant_item (in dtConsumo: Date): short Operaes (classe Restaurante): vl_consumo (in dtInicApur: Date, in dtFimApur: Date): Currency recRealiz (... idem anterior ...): Currency recPend (... idem anterior ...): Currency recTxServ (... idem anterior ...): Currency recTotal (... idem anterior ...): Currency 20

Regra R4c

OPERAES DAS CLASSES: FLUXOS DE SADA

Regra R4c: Todo fluxo de sada, presente em UC cujo processamento no produz mudana de estado no sistema (UCs de consulta) e que no se resuma a apenas um nico item no persistido, d origem a uma operao para produo do fluxo, a ser includa em uma das classes alcanadas pelos identificadores presentes na interface informacional do UC, ou na classe que representa a aplicao.

Mesmo nome do fluxo de sada

ATOR: Gerente UC 8: Solicitar consumo dirio solic_consumo = dt_emissao + dt_consumo consumo_dia = dt_emissao + dt_consumo + consumo_itens consumo_itens = 0{cat_item + {id_item + nome_item + quant_item} }2 ATOR: Gerente UC 9: Solicitar receita

Operao (classe Restaurante) : consumo_dia (in dtEmissao, dtConsumo: Date)

Operao (classe Restaurante) : receita (in dtEmissao, dtInicApur, dtFimApur: Date)

solic_receita = periodo_apur + dt_emissao periodo_apur = dt_inicio + dt_fim receita = dt_emissao + periodo_apur + vl_consumo + receita_realiz + receita_pend + receita_txServ + receita_total ATOR: Gerente UC 11: Solicitar relao de notas penduradas

solic_penduras = periodo_apur + dt_emissao periodo_apur = dt_inicio + dt_fim penduras = dt_emissao + periodo_apur + {id_cliente + nome_cliente + tel_cliente + notas_pend + vl_pendCli} + vl_pend notas_pend = 1{id_pedido + dt_pedido + nr_mesa + itens_nota + vl_nota} itens_nota = 1{id_item + cat_item + nome_item + p_item + quant_item + vl_item}

Os argumentos de entrada provem de itens no fluxo de entrada do UC; As operaes no retornam valor (so procedimentos).
Operaes (classe Restaurante): penduras (in dtEmissao, dtInicApur, dtFimApur: Date)
21

OPERAES DAS CLASSES: MUDANA DE ESTADO Regra R4d

Regra R4d: Todo IC que causa mudana no estado do sistema produz uma operao para realizar essa mudana e para produzir o fluxo de sada (se existir), a menos que uma operao construtora, resultante da aplicao da regra R4a, realize toda a mudana de estado requerida, e no exista sada a produzir. A operao deve ser includa em uma das classes alcanadas pelos identificadores presentes na interface informacional do UC, ou na classe que representa a aplicao.
Mesmo nome do UC
ATOR: Cliente UC 2: Cancelar pedido
Operao (classe Pedido) : cancelarPed ()

cancela_ped = id_pedido ATOR: Cliente UC 3: Pedir a nota solicitacao_nota = id_pedido + [id_cliente] nota = id_pedido + nr_mesa + dt_pedido + itens_nota + vl_nota + [nome_cliente + tel_cliente] itens_nota = 1{id_item + cat_item + nome_item + p_unit + quant_item + vl_item} ATOR: Cliente troco ATOR: Cliente UC 5: Pendurar a nota pendura = id_pedido + id_cliente UC 4: Pagar a nota pagamento = id_pedido + vl_entregue + dt_pagto

Os argumentos de entrada provem de itens no fluxo de entrada do UC; As operaes no retornam valor (so procedimentos).
Operao (classe Pedido) : pagarNota (in dtPagto: Date)
22

Operaes (classe Pedido): pendurarNota (in cliente: Cliente)

Mod. de Classes final

MODELO DE CLASSES RESULTANTE

1

0..*

A visibilidade das operaes public

23