Sistema de Gestão

de Empresa de Eventos
Relatório

Carlos Henrique Silva de Oliveira Bueno

Henrick Oliveira de Souza
Vitor Hugo Souto Oliveira
Diagrama de Classes — Versão Inicial
Diagrama de Classes — Versão Inicial
Nós criamos essa versão do diagrama de classes já pensando em como as partes do sistema se comunicariam entre si
A estrutura básica não mudou muito, mas nós acabamos adicionando duas novas classes que foram identificadas respectivamente
na etapa 3 e na etapa 5, sendo elas:
ProdutoVenda
Identificada ao ver que seria necessário que os pacotes de produto guardassem a informação de produto e quantidade
ofertada desses produtos
DispatchServlet
Introduzida como elemento da solução computacional
O relacionamento entre as classes da fase inicial quase se manteve o mesmo, salvo as exceções:
Classe PacoteProduto passar a agrupar ProdutoVenda, que por sua vez depende de Produto
Classe EmpresaEventos deixa de agrupar a classe genérica Pessoa e passa a agrupar suas especializações
O relacionamento inicial foi um equívoco da nossa parte, consertado durante as etapas seguintes
Classe DispatchServlet passa a se associar às classes:
EmpresaEventos
Cliente
Funcionario
Fornecedor
Diagrama de Classes — Versão Final
Diagrama de Casos de Uso (Cadastro de Evento) — Versão Inicial
Diagrama de Casos de Uso (Cadastro de Evento) — Versão Final
Diagrama de Casos de Uso (Cadastro de Evento) — Versão Final
Comparando esses diagramas a gente consegue demonstrar como as responsabilidades do sistema se desenvolveram desde a
versão inicial.
Na nossa primeira iteração, os casos de uso referentes a cadastro de evento envolviam apenas os atores AtorFuncionario e
AtorCliente.
Conforme a modelagem prosseguiu, com o diagrama de comunicação e depois o diagrama de sequência, nós conseguimos
identificar quais casos de uso precisariam ser particionados e quais precisariam ser adicionados ou envolver outros atores.
No fim nós conseguimos chegar em uma estrutura que envolvesse os três atores previstos no sistema e que explicitasse o
relacionamento entre eles através dos casos de uso.
Diagrama de Casos de Uso (Cobrança de Contas) — Versão Final

Durante a modelagem, algumas partes também se mantiveram.

Mesmo após a introdução dos elementos da solução computacional, os casos de uso referentes a essa porção do sistema não se
alteraram.
Um alteração associada ao AtorCliente e ao AtorFuncionario que vale ser explicitada envolvendo essa etapa foi a mudança do caso
de uso “Cadastrar clientes” do AtorFuncionario para o AtorCliente. Essa alteração é fruto da decisão de tratar o sistema como o
back-end de uma aplicação.
Diagramas de Sequência
Os diagramas de sequência foram os que mais sofreram alterações durante o processo de modelagem com a introdução dos
elementos da solução computacional.
A introdução da classe DispatchServlet introduziu uma nova camada na comunicação entre as classes e trouxe a interação com os
atores para dentro desse diagrama, com comandos sendo enviados para a instância dessa classe representada no diagrama para
então serem encaminhados para o resto do sistema ou servirem como feedback para os atores.
Ex.: Diagrama de Sequência — Cadastro de Evento de Clientes
Diagramas de Algoritmos de Métodos — solicitaEvento

No que se refere a algoritmos de métodos, nós mantivemos a abordagem de modelar apenas os métodos que não tivessem a
implementação óbvia por sua assinatura ou que envolvessem passos complexos.
Esse método, solicitaEvento da classe DispatchServlet tem a responsabilidade de encaminhar a solicitação feita pelo AtorCliente
para a instância de Cliente referente ao solicitante no sistema, notificar o atendimento caso tenha sucesso e pedir e encaminhar as
opções para o AtorCliente.
Apesar de ter uma assinatura instintiva, esse método envolvia mais passos do que deixava transparecer, então nós resolvemos
fazer a modelagem do algoritmo.
Diagramas de Algoritmos de Métodos — checaConta

Outros métodos também foram modelados, mas o que melhor exemplifica o resultado do
processo de modelagem é o método checaContas.
A modelagem de algoritmo desse método surgiu tanto do diagrama de sequência quanto do
diagrama de máquina de estados referente à classe Conta.
A partir do diagrama nós geramos o código que faria parte de uma possível implementação
computacional do sistema
Diagramas de Algoritmos de Métodos — checaConta

Como podemos ver, a invocação dos métodos detalhados no diagrama acontece aqui também, na mesma ordem que
O loop do-while não é óbvio a partir do diagrama, o que exemplifica a necessidade da discrição de quem quer que fosse
implementar o sistema, mesmo tendo os algoritmos modelados.