Sistema de Gestão

de Empresa de Eventos
Etapas 3 e 4

Carlos Henrique Silva de Oliveira Bueno

Henrick Oliveira de Souza
Vitor Hugo Souto Oliveira
Diagrama de Visão Geral de Interação
Diagrama de Atividades

Diagrama de atividades descreve o que o sistema deve fazer

Visão básica do processo de cadastro de eventos e cobrança de contas
A partir desse diagrama foram identificados dois novos casos de uso:
Emitir contrato de evento
O caso de uso “Cadastrar evento de um cliente” inclui esse caso de uso
Contratar serviços
Esse caso de uso estende “Cadastrar evento de um cliente”
Primeiro Refinamento de Casos de Uso
Diagramas de Comunicação — Cadastro de Evento
Diagramas de Comunicação — Cadastro de Evento
Esse diagrama descreve o “Quem Faz” no caso em que tudo dá certo com relação ao cadastro de eventos
Como fruto dessa etapa da modelagem surge outro caso de uso, “Gera conta” que descreve mais uma
ação executada durante o cadastro de um evento.
Assim como “Emitir contrato de evento”, esse caso de uso está incluso em "Cadastrar evento de um
cliente”
Diagramas de Comunicação — Cobrança de Conta
Diagramas de Comunicação — Cobrança de Conta
Esse diagrama descreve o “Quem Faz” no caso em que tudo dá certo com relação à cobrança de conta
A gente considerou como o caso de sucesso nesse diagrama quando uma conta ainda não foi paga pra descrever completamente o
processo de pagamento
Nenhum caso de uso novo foi gerado a partir desse diagrama
Os casos de uso relacionados a esse processo permaneceram da seguinte forma:
Diagramas de Sequência — Cadastro de um evento
Diagramas de Sequência — Cadastro de um evento
Esse diagrama descreve o “Quem Faz” em todos os casos do cadastro de um evento
Primeira decisão que foi tomada explicitamente nesse diagrama foi que o processo de cadastro de evento só acontece se a resposta da
requisição feita por uma instância de Funcionário não for nula, ou seja, um funcionário responsável for atribuído ao cadastro do evento
Isso porque não faz sentido um cliente ter a possibilidade de cadastrar um evento quando isso envolve a compra ou uso de produtos
comprados e a possível contratação de serviços
Uma vez que o funcionário for designado, o cliente vai checar as opções de temas, pacotes e serviços e enviar os detalhes para o
funcionário que lhe foi designado
Depois disso, através da instância de empresa, o funcionário vai encaminhar os detalhes do evento para eventualmente ele ser
adicionado à agenda e haver a emissão de contrato e geração de uma conta associados ao evento
Diagramas de Sequência — Cadastro de um evento

Uma vez que os detalhes tenham sido encaminhados para EmpresaEventos, a empresa extrai os produtos dos pacotes
Com os produtos e quantidades em mãos, checa-se o estoque para ver se os produtos na quantidade necessária estão disponíveis
Diagramas de Sequência — Cadastro de um evento

Caso existam produtos sem estoque o suficiente, entra no fragmento combinado ALT que prevê essa condição
Realiza-se o pedido dos produtos sem estoque suficiente, o que dispara um loop pra pedir cada produto individualmente
Dentro do loop o pedido é realizado e o produto adicionado ao estoque
Caso algum dos pedidos não seja atendido, conforme a anotação, há um break no loop e a variável atendidos é false
A UML não prevê breaks, então a anotação já pensa um pouco no processo de implementação
Diagramas de Sequência — Cadastro de um evento

Após o loop nos produtos sem estoque, um fragmento combinado ALT checa se algum dos pedidos não foi atendido
Caso algum deles não tenha sido atendido, os pedidos cancelados, de forma a evitar prejuízos, assim como o próprio evento
Abaixo da linha pontilhada fica o “else” desse fragmento, que cobre o caso de que todos os pedidos tenham sido atendidos
Nesse caso, remove-se do estoque os produtos na quantidade necessária para atender ao evento e entramos no subdiagrama de
finalização de cadastro de eventos
Diagramas de Sequência — Cadastro de um evento

E por fim, temos o else do fragmento combinado que checava se os produtos estavam sem estoque
Aqui removemos do estoque esses produtos e chamamos também o subdiagrama de finalização de cadastro
Diagramas de Sequência — Cadastro de um evento (finalização)

Na finalização do cadastro a empresa contrata os serviços que foram designados pelo cliente (caso não exista nenhum serviço o loop não
começaria)
Os detalhes são repassados para agenda e por fim o evento é criado e tanto conta quanto contrato são emitidos.
Diagramas de Sequência — Cadastro de um evento

Como resultado dessa etapa surge o caso de uso “Enviar detalhes de evento” e o caso de uso “Cadastrar evento de um cliente” passa a
estendê-lo
Diagramas de Sequência — Cadastro de um evento

Também surge os casos de uso:

“Cancelar cadastro de evento”, que estende “Enviar detalhes de evento”
“Contratar servicos”, que estende “Enviar detalhes de evento” e tem relação tanto com AtorFuncionario quanto AtorFornecedor
Diagramas de Sequência — Cadastro de um evento

Por fim, surge o caso de uso “Checar estoque”, que estende também “Enviar detalhes do evento” e está associado com AtorFuncionario e
o caso de uso “Realizar pedido de compra para o fornecedor, que estende o caso de uso já existente “Receber pedido de compra”
Diagramas de Sequência — Cobrança de Conta

A partir de AtorFuncionario começa o processo de checagem de contas, que parte de uma instância de Funcionario para uma instância de
EmpresaEventos e dessa instância para uma instância de AgendaEventos.
Uma vez na agenda, começa o fragmento combinado LOOP que vai passar por todos os eventos na agenda
Diagramas de Sequência — Cobrança de Conta
Diagramas de Sequência — Cobrança de Conta
Dentro do loop, a instância de agenda checa um Evento por vez através de checaConta(), que por sua vez checa a instância de Conta
dentro de si para verificar o pagamento
Caso a conta ainda não tenha sido paga, realiza a cobrança para a instância de Cliente associada a conta.
Caso o cliente tenha saldo suficiente, o pagamento é realizado e se dá baixa em conta.
Não foge do que foi visto previamente no diagrama de comunicação, havendo a adição apenas dos fragmentos combinados que
envolvem o loop e a checagem dos estados das variáveis.
O diagrama de casos de uso permanece o mesmo:
Diagramas de Máquina de Estados — Classe Conta

Existem dois pontos de partida nesse diagrama de classes

Estado instanciada, atributo pago = false
Transição verificaPagamento() retorna para instanciada
Transição realizaCobranca() para um pseudoestado de escolha
Se pagamentoRecebido usa a transição darBaixaEmConta() para o estado contaPaga
Se NOT pagamentoRecebido retorna para o estado instanciada
Estado contaPaga, atributo pago = true
Transição verificaPagamento() retorna para contaPaga
Transição sem guarda para o final
Diagramas de Máquina de Estados — Classe Estoque
Diagramas de Máquina de Estados — Classe Estoque
Parte do estado instanciada, descrito por
pedidosDeCompra nulo
produtosEmEstoque nulo
algumPedidoPendente = false
A transição fazPedidos() parte de instanciada para o estado pedidos pendentes, descrito por:
pedidosDeCompra não nulo
algumPedidoPendente = true
A transição pedidoDeProduto() parte de pedidos pendentes para um pseudoestado de escolha
Se NOT produtoRecebido, a transição cancelaPedidos() retorna para o estado instanciada
Se produtoRecebido, a transição adicionaNoEstoque() parte desse pseudoestado de escolha para outro pseudoestado de escolha
A partir desse pseudoestado, verifica-se se há ainda algumPedidoPendente
Em caso negativo, parte para o estado produtos em estoque
Em caso positivo, retorna para o estado pedidos pendentes
Voltando ao estado instanciada, a transição pedidoDeProduto() parte para um pseudoestado de escolha
Se NOT produtoRecebido, retorna para o estado instanciada
Se produtoRecebido, a transição adicionaNoEstoque() parte para o estado produtos em estoque
O estado produtos em estoque é descrito por:
pedidosDeCompra não nulo
produtosEmEstoque não nulo
algumPedidoPendente = false
A partir de produtos em estoque, parte-se para o final
Diagramas de Máquina de Estados
A classe Evento era uma candidata para ter uma máquina de estados, afinal dá para contar uma historinha com as situações envolvendo
um evento
Contudo, foi decidido durante a etapa 3, no diagrama de sequência, que as checagens que ocasionariam no cancelamento de um evento
seriam feitas anteriormente a existência de uma instância da classe
Sendo assim, Evento acabou por não ter um diagrama de máquina de estados devido a falta de estados relevantes restritos apenas a
essa classe