Você está na página 1de 44

Unioeste Universidade Estadual do Oeste do Paran

CENTRO DE CINCIAS EXATAS E TECNOLGICAS


Colegiado de Cincias da Computao
Curso de Bacharelado em Cincias da Computao

Especificao de Requisitos e Modelagem


Sistema de Entrega de Pizza - SISEP

Andr Luiz Luchesi


Eder Schaphauser Ziomek
Heitor Faccioni

Cascavel Paran 12 de abril de 2012

SUMRIO
1. INTRODUO.............................................................................................................3
2. PROBLEMA DA EMPRESA.......................................................................................3
3. METODOLOGIA ESCOLHIDA..................................................................................3
4. MODELAGEM ORGANIZACIONAL I*....................................................................4
4.1. MODELO DE DEPENDNCIAS ESTRATGICAS...............................................4
4.1.1 DESCRIO DO MODELO DE DEPENDNCIAS ESTRATGICAS..............4
4.2. MODELO DE RAZES ESTRATGICAS..............................................................8
4.2.1 DESCRIO DO MODELO DE DEPENDNCIAS ESTRATGICAS...............8
5. ESPECIFICAO DE REQUISITOS .......................................................................10
5.1 REQUISITOS FUNCIONAIS...................................................................................10
5.2 REQUISITOS NO FUNCIONAIS ........................................................................14
6. O GRAFO SIG............... 16
7. CASOS DE USO ........................................................................................................18
7.1. DIAGRAMA DOS CASOS DE USO......................................................................18
7.2. DIAGRAMA DOS CASOS DE USO......................................................................19
8. DIAGRAMAS DE CLASSES ....................................................................................29
9. CONCLUSO.............................................................................................................43
APNDICE A COLETA DE INFORMAES..........................................................43

SUMRIO DE FIGURAS
FIGURA 1. MODELO DE DEPENDNCIAS ESTRATGICAS.................................7
FIGURA 2. MODELO DE RAZES ESTRATGICAS................................................9
FIGURA 3. GRAFO SIG .............................................................................................. 17
FIGURA 4. DIAGRAMA DE CASOS DE USO............................................................18
FIGURA 5. DIAGRAMA DE CLASSES.......................................................................30

1. INTRODUO E MOTIVAO
A equipe busca por conhecimento visando aprender as tcnicas de engenharia de
software, com o objetivo de aplicar essas tcnicas de forma correta para o
desenvolvimento de sistemas em geral.
A equipe deseja criar um software que auxilie pizzarias com as entregas, esse
sistema ir conter um controle de caixa, cadastro de clientes, produtos e pizzas. O
sistema far o gerenciamento de vendas, desde o pedido at a entrega da pizza, bem
como dar suporte para pedidos de pizzas e acompanhamentos especificando se haver
entrega. O sistema exibe um status informando em qual estagio o pedido se encontra e
para fins de planejamento estratgico e econmico o gerente pode Relatrios.
O sistema apresentar uma interface padronizada e intuitiva. O objetivo
diminuir o tempo e esforo gasto nos procedimentos, aumentando a produtividade e
gerenciando os pedidos com uma melhor qualidade e segurana.
2. PROBLEMA DA EMPRESA
O problema consiste em desenvolver um sistema que auxilie a pizzaria Bella
Pizza.LTDA, com o foco especifico no setor de entrega de pizza. A pizzaria trabalha
com entrega a domicilio e retirada no balco, hoje a empresa trabalha com processo
manual, o processo consiste em atender o cliente e anotar em nota de pedido da
empresa, em duas vias o nome, telefone, hora do pedido, o pedido, observaes,
previso de concluso e no caso de entrega tambm anotado o endereo. Aps
efetuado o pedido ele despachado para a cozinha e s retorna quando com a pizza
pronta para seu devido destino (entrega no balco ou entrega domicilio).
Devido ao grande fluxo de pedidos em determinados horrios a empresa
necessita de um sistema que agilize e gerencie o processo.
3. METODOLOGIA ESCOLHIDA
Scrum foi a metodologia escolhida nesse trabalho, devido a as suas
caractersticas de metodologia gil de desenvolvimento, focada no trabalho em equipe,
com equipes auto-gerenciadas e participao ativa do cliente para gesto e planejamento
de projetos de software.
A rotina de Scrum comea com o product backlog, lista dos requisitos do
projeto, ordenados por prioridade. A partir desta lista formado o sprint backlog
requisitos que sero implementados no prximo sprint (iterao); cada sprint dura cerca
de 30 dias e, aps seu final, as funcionalidades desenvolvidas so validadas pelo
product owner (cliente, normalmente) e liberadas, iniciando-se um novo ciclo.
A rotina de Scrum consiste nos seguintes passos:
1. O ScrumMaster, que mantm os processos (normalmente no lugar de um gerente de
projeto).
2. O Proprietrio do Produto, ou Product Owner, que representa os stakeholders e o
negcio.
3. A Equipe, ou Team, um grupo multifuncional com cerca de 7 ou menos pessoas e que
fazem a anlise, projeto, implementao, teste etc.
O Scrum incentiva o controle da qualidade como varivel do projeto, dentre as
variveis de controle em projetos (custo, tempo, qualidade e escopo), h um foco
3

explcito em escopo (backlog). Para isso, recomenda-se a priorizao de funcionalidades


que representem maior valor possvel para o negcio. Desta forma, caso seja necessrio
diminuio de escopo, as funcionalidades menos valiosas sero adiadas ou canceladas.
4. MODELAGEM ORGANIZACIONAL i*
A tcnica I* de YU (1995) composta por dois modelos: o Modelo de
Dependncias Estratgicas (SD) e o Modelo de Razes Estratgicas (SR).
O Modelo de Dependncias Estratgicas (SD) descreve os relacionamentos de
dependncia entre vrios atores no contexto organizacional, enquanto o Modelo de
Razes Estratgicas (SR) descreve os interesses e preocupaes dos stakeholders, e as
razes que os levam a adotar uma configurao ou outra.
4.1. MODELO DE DEPENDNCIAS ESTRATGICAS
A partir de uma viso macro do modelo de Dependncias Estratgicas (SD)
figura 2, nota-se que composto de cinco atores, sendo que a utilizao direta do
sistema feita apenas pelos atores gerente e funcionrio, essa interao especificada
pelas dependncias destes com o ator sistema.
4.1.1 Descrio do modelo de Dependncias Estratgicas
Os crculos representam os atores, como Motoboy, Cliente, SisEP,
Funcionrio e Gerente. Os atores que efetivamente executaro atividades no sistema
so: SisEP, Funcionrio e Gerente. Os retngulos so os recursos, ou seja, os dados
propriamente ditos. As outras formas so os softgoals. Eles simbolizam o que o sistema
deve proporcionar (independentemente dos requisitos e das funcionalidades, os
softgoals devem ser satisfeitos).
Ator SisEP
O ator SisEP o sistema computacional. Este responsvel pelo armazenamento,
gerenciamento e manipulao dos dados. Atravs dele que os outros atores iro solicitar
tarefas, inserir e visualizar os dados.
Ator Funcionrio
O ator funcionrio o usurio comum do sistema. Este ter acesso a uma parte
do sistema, este ator somente poder realizar as seguintes tarefas:
Checar cadastro do cliente, gerenciar (inserir, alterar, remover e buscar) cliente, fazer
pedido, acompanhar pedido, alterar status do pedido, cancelar pedido, adicionar
acompanhamento no pedido, adicionar pizza no pedido, receber pagamento, gerar nota e
realizar backup.
Ator Gerente
O ator gerente o usurio que tem acesso a todas as tarefas do funcionrio e
possui privilegio no sistema podendo realizar alm das tarefas do funcionrio as
seguintes tarefas:
Gerenciar (inserir, alterar, remover e buscar) categoria, gerenciar (inserir, alterar,
remover e buscar) acompanhamento, gerenciar (inserir, alterar, remover e buscar)
sabores, gerar Relatrios, logar no sistema, deslogar do sistema e alterar a Senha.

Ator Motoboy
O ator motoboy no vai interagir com o sistema. Ele responsvel por pegar
pedidos de clientes, junto com cada pedido tem uma nota, ele recebe ambos do
funcionrio e aps tem a funo de entregar aos clientes, aps feita a entrega, caso o
pedido do cliente no tenha sido pago anteriormente o motoboy deve receber o valor
referente ao pedido e mais o preo da entrega. Aps ter recebido o ator motoboy deve
retornar a pizzaria e entregar o valor ao funcionrio.
Ator Cliente
O ator cliente no vai interagir com o sistema. Ele responsvel pelos pedidos
feito na pizzaria. O ator cliente faz pedidos escolhendo suas pizzas e acompanhamentos
e escolhe se deseja que seu pedido seja entregue ou no. O ator cliente pode pagar seu
pedido no balo ou pagar ao motoboy em caso de entrega.
Interao entre Ator Motoboy e Ator Funcionrio.
Obter nota fiscal : O ator motoboy obtm a nota fiscal referente a um pedido com o
ator funcionrio.
Pegar Pedido: O ator motoboy obtm um pedido com pizzas e acompanhamentos quem
so para entrega com o ator funcionrio.
Receber Pagamento: O ator motoboy recebe o pagamento referente a um pedido e
entrega este pagamento ao ator funcionrio.
Interao entre Ator Cliente e Ator Funcionrio.
Pagar Pedido: O ator cliente pode pagar o seu pedido diretamente no balo para o ator
funcionrio ou pode pagar para o ator motoboy em caso de entrega.
Interao entre Ator Funcionrio e Ator SisEP
Alterar Status: O ator funcionrio modifica o status de um pedido conforme as suas
etapas so concludas.
Cancelar Pedido: O ator funcionrio cancela um pedido.
Acompanhar Pedido: O ator funcionrio acompanha o pedido verificando sua etapa.
Receber Pagamento: O ator funcionrio recebe um pagamento do ator motoboy ou do
ator cliente.
Backup: O ator funcionrio gera um backup do sistema.
Fazer Pedido: O ator funcionrio faz um pedido para o ator cliente selecionando pizza
e acompanhamento conforme o gosto do ator cliente.
Gerar Nota: O ator funcionrio gera uma nota do pedido.
Alterar Cliente: O ator funcionrio altera as informaes de um cliente no sistema.
Buscar Cliente: O ator funcionrio busca um cliente no sistema.
Inserir Cliente: O ator funcionrio insere um novo cliente no sistema.
Remover Cliente: O ator funcionrio remove um cliente do sistema.
Adicionar Pizza no Pedido: O ator funcionrio adiciona uma pizza ao pedido.
Adicionar Acompanhamento no Pedido: O ator funcionrio adiciona um
acompanhamento ao pedido.
Checar Cadastro: O ator funcionrio checa se j existe um certo cadastro de um
cliente.

Interao entre Ator Gerente e Ator SisEP


Buscar Categoria: O ator gerente busca uma categoria no sistema.
Alterar Categoria: O ator gerente altera uma categoria no sistema.
Inserir Categoria: O ator gerente insere uma nova categoria no sistema.
Remover Categoria: O ator gerente remove uma categoria do sistema.
Relatrios: O ator gerente pode gerar relatrios.
Buscar Acompanhamento: O ator gerente busca um acompanhamento no sistema.
Alterar Acompanhamento: O ator gerente altera um acompanhamento no sistema.
Inserir Acompanhamento: O ator gerente insere um novo acompanhamento no
sistema.
Remover Acompanhamento: O ator gerente remove um acompanhamento do sistema.
Buscar Sabores: O ator gerente busca um sabor no sistema.
Alterar Sabores: O ator gerente altera um sabor no sistema.
Inserir Sabores: O ator gerente insere um novo sabor no sistema.
Remover Sabores: O ator gerente remove um sabor do sistema.
Alterar Senha: O ator gerente alterar a sua senha de acesso a regio do gerente.
Logar no Sistema: O ator gerente efetua o login na regio do gerente.
Deslogar do Sistema: O ator gerente desloga do sistema.

Figura 1. Modelo de Dependncias Estratgicas - SD

4.2 MODELO DE RAZES ESTRATGICAS


O modelo de Razes Estratgicas (SR), ilustrado na figura 3, complementa o
modelo Dependncia Estratgicas (SD) de forma a compreender e modelar de maneira
mais detalhada as razes associadas com cada ator e suas dependncias.
4.2.1 Descrio do modelo de Dependncias Estratgicas
A descrio visa mostrar de uma maneira melhor como compreender o modelo
de Razes Estratgicas (SR) que um complemento do modelo anteriormente j
descrito modelo de Dependncia Estratgicas (SD).
Interao entre Ator Cliente e Ator Funcionrio.
Pagar Pedido: O ator cliente pode pagar o seu pedido diretamente no balo para o ator
funcionrio ou pode pagar para o ator motoboy em caso de entrega.
Interao entre Ator Funcionrio e Ator SisEP
Alterar Status: A tarefa Alterar Status consiste na tarefa Selecionar Pedido.
Cancelar Pedido: A tarefa Cancelar Pedido consiste nas tarefas (Selecionar Pedido e
Efetuar Cancelamento).
Acompanhar Pedido: A tarefa Acompanhar Pedido consiste nas tarefas (Obter Status e
Buscar Pedido).
Receber Pagamento: A tarefa Receber Pagamento consiste nas tarefas (Selecionar
Pedido, Efetuar Pagamento e Selecionar Forma de Pagamento, que tem como opes:
[carto de credito, carto de debito e dinheiro]).
Backup: A tarefa Backup consiste na tarefa Gerar Backup.
Fazer Pedido: A tarefa Fazer Pedido consiste nas tarefas (Checar Cadastro que consiste
nas tarefas [Selecionar Cliente e Cadastrar Cliente], Adicionar Acompanhamento no
Pedido e Adicionar Pizza no Pedido que consiste nas tarefas [Escolher Tamanho,
Escolher Sabores]).
Gerar Nota: A tarefa Gerar Nota consiste na tarefa de selecionar um pedido.
Gerenciar Cliente: A tarefa Gerenciar Cliente consiste nas tarefas (Alterar cliente,
Buscar Cliente, Inserir Cliente, Remover Cliente).
Checar Cadastro: A tarefa Checar Cadastro consiste na tarefa Buscar Cliente.
Interao entre Ator Gerente e Ator SisEP
Gerenciar Categoria: A tarefa Gerenciar Categoria consiste nas tarefas (Alterar
Categoria, Buscar Categoria, Inserir Categoria, Remover Categoria).
Relatrios: A tarefa Relatrios consiste nas tarefas (Selecionar tipo de relatrio e
Efetuar Relatrio).
Gerenciar Acompanhamento: A tarefa Gerenciar Acompanhamento consiste nas
tarefas (Alterar Acompanhamento, Buscar Acompanhamento, Inserir Acompanhamento,
Remover Acompanhamento).
Gerenciar Sabores: A tarefa Gerenciar Sabores consiste nas tarefas (Alterar Sabores,
Buscar Sabores, Inserir Sabores, Remover Sabores).
Alterar Senha: A tarefa Alterar Senha consiste na tarefa Nova Senha.
Logar no Sistema: A tarefa Logar no Sistema consiste na tarefa Efetuar Login.
Deslogar do Sistema: A tarefa Deslogar do Sistema consiste na tarefa Deslogar.

Figura 2. Modelo de Razes Estratgicas - SR

5. Especificao de Requisitos
So as declaraes de servios que o sistema deve fornecer como o sistema
deve reagir a entradas especficas e como o sistema deve se comportar em determinadas
situaes. Em alguns casos, os requisitos funcionais podem tambm estabelecer
explicitamente o que o sistema no deve fazer (Sommerville, 2007).
5.1 Requisitos Funcionais
[RF-01] Inserir Sabor
O sistema dever permitir o cadastro de um novo sabor de pizza, com a
especificao referente entrada dos dados fornecida pelo usurio. A entrada de dados
consiste nas seguintes informaes: [Nome do sabor, categoria e ingredientes].
O nome do sabor deve identificar claramente a que se refere. A categoria
selecionada de um conjunto de categorias j criadas conforme expresso no RF-05. Os
ingredientes devem ser fornecidos conforme especificado para o sabor sem a
necessidade de pr-existncia.
Prioridade: Alta.
Solicitante: Gerente.
[RF-02] Alterar Sabor
O sistema dever permitir a alterao de um determinado sabor de pizza j
cadastrado. A alterao dada pela nova entrada dos dados fornecida pelo usurio. A
entrada de dados consiste nas seguintes informaes: [Nome do sabor, categoria e
ingredientes].
Prioridade: Mdia.
Solicitante: Gerente.
[RF-03] Remover Sabor
O sistema dever permitir a remoo de um determinado sabor de pizza j
cadastrado. Contudo, o sistema dever permitir emitir relatrios contendo o sabor
removido.
Prioridade: Mdia.
Solicitante: Gerente.
[RF-04] Buscar Sabor
O sistema dever permitir a busca de um determinado sabor de pizza j
cadastrado. A busca feita a partir do nome do sabor fornecido pelo usurio.
Prioridade: Alta.
Solicitante: Funcionrio.
[RF-05] Inserir Categoria
O sistema dever permitir o cadastro de uma nova categoria de pizza no sistema,
com a especificao referente entrada dos dados fornecida pelo usurio. A entrada de
dados consiste nas seguintes informaes: [Nome da categoria, tamanho e valor].
O nome da categoria deve identificar claramente a que se refere. O tamanho
selecionado de um conjunto de tamanhos pr-definidos, os tamanhos possveis so:
[Pequena, Mdia, Grande e Gigante]. O valor o preo de venda dos sabores de pizzas
associados a categoria.
Prioridade: Alta.
10

Solicitante: Gerente
[RF-06] Alterar Categoria
O sistema dever permitir a alterao de uma determinada categoria de pizza j
cadastrada, a alterao dada pela nova entrada dos dados fornecida pelo usurio. A
entrada de dados consiste nas seguintes informaes: [Nome da categoria, tamanho e
valor].
Prioridade: Mdia.
Solicitante: Gerente.
[RF-07] Remover Categoria
O sistema dever permitir a remoo de uma determinada categoria de pizza j
cadastrada. Contudo, o sistema dever permitir emitir relatrios contendo a categoria
removida.
Prioridade: Baixa.
Solicitante: Gerente
[RF-08] Buscar Categoria
O sistema dever permitir a busca de uma determinada categoria de pizza j
cadastrada. A busca feita a partir do nome do sabor fornecido pelo usurio.
Prioridade: Alta.
Solicitante: Funcionrio.
[RF-09] Inserir Acompanhamento
O sistema dever permitir o cadastro de um novo acompanhamento, com a
especificao referente entrada dos dados fornecida pelo usurio. A entrada de dados
consiste nas seguintes informaes: [Nome do acompanhamento e valor].
O acompanhamento refere-se a qualquer item que acompanhe a pizza, tais como
bebidas, balas, doces ou qualquer outro produto que no seja uma pizza.
Prioridade: Alta.
Solicitante: Gerente.
[RF-10] Alterar Acompanhamento
O sistema dever permitir a alterao de um determinado acompanhamento j
cadastrado, a alterao dada pela nova entrada dos dados fornecida pelo usurio. A
entrada de dados consiste nas seguintes informaes: [Nome do acompanhamento e
valor].
Prioridade: Mdia.
Solicitante: Gerente.
[RF-11] Remover Acompanhamento
O sistema dever permitir a remoo de um determinado acompanhamento j
cadastrado. Contudo, o sistema dever permitir emitir relatrios contendo o
acompanhamento removido.
Prioridade: Baixa.
Solicitante: Gerente.

11

[RF-12] Buscar Acompanhamento


O sistema dever permitir a busca de um determinado acompanhamento j
cadastrado. A busca feita a partir do nome do acompanhamento fornecido pelo
usurio.
Prioridade: Alta.
Solicitante: Gerente.
[RF-13] Inserir Cliente
O sistema dever permitir o cadastro de um novo cliente, com a especificao
referente entrada dos dados fornecida pelo usurio. A entrada de dados consiste nas
seguintes informaes: [Nome completo do cliente, o nmero do RG, a data de
nascimento, dois telefones para contato, o sexo e o endereo contendo: bairro, rua,
nmero e complemento].
Prioridade: Alta.
Solicitante: Funcionrio.
[RF-14] Alterar Cliente
O sistema dever permitir a alterao de um determinado cliente j cadastrado.
A alterao dada pela nova entrada dos dados fornecida pelo usurio. A entrada de
dados consiste nas seguintes informaes: [Nome completo do cliente, o nmero do
RG, a data de nascimento, dois telefones para contato, o sexo e o endereo contendo:
bairro, rua, nmero e complemento].
Prioridade: Mdia.
Solicitante: Funcionrio.
[RF-15] Remover Cliente
O sistema dever permitir a remoo de um determinado cliente j cadastrado.
Prioridade: Mdia. Contudo, o sistema dever permitir emitir relatrios contendo o
cliente removido.
Prioridade: Baixa.
Solicitante: Funcionrio.
[RF-16] Buscar Cliente
O sistema dever permitir a busca de um determinado cliente j cadastrado. A
busca poder ser feita a partir de um dos seguintes campos: [Nome do cliente, nmero
do RG e telefone].
Prioridade: Alta.
Solicitante: Funcionrio.
[RF-17] Fazer Pedido
O sistema dever permitir realizar um pedido para o cliente. Este pedido deve
conter o nome do cliente, a hora que pedido foi efetuado, as pizzas e acompanhamentos
desejados e o endereo de entrega caso a entrega seja solicitada.
Prioridade: Alta.
Solicitante: Funcionrio.

12

[RF-18] Acompanhar Pedido * Este caso de uso no ser implementado neste trabalho.
O sistema dever permitir acompanhar um determinado pedido. Exibindo as suas
informaes para o usurio. Um pedido contm as seguintes informaes: [Nome do
Cliente, um campo para solicitao de entrega, endereo de entrega, as pizzas e
acompanhamentos referentes ao pedido, o valor total e um campo para especificar se o
pedido j foi pago].
Prioridade: Alta.
Solicitante: Funcionrio.
[RF-19] Alterar Status * Este caso de uso no ser implementado neste trabalho.
O sistema dever permitir a alterao do status de um pedido em determinados
momentos. O status indicar em qual etapa o pedido estar em um determinado
momento. Os status possveis so: [preparando, pronta, entregando, finalizado e
cancelado].
Prioridade: Alta.
Solicitante: Funcionrio.
[RF-20] Cancelar Pedido
O sistema dever permitir o cancelamento de um determinado pedido. Sendo de
total responsabilidade do usurio, os defeitos associados ao mesmo.
Prioridade: Alta.
Solicitante: Funcionrio.
[RF-21] Receber Pagamento
O sistema dever permitir o recebimento do pagamento de um determinado
pedido. O pagamento poder ser feito nas seguintes formas: [Dinheiro, carto debito e
carto crdito]. O sistema armazenar o valor e a forma do pagamento.
Prioridade: Alta.
Solicitante: Funcionrio.
[RF-22] Gerar Nota
O sistema dever permitir gerar uma nota aps o pagamento de um determinado
pedido. A nota dever conter as seguintes informaes: [Um cabealho contendo nome
da empresa, razo social, endereo, telefone, CNPJ, Inscrio Estadual], [Um corpo
contendo o nome do cliente, data, hora, nome do produto, quantidade, valor unitrio,
valor total, forma de pagamento, troco].
Prioridade: Alta.
Solicitante: Funcionrio.
[RF-23] Relatrios
O sistema dever permitir gerar relatrios especficos. Os tipos relatrios
possveis so: [Relatrio de controle de caixa, relatrio de vendas (pizzas,
acompanhamentos), relatrio de cliente].
Prioridade: Mdia.
Solicitante: Gerente.
[RF-24] Alterar Senha * Este caso de uso no ser implementado neste trabalho.
O sistema dever permitir a alterao da senha do login do gerente.
Prioridade: Baixa.
Solicitante: Gerente.
13

[RF-25] Logar no Sistema * Este caso de uso no ser implementado neste trabalho.
O sistema dever permitir o login do gerente, ao logar no sistema a rea do
gerente liberada. A rea do gerente dar acesso s funes exclusivas do gerente.
Prioridade: Baixa.
Solicitante: Gerente.
[RF-26] Deslogar do Sistema * Este caso de uso no ser implementado neste trabalho.
O usurio sai do modo do gerente e vai para o modo funcionrio, portanto o
sistema dever restringir o acesso ao contedo exclusivo do gerente.
Prioridade: Baixa.
Solicitante: Gerente.
[RF-27] Checar Cadastro
O sistema dever permitir chegar se um determinado cliente j esta cadastrado.
Prioridade: Alta.
Solicitante: Funcionrio.
[RF-28] Adicionar Acompanhamento no pedido
O sistema dever permitir que o usurio selecionar um acompanhamento para
adicionar a um pedido.
Prioridade: Alta.
Solicitante: Funcionrio.
[RF-29] Adicionar Pizza no pedido
O sistema dever permitir que o usurio monte e adicione uma pizza,
selecionando o tamanho e escolhendo os seus sabores.
Prioridade: Alta.
Solicitante: Funcionrio.
[RF-30] Backup
O sistema dever permitir realizar um backup (salvar os dados) do sistema.
Prioridade: Baixa.
Solicitante: Funcionrio.
5.2 REQUISITOS NO FUNCIONAIS
Os requisitos no funcionais referem-se a aspectos no funcionais do sistema,
como restries nas quais o sistema deve operar ou propriedades emergentes do sistema.
O sistema est dividido nos seguintes requisitos no funcionais: manutenibilidade,
segurana, confiabilidade e usabilidade. Segue abaixo a especificao de cada um deles
e, posteriormente, o diagrama NFR (Non-Functional Requirements in Software
Engineering).
Quanto Manutenibilidade
[RNF 01] O sistema dever ser implementado utilizando a linguagem de programao
Java, utilizando a tcnica da programao orientada a objeto. O cdigo ser
documentado com a API JavaDoc.

14

[RNF-02] O sistema dever ser implementado utilizando-se o PostgreSQL como


sistema gerenciador de banco de dados.
[RNF-03] O sistema dever ser implementado utilizando-se o padro de camadas MVC
(Model-view-controller). Onde os modelos de dados, a parte visual e a parte lgica de
funcionamento so separados, tornando mais fcil qualquer incremento no software.
Quanto Usabilidade
[RNF-04] O sistema dever possuir uma interface amigvel, explorando os aspectos
visuais para interagir com o usurio, tais como uso de tons de cores mais suaves,
padronizao de telas e restringindo os nveis de menus, tornando o programa mais
interativo e produtivo.
[RNF-05] O sistema dever ter botes intuitivos, deixando explicito as funcionalidades
de cada opo.
[RNF-06] Mensagens de erro ou mensagens de confirmao devero ser mostradas ao
usurio. Mensagens de confirmao devero aparecer quando uma determinada
operao for considerada crtica e as mensagens de erro devero aparecer quando uma
operao no for concluda com sucesso, de modo explicativo para melhor orientao
do usurio.
Quanto Confiabilidade
[RNF-07] A integridade dos dados ser mantida pela utilizao do SGBD PostgreSQL,
pois uma ferramenta open source, ou seja, software livre dispensando o gasto com
licenas. Alm de tudo uma ferramenta confivel e muito utilizada principalmente
para o uso acadmico.
Quanto Segurana do Sistema
[RNF-08] A confidencialidade do sistema ser garantida pela poltica de login e senha.
Backup
Quanto Portabilidade
[RNF-09] O sistema ser implementado utilizando a linguagem de programao Java
para a facilidade de portabilidade caso seja necessrio.
Quanto ao Custo e Desempenho
[RNF-10] Tratando-se de um trabalho acadmico, todos os recursos envolvidos para o
desenvolvimento do software devem ser open source.
[RNF-11] Para um melhor desempenho do sistema recomendado computador com as
configuraes:
Configurao mnima: Processador 1200 MHz, 512MB de memria e espao mnimo
de HD de 1 GB.

15

Configurao recomendvel: Processador 1800 MHz, 1GB de memria e espao


mnimo de HD de 2 GB.
6. O GRAFO SIG (SOFTGOAL INTERDEPENDENCY GRAPHS)
O grafo SIG permite uma viso de alto nvel, cujo principal objetivo apresentar
os requisitos nofuncionais, proporcionam uma viso mais realista do sistema. Atravs
dele podemos verificar o que deve ser operacionalizado para atender determinado
requisito e como ele contribui (positivo ou negativamente) para os demais.
Consideramos os seguintes requisitos no funcionais: Manutenibilidade,
Usabilidade, Confiabilidade, Segurana, Portabilidade, Custo e Desempenho.

16

Figura 3. Grafo SIG

17

7. CASOS DE USO
Um caso de uso uma descrio narrativa de uma sequencia de eventos que ocorre
quando um ator (agente externo) usa um sistema para realizar uma tarefa [Jacobson 92].
7.1 DIAGRAMA DE CASOS DE USOS.
O diagrama de casos de uso um diagrama da UML cujo objetivo representar um
requisito do sistema que ser automatizado. Considere como requisito uma necessidade
do sistema.
Usamos atores para representar as entidades que interagem com o sistema. Podem
ser usurios, mquinas, sensores, etc Um ator representa um papel no sistema, mas
um papel pode ser representando por vrios atores.

Figura 4. Diagrama de Casos de Uso

18

7.2. DESCRIO DOS CASOS DE USO


[Caso de uso 001] Inserir Sabor
Descrio: Cadastra um novo sabor de pizza no sistema, com a especificao referente
entrada dos dados fornecida pelo usurio.
Escopo: SisEP.
Pr-condio: O gerente estar logado no sistema.
Ps-Condies: Retorna mensagem Sabor inserido com sucesso.
Ator Primrio: Gerente.
Cenrio Principal de Sucesso:
1. O usurio escolhe a opo Inserir Sabor.
2. O usurio dever informar os dados do novo Sabor. A entrada de dados consiste nas
seguintes informaes: [Nome do sabor, categoria e ingredientes].
3. O usurio aps concluir o preenchimento, submete os dados para armazenamento no
banco de dados.
4. O sistema valida os dados e retorna mensagem de sucesso.

Cenrio Secundrio:
4.1. Caso os dados sejam invlidos: O sistema aborta o procedimento e retorna
mensagem de erro mostrando quais dados so necessrios para o cadastro do produto.
[Caso de uso 002] Alterar Sabor
Descrio: Altera um determinado sabor de pizza cadastrado no sistema, a alterao
dada pela nova entrada dos dados fornecida pelo usurio.
Escopo: SisEP.
Pr-condio: O gerente estar logado no sistema.
Ps-Condies: Retorna mensagem Sabor alterado com sucesso.
Ator Primrio: Gerente
Cenrio Principal de Sucesso:
1. O usurio escolhe a opo: Alterar Sabor.
2. O usurio dever editar os dados do Sabor desejado. A entrada de dados consiste nas
seguintes informaes: [Nome do sabor, categoria e ingredientes].
3. O usurio aps concluir o preenchimento, submete os dados para armazenamento no
banco de dados.
4. O sistema valida os dados e retorna mensagem de sucesso.
Cenrio Secundrio:
4.1. Caso os dados sejam invlidos: O sistema aborta o procedimento e retorna
mensagem de erro mostrando quais dados so necessrios para o cadastro do produto.

19

[Caso de uso 003] Remover Sabor


Descrio: Remove um determinado sabor de pizza cadastrado no sistema, a remoo
no fsica, portanto no remove do banco de dados.
Escopo: SisEP.
Pr-condio: O gerente estar logado no sistema.
Ps-Condies: Retorna mensagem Sabor removido com sucesso.
Ator Primrio: Gerente
Cenrio Principal de Sucesso:
1. O usurio escolhe a opo: Remover Sabor.
2. O usurio dever selecionar o Sabor desejado.
3. O usurio dever confirmar que deseja remover o Sabor.
4. O Sistema altera a flag no banco de dados e retorna mensagem de sucesso.
Cenrio Secundrio:
3.1. Caso o usurio no confirme a remoo: o sistema aborta o procedimento.
[Caso de uso 004] Buscar Sabor
Descrio: Busca um determinado sabor de pizza cadastrado no sistema, a busca feita
a partir de dados fornecidos pelo usurio referentes ao sabor que deseja buscar. Para
listar todos os sabores basta no inserir dados na pesquisa.
Escopo: SisEP.
Pr-condio:
Ps-Condies:
Ator Primrio: Gerente
Cenrio Principal de Sucesso:
1. O caso de uso inicia-se j com o sistema exibindo a lista de sabores.
2. O usurio insere o nome do sabor que deseja buscar.
3. O sistema exibe filtra o resultado da busca.
[Caso de uso 005] Inserir Categoria
Descrio: Cadastra uma nova categoria de pizza no sistema, com a especificao
referente entrada dos dados fornecida pelo usurio.
Escopo: SisEP.
Pr-condio: O gerente estar logado no sistema.
Ps-Condies: Retorna mensagem Categoria inserida com sucesso.
Ator Primrio: Gerente
Cenrio Principal de Sucesso:
1. O usurio escolhe a opo: Inserir Categoria.
2. O usurio dever informar os dados da nova Categoria. A entrada de dados consiste
nas seguintes informaes: [Nome da categoria, tamanho e valor].
3. O usurio aps concluir o preenchimento, submete os dados para armazenamento no
banco de dados.
4. O sistema valida os dados e retorna mensagem de sucesso.
Cenrio Secundrio:
4.1. Caso os dados sejam invlidos: O sistema aborta o procedimento e retorna
mensagem de erro mostrando quais dados so necessrios para o cadastro do produto.

20

[Caso de uso 006] Alterar Categoria


Descrio: Altera uma determinada categoria de pizza cadastrada no sistema, a
alterao dada pela nova entrada dos dados fornecida pelo usurio.
Escopo: SisEP.
Pr-condio: O gerente estar logado no sistema.
Ps-Condies: Retorna mensagem Categoria alterada com sucesso.
Ator Primrio: Gerente
Cenrio Principal de Sucesso:
1. O usurio escolhe a opo: Alterar Categoria.
2. O usurio dever editar os dados da Categoria desejada. A entrada de dados consiste
nas seguintes informaes: [Nome da categoria, tamanho e valor].
3. O usurio aps concluir o preenchimento, submete os dados para armazenamento no
banco de dados.
4. O sistema valida os dados e retorna mensagem de sucesso.
Cenrio Secundrio:
4.1. Caso os dados sejam invlidos: O sistema aborta o procedimento e retorna
mensagem de erro mostrando quais dados so necessrios para o cadastro do produto.
[Caso de uso 007] Remover Categoria
Descrio: Remove uma determinada Categoria de pizza cadastrada no sistema, a
remoo no fsica, portanto no remove do banco de dados.
Escopo: SisEP.
Pr-condio: O gerente estar logado no sistema.
Ps-Condies: Retorna mensagem Categoria removida com sucesso.
Ator Primrio: Gerente
Cenrio Principal de Sucesso:
1. O usurio escolhe a opo: Remover Categoria
2. O usurio dever selecionar a Categoria desejada.
3. O usurio dever confirmar que deseja remover a Categoria.
4. O usurio aps concluir, altera a flag no banco de dados e retorna mensagem de
sucesso.
Cenrio Secundrio:
3.1. Caso o usurio no confirme a remoo: o sistema aborta o procedimento.
[Caso de uso 008] Buscar Categoria
Descrio: Busca uma determinada categoria de pizza cadastrado no sistema, a busca
feita a partir de dados fornecidos pelo usurio referentes a categoria que deseja buscar.
Para listar todas as categorias basta no inserir dados na pesquisa.
Escopo: SisEP.
Pr-condio: O gerente estar logado no sistema.
Ator Primrio: Gerente.
Cenrio Principal de Sucesso:
1. O caso de uso inicia-se com o sistema exibindo a lista de categorias.
2. O usurio insere o nome da categoria que deseja buscar.
3. O sistema exibe filtra o resultado da busca.

21

[Caso de uso 009] Inserir Acompanhamento


Descrio: Cadastra um novo acompanhamento no sistema, com a especificao
referente entrada dos dados fornecida pelo usurio.
Escopo: SisEP.
Pr-condio: O gerente deve estar logado no sistema.
Ps-Condies: Retorna mensagem Acompanhamento inserido com sucesso.
Ator Primrio: Gerente
Cenrio Principal de Sucesso:
1. O usurio escolhe a opo: Inserir Acompanhamento.
2. O usurio dever informar os dados do novo acompanhamento. A entrada de dados
consiste nas seguintes informaes: [Nome do acompanhamento e valor].
3. O usurio aps concluir o preenchimento, submete os dados para armazenamento no
banco de dados.
4. O sistema valida os dados e retorna mensagem de sucesso.
Cenrio Secundrio:
4.1. Caso os dados sejam invlidos: O sistema aborta o procedimento e retorna
mensagem de erro mostrando quais dados so necessrios para o cadastro do produto.
[Caso de uso 010] Alterar Acompanhamento
Descrio: Altera um determinado Acompanhamento cadastrado no sistema, a alterao
dada pela nova entrada dos dados fornecida pelo usurio.
Escopo: SisEP.
Pr-condio: O gerente estar logado no sistema.
Ps-Condies: Retorna mensagem Acompanhamento alterado com sucesso.
Ator Primrio: Gerente
Cenrio Principal de Sucesso:
1. O usurio escolhe a opo: Alterar Acompanhamento.
2. O usurio dever editar os dados do Acompanhamento desejado. A entrada de dados
consiste nas seguintes informaes: [Nome do acompanhamento e valor].
3. O usurio aps concluir o preenchimento, submete os dados para armazenamento no
banco de dados.
4. O sistema valida os dados e retorna mensagem de sucesso.
Cenrio Secundrio:
4.1. Caso os dados sejam invlidos: O sistema aborta o procedimento e retorna
mensagem de erro mostrando quais dados so necessrios para o cadastro do produto.
[Caso de uso 011] Remover Acompanhamento
Descrio: Remove um determinado Acompanhamento cadastrado no sistema, a
remoo no fsica, portanto no remove do banco de dados..
Escopo: SisEP.
Pr-condio: O gerente estar logado no sistema.
Ps-Condies: Retorna mensagem Acompanhamento removido com sucesso.
Ator Primrio: Gerente
Cenrio Principal de Sucesso:
1. O usurio escolhe a opo: Remover Acompanhamento.
2. O usurio dever selecionar o Acompanhamento desejado.
3. O usurio dever confirmar que deseja remover o Acompanhamento.
22

4. O usurio aps concluir, altera a flag no banco de dados e retorna mensagem de


sucesso.
Cenrio Secundrio:
3.1. Caso o usurio no confirme a remoo: o sistema aborta o procedimento.
[Caso de uso 012] Buscar Acompanhamento
Descrio: Busca um determinado acompanhamento cadastrado no sistema, a busca
feita a partir de dados fornecidos pelo usurio referentes ao acompanhamento que deseja
buscar. Para listar todos os acompanhamentos basta no inserir dados na pesquisa.
Escopo: SisEP.
Pr-condio: O gerente estar logado no sistema.
Ator Primrio: Gerente
Cenrio Principal de Sucesso:
1. O caso de uso inicia-se com o sistema exibindo a lista de acompanhamento.
2. O usurio insere o nome do acompanhamento que deseja buscar.
3. O sistema exibe filtra o resultado da busca.
[Caso de uso 013] Inserir Cliente
Descrio: Cadastra um novo cliente no sistema, com a especificao referente
entrada dos dados fornecida pelo usurio.
Escopo: SisEP.
Pr-condio:
Ps-Condies: Retorna mensagem Cliente inserido com sucesso.
Ator Primrio: Funcionrio
Cenrio Principal de Sucesso:
1. O usurio escolhe a opo: Inserir Cliente.
2. O usurio dever informar os dados do novo Cliente. A entrada de dados consiste nas
seguintes informaes: [Nome completo do cliente, o nmero do RG, a data de
nascimento, dois telefones para contato, o sexo e o endereo contendo: bairro, rua,
nmero e complemento].
3. O usurio aps concluir o preenchimento, submete os dados para armazenamento no
banco de dados.
4. O sistema valida os dados e retorna mensagem de sucesso.
Cenrio Secundrio:
4.1. Caso os dados sejam invlidos: O sistema aborta o procedimento e retorna
mensagem de erro mostrando quais dados so necessrios para o cadastro do produto.

23

[Caso de uso 014] Alterar Cliente


Descrio: Altera um determinado cliente cadastrado no sistema, a alterao dada
pela nova entrada dos dados fornecida pelo usurio.
Escopo: SisEP.
Pr-condio: O cliente j dever estar cadastrado no banco de dados.
Ps-Condies: Retorna mensagem Cliente alterado com sucesso.
Ator Primrio: Funcionrio
Cenrio Principal de Sucesso:
1. O usurio escolhe a opo: Alterar Cliente.
2. O usurio dever editar os dados do Cliente desejado. A entrada de dados consiste
nas seguintes informaes: [Nome completo do cliente, o nmero do RG, a data de
nascimento, dois telefones para contato, o sexo e o endereo contendo: bairro, rua,
nmero e complemento].
3. O usurio aps concluir o preenchimento, submete os dados para armazenamento no
banco de dados.
4. O sistema valida os dados e retorna mensagem de sucesso.
Cenrio Secundrio:
4.1. Caso os dados sejam invlidos: O sistema aborta o procedimento e retorna
mensagem de erro mostrando quais dados so necessrios para o cadastro do produto.
[Caso de uso 015] Remover Cliente
Descrio: Remove um determinado cliente cadastrado no sistema, a remoo no
fsica, portanto no remove do banco de dados.
Escopo: SisEP.
Pr-condio: O cliente j dever estar cadastrado no banco de dados.
Ps-Condies: Retorna mensagem Cliente removido com sucesso.
Ator Primrio: Funcionrio
Cenrio Principal de Sucesso:
1. O usurio escolhe a opo: Remover Cliente.
2. O usurio dever selecionar o Cliente desejado.
3. O usurio dever confirmar que deseja remover o Cliente.
4. O usurio aps concluir, altera a flag no banco de dados e retorna mensagem de
sucesso.
Cenrio Secundrio:
3.1. Caso o usurio no confirme a remoo: o sistema aborta o procedimento.
[Caso de uso 016] Buscar Cliente
Descrio: Busca um determinado cliente cadastrado no sistema, a busca feita a partir
de dados fornecidos pelo usurio referentes ao cliente que deseja buscar. Para listar
todos os clientes basta no inserir dados na pesquisa.
Escopo: SisEP.
Ator Primrio: Funcionrio
Cenrio Principal de Sucesso:
1. O caso de uso inicia-se com o sistema exibindo a lista de clientes.
2. O usurio insere o nome do cliente ou nmero do RG ou nmero do telefone, que
deseja buscar.
3. O sistema exibe filtra o resultado da busca.
24

[Caso de uso 017]: Fazer Pedido


Descrio: Cria um novo pedido contendo as informaes do cliente, do endereo de
entrega e os itens pedidos pelo cliente.
Escopo: SisEP.
Pr-condio.
Ps-Condies: Retorna mensagem Pedido efetuado com sucesso.
Ator Primrio: Funcionrio
Cenrio Principal de Sucesso:
1. O usurio escolhe a opo: Fazer Pedido.
2. O usurio verifica se o cliente j possui cadastro.
3. O usurio adiciona a quantidade desejada de pizzas. Para adicionar uma pizza o
usurio dever escolhe a opo: Adicionar Pizza.
4. O usurio selecionar o tamanho da pizza.
5. O usurio dever selecionar o sabor desejado.
6. O usurio adiciona o sabor pizza clicando no boto: Adicionar Sabor.
7. O usurio adiciona a quantidade desejada de acompanhamentos. Para adicionar uma
acompanhamento o usurio dever escolhe a opo: Adicionar Acompanhamento.
8. O usurio dever selecionar o acompanhamento desejado.
9. O usurio adiciona o acompanhamento no pedido clicando no boto: Adicionar
Acompanhamento.
10. O usurio dever informar se o pedido para entrega ou no.
11. O usurio dever verificar se o endereo do cadastro do cliente o endereo
desejado da entrega.
12. Se necessrio o usurio informa o valor da taxa de entrega.
13. O sistema pega a hora do sistema do operacional.
14. O sistema atribui a hora ao pedido.
15. O usurio conclui o pedido.
16. O sistema armazena o pedido no banco de dados.
17. O sistema adiciona o pedido na lista de pedidos.
Cenrio Secundrio:
2.1 Caso o cliente no possua cadastro: o usurio dever inserir o cliente.
3.1 Caso o cliente no deseja pizza: o usurio avana para o passo 7.
7.1 Caso o cliente no deseja acompanhamento: o usurio avana para o passo 10.
10.1 Caso no seja para entrega: o usurio avana para o passo 13.
11.1 Caso o endereo cadastrado no seja o desejado para entrega: o usurio dever
adiciona um endereo de entrega ao pedido.
[Caso de uso 018]: Acompanhar Pedido
Descrio: Visualiza as informaes relevantes de um determinado pedido.
Escopo: SisEP.
Pr-condio. O pedido deve estar em andamento.
Ator Primrio: Funcionrio
Cenrio Principal de Sucesso:
1. O usurio dever selecionar o Pedido desejado.
2. O sistema busca o pedido no banco de dados e obtm suas informaes.
3. O sistema exibe o resultado na tela.
Cenrio Secundrio:
25

1.1 Caso o pedido no seja selecionado: o sistema retorna a mensagem de erro:


Selecione um Pedido.
[Caso de uso 019]: Alterar Status
Descrio: O sistema dever alterar o status de um pedido em determinados momentos,
os status possveis so: preparando, pronto, entregando, finalizado e cancelado.
Escopo: SisEP.
Pr-condio. O pedido deve estar em andamento.
Ps-Condies: Retorna mensagem Status alterando com sucesso.
Ator Primrio: Funcionrio
Cenrio Principal de Sucesso:
1. O usurio dever selecionar o pedido.
2. O usurio dever definir o status atual do pedido.
Cenrio Secundrio:
1.1 Caso o pedido no seja selecionado: o sistema retorna a mensagem de erro:
Selecione um Pedido.
[Caso de uso 020]: Cancelar Pedido
Descrio: Cancela um pedido que esta em andamento.
Escopo: SisEP.
Pr-condio pedido em andamento e com status no finalizado ainda.
Ps-Condies: Retorna mensagem Pedido cancelado com sucesso.
Ator Primrio: Funcionrio
Cenrio Principal de Sucesso:
1. O usurio dever selecionar o Pedido desejado.
2. O usurio confirma o cancelamento do pedido.
3. O sistema efetua Cancelamento.
Cenrio Secundrio:
1.1 Caso o pedido no seja selecionado: o sistema retorna a mensagem de erro:
Selecione um Pedido.
2.1 Caso o usurio no confirme o cancelamento: o sistema aborta o procedimento.
[Caso de uso 021]: Receber Pagamento
Descrio: Confirma o pagamento de um determinado pedido.
Escopo: SisEP.
Pr-condio. O pedido deve estar em andamento.
Ps-Condies: Retorna mensagem Pagamento de Pedido realizado com sucesso.
Ator Primrio: Funcionrio
Cenrio Principal de Sucesso:
1. O usurio dever selecionar o pedido.
2. O usurio dever definir a forma de pagamento. O pagamento poder ser feito nas
seguintes formas: [Dinheiro, carto debito e carto crdito].
3. O sistema atribui ao pedido o status de pago.
4. O sistema emite a nota.
Cenrio Secundrio:
1.1 Caso o pedido no seja selecionado: o sistema retorna a mensagem de erro:
Selecione um Pedido.
26

[Caso de uso 022]: Gerar Nota


Descrio: O sistema dever fornecer uma nota aps efetuado o pagamento do pedido.
Escopo: SisEP.
Pr-condio. O pedido deve estar em andamento.
Ps-Condies: Gera um arquivo PDF contendo os dados da nota.
Ator Primrio: Funcionrio
Cenrio Principal de Sucesso:
1. O usurio dever selecionar o pedido.
2. O sistema ir gerar o arquivo PDF referente aos dados do pedido selecionado. A nota
dever conter as seguintes informaes: [Um cabealho contendo nome da empresa,
razo social, endereo, telefone, CNPJ, IE], [Um corpo contendo o nome do cliente,
data, hora, nome do produto, quantidade, valor unitrio, valor total, forma de
pagamento, troco].
Cenrio Secundrio:
1.1 Caso o pedido no seja selecionado: o sistema retorna a mensagem de erro:
Selecione um Pedido.
[Caso de uso 023] Relatrios
Descrio: Gera relatrios especficos, que sero implementados posteriormente. No
discorreremos mais sobre a gerao de relatrios, pois esta faz parte do processo
incremental e iterativo da construo do sistema, dependendo diretamente das
necessidades do cliente.
Escopo: SisEP.
Pr-condio: O gerente estar logado no sistema.
Ator Primrio: Gerente
Cenrio Principal de Sucesso:
1. O usurio escolhe a opo: Relatrios.
2. O usurio seleciona o tipo de relatrio. Os tipos relatrios possveis so: [Relatrio de
controle de caixa, relatrio de vendas (pizzas, acompanhamentos), relatrio de cliente].
3. Preencher, se houver, os dados de filtro a respeito do relatrio selecionado.
4. O sistema validar os dados.
5. O sistema gera o relatrio na tela, (posteriormente ser analisada a possibilidade da
gerao de relatrios no formato PDF).
Cenrio Secundrio:
4.1. Caso os dados sejam invlidos: O sistema aborta o procedimento e retorna
mensagem de erro mostrando quais dados so necessrios para gerar o relatrio.
[Caso de uso 024]: Alterar senha
Descrio: Altera a senha atual do login do gerente.
Escopo: SisEP.
Pr-condio. O gerente deve estar logado no sistema.
Ps-Condies: O sistema retorna a mensagem Senha alterada com sucesso.
Ator Primrio: Gerente.
Cenrio Principal de Sucesso:
1. O gerente escolhe a opo: Alterar Senha.
2. O gerente dever informar a senha atual.
27

3. O gerente dever informar a nova senha, a nova senha dever conter no mnimo 6
dgitos, sendo possvel o uso de qualquer tipo de caractere e fazendo distino de letras
maisculas de minsculas.
4. O gerente dever confirmar a alterao.
5. O sistema altera a senha do gerente.
Cenrio Secundrio:
2.1 Caso a senha informada seja incorreta: o sistema retorna a mensagem de erro: Senha
incorreta.
3.1. Caso a nova senha seja invlida: O sistema retorna a mensagem de erro: Senha
invlida.
4.1. Caso o gerente no confirme a alterao da senha: o sistema aborta o procedimento.
[Caso de uso 025]: Logar no Sistema
Descrio: O gerente dever entrar com seus dados: login e senha. O Sistema dever
permitir acesso ao contedo restrito do software somente se os dados estiverem
corretos.
Escopo: SisEP.
Pr-condio O usurio j devera possuir seu cadastro no sistema.
Ps-Condies: O Sistema libera acesso rea restrita.
Ator Primrio: Gerente
Cenrio Principal de Sucesso:
1. O gerente escolhe a opo: Logar no Sistema.
2. O usurio dever entrar com seu login e senha.
3. O sistema busca no banco de dados e verifica se os dados esto corretos.
4. O sistema retorna mensagem de login realizado com sucesso e ser iniciado.
5. O sistema libera o acesso a rea do gerente.
Cenrio Secundrio:
3.1 Caso os dados no estejam corretos: o sistema aborta o procedimento e retorna a
mensagem de erro login ou senha invlida.
Requisitos Especiais (Special Requirements)
Requisitos No Funcionais: Segurana.

[Caso de uso 026]: Deslogar do Sistema


Descrio: O usurio sai do modo do gerente e vai para modo funcionrio, portanto o
sistema dever restringir o acesso ao contedo exclusivo do gerente.
Escopo: SisEP.
Pr-condio. O usurio deve estar logado no sistema.
Ps-Condies: O sistema restringe o acesso contedo exclusivo do gerente.
Ator Primrio: Gerente.
Cenrio Principal de Sucesso:
1. O usurio clica em deslogar.
2. O sistema sai do modo gerente e vai para o modo funcionrio.
Requisitos Especiais (Special Requirements)
Requisitos No Funcionais: Segurana.

28

[Caso de uso 027]: Backup


Descrio: Salva os dados presentes no banco de dados em um arquivo do tipo backup
do PostgreSQL. O Backup s acontece quando o usurio realiza a operao.
Escopo: SisEP.
Ps-Condies: Cria o arquivo de backup.
Ator Primrio: Funcionrio
Cenrio Principal de Sucesso:
1. O usurio escolhe a opo fazer backup.
2. O usurio informa o nome do arquivo de backup e seleciona a pasta onde o
arquivo ser salvo.
3. O sistema salva a base de dados com o nome e na pasta especificada.
Cenrio Secundrio:
3.1 Caso ocorra um erro ao realizar o backup: o sistema aborta o
procedimento e envia uma mensagem de erro.
Requisitos Especiais (Special Requirements)

Requisitos No Funcionais: Integridade, Segurana e Confiabilidade.


8. DIAGRAMA DE CLASSES
Um diagrama de classes uma representao da estrutura e relaes
das classes que servem de modelo para objetos. No diagrama de classe que
ser apresentado podemos ver as classes mais importantes com os mtodos j
declarados. No ser feita uma descrio pontual sobre as classes do
diagrama, pois os nomes dados aos atributos e aos mtodos j esto muito
bem esclarecidos e sucintos. Apenas com a visualizao do diagrama j se
tem uma boa noo do que trata. Ainda contamos com a documentao
javadoc durante o desenvolvimento, contribuindo para a compreenso na
leitura do cdigo. A documentao completa ser gerada posteriormente para
consultas.
Descrio textual das classes presentes no diagrama de classes figura 5.

29

Figura 3. Diagrama de Classes

30

1. PACOTE MODELO

CLIENTE
Descrio

Atributos
Nome: String
RG: String
telefone_1: String
telefone_2: String
data_nasc: Date
Endereo: Endereco
codigo: Int
codigo_endereco : Int

A classe cliente representa um cliente que tem cadastro na


pizzaria, com essa classe possvel armazenar informaes
sobre o cliente e assim agilizar o atendimentos posteriores ao
cadastro.
Responsvel pelo armazenamento de informao referente ao
nome do cliente.
Responsvel pelo armazenamento de informao referente ao
nmero do RG.
Responsvel pelo armazenamento de informao referente ao
nmero do primeiro telefone do cliente.
Responsvel pelo armazenamento de informao referente ao
nmero do segundo telefone do cliente.
Responsvel pelo armazenamento de informao referente a data
de nascimento do cliente.
Responsvel pelo armazenamento de informao referente ao
endereo do cliente.
Responsvel pelo armazenamento de informao referente ao
cdigo do cliente no banco de dados.
Responsvel pelo armazenamento de informao referente ao
cdigo do endereo do cliente no banco de dados.

Operaes

Cliente()
getCodigo_endereco() :
Int
getCodigo(): Int
getData_nasc(): Date
getEndereco() :
Endereco
getNome() : String
getRg(): String
getTelefone_1(): String
getTelefone_2(): String

Construtor Default

Retorna o valor da varivel referente ao cdigo do endereo


do cliente.
Retorna o valor da varivel referente ao cdigo do cliente.
Retorna o valor da varivel referente a data de nascimento do
cliente.
Retorna o valor da varivel referente ao endereo do cliente.
Retorna o valor da varivel referente ao nome do cliente.
Retorna o valor da varivel referente ao nmero do RG do
cliente.
Retorna o valor da varivel referente ao nmero do primeiro
telefone do cliente.
Retorna o valor da varivel referente ao nmero do segundo
telefone do cliente.
Seta todas as variveis do cliente a partir de um ResultSet.
Retorna verdadeiro se todos os dados foram setados com
Sucesso, caso contrrio retorna falso.
Altera o valor da varivel referente ao cdigo do endereo do
cliente.

setALL(rs: ResultSet,
nextInicial: boolean) :
boolean
setCodigo_endereco(
Integer
codigo_endereco) : void
setCodigo( Integer
Altera o valor da varivel referente ao cdigo do cliente.
codigo) : void
setData_nasc(data_nasc: Altera o valor da varivel referente a data de nascimento do
Date) : void
cliente.

31

setEndereco(endereco:
Endereco) : void
setNome(nome: String)
: void
setRg(rg: String) : void
setTelefone_1(tel_1:
String) : void
setTelefone_2(tel_2:
String) : void

Altera o valor da varivel referente ao endereo do cliente.


Altera o valor da varivel referente ao nome do cliente.
Altera o valor da varivel referente ao nmero do rg do
cliente.
Altera o valor da varivel referente ao nmero do primeiro
telefone do cliente.
Altera o valor da varivel referente ao nmero do segundo
telefone do cliente.

ENDEREO
Descrio
Atributos
codigo: Integer
bairro: String
rua: String
num: String
complemento: String

a classe que armazena informaes sobre o


endereo como rua, bairro, proximidades.
Responsvel pelo armazenamento de informao
referente ao cdigo do endereo
Responsvel pelo armazenamento de informao
referente ao bairro do endereo.
Responsvel pelo armazenamento de informao
referente a rua do endereo.
Responsvel pelo armazenamento de informao
referente ao nmero do endereo.
Responsvel pelo armazenamento de informao
referente ao complemento do endereo..

Operaes

endereo()
getBairro(): String

Construtor Default
Retorna o valor da varivel referente ao bairro do
endereo.
getCodigo(): Integer
Retorna o valor da varivel referente ao cdigo do
endereo.
getComplemento(): String
Retorna o valor da varivel referente ao complemento
do endereo.
getNum(): String
Retorna o valor da varivel referente ao nmero do
endereo.
getRua(): String
Retorna o valor da varivel referente a rua do
endereo.
setALL(rs : ResultSet,
Seta todas as variveis do cliente a partir de um
nextInicial: boolean) : boolean ResultSet. Retorna verdadeiro se todos os dados
foram setados com Sucesso, caso contrrio retorna
falso.
setBairro(bairro: String) :void
Altera o valor da varivel referente ao bairro do
endereo.
setCodigo(codigo: Integer)
Altera o valor da varivel referente ao cdigo do
:void
endereo.
setComplemento(complemento: Altera o valor da varivel referente ao complemento
String) :void
do endereo.
setNum(num: String) :void
Altera o valor da varivel referente ao nmero do
32

setRua( rua: String) :void

endereo.
Altera o valor da varivel referente a rua do endereo.

PEDIDO
Descrio

Atributos
codigo: Integer
codigo_cliente: Integer
codigo_endereco_entrega: Integer
data: Date
valor_entrega: Float
desconto: Float
valor_total: Float
status: String
listaItens: ArrayList<Object>

A classe pedido tem o objetivo de armazenar os


produtos do pedido, valores e outras informaes
que representam um pedido.
Responsvel pelo armazenamento de informao
referente ao cdigo do pedido.
Responsvel pelo armazenamento de informao
referente ao cdigo do cliente.
Responsvel pelo armazenamento de informao
referente ao cdigo do endereo de entrega.
Responsvel pelo armazenamento de informao
referente a data do pedido.
Responsvel pelo armazenamento de informao
referente ao valor da taxa de entrega do pedido.
Responsvel pelo armazenamento de informao
referente ao valor de desconto do pedido.
Responsvel pelo armazenamento de informao
referente ao valor total do pedido.
Responsvel pelo armazenamento de informao
referente ao status do pedido.
Responsvel pelo armazenamento de informao
referente aos itens do pedido.

Operaes

pedido()
getCodigo_cliente(): Integer
getCodigo_endereco_entrega() :
Integer
getCodigo(): Integer
getData():Date
getDesconto():Float
getListaItens(): ArrayList<Object>
getStatus(): String
getValor_entrega(): Float
getValor_total(): Float
setALL(ResultSet rs, boolean
nextInicial) : boolean

setCodigo_cliente(codigo_cliente:
Integer) : void

Construtor Default
Retorna o valor da varivel referente ao cdigo do
cliente.
Retorna o valor da varivel referente ao cdigo do
endereo de entrega.
Retorna o valor da varivel referente ao cdigo do
pedido.
Retorna o valor da varivel referente a data do
pedido.
Retorna o valor da varivel referente ao valor de
desconto do pedido.
Retorna a lista de itens do pedido.
Retorna o valor da varivel referente ao status do
pedido.
Retorna o valor da varivel referente ao valor da
taxa de entrega do pedido.
Retorna o valor da varivel referente ao valor total
do pedido.
Seta todas as variveis do cliente a partir de um
ResultSet. Retorna verdadeiro se todos os dados
foram setados com Sucesso, caso contrrio retorna
falso.
Altera o valor da varivel referente ao cdigo do
cliente do pedido.
33

setCodigo_endereco_entrega
(codigo_endereco_entrega :
Integer) : void
setCodigo(codigo: Integer) : void

Altera o valor da varivel referente ao cdigo do


endereo de entrega do pedido.

setData(data: Date) : void


setDesconto(desconto: Float) : void
setListaItens(listaItens: ArrayList<
Object>) : void
setStatus(status: String) : void
setValor_entrega(valor_entrega:
Float) : void
setValor_total(valor_total: Float) :
void

Altera o valor da varivel referente ao cdigo do


pedido.
Altera o valor da varivel referente a data do
pedido.
Altera o valor da varivel referente ao valor de
desconto do pedido.
Altera a lista de objetos referente a lista de itens do
pedido.
Altera o valor da varivel referente ao status do
pedido.
Altera o valor da varivel referente ao valor da
taxa de entrega do pedido.
Altera o valor da varivel referente ao valor total
do pedido.

PIZZA
Descrio

Atributos
codigo: Integer
sabores : ArrayList<Sabor>

a classe que armazena informaes da pizza. Esta


tendo entre seus atributos vrios sabores, onde seus
sabores pertence m a uma determinada categoria, que
contm as informaes de tamanho e valor.

Responsvel pelo armazenamento de informao


referente ao cdigo da pizza.
Responsvel pelo armazenamento de informao
referente a lista de sabores da pizza.

Operaes

pizza()
getCodigo(): Integer
getSabores():ArrayList<Sabor>
setCodigo(codigo: Integer)
:void
setSabores():ArrayList<Sabor>
setALL(rs : ResultSet,
nextInicial: boolean) : boolean

Construtor Default
Retorna o valor da varivel referente ao cdigo do
endereo.
Retorna uma lista do tipo sabor referente aos sabores
da pizza.
Altera o valor da varivel referente ao cdigo da
pizza.
Altera a lista do tipo sabor referente aos sabores da
pizza.
Seta todas as variveis do cliente a partir de um
ResultSet. Retorna verdadeiro se todos os dados
foram setados com Sucesso, caso contrrio retorna
falso.

SABOR
34

Descrio

Atributos
nome: String
cdigo: Integer
ingredientes: String
categoria: Categoria
cdigo_categoria: Integer
removido: boolean
Operaes
sabor()
getCategoria(): Categoria
getCodigo(): Integer
getCodigo_categoria(): Integer
getIngredientes(): String
getNome(): String
isRemovido(): boolean
setALL(rs : ResultSet,
nextInicial: boolean) : boolean
setCategoria(categoria:
Categoria): void
setCodigo(codigo: Integer) :void
setCodigo_categoria(codigo_cate
goria: Integer) :void
setIngredientes(ingredientes:
String) :void
setNome( nome: String) :void
setRemovido(removido:
boolean): void

a classe que armazena informaes sobre o Sabor


como nome, cdigo, ingredientes, categoria, cdigo da
categoria, removido.
Responsvel pelo armazenamento de informao
referente ao nome do sabor.
Responsvel pelo armazenamento de informao
referente ao cdigo do sabor.
Responsvel pelo armazenamento de informaes
referente aos ingredientes do sabor.
Responsvel pelo armazenamento de informao
referente a categoria do sabor.
Responsvel pelo armazenamento de informao
referente a categoria do sabor.
Responsvel pelo armazenamento de informao
referente a excluso logica do sabor no banco de dados.
Construtor Default
Retorna o valor da varivel referente a categoria do
sabor.
Retorna o valor da varivel referente ao cdigo do
sabor.
Retorna o valor da varivel referente ao cdigo da
categoria do sabor
Retorna o valor da varivel referente aos ingredientes
do sabor.
Retorna o valor da varivel referente ao nome do sabor.
Retorna o valor da varivel referente a excluso logica
do sabor no banco de dados.
Seta todas as variveis do sabor a partir de um
ResultSet. Retorna verdadeiro se todos os dados foram
setados com Sucesso, caso contrrio retorna falso.
Altera o valor da varivel referente a categoria do
sabor.
Altera o valor da varivel referente ao cdigo do sabor.
Altera o valor da varivel referente ao cdigo da
categoria do sabor.
Altera o valor da varivel referente aos ingredientes de
um sabor.
Altera o valor da varivel referente ao nome de um
sabor.
Altera o valor da varivel referente a excluso logica do
sabor no banco de dados.

35

ACOMPANHAMENTO
Descrio

a classe que armazena informaes sobre a categoria


como nome, cdigo, tamanho, valor, removido.

Atributos

nome: String
cdigo: Integer
valor: Float
removido: boolean

Responsvel pelo armazenamento de informao


referente ao nome do acompanhamento.
Responsvel pelo armazenamento de informao
referente ao cdigo do acompanhamento.
Responsvel pelo armazenamento de informao
referente ao valor do acompanhamento.
Responsvel pelo armazenamento de informao
referente a excluso lgica do acompanhamento no
banco de dados.

Operaes

categoria()
getValor(): Float
getCodigo(): Integer
getNome(): String
isRemovido(): boolean
setALL(rs : ResultSet,
nextInicial: boolean) : boolean

setValor(valor: Float): void


setCodigo(codigo: Integer) :void
setNome( nome: String) :void
setRemovido(removido:
boolean): void

Construtor Default
Retorna o valor da varivel referente ao valor do
acompanhamento.
Retorna o valor da varivel referente ao cdigo do
acompanhamento.
Retorna o valor da varivel referente ao nome do
acompanhamento.
Retorna o valor da varivel referente a excluso lgica
do acompanhamento no banco de dados.
Seta todas as variveis do acompanhamento a partir de
um ResultSet. Retorna verdadeiro se todos os dados
foram setados com Sucesso, caso contrrio retorna
falso.
Altera o valor da varivel referente ao valor do
acompanhamento.
Altera o valor da varivel referente ao cdigo do
acompanhamento.
Altera o valor da varivel referente ao nome de uma
categoria.
Altera o valor da varivel referente a excluso lgica do
acompanhamento no banco de dados.

36

CATEGORIA
Descrio
Atributos
nome: String
cdigo: Integer
tamanho: String
valor: Float
removido: boolean

Operaes
categoria()
getValor(): Float
getCodigo(): Integer
getTamanho(): String
getNome(): String
isRemovido(): boolean
setALL(rs : ResultSet,
nextInicial: boolean) : boolean
setValor(valor: Float): void
setCodigo(codigo: Integer) :void
setTamanho(ingredientes: String)
:void
setNome( nome: String) :void
setRemovido(removido:
boolean): void

a classe que armazena informaes sobre a categoria


como nome, cdigo, tamanho, valor, removido.
Responsvel pelo armazenamento de informao
referente ao nome da categoria.
Responsvel pelo armazenamento de informao
referente ao cdigo da categoria.
Responsvel pelo armazenamento de informaes
referente ao tamanho da categoria.
Responsvel pelo armazenamento de informao
referente ao valor da categoria.
Responsvel pelo armazenamento de informao
referente a excluso logica da categoria no banco de
dados.
Construtor Default
Retorna o valor da varivel referente ao valor da
categoria.
Retorna o valor da varivel referente ao cdigo da
categoria.
Retorna o valor da varivel referente ao tamanho da
categoria.
Retorna o valor da varivel referente ao nome da
categoria.
Retorna o valor da varivel referente a excluso logica
da categoria no banco de dados.
Seta todas as variveis da categoria a partir de um
ResultSet. Retorna verdadeiro se todos os dados foram
setados com Sucesso, caso contrrio retorna falso.
Altera o valor da varivel referente ao valor da
categoria.
Altera o valor da varivel referente ao cdigo da
categoria.
Altera o valor da varivel referente ao tamanho da
categoria.
Altera o valor da varivel referente ao nome de uma
categoria.
Altera o valor da varivel referente a excluso logica da
categoria no banco de dados.

37

RELATRIO
Descrio
Atributos
tipo: String
data_geracao: Date
data_inicio: Date
Data_Fim: Date
Operaes
relatorio()
getTipo(): String
getData_geracao(): Date
getData_incio(): Date
getData_Fim(): Date
setTipo(tipo: String): void
setData_geracao(data_geracao:
Date) :void
setData_inicio(data_inicio: Date)
:void
setData_fim(data_fim: Date)
:void

a classe que armazena informaes sobre o relatrio


como tipo, data_gerao, data_inicio, data_fim.
Responsvel pelo armazenamento de informao
referente ao tipo do relatrio.
Responsvel pelo armazenamento de informao
referente a data de gerao do relatrio.
Responsvel pelo armazenamento de informao
referente a data de inicio do relatrio.
Responsvel pelo armazenamento de informao
referente a data final do relatrio.
Construtor Default
Retorna o valor da varivel referente ao tipo do
relatrio.
Retorna o valor da varivel referente a data de gerao
do relatrio.
Retorna o valor da varivel referente a data de inicio do
relatrio.
Retorna o valor da varivel referente a data final do
relatrio.
Altera o valor da varivel referente ao tipo do relatrio.
Altera o valor da varivel referente a data de gerao do
relatrio.
Altera o valor da varivel referente a data de inicio do
relatrio.
Altera o valor da varivel referente a data final do
relatrio.

PAGAMENTO
Descrio
Atributos
codigo: Integer
tipo: String
Operaes
pagamento()
getCodigo(): Integer
getTipo(): String
setCodigo(codigo: Integer): void
setTipo(tipo: String): void

a classe que armazena informaes sobre o


pagamento como cdigo e tipo.
Responsvel pelo armazenamento de informao
referente ao cdigo do pagamento.
Responsvel pelo armazenamento de informao
referente ao tipo do pagamento.
Construtor Default
Retorna o valor da varivel referente ao cdigo do
pagamento.
Retorna o valor da varivel referente ao tipo do
pagamento.
Altera o valor da varivel referente ao cdigo do
pagamento.
Altera o valor da varivel referente ao tipo do
pagamento.
38

NOTA
Descrio
Atributos
codigo: Integer
lista_pizza: ArrayList<Pizza>
lista_acompanhamento:
ArrayList<Acompanhamento>
pagamento: Pagamento
Operaes
nota()
getCodigo(): Integer
getLista_pizza():
ArrayList<Pizza>
getLista_acompanhamento:
ArrayList<Acompanhamento>
getPagamento(): Pagamento
setALL(rs : ResultSet,
nextInicial: boolean) : boolean
setCodigo(codigo: Integer): void
setLista_pizza(lista_pizza:
ArrayList<Pizza>):void
setLista_acompanhamento(lista_
acompanhamento:
ArrayList<Acompanhamento>)
:void
setPagamento(pagamento:
Pagamento): void

a classe que armazena informaes sobre a nota como


cdigo, lista_pizza, lista_acompanhamento, pagamento.
Responsvel pelo armazenamento de informao
referente ao cdigo da nota.
Responsvel pelo armazenamento de informao
referente a lista de pizzas da nota.
Responsvel pelo armazenamento de informao
referente a lista de acompanhamento da nota.
Responsvel pelo armazenamento de informao
referente ao pagamento da nota.
Construtor Default
Retorna o valor da varivel referente ao tipo do
relatrio.
Retorna o valor da lista referente a lista de pizzas da
nota.
Retorna o valor da lista referente a lista de
acompanhamentos da nota.
Retorna o valor da varivel referente ao pagamento da
nota.
Seta todas as variveis da nota a partir de um ResultSet.
Retorna verdadeiro se todos os dados foram setados
com Sucesso, caso contrrio retorna falso.
Altera o valor da varivel referente ao cdigo da nota.
Altera o valor da lista referente a lista de pizzas da nota
Altera o valor da lista referente a lista de
acompanhamento da nota.

Altera o valor da varivel referente ao pagamento da


nota.

39

GERENTE
Descrio

a classe que armazena informaes sobre gerente


como nome, cdigo, usurio e senha.

Atributos

nome: String
cdigo: Integer
usuario: String
senha: String

Responsvel pelo armazenamento de informao


referente ao nome do gerente.
Responsvel pelo armazenamento de informao
referente ao cdigo do gerente.
Responsvel pelo armazenamento de informao
referente login usurio do gerente.
Responsvel pelo armazenamento de informao
referente a senha do gerente.

Operaes

categoria()
getUsuario():String
getCodigo(): Integer
getNome(): String
getSenha ():String
setALL(rs : ResultSet,
nextInicial: boolean) : boolean

setUsuario (usuario: String): void


setCodigo(codigo: Integer) :void
setNome( nome: String) :void
setSenha (senha:String): void

Construtor Default
Retorna o valor da varivel referente ao login usurio
do gerente.
Retorna o valor da varivel referente ao cdigo do
gerente.
Retorna o valor da varivel referente ao nome do
gerente.
Retorna o valor da varivel referente senha do gerente.
Seta todas as variveis do acompanhamento a partir de
um ResultSet. Retorna verdadeiro se todos os dados
foram setados com Sucesso, caso contrrio retorna
falso.
Altera o valor da varivel referente ao login usurio do
gerente.
Altera o valor da varivel referente ao cdigo do
gerente.
Altera o valor da varivel referente ao nome do gerente.
Altera o valor da varivel referente a senha do gerente.

40

2. PACOTE CONTROLE
PRINCIPAL
A classe principal responsvel pela conexo com o banco de dados.
CONTROLADOR
Esta classe a principal do processo. Ela responsvel pela comunicao entre todas as
outras camadas.
3. PACOTE DAO
DAO
Esta classe faz a persistncia e pesquisas no banco de dados.
FORMULAPARAMETROSBD
Classe responsvel por formular parmetros responsveis para a persistncia e pesquisa
no banco de dados de um objeto.
PARAMETROSBD
Classe que determina os parmetros de persistncia do banco de dados. Consiste em
nome da tabela, colunas, parmetros e condio.
SINGLETON
Classe responsvel pela execuo dos comandos SQL.
4. VISAO
ADDACOMPANHAMENTO
A tela AddAcompanhamento destinada a adio de acompanhamento em um pedido.
CADASTRARCLIENTE
Esta tela apresenta campos de preenchimento relacionados ao cadastro de um cliente.
ENDERECOENTREGA
Tela onde se adiciona informaes quanto ao endereo de entrega de um pedido.

41

AREAADMINISTRADOR
Esta tela tem como ator principal o gerente, sendo apresentada nela funcionalidades
voltadas a este. O gerente pode realizar cadastros, edio e deleo de pizzas e produtos,
ainda pode alterar a sua senha e extrair relatrios especficos.
ADDPIZZA
A tela AddPizza destinada a adio de uma pizza em um pedido. Nela escolhido um
tamanho de pizza e a ela adicionado sabores, a quantidade de sabores varia de acordo
com o tamanho da pizza selecionada. O valor final da pizza obtido da soma
proporcional das parcelas dos sabores, onde cada sabor tem uma categoria e um valor
vinculado, por exemplo, uma pizza com 2 sabores no tamanho grande, onde um sabor
da pizza o especial que custa R$25,00 e uma doce que custa R$30,00, o valor final da
pizza fica sendo a proporo de cada parte da pizza em relao ao valor, sendo metade
dos 25 reais mais a metade dos 30 reais, resultando em 27,50 reais.
NOVOPEDIDO
A tela de NovoPedido destinada a realizao de um pedido. Nela pode-se adicionar
produtos como pizza e acompanhamentos, endereo de entrega, marcar como
entregar, alterar os itens e remover itens, tambm exibido os valores parciais e final
da compra e todos os itens adicionados nela.
PAGAR
Esta tela direcionada ao pagamento de um pedido selecionado. Nela pode-se escolher
a forma do pagamento e quando um valor inserido no campo de dinheiro um valor
de troco processado e exibido para o usurio.
CLIENTES
Esta tela voltada manipulao dos dados dos clientes, nela possvel editar,
visualizar, cadastrar e pesquisar clientes.
SELECIONARCLIENTE
Esta tela apresenta os clientes cadastrados, exibindo o nome e o telefone dos clientes
com a possibilidade de busca por qualquer um dos dois valores. Aps selecionado o
cliente possvel ir para a tela de venda j com os campos relacionados ao cliente
preenchidos com os dados do cliente selecionado.
TELAPRINCIPAL
Esta tela a tela principal do programa, onde se da incio a todos os processos. A tela
principal apresenta os pedidos em andamento, botes de controle e informaes
relacionadas a um pedido selecionado.

42

9. CONCLUSO
Conclumos ao trmino deste documento, que chegamos a uma modelagem funcional
para o sistema inicialmente proposto: um sistema de entrega de pizzas.
Foram construdos diagramas de: caso de uso, classe, modelagem organizacional i*.
Com todos esses diagramas construdos a modelagem e a estruturao dos processos de
engenharia de software se tornam mais claros e com isso consegue-se um processo de
qualidade.
Esta modelagem orientada a objetos tornou o processo de desenvolvimento do software
mais gil, prtico e de melhor entendimento a todos os membros da equipe, pois todos
os passos foram seguidos por dicas e informaes do cliente.
Assim com todos os artefatos apresentados, conclumos que a documentao est bem
esclarecida e que todos os requisitos necessrios para a satisfao da empresa-cliente
foram cumpridos.
APNDICE A COLETA DE INFORMAES
Foi realizada uma entrevista com a proprietria da Pizzaria Bella Pizza (Neide da Silva)
onde foram coletadas informaes relevantes quanto ao contexto do funcionamento da
pizzaria e a possibilidade de uma implantao de um sistema. A baixo encontra-se o
questionrio aplicado juntamente com as respostas obtidas.
Bella Pizza.
Avenida Carlos Gomes, n 904, Cascavel PR.
Fone/Fax: (45) 3038-3857
Entrevista: 09/03/2012
Entrevistado(a): Neide da Silva
Fale um pouco sobre a sua empresa?
uma microempresa localizada no bairro Faculdade que conta com 10
funcionrios trabalhando no local e mais alguns moto-boys que trabalham entregando
as pizzas.
Quais as reas em que h uma maior dificuldade no gerenciamento da empresa?
Obteno de relatrios para o planejamento.
A empresa j utiliza solues tecnolgicas? Quais?
No utiliza nenhum sistema, o processo todo feito manualmente.
Qual o objetivo da empresa com o sistema a ser implementado?
Agilizar o atendimento e fazer um controle de funcionrios e caixa de forma
mais prtica.
Quais as funes que o sistema deve oferecer?
Realizar o cadastro de clientes, cadastro de todos os produtos, gerenciar os
pedidos, controle de caixa e que fornea relatrios.
Quem utilizar o sistema?
As duas moas que trabalham no balco de atendimento.

43

FORMULRIO DO RELATRIO DA EQUIPE


Nome Contribuio Assinatura
Andr L. Luchesi

33,3333%

___________________________________

Eder S. Ziomek

33,3333%

___________________________________

Heitor Faccioni

33,3333%

___________________________________

44