Trabalho do Curso de Gestão HospitalarDescrição completa
Descrição: PORTIFOLIO EM GRUPO
Descrição: 3º Semestre UNOPAR
Descrição completa
Descrição: Livros Da Unopar
Modelo de Relatório de Estagio - UnoparDescrição completa
mais informações pelo whatsApp 74 9-88067681
Modelo de Relatório de Estagio - UnoparDescrição completa
documentoDescripción completa
Descrição completa
Sistema de Puesta a TierraDescripción completa
Full description
cálculo de sistema puesta a tierraDescripción completa
automotrisFull description
Descripción completa
InacapDescripción completa
Unioeste – Universidade Universidade Estadual do Oeste do Paraná CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS Colegiado de Ciências da Computação Cu r so de Bach B achar ar elado ela do em Ci ên cias ci as da Comp C ompu u tação
Especificação de Requisitos e Modelagem Sistema de Entrega de Pizza - SISEP
André Luiz Luchesi Eder Schaphauser Ziomek Heitor Faccioni
Cascavel – Paraná Paraná 12 de abril de 2012
SUMÁRIO 1. INTRODUÇÃO............................. INTRODUÇÃO................................................... ............................................ ............................................ ....................................3 ..............3 2. PROBLEMA DA EMPRESA................................. EMPRESA....................................................... ............................................ ................................3 ..........3 3. METODOLOGIA ESCOLHIDA..................................... ESCOLHIDA........................................................... ............................................ .......................3 .3 4. MODELAGEM ORGANIZACIONAL I*........................................ I*.............................................................. ............................4 ......4 4.1. MODELO DE DEPENDÊNCIAS ESTRATÉGICAS...................................... ESTRATÉGICAS...............................................4 .........4 4.1.1 DESCRIÇÃO DO MODELO DE DEPENDÊNCIAS ESTRATÉGICAS..............4 4.2. MODELO DE RAZÕES ESTRATÉGICAS......................... ESTRATÉGICAS.................................................... .....................................8 ..........8 4.2.1 DESCRIÇÃO DO MODELO DE DEPENDÊNCIAS ESTRATÉGICAS...............8 ESTRATÉGICAS...............8 5. ESPECIFICAÇÃO DE REQUISITOS ............................................................... .......................................................................10 ........10 5.1 REQUISITOS FUNCIONAIS..................................... FUNCIONAIS........................................................... ............................................ ........................10 ..10 5.2 REQUISITOS NÃO FUNCIONAIS .............................................................. ........................................................................14 ..........14 6. O GRAFO SIG……………………………………………………………............... 16 7. CASOS DE USO .......................................... ................................................................ ............................................ ........................................18 ..................18 7.1. DIAGRAMA DOS CASOS DE USO............................................................. USO......................................................................18 .........18 7.2. DIAGRAMA DOS CASOS DE USO............................................................. USO......................................................................19 .........19 8. DIAGRAMAS DE CLASSES ................................................................ ....................................................................................29 ....................29 9. CONCLUSÃO.............................. CONCLUSÃO.................................................... ............................................ .............................................. ...................................43 ...........43 APÊNDICE A – COLETA DE INFORMAÇÕES........................... INFORMAÇÕES................................................. ...............................43 .........43
SUMÁRIO DE FIGURAS FIGURA 1. MODELO DE DEPENDÊNCIAS ESTRATÉGICAS................................ ESTRATÉGICAS.................................7 .7 FIGURA 2. MODELO DE RAZÕES ESTRATÉGICAS........................................... ESTRATÉGICAS................................................9 .....9 FIGURA 3. GRAFO SIG ............................................ .................................................................. ............................................. ............................ ..... 17 FIGURA 4. DIAGRAMA DE CASOS DE USO.......................................... USO............................................................18 ..................18 FIGURA 5. DIAGRAMA DE CLASSES....................................... CLASSES............................................................. ................................30 ..........30
2
SUMÁRIO 1. INTRODUÇÃO............................. INTRODUÇÃO................................................... ............................................ ............................................ ....................................3 ..............3 2. PROBLEMA DA EMPRESA................................. EMPRESA....................................................... ............................................ ................................3 ..........3 3. METODOLOGIA ESCOLHIDA..................................... ESCOLHIDA........................................................... ............................................ .......................3 .3 4. MODELAGEM ORGANIZACIONAL I*........................................ I*.............................................................. ............................4 ......4 4.1. MODELO DE DEPENDÊNCIAS ESTRATÉGICAS...................................... ESTRATÉGICAS...............................................4 .........4 4.1.1 DESCRIÇÃO DO MODELO DE DEPENDÊNCIAS ESTRATÉGICAS..............4 4.2. MODELO DE RAZÕES ESTRATÉGICAS......................... ESTRATÉGICAS.................................................... .....................................8 ..........8 4.2.1 DESCRIÇÃO DO MODELO DE DEPENDÊNCIAS ESTRATÉGICAS...............8 ESTRATÉGICAS...............8 5. ESPECIFICAÇÃO DE REQUISITOS ............................................................... .......................................................................10 ........10 5.1 REQUISITOS FUNCIONAIS..................................... FUNCIONAIS........................................................... ............................................ ........................10 ..10 5.2 REQUISITOS NÃO FUNCIONAIS .............................................................. ........................................................................14 ..........14 6. O GRAFO SIG……………………………………………………………............... 16 7. CASOS DE USO .......................................... ................................................................ ............................................ ........................................18 ..................18 7.1. DIAGRAMA DOS CASOS DE USO............................................................. USO......................................................................18 .........18 7.2. DIAGRAMA DOS CASOS DE USO............................................................. USO......................................................................19 .........19 8. DIAGRAMAS DE CLASSES ................................................................ ....................................................................................29 ....................29 9. CONCLUSÃO.............................. CONCLUSÃO.................................................... ............................................ .............................................. ...................................43 ...........43 APÊNDICE A – COLETA DE INFORMAÇÕES........................... INFORMAÇÕES................................................. ...............................43 .........43
SUMÁRIO DE FIGURAS FIGURA 1. MODELO DE DEPENDÊNCIAS ESTRATÉGICAS................................ ESTRATÉGICAS.................................7 .7 FIGURA 2. MODELO DE RAZÕES ESTRATÉGICAS........................................... ESTRATÉGICAS................................................9 .....9 FIGURA 3. GRAFO SIG ............................................ .................................................................. ............................................. ............................ ..... 17 FIGURA 4. DIAGRAMA DE CASOS DE USO.......................................... USO............................................................18 ..................18 FIGURA 5. DIAGRAMA DE CLASSES....................................... CLASSES............................................................. ................................30 ..........30
2
1. INTRODUÇÃO E MOTIVAÇÃO A equipe busca por conhecimento visando aprender aprender as técnicas de engenharia de software, com o objetivo de aplicar essas técnicas de forma correta para o desenvolvimento 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 planejamento estratégico estratégico e econômico o gerente pode pode Relatórios. O sistema apresentará uma interface padronizada e intuitiva. O objetivo é diminuir o tempo e esforço gasto nos procedimentos, aumentando a produtividade e gerenciando os pedidos com uma melhor qualidade e segurança.
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 balcão, 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, observações, previsão de conclusão e no caso de entrega também é anotado o endereço. endereço. Após efetuado o pedido ele é despachado para a cozinha e só retorna quando com a pizza pronta para seu devido destino (entrega (entrega no balcão balcão ou entrega domicilio). Devido ao grande fluxo de pedidos em determinados horários 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 características de metodologia ágil de desenvolvimento, focada no trabalho em equipe, com equipes auto-gerenciadas e participação ativa do cliente para gestão e planejamento de projetos de software. A rotina de Scrum começa com o product backlog, lista dos requisitos do projeto, ordenados por prioridade. A partir desta lista é formado o sprint backlog – requisitos que serão implementados no próximo sprint (iteração); cada sprint dura cerca de 30 dias e, após seu final, as funcionalidades desenvolvidas são validadas pelo product owner (cliente, (cliente, normalmente) e liberadas, iniciando-se um novo ciclo. A rotina de Scrum consiste nos seguintes passos: 1. O ScrumMaster, que mantém os processos (normalmente no lugar de um gerente de projeto). 2. O Proprietário do Produto, ou Product Owner, que representa os stakeholders e o negócio. 3. A Equipe, ou Team, um grupo multifuncional com cerca de 7 ou menos pessoas e que fazem a análise, projeto, implementação, teste etc. O Scrum incentiva o controle da qualidade como variável do projeto, dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo), há um foco 3
explícito em escopo (backlog). Para isso, recomenda-se a priorização de funcionalidades que representem maior valor possível para o negócio. Desta forma, caso seja necessário à diminuição de escopo, as funcionalidades menos valiosas serão adiadas ou canceladas. canceladas.
4. MODELAGEM ORGANIZACIONAL i* A técnica I* de YU (1995) é composta por dois modelos: o Modelo de Dependências Dependências Estratégicas (SD) e o Modelo de Razões Estratégicas (SR). O Modelo de Dependências Estratégicas (SD) descreve os relacionamentos de dependência entre vários atores no contexto organizacional, enquanto o Modelo de Razões Estratégicas (SR) descreve os interesses e preocupações dos stakeholders, stakeholders, e as razões que os levam a adotar uma configuração ou outra.
4.1. MODELO DE DEPENDÊNCIAS ESTRATÉGICAS ESTRATÉGICAS A partir de uma visão macro do modelo de Dependências Estratégicas (SD) figura 2, nota-se que é composto de cinco atores, sendo que a utilização direta do sistema é feita apenas pelos atores gerente e funcionário, essa interação é especificada pelas dependências dependências destes com o ator sistema. sistema. 4.1.1 Descrição do modelo de Dependências Dependências Estratégicas Os círculos representam os atores, como Motoboy, Cliente, SisEP, Funcionário e Gerente. Os atores que efetivamente executarão atividades no sistema são: SisEP, Funcionário e Gerente. Os retângulos são os recursos, ou seja, os dados propriamente ditos. As outras formas são os softgoals. 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 responsável pelo armazenamento, gerenciamento e manipulação dos dados. Através Através dele que os outros atores irão solicitar tarefas, inserir e visualizar os dados. Ator Funcionário O ator funcionário é o usuário 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 acompanhamento no pedido, adicionar pizza no pedido, receber pagamento, gerar nota e realizar backup. Ator Gerente O ator gerente é o usuário que tem acesso a todas as tarefas do funcionário e possui privilegio no sistema podendo realizar além das tarefas do funcionário 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 Relatórios, logar no sistema, deslogar do sistema e alterar a Senha.
4
Ator Motoboy O ator motoboy não vai interagir com o sistema. Ele é responsável por pegar pedidos de clientes, junto com cada pedido tem uma nota, ele recebe ambos do funcionário e após tem a função de entregar aos clientes, após feita a entrega, caso o pedido do cliente não tenha sido pago anteriormente o motoboy deve receber o valor referente ao pedido e mais o preço da entrega. Após ter recebido o ator motoboy deve retornar a pizzaria e entregar o valor ao funcionário. Ator Cliente O ator cliente não vai interagir com o sistema. Ele é responsável 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 não. O ator cliente pode pagar seu pedido no balção ou pagar ao motoboy em caso de entrega. Interação entre Ator Motoboy e Ator Funcionário. Obter nota fiscal : O ator motoboy obtém a nota fiscal referente a um pedido com o ator funcionário. Pegar Pedido: O ator motoboy obtém um pedido com pizzas e acompanhamentos quem são para entrega com o ator funcionário. Receber Pagamento: O ator motoboy recebe o pagamento referente a um pedido e entrega este pagamento ao ator funcionário. Interação entre Ator Cliente e Ator Funcionário. Pagar Pedido: O ator cliente pode pagar o seu pedido diretamente no balção para o ator funcionário ou pode pagar para o ator motoboy em caso de entrega. Interação entre Ator Funcionário e Ator SisEP Alterar Status: O ator funcionário modifica o status de um pedido conforme as suas etapas são concluídas. Cancelar Pedido: O ator funcionário cancela um pedido. Acompanhar Pedido: O ator funcionário acompanha o pedido verificando sua etapa. Receber Pagamento: O ator funcionário recebe um pagamento do ator motoboy ou do ator cliente. Backup: O ator funcionário gera um backup do sistema. Fazer Pedido: O ator funcionário faz um pedido para o ator cliente selecionando pizza e acompanhamento conforme o gosto do ator cliente. Gerar Nota: O ator funcionário gera uma nota do pedido. Alterar Cliente: O ator funcionário altera as informações de um cliente no sistema. Buscar Cliente: O ator funcionário busca um cliente no sistema. Inserir Cliente: O ator funcionário insere um novo cliente no sistema. Remover Cliente: O ator funcionário remove um cliente do sistema. Adicionar Pizza no Pedido: O ator funcionário adiciona uma pizza ao pedido. Adicionar Acompanhamento no Pedido: O ator funcionário adiciona um acompanhamento ao pedido. Checar Cadastro: O ator funcionário checa se já existe um certo cadastro de um cliente.
5
Interação 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. Relatórios: O ator gerente pode gerar relatórios. 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 região do gerente. Logar no Sistema: O ator gerente efetua o login na região do gerente. Deslogar do Sistema: O ator gerente desloga do sistema.
6
Figura 1. Modelo de Dependências Estratégicas - SD
7
4.2 MODELO DE RAZÕES ESTRATÉGICAS
O modelo de Razões Estratégicas (SR), ilustrado na figura 3, complementa o modelo Dependência Estratégicas (SD) de forma a compreender e modelar de maneira mais detalhada as razões associadas com cada ator e suas dependências.
4.2.1 Descrição do modelo de Dependências Estratégicas A descrição visa mostrar de uma maneira melhor como compreender o modelo de Razões Estratégicas (SR) que é um complemento do modelo anteriormente já descrito modelo de Dependência Estratégicas (SD). Interação entre Ator Cliente e Ator Funcionário. Pagar Pedido: O ator cliente pode pagar o seu pedido diretamente no balção para o ator funcionário ou pode pagar para o ator motoboy em caso de entrega. Interação entre Ator Funcionário 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 opções: [cartão de credito, cartão 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. Interação entre Ator Gerente e Ator SisEP Gerenciar Categoria: A tarefa Gerenciar Categoria consiste nas tarefas (Alterar Categoria, Buscar Categoria, Inserir Categoria, Remover Categoria). Relatórios: A tarefa Relatórios consiste nas tarefas (Selecionar tipo de relatório e Efetuar Relatório). 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.
8
Figura 2. Modelo de Razões Estratégicas - SR
9
5. Especificação de Requisitos “São as declarações de s erviços
que o sistema deve fornecer como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações. Em alguns casos, os requisitos funcionais podem também estabelecer explicitamente o que o sistema não deve f azer” (Sommerville, 2007).
5.1 Requisitos Funcionais [RF-01] – Inserir Sabor O sistema deverá permitir o cadastro de um novo sabor de pizza, com a especificação referente à entrada dos dados fornecida pelo usuário. A entrada de dados consiste nas seguintes informações: [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é-existência. Prioridade: Alta. Solicitante: Gerente. [RF-02] – Alterar Sabor O sistema deverá permitir a alteração de um determinado sabor de pizza já cadastrado. A alteração é dada pela nova entrada dos dados fornecida pelo usuário. A entrada de dados consiste nas seguintes informações: [Nome do sabor, categoria e ingredientes]. Prioridade: Média. Solicitante: Gerente. [RF-03] – Remover Sabor O sistema deverá permitir a remoção de um determinado sabor de pizza já cadastrado. Contudo, o sistema deverá permitir emitir relatórios contendo o sabor removido. Prioridade: Média. 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 usuário. Prioridade: Alta. Solicitante: Funcionário. [RF-05] – Inserir Categoria O sistema deverá permitir o cadastro de uma nova categoria de pizza no sistema, com a especificação referente à entrada dos dados fornecida pelo usuário. A entrada de dados consiste nas seguintes informações: [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 possíveis são: [Pequena, Média, Grande e Gigante]. O valor é o preço de venda dos sabores de pizzas associados a categoria. Prioridade: Alta. 10
Solicitante: Gerente [RF-06] – Alterar Categoria O sistema deverá permitir a alteração de uma determinada categoria de pizza já cadastrada, a alteração é dada pela nova entrada dos dados fornecida pelo usuário. A entrada de dados consiste nas seguintes informações: [Nome da categoria, tamanho e valor]. Prioridade: Média. Solicitante: Gerente.
[RF-07] – Remover Categoria O sistema deverá permitir a remoção de uma determinada categoria de pizza já cadastrada. Contudo, o sistema deverá permitir emitir relatórios 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 usuário. Prioridade: Alta. Solicitante: Funcionário. [RF-09] – Inserir Acompanhamento O sistema deverá permitir o cadastro de um novo acompanhamento, com a especificação referente à entrada dos dados fornecida pelo usuário. A entrada de dados consiste nas seguintes informações: [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 não seja uma pizza. Prioridade: Alta. Solicitante: Gerente. [RF-10] – Alterar Acompanhamento O sistema deverá permitir a alteração de um determinado acompanhamento já cadastrado, a alteração é dada pela nova entrada dos dados fornecida pelo usuário. A entrada de dados consiste nas seguintes informações: [Nome do acompanhamento e valor]. Prioridade: Média. Solicitante: Gerente. [RF-11] – Remover Acompanhamento O sistema deverá permitir a remoção de um determinado acompanhamento já cadastrado. Contudo, o sistema deverá permitir emitir relatórios 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 usuário. Prioridade: Alta. Solicitante: Gerente. [RF-13] – Inserir Cliente O sistema deverá permitir o cadastro de um novo cliente, com a especificação referente à entrada dos dados fornecida pelo usuário. A entrada de dados consiste nas seguintes informações: [Nome completo do cliente, o número do RG, a data de nascimento, dois telefones para contato, o sexo e o endereço contendo: bairro, rua, número e complemento]. Prioridade: Alta. Solicitante: Funcionário. [RF-14] – Alterar Cliente O sistema deverá permitir a alteração de um determinado cliente já cadastrado. A alteração é dada pela nova entrada dos dados fornecida pelo usuário. A entrada de dados consiste nas seguintes informações: [Nome completo do cliente, o número do RG, a data de nascimento, dois telefones para contato, o sexo e o endereço contendo: bairro, rua, número e complemento]. Prioridade: Média. Solicitante: Funcionário. [RF-15] – Remover Cliente O sistema deverá permitir a remoção de um determinado cliente já cadastrado. Prioridade: Média. Contudo, o sistema deverá permitir emitir relatórios contendo o cliente removido. Prioridade: Baixa. Solicitante: Funcionário. [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, número do RG e telefone]. Prioridade: Alta. Solicitante: Funcionário. [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 endereço de entrega caso a entrega seja solicitada. Prioridade: Alta. Solicitante: Funcionário.
12
[RF-18] – Acompanhar Pedido * Este caso de uso não será implementado neste trabalho. O sistema deverá permitir acompanhar um determinado pedido. Exibindo as suas informações para o usuário. Um pedido contém as seguintes informações: [Nome do Cliente, um campo para solicitação de entrega, endereço 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: Funcionário.
[RF-19] – Alterar Status * Este caso de uso não será implementado neste trabalho. O sistema deverá permitir a alteração do status de um pedido em determinados momentos. O status indicará em qual “etapa” o pedido estará em um determinado momento. Os status possíveis são: [preparando, pronta, entregando, finalizado e cancelado]. Prioridade: Alta. Solicitante: Funcionário. [RF-20] – Cancelar Pedido O sistema deverá permitir o cancelamento de um determinado pedido. Sendo de total responsabilidade do usuário, os defeitos associados ao mesmo. Prioridade: Alta. Solicitante: Funcionário. [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, cartão debito e cartão crédito]. O sistema armazenará o valor e a forma do pagamento. Prioridade: Alta. Solicitante: Funcionário. [RF-22] – Gerar Nota O sistema deverá permitir gerar uma nota após o pagamento de um determinado pedido. A nota deverá conter as seguintes informações: [Um cabeçalho contendo nome da empresa, razão social, endereço, telefone, CNPJ, Inscrição Estadual], [Um corpo contendo o nome do cliente, data, hora, nome do produto, quantidade, valor unitário, valor total, forma de pagamento, troco]. Prioridade: Alta. Solicitante: Funcionário. [RF-23] – Relatórios O sistema deverá permitir gerar relatórios específicos. Os tipos relatórios possíveis são: [Relatório de controle de caixa, relatório de vendas (pizzas, acompanhamentos), relatório de cliente]. Prioridade: Média. Solicitante: Gerente. [RF-24] – Alterar Senha * Este caso de uso não será implementado neste trabalho. O sistema deverá permitir a alteração da senha do login do gerente. Prioridade: Baixa. Solicitante: Gerente. 13
[RF-25] – Logar no Sistema * Este caso de uso não 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 funções exclusivas do gerente. Prioridade: Baixa. Solicitante: Gerente. [RF-26] – Deslogar do Sistema * Este caso de uso não será implementado neste trabalho. O usuário sai do modo do gerente e vai para o modo funcionário, portanto o sistema deverá restringir o acesso ao conteúdo 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: Funcionário. [RF-28] – Adicionar Acompanhamento no pedido O sistema deverá permitir que o usuário selecionar um acompanhamento para adicionar a um pedido. Prioridade: Alta. Solicitante: Funcionário. [RF-29] – Adicionar Pizza no pedido O sistema deverá permitir que o usuário monte e adicione uma pizza, selecionando o tamanho e escolhendo os seus sabores. Prioridade: Alta. Solicitante: Funcionário. [RF-30] – Backup O sistema deverá permitir realizar um backup (salvar os dados) do sistema. Prioridade: Baixa. Solicitante: Funcionário. 5.2 REQUISITOS NÃO FUNCIONAIS Os requisitos não funcionais referem-se a aspectos não funcionais do sistema, como restrições nas quais o sistema deve operar ou propriedades emergentes do sistema. O sistema está dividido nos seguintes requisitos não funcionais: manutenibilidade, segurança, confiabilidade e usabilidade. Segue abaixo a especificação 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 programação Java, utilizando a técnica da programação orientada a objeto. O código 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 padrão de camadas MVC (Model-view-controller). Onde os modelos de dados, a parte visual e a parte lógica de funcionamento são separados, tornando mais fácil qualquer incremento no software. Quanto à Usabilidade [RNF-04] O sistema deverá possuir uma interface amigável, explorando os aspectos visuais para interagir com o usuário, tais como uso de tons de cores mais suaves, padronização de telas e restringindo os níveis de menus, tornando o programa mais interativo e produtivo. [RNF-05] O sistema deverá ter botões intuitivos, deixando explicito as funcionalidades de cada opção. [RNF-06] Mensagens de erro ou mensagens de confirmação deverão ser mostradas ao usuário. Mensagens de confirmação deverão aparecer quando uma determinada operação for considerada crítica e as mensagens de erro deverão aparecer quando uma operação não for concluída com sucesso, de modo explicativo para melhor orientação do usuário. Quanto à Confiabilidade [RNF-07] A integridade dos dados será mantida pela utilização do SGBD PostgreSQL, pois é uma ferramenta open source, ou seja, software livre dispensando o gasto com licenças. Além de tudo é uma ferramenta confiável e muito utilizada principalmente para o uso acadêmico. Quanto à Segurança do Sistema [RNF-08] A confidencialidade do sistema será garantida pela política de login e senha. Backup Quanto à Portabilidade [RNF-09] O sistema será implementado utilizando a linguagem de programação Java para a facilidade de portabilidade caso seja necessário. Quanto ao Custo e Desempenho [RNF-10] Tratando-se de um trabalho acadêmico, 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 configurações: Configuração mínima: Processador 1200 MHz, 512MB de memória e espaço mínimo de HD de 1 GB.
15
Configuração recomendável: Processador 1800 MHz, 1GB de memória e espaço mínimo de HD de 2 GB.
6. O GRAFO SIG ( SOFTGOAL I NTERDEPENDE NCY GRAPHS) O grafo SIG permite uma visão de alto nível, cujo principal objetivo é apresentar os requisitos não – funcionais, proporcionam uma visão mais realista do sistema. Através 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 não funcionais: Manutenibilidade, Usabilidade, Confiabilidade, Segurança, Portabilidade, Custo e Desempenho.
16
Figura 3. Grafo SIG
17
7. CASOS DE USO Um caso de uso é uma descrição 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 usuários, máquinas, sensores, etc… Um ator representa um papel no sistema, mas um papel pode ser representando por vários atores.
Figura 4. Diagrama de Casos de Uso
18
7.2. DESCRIÇÃO DOS CASOS DE USO [Caso de uso 001] Inserir Sabor Descrição: Cadastra um novo sabor de pizza no sistema, com a especificação referente à entrada dos dados fornecida pelo usuário. Escopo: SisEP. Pré-condição: O gerente estar logado no sistema. Pós-Condições: Retorna mensagem Sabor inserido com sucesso. Ator Primário: Gerente. Cenário Principal de Sucesso: 1. O usuário escolhe a opção Inserir Sabor. 2. O usuário deverá informar os dados do novo Sabor. A entrada de dados consiste nas seguintes informações: [Nome do sabor, categoria e ingredientes]. 3. O usuário após concluir o preenchimento, submete os dados para armazenamento no banco de dados. 4. O sistema valida os dados e retorna mensagem de sucesso. Cenário Secundário: 4.1. Caso os dados sejam inválidos: O sistema aborta o procedimento e retorna mensagem de erro mostrando quais dados são necessários para o cadastro do produto. [Caso de uso 002] Alterar Sabor Descrição: Altera um determinado sabor de pizza cadastrado no sistema, a alteração é dada pela nova entrada dos dados fornecida pelo usuário. Escopo: SisEP. Pré-condição: O gerente estar logado no sistema. Pós-Condições: Retorna mensagem Sabor alterado com sucesso. Ator Primário: Gerente Cenário Principal de Sucesso: 1. O usuário escolhe a opção: Alterar Sabor. 2. O usuário deverá editar os dados do Sabor desejado. A entrada de dados consiste nas seguintes informações: [Nome do sabor, categoria e ingredientes]. 3. O usuário após concluir o preenchimento, submete os dados para armazenamento no banco de dados. 4. O sistema valida os dados e retorna mensagem de sucesso. Cenário Secundário: 4.1. Caso os dados sejam inválidos: O sistema aborta o procedimento e retorna mensagem de erro mostrando quais dados são necessários para o cadastro do produto.
19
[Caso de uso 003] Remover Sabor Descrição: Remove um determinado sabor de pizza cadastrado no sistema, a remoção não é física, portanto não remove do banco de dados. Escopo: SisEP. Pré-condição: O gerente estar logado no sistema. Pós-Condições: Retorna mensagem Sabor removido com sucesso. Ator Primário: Gerente Cenário Principal de Sucesso: 1. O usuário escolhe a opção: Remover Sabor. 2. O usuário deverá selecionar o Sabor desejado. 3. O usuário deverá confirmar que deseja remover o Sabor. 4. O Sistema altera a flag no banco de dados e retorna mensagem de sucesso. Cenário Secundário: 3.1. Caso o usuário não confirme a remoção: o sistema aborta o procedimento. [Caso de uso 004] Buscar Sabor Descrição: Busca um determinado sabor de pizza cadastrado no sistema, a busca é feita a partir de dados fornecidos pelo usuário referentes ao sabor que deseja buscar. Para listar todos os sabores basta não inserir dados na pesquisa. Escopo: SisEP. Pré-condição: Pós-Condições: Ator Primário: Gerente Cenário Principal de Sucesso: 1. O caso de uso inicia-se já com o sistema exibindo a lista de sabores. 2. O usuário insere o nome do sabor que deseja buscar. 3. O sistema exibe “filtra” o resultado da busca. [Caso de uso 005] Inserir Categoria Descrição: Cadastra uma nova categoria de pizza no sistema, com a especificação referente à entrada dos dados fornecida pelo usuário. Escopo: SisEP. Pré-condição: O gerente estar logado no sistema. Pós-Condições: Retorna mensagem Categoria inserida com sucesso. Ator Primário: Gerente Cenário Principal de Sucesso: 1. O usuário escolhe a opção: Inserir Categoria. 2. O usuário deverá informar os dados da nova Categoria. A entrada de dados consiste nas seguintes informações: [Nome da categoria, tamanho e valor]. 3. O usuário após concluir o preenchimento, submete os dados para armazenamento no banco de dados. 4. O sistema valida os dados e retorna mensagem de sucesso. Cenário Secundário: 4.1. Caso os dados sejam inválidos: O sistema aborta o procedimento e retorna mensagem de erro mostrando quais dados são necessários para o cadastro do produto.
20
[Caso de uso 006] Alterar Categoria Descrição: Altera uma determinada categoria de pizza cadastrada no sistema, a alteração é dada pela nova entrada dos dados fornecida pelo usuário. Escopo: SisEP. Pré-condição: O gerente estar logado no sistema. Pós-Condições: Retorna mensagem Categoria alterada com sucesso. Ator Primário: Gerente Cenário Principal de Sucesso: 1. O usuário escolhe a opção: Alterar Categoria. 2. O usuário deverá editar os dados da Categoria desejada. A entrada de dados consiste nas seguintes informações: [Nome da categoria, tamanho e valor]. 3. O usuário após concluir o preenchimento, submete os dados para armazenamento no banco de dados. 4. O sistema valida os dados e retorna mensagem de sucesso. Cenário Secundário: 4.1. Caso os dados sejam inválidos: O sistema aborta o procedimento e retorna mensagem de erro mostrando quais dados são necessários para o cadastro do produto. [Caso de uso 007] Remover Categoria Descrição: Remove uma determinada Categoria de pizza cadastrada no sistema, a remoção não é física, portanto não remove do banco de dados. Escopo: SisEP. Pré-condição: O gerente estar logado no sistema. Pós-Condições: Retorna mensagem Categoria removida com sucesso. Ator Primário: Gerente Cenário Principal de Sucesso: 1. O usuário escolhe a opção: Remover Categoria 2. O usuário deverá selecionar a Categoria desejada. 3. O usuário deverá confirmar que deseja remover a Categoria. 4. O usuário após concluir, altera a “flag” no banco de dados e retorna mensagem de sucesso. Cenário Secundário: 3.1. Caso o usuário não confirme a remoção: o sistema aborta o procedimento. [Caso de uso 008] Buscar Categoria Descrição: Busca uma determinada categoria de pizza cadastrado no sistema, a busca é feita a partir de dados fornecidos pelo usuário referentes a categoria que deseja buscar. Para listar todas as categorias basta não inserir dados na pesquisa. Escopo: SisEP. Pré-condição: O gerente estar logado no sistema. Ator Primário: Gerente. Cenário Principal de Sucesso: 1. O caso de uso inicia-se com o sistema exibindo a lista de categorias. 2. O usuário insere o nome da categoria que deseja buscar. 3. O sistema exibe “filtra” o resultado da busca.
21
[Caso de uso 009] Inserir Acompanhamento Descrição: Cadastra um novo acompanhamento no sistema, com a especificação referente à entrada dos dados fornecida pelo usuário. Escopo: SisEP. Pré-condição: O gerente deve estar logado no sistema. Pós-Condições: Retorna mensagem Acompanhamento inserido com sucesso. Ator Primário: Gerente Cenário Principal de Sucesso: 1. O usuário escolhe a opção: Inserir Acompanhamento. 2. O usuário deverá informar os dados do novo acompanhamento. A entrada de dados consiste nas seguintes informações: [Nome do acompanhamento e valor]. 3. O usuário após concluir o preenchimento, submete os dados para armazenamento no banco de dados. 4. O sistema valida os dados e retorna mensagem de sucesso. Cenário Secundário: 4.1. Caso os dados sejam inválidos: O sistema aborta o procedimento e retorna mensagem de erro mostrando quais dados são necessários para o cadastro do produto. [Caso de uso 010] Alterar Acompanhamento Descrição: Altera um determinado Acompanhamento cadastrado no sistema, a alteração é dada pela nova entrada dos dados fornecida pelo usuário. Escopo: SisEP. Pré-condição: O gerente estar logado no sistema. Pós-Condições: Retorna mensagem Acompanhamento alterado com sucesso. Ator Primário: Gerente Cenário Principal de Sucesso: 1. O usuário escolhe a opção: Alterar Acompanhamento. 2. O usuário deverá editar os dados do Acompanhamento desejado. A entrada de dados consiste nas seguintes informações: [Nome do acompanhamento e valor]. 3. O usuário após concluir o preenchimento, submete os dados para armazenamento no banco de dados. 4. O sistema valida os dados e retorna mensagem de sucesso. Cenário Secundário: 4.1. Caso os dados sejam inválidos: O sistema aborta o procedimento e retorna mensagem de erro mostrando quais dados são necessários para o cadastro do produto. [Caso de uso 011] Remover Acompanhamento Descrição: Remove um determinado Acompanhamento cadastrado no sistema, a remoção não é física, portanto não remove do banco de dados.. Escopo: SisEP. Pré-condição: O gerente estar logado no sistema. Pós-Condições: Retorna mensagem Acompanhamento removido com sucesso. Ator Primário: Gerente Cenário Principal de Sucesso: 1. O usuário escolhe a opção: Remover Acompanhamento. 2. O usuário deverá selecionar o Acompanhamento desejado. 3. O usuário deverá confirmar que deseja remover o Acompanhamento. 22
4. O usuário após concluir, altera a flag no banco de dados e retorna mensagem de sucesso. Cenário Secundário: 3.1. Caso o usuário não confirme a remoção: o sistema aborta o procedimento.
[Caso de uso 012] Buscar Acompanhamento Descrição: Busca um determinado acompanhamento cadastrado no sistema, a busca é feita a partir de dados fornecidos pelo usuário referentes ao acompanhamento que deseja buscar. Para listar todos os acompanhamentos basta não inserir dados na pesquisa. Escopo: SisEP. Pré-condição: O gerente estar logado no sistema. Ator Primário: Gerente Cenário Principal de Sucesso: 1. O caso de uso inicia-se com o sistema exibindo a lista de acompanhamento. 2. O usuário insere o nome do acompanhamento que deseja buscar. 3. O sistema e xibe “filtra” o resultado da busca. [Caso de uso 013] Inserir Cliente Descrição: Cadastra um novo cliente no sistema, com a especificação referente à entrada dos dados fornecida pelo usuário. Escopo: SisEP. Pré-condição: Pós-Condições: Retorna mensagem Cliente inserido com sucesso. Ator Primário: Funcionário Cenário Principal de Sucesso: 1. O usuário escolhe a opção: Inserir Cliente. 2. O usuário deverá informar os dados do novo Cliente. A entrada de dados consiste nas seguintes informações: [Nome completo do cliente, o número do RG, a data de nascimento, dois telefones para contato, o sexo e o endereço contendo: bairro, rua, número e complemento]. 3. O usuário após concluir o preenchimento, submete os dados para armazenamento no banco de dados. 4. O sistema valida os dados e retorna mensagem de sucesso. Cenário Secundário: 4.1. Caso os dados sejam inválidos: O sistema aborta o procedimento e retorna mensagem de erro mostrando quais dados são necessários para o cadastro do produto.
23
[Caso de uso 014] Alterar Cliente Descrição: Altera um determinado cliente cadastrado no sistema, a alteração é dada pela nova entrada dos dados fornecida pelo usuário. Escopo: SisEP. Pré-condição: O cliente já deverá estar cadastrado no banco de dados. Pós-Condições: Retorna mensagem Cliente alterado com sucesso. Ator Primário: Funcionário Cenário Principal de Sucesso: 1. O usuário escolhe a opção: Alterar Cliente. 2. O usuário deverá editar os dados do Cliente desejado. A entrada de dados consiste nas seguintes informações: [Nome completo do cliente, o número do RG, a data de nascimento, dois telefones para contato, o sexo e o endereço contendo: bairro, rua, número e complemento]. 3. O usuário após concluir o preenchimento, submete os dados para armazenamento no banco de dados. 4. O sistema valida os dados e retorna mensagem de sucesso. Cenário Secundário: 4.1. Caso os dados sejam inválidos: O sistema aborta o procedimento e retorna mensagem de erro mostrando quais dados são necessários para o cadastro do produto. [Caso de uso 015] Remover Cliente Descrição: Remove um determinado cliente cadastrado no sistema, a remoção não é física, portanto não remove do banco de dados. Escopo: SisEP. Pré-condição: O cliente já deverá estar cadastrado no banco de dados. Pós-Condições: Retorna mensagem Cliente removido com sucesso. Ator Primário: Funcionário Cenário Principal de Sucesso: 1. O usuário escolhe a opção: Remover Cliente. 2. O usuário deverá selecionar o Cliente desejado. 3. O usuário deverá confirmar que deseja remover o Cliente. 4. O usuário após concluir, altera a flag no banco de dados e retorna mensagem de sucesso. Cenário Secundário: 3.1. Caso o usuário não confirme a remoção: o sistema aborta o procedimento. [Caso de uso 016] Buscar Cliente Descrição: Busca um determinado cliente cadastrado no sistema, a busca é feita a partir de dados fornecidos pelo usuário referentes ao cliente que deseja buscar. Para listar todos os clientes basta não inserir dados na pesquisa. Escopo: SisEP. Ator Primário: Funcionário Cenário Principal de Sucesso: 1. O caso de uso inicia-se com o sistema exibindo a lista de clientes. 2. O usuário insere o nome do cliente ou número do RG ou número do telefone, que deseja buscar. 3. O sistema exibe “filtra” o resultado da busca. 24
[Caso de uso 017]: Fazer Pedido Descrição: Cria um novo pedido contendo as informações do cliente, do endereço de entrega e os itens pedidos pelo cliente. Escopo: SisEP. Pré-condição. Pós-Condições: Retorna mensagem Pedido efetuado com sucesso. Ator Primário: Funcionário Cenário Principal de Sucesso: 1. O usuário escolhe a opção: Fazer Pedido. 2. O usuário verifica se o cliente já possui cadastro. 3. O usuário adiciona a quantidade desejada de pizzas. Para adicionar uma pizza o usuário deverá escolhe a opção: Adicionar Pizza. 4. O usuário selecionar o tamanho da pizza. 5. O usuário deverá selecionar o sabor desejado. 6. O usuário adiciona o sabor à pizza clicando no botão: Adicionar Sabor. 7. O usuário adiciona a quantidade desejada de acompanhamentos. Para adicionar uma acompanhamento o usuário deverá escolhe a opção: Adicionar Acompanhamento. 8. O usuário deverá selecionar o acompanhamento desejado. 9. O usuário adiciona o acompanhamento no pedido clicando no botão: Adicionar Acompanhamento. 10. O usuário deverá informar se o pedido é para entrega ou não. 11. O usuário deverá verificar se o endereço do cadastro do cliente é o endereço desejado da entrega. 12. Se necessário o usuário 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 usuário conclui o pedido. 16. O sistema armazena o pedido no banco de dados. 17. O sistema adiciona o pedido na lista de pedidos. Cenário Secundário: 2.1 Caso o cliente não possua cadastro: o usuário deverá inserir o cliente. 3.1 Caso o cliente não deseja pizza: o usuário avança para o passo 7. 7.1 Caso o cliente não deseja acompanhamento: o usuário avança para o passo 10. 10.1 Caso não seja para entrega: o usuário avança para o passo 13. 11.1 Caso o endereço cadastrado não seja o desejado para entrega: o usuário deverá adiciona um endereço de entrega ao pedido. [Caso de uso 018]: Acompanhar Pedido Descrição: Visualiza as informações relevantes de um determinado pedido. Escopo: SisEP. Pré-condição. O pedido deve estar em andamento. Ator Primário: Funcionário Cenário Principal de Sucesso: 1. O usuário deverá selecionar o Pedido desejado. 2. O sistema busca o pedido no banco de dados e obtém suas informações. 3. O sistema exibe o resultado na tela. Cenário Secundário: 25
1.1 Caso o pedido não seja selecionado: o sistema retorna a mensagem de erro: Selecione um Pedido.
[Caso de uso 019]: Alterar Status Descrição: O sistema deverá alterar o status de um pedido em determinados momentos, os status possíveis são: preparando, pronto, entregando, finalizado e cancelado. Escopo: SisEP. Pré-condição. O pedido deve estar em andamento. Pós-Condições: Retorna mensagem Status alterando com sucesso. Ator Primário: Funcionário Cenário Principal de Sucesso: 1. O usuário deverá selecionar o pedido. 2. O usuário deverá definir o status atual do pedido. Cenário Secundário: 1.1 Caso o pedido não seja selecionado: o sistema retorna a mensagem de erro: Selecione um Pedido. [Caso de uso 020]: Cancelar Pedido Descrição: Cancela um pedido que esta em andamento. Escopo: SisEP. Pré-condição pedido em andamento e com status não finalizado ainda. Pós-Condições: Retorna mensagem Pedido cancelado com sucesso. Ator Primário: Funcionário Cenário Principal de Sucesso: 1. O usuário deverá selecionar o Pedido desejado. 2. O usuário confirma o cancelamento do pedido. 3. O sistema efetua Cancelamento. Cenário Secundário: 1.1 Caso o pedido não seja selecionado: o sistema retorna a mensagem de erro: Selecione um Pedido. 2.1 Caso o usuário não confirme o cancelamento: o sistema aborta o procedimento. [Caso de uso 021]: Receber Pagamento Descrição: Confirma o pagamento de um determinado pedido. Escopo: SisEP. Pré-condição. O pedido deve estar em andamento. Pós-Condições: Retorna mensagem Pagamento de Pedido realizado com sucesso. Ator Primário: Funcionário Cenário Principal de Sucesso: 1. O usuário deverá selecionar o pedido. 2. O usuário deverá definir a forma de pagamento. O pagamento poderá ser feito nas seguintes formas: [Dinheiro, cartão debito e cartão crédito]. 3. O sistema atribui ao pedido o status de pago. 4. O sistema emite a nota. Cenário Secundário: 1.1 Caso o pedido não seja selecionado: o sistema retorna a mensagem de erro: Selecione um Pedido. 26
[Caso de uso 022]: Gerar Nota Descrição: O sistema deverá fornecer uma nota após efetuado o pagamento do pedido. Escopo: SisEP. Pré-condição. O pedido deve estar em andamento. Pós-Condições: Gera um arquivo PDF contendo os dados da nota. Ator Primário: Funcionário Cenário Principal de Sucesso: 1. O usuário deverá selecionar o pedido. 2. O sistema irá gerar o arquivo PDF referente aos dados do pedido selecionado. A nota deverá conter as seguintes informações: [Um cabeçalho contendo nome da empresa, razão social, endereço, telefone, CNPJ, IE], [Um corpo contendo o nome do cliente, data, hora, nome do produto, quantidade, valor unitário, valor total, forma de pagamento, troco]. Cenário Secundário: 1.1 Caso o pedido não seja selecionado: o sistema retorna a mensagem de erro: Selecione um Pedido. [Caso de uso 023] Relatórios Descrição: Gera relatórios específicos, que serão implementados posteriormente. Não discorreremos mais sobre a geração de relatórios, pois esta faz parte do processo incremental e iterativo da construção do sistema, dependendo diretamente das necessidades do cliente. Escopo: SisEP. Pré-condição: O gerente estar logado no sistema. Ator Primário: Gerente Cenário Principal de Sucesso: 1. O usuário escolhe a opção: Relatórios. 2. O usuário seleciona o tipo de relatório. Os tipos relatórios possíveis são: [Relatório de controle de caixa, relatório de vendas (pizzas, acompanhamentos), relatório de cliente]. 3. Preencher, se houver, os dados de “filtro” a res peito do relatório selecionado. 4. O sistema validará os dados. 5. O sistema gera o relatório na tela, (posteriormente será analisada a possibilidade da geração de relatórios no formato PDF). Cenário Secundário: 4.1. Caso os dados sejam inválidos: O sistema aborta o procedimento e retorna mensagem de erro mostrando quais dados são necessários para gerar o relatório. [Caso de uso 024]: Alterar senha Descrição: Altera a senha atual do login do gerente. Escopo: SisEP. Pré-condição. O gerente deve estar logado no sistema. Pós-Condições: O sistema retorna a mensagem Senha alterada com sucesso. Ator Primário: Gerente. Cenário Principal de Sucesso: 1. O gerente escolhe a opção: 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 mínimo 6 dígitos, sendo possível o uso de qualquer tipo de caractere e fazendo distinção de letras maiúsculas de minúsculas. 4. O gerente deverá confirmar a alteração. 5. O sistema altera a senha do gerente. Cenário Secundário: 2.1 Caso a senha informada seja incorreta: o sistema retorna a mensagem de erro: Senha incorreta. 3.1. Caso a nova senha seja inválida: O sistema retorna a mensagem de erro: Senha inválida. 4.1. Caso o gerente não confirme a alteração da senha: o sistema aborta o procedimento.
[Caso de uso 025]: Logar no Sistema Descrição: O gerente deverá entrar com seus dados: login e senha. O Sistema deverá permitir acesso ao conteúdo restrito do software somente se os dados estiverem corretos. Escopo: SisEP. Pré-condição O usuário já devera possuir seu cadastro no sistema. Pós-Condições: O Sistema libera acesso à área restrita. Ator Primário: Gerente Cenário Principal de Sucesso: 1. O gerente escolhe a opção: Logar no Sistema. 2. O usuário deverá entrar com seu login e senha. 3. O sistema busca no banco de dados e verifica se os dados estão corretos. 4. O sistema retorna mensagem de login realizado com sucesso e será iniciado. 5. O sistema libera o acesso a área do gerente. Cenário Secundário: 3.1 Caso os dados não estejam corretos: o sistema aborta o procedimento e retorna a mensagem de erro login ou senha inválida. Requisitos Especiais (Special Requirements) Requisitos Não Funcionais: Segurança.
[Caso de uso 026]: Deslogar do Sistema Descrição: O usuário sai do modo do gerente e vai para modo funcionário, portanto o sistema deverá restringir o acesso ao conteúdo exclusivo do gerente. Escopo: SisEP. Pré-condição. O usuário deve estar logado no sistema. Pós-Condições: O sistema restringe o acesso conteúdo exclusivo do gerente. Ator Primário: Gerente. Cenário Principal de Sucesso: 1. O usuário clica em deslogar. 2. O sistema sai do modo gerente e vai para o modo funcionário. Requisitos Especiais (Special Requirements) Requisitos Não Funcionais: Segurança.
28
[Caso de uso 027]: Backup Descrição: Salva os dados presentes no banco de dados em um arquivo do tipo backup do PostgreSQL. O Backup só acontece quando o usuário realiza a operação. Escopo: SisEP. Pós-Condições: Cria o arquivo de backup. Ator Primário: Funcionário Cenário Principal de Sucesso: 1. O usuário escolhe a opção fazer backup. 2. O usuário 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. Cenário Secundário: 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 Não Funcionais: Integridade, Segurança e Confiabilidade.
8. DIAGRAMA DE CLASSES Um diagrama de classes é uma representação da estrutura e relações das classes que servem de modelo para objetos. No diagrama de classe que será apresentado podemos ver as classes mais importantes com os métodos já declarados. Não será feita uma descrição pontual sobre as classes do diagrama, pois os nomes dados aos atributos e aos métodos já estão muito bem esclarecidos e sucintos. Apenas com a visualização do diagrama já se tem uma boa noção do que trata. Ainda contamos com a documentação javadoc durante o desenvolvimento, contribuindo para a compreensão na leitura do código. A documentação completa será gerada posteriormente para consultas. Descrição textual das classes presentes no diagrama de classes – figura 5.
29
Figura 3. Diagrama de Classes
30
1. PACOTE MODELO
CLIENTE Descrição
Atributos Nome: String RG: String telefone_1: String telefone_2: String data_nasc: Date Endereço: Endereco codigo: Int codigo_endereco : Int
A classe cliente representa um cliente que tem cadastro na pizzaria, com essa classe é possível armazenar informações sobre o cliente e assim agilizar o atendimentos posteriores ao cadastro. Responsável pelo armazenamento de informação referente ao nome do cliente. Responsável pelo armazenamento de informação referente ao número do RG. Responsável pelo armazenamento de informação referente ao número do primeiro telefone do cliente. Responsável pelo armazenamento de informação referente ao número do segundo telefone do cliente. Responsável pelo armazenamento de informação referente a data de nascimento do cliente. Responsável pelo armazenamento de informação referente ao endereço do cliente. Responsável pelo armazenamento de informação referente ao código do cliente no banco de dados. Responsável pelo armazenamento de informação referente ao código do endereço do cliente no banco de dados.
Operações
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 variável referente ao código do endereço do cliente. Retorna o valor da variável referente ao código do cliente. Retorna o valor da variável referente a data de nascimento do cliente. Retorna o valor da variável referente ao endereço do cliente. Retorna o valor da variável referente ao nome do cliente. Retorna o valor da variável referente ao número do RG do cliente. Retorna o valor da variável referente ao número do primeiro telefone do cliente. Retorna o valor da variável referente ao número do segundo telefone do cliente. Seta todas as variáveis do cliente a partir de um ResultSet. Retorna verdadeiro se todos os dados foram setados com Sucesso, caso contrário retorna falso. Altera o valor da variável referente ao código do endereço do cliente.
setALL(rs: ResultSet, nextInicial: boolean) : boolean setCodigo_endereco( Integer codigo_endereco) : void setCodigo( Integer Altera o valor da variável referente ao código do cliente. codigo) : void setData_nasc(data_nasc: Altera o valor da variável referente a data de nascimento do Date) : void cliente.
Altera o valor da variável referente ao endereço do cliente. Altera o valor da variável referente ao nome do cliente. Altera o valor da variável referente ao número do rg do cliente. Altera o valor da variável referente ao número do primeiro telefone do cliente. Altera o valor da variável referente ao número do segundo telefone do cliente.
É a classe que armazena informações sobre o endereço como rua, bairro, proximidades. Responsável pelo armazenamento de informação referente ao código do endereço Responsável pelo armazenamento de informação referente ao bairro do endereço. Responsável pelo armazenamento de informação referente a rua do endereço. Responsável pelo armazenamento de informação referente ao número do endereço. Responsável pelo armazenamento de informação referente ao complemento do endereço..
Operações
endereço() getBairro(): String
Construtor Default Retorna o valor da variável referente ao bairro do endereço. getCodigo(): Integer Retorna o valor da variável referente ao código do endereço. getComplemento(): String Retorna o valor da variável referente ao complemento do endereço. getNum(): String Retorna o valor da variável referente ao número do endereço. getRua(): String Retorna o valor da variável referente a rua do endereço. setALL(rs : ResultSet, Seta todas as variáveis do cliente a partir de um nextInicial: boolean) : boolean ResultSet. Retorna verdadeiro se todos os dados foram setados com Sucesso, caso contrário retorna falso. setBairro(bairro: String) :void Altera o valor da variável referente ao bairro do endereço. setCodigo(codigo: Integer) Altera o valor da variável referente ao código do :void endereço. setComplemento(complemento: Altera o valor da variável referente ao complemento String) :void do endereço. setNum(num: String) :void Altera o valor da variável referente ao número do 32
setRua( rua: String) :void
endereço. Altera o valor da variável referente a rua do endereço.
