Professional Documents
Culture Documents
CF-Rest
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
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
ATOR: Cliente
UC 3: Pedir a nota
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
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.
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;
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
11
Consistncia R3a/R3b
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
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).
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
15
Classes alcanada s
id_mesa
1..1
Pedido-Item
id_mesa: Mesa;
0..* ?..?
1..* Item
id_item:
Item, Pedido-Item;
0..? 0..*
id_pedido
id_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.
Regra R3d
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
O fluxo de entrada no contm apenas um nico identificador; portanto a regra R3e no aplicvel.
18
Regra R4a
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
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.
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
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.
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
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
0..*
23