Escolar Documentos
Profissional Documentos
Cultura Documentos
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
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.
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
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
15
16
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.
18
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
20
21
23
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.
28
29
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
Operaes
Cliente()
getCodigo_endereco() :
Int
getCodigo(): Int
getData_nasc(): Date
getEndereco() :
Endereco
getNome() : String
getRg(): String
getTelefone_1(): String
getTelefone_2(): String
Construtor Default
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
ENDEREO
Descrio
Atributos
codigo: Integer
bairro: String
rua: String
num: String
complemento: String
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
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>
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
PIZZA
Descrio
Atributos
codigo: Integer
sabores : ArrayList<Sabor>
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
35
ACOMPANHAMENTO
Descrio
Atributos
nome: String
cdigo: Integer
valor: Float
removido: boolean
Operaes
categoria()
getValor(): Float
getCodigo(): Integer
getNome(): String
isRemovido(): boolean
setALL(rs : ResultSet,
nextInicial: boolean) : boolean
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
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
PAGAMENTO
Descrio
Atributos
codigo: Integer
tipo: String
Operaes
pagamento()
getCodigo(): Integer
getTipo(): String
setCodigo(codigo: Integer): void
setTipo(tipo: String): void
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
39
GERENTE
Descrio
Atributos
nome: String
cdigo: Integer
usuario: String
senha: String
Operaes
categoria()
getUsuario():String
getCodigo(): Integer
getNome(): String
getSenha ():String
setALL(rs : ResultSet,
nextInicial: boolean) : boolean
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
33,3333%
___________________________________
Eder S. Ziomek
33,3333%
___________________________________
Heitor Faccioni
33,3333%
___________________________________
44