SISTEMA PARA CADASTRO DE CLIENTES E PRODUTOS LOJA BIG S

Transcrição

1 1 MAYQUEL SILAS ALVES SISTEMA PARA CADASTRO DE CLIENTES E PRODUTOS LOJA BIG S Assis 2010

2 2 MAYQUEL SILAS ALVES SISTEMA PARA CADASTRO DE CLIENTES E PRODUTOS LOJA BIG S Trabalho de Conclusão de Curso apresentado ao Curso de Processamento de Dados do Instituto Municipal de Ensino Superior de Assis IMESA e a Fundação Educacional do Município de Assis FEMA como requisito parcial à obtenção do Certificado de Conclusão. Orientador: Célio Desiró Área de Concentração: Desenvolvimento de Sistemas Assis 2010

3 3 FICHA CATALOGRÁFICA Alves, Mayquel Silas. Sistema para Cadastro de clientes e produtos Loja Big s, Mayquel Silas Alves.Fundação Educacional do Município de Assis - FEMA - Assis Número de Páginas: 61. Orientador: Célio Desiró. Trabalho de Conclusão de Curso Instituto Municipal de Ensino Superior de Assis 1 Sistema de Cadastro 2. Loja CDD: Biblioteca Fema

4 4 SISTEMA PARA CADASTRO DE CLIENTE E PRODUTOS LOJA BIG S MAYQUEL SILAS ALVES Trabalho de conclusão de Curso apresentado ao Instituto Municipal de Ensino Superior de Assis, como requisito do curso de Graduação, analisado pela seguinte comissão examinadora: Orientador: Célio Desiró Analisador(1):Diomara Martins Reigato Barros ASSIS 2010

5 5 AGRADECIMENTOS Primeiramente a Deus, por me ajudar a cumprir mais esta importante etapa de minha vida e por encorajar-me a enfrentar os desafios encontrados ao longo do caminho. Aos meus avós pela compreensão, apoio e paciência comigo nessa difícil jornada. Ao meu orientador e amigo Célio, pela paciência, por ter dividido um pouco de seu conhecimento comigo, pela orientação e pelo constante estímulo transmitido durante o trabalho. Aos amigos Polyano e Gabriel Rios que esclareceram minhas dúvidas no decorrer do desenvolvimento e, especialmente, aos que mais estiveram ao meu lado me apoiando constantemente e me motivando, Luiz Ângelo (Vo), Priscila, Jefferson Ferreira, André do Lago e João, a todos que colaboraram direta ou indiretamente na execução desse trabalho. A minha namorada Franciele, pela compreensão, paciência, motivação e apoio em todos os momentos.

6 6 RESUMO Este trabalho descreve as dificuldades enfrentadas pelo proprietário sr. José Batista, pelo fato de tudo em sua loja ser feito sem qualquer tipo de automação. O sistema busca atender todas as necessidades, especialmente a parte financeira da loja, que é muito importante. Ele faz isso sem qualquer ajuda de terceiros o que tem dificultado a vida dele em manter um bom controle das contas a pagar e receber, além disso, ele tem que atender os clientes, receber produtos dos fornecedores entre outras tarefas e para fazer o levantamento do caixa da loja requer muito tempo. O sistema irá auxiliá-lo com relatórios para que o mesmo possa agilizar e controlar melhor as suas finanças. O software buscará facilitar o trabalho do sr. José auxiliando no controle do estoque, nas finanças, na geração de relatórios de contas a pagar e receber, aniversariantes do mês, já que uma loja, para sobreviver no mercado, não pode ser apenas uma loja tem que sempre estar buscando um diferencial no atendimento ao cliente agilizando o mesmo. Palavras chave: Java, PostgreSQL, Netbeans.

7 7 ABSTRACT This paper describes the difficulties faced by the owner sr. Jose Batista, because everything in your store is done without any kind of automation. The system aims to meet all needs, especially the financial part of the store, which is very important. It does so without the help of third parties which has hindered his life in maintaining a good control of accounts payable and receivable, in addition, he has to meet clients, receive products from suppliers across tasks and to do the lifting box store requires a long time. The system will assist you with reports so that it can streamline and better Manage their finances. The software had sought to facilitate the work of Mr.. Joseph assisting in inventory control, finance, the reporting of accounts payable and receivable, birthdays of the month, as a store to survive in the market, there can be only one store has to always be looking for a gap in care Customer expediting the same. Keywords: Java, PostgreSQL, Netbeans.

8 8 LISTA DE ILUSTRAÇÕES FIGURA 01 CSU01 Diagrama de Use case Manter...23 FIGURA 02 CSU02 Diagrama de Use case Emitir...24 FIGURA 03 CSU03 Diagrama de Use case Manter Usuário...25 FIGURA 04 CSU04 Diagrama de Use case Manter Cliente...26 FIGURA 05 CSU05 Diagrama de Use case Manter Tipo do Produto...27 FIGURA 06 CSU06 Diagrama de Use case Manter Produto...28 FIGURA 07 CSU07 Diagrama de Use case Manter Fornecedor...29 FIGURA 08 CSU08 Diagrama de Use case Manter Cidade...30 FIGURA 09 CSU09 Diagrama de Use case Manter Tipo do Pagamento...31 FIGURA 10 CSU10 Diagrama de Use case Manter Pagamento...32 FIGURA 11 CSU11 Diagrama de Use case Manter Contas a Receber...33 FIGURA 12 CSU12 Diagrama de Use case Manter Contas a Pagar...34 FIGURA 13 CSU13 Diagrama de Use case Manter Venda...35 FIGURA 14 CSU14 Diagrama de Use case Manter Compra...36 FIGURA 15 CSU15 Diagrama de Use case Emitir Relatório das Compras...37 FIGURA 16 CSU16 Diagrama de Use case Emitir Relatório das Vendas...38 FIGURA 17 CSU17 Diagrama de Use case Emitir Relatório dos Produtos do Estoque...39 FIGURA 18 CSU18 Diagrama de Use case Emitir Relatórios das Contas a Pagar...40 FIGURA 19 CSU19 Diagrama de Use case Emitir Relatórios das Contas a Receber...41 FIGURA 20 CSU20 Diagrama de Use case Emitir Relatório dos Aniversariantes...42 FIGURA 21 CSU21 Diagrama de Use case Emitir Relatórios dos Clientes...43

9 9 FIGURA 22 CSU22 Diagrama de Use case Emitir Relatório dos Fornecedores...44 FIGURA 23 Diagrama de Classe...45 FIGURA 24 Diagrama de Sequência Manter Cliente...46 FIGURA 25 Diagrama de Sequência Manter Produto...47 FIGURA 26 Diagrama de Sequência Manter Fornecedor...47 FIGURA 27 Diagrama de Sequência Manter Cidade...48 FIGURA 28 Diagrama de Sequência Manter Pagamento...48 FIGURA 39 Diagrama de Sequência Manter Contas a Pagar...49 FIGURA 30 Diagrama de Sequência Manter Contas a Receber...49 FIGURA 31 Diagrama de Sequência Manter Venda...50 FIGURA 32 Diagrama de Sequência Manter Compra...50 FIGURA 33 Diagrama de Sequência Emitir Relatório das Compras...51 FIGURA 34 Diagrama de Sequência Emitir Relatório das Vendas...51 FIGURA 35 - Diagrama de Sequência Emitir Relatório dos Aniversariantes...52 FIGURA 36 Diagrama de Sequência Emitir Relatório dos Produtos do Estoque...52 FIGURA 37 Diagrama de Sequência Emitir Relatório das Contas a Pagar...53 FIGURA 38 Diagrama de Sequência Emitir Relatório das Contas a Receber...53 FIGURA 39 WBS...54 FIGURA 40 Interface do Sistema Manter Cidade...58 FIGURA 41 Interface do Sistema Manter Compra...58 FIGURA 42 Interface do Sistema Manter Cliente...59 FIGURA 43 - Interface do Sistema Manter Produto...59

10 10 LISTA DE TABELAS Tabela 01 Manter Usuário...25 Tabela 02 Manter Cliente...26 Tabela 03 Manter Tipo do Produto...27 Tabela 04 Manter Produto...28 Tabela 05 Manter Fornecedor...29 Tabela 06 Manter Cidade...30 Tabela 07 Manter Tipo do Pagamento...31 Tabela 08 Manter Pagamento...32 Tabela 09 Manter Contas a Receber...33 Tabela 10 Manter Contas a Pagar...34 Tabela 11 Manter Venda...35 Tabela 12 Manter Compra...36 Tabela 13 Emitir Relatório das Compras...37 Tabela 14 Emitir Relatório das Vendas...38 Tabela 15 Emitir Relatórios dos Produtos do Estoque...39 Tabela 16 Emitir Relatórios das Contas a Pagar...40 Tabela 17 Emitir Relatórios das Contas a Receber...41 Tabela 18 Emitir Relatórios dos Aniversariantes...42 Tabela 19 Emitir Relatórios dos Clientes...43 Tabela 20 Emitir Relatórios dos Fornecedores...44

11 11 SUMÁRIO 1. INTRODUÇÃO OBJETIVO PÚBLICO ALVO JUSTIFICATIVA METODOLOGIA E FERRAMENTAS UTILIZADAS TECNOLOGIAS UTILIZADAS Java PostgreSQL Uml Caso de Uso (UC) Diagrama de Classes Orientação a objeto ireport Netbeans Jude Hibernate ESPECIFICAÇÃO DO SISTEMA ANÁLISE DE REQUISITOS LISTA DE EVENTOS CASO DE USO GERAL CASO DE USO ESPECÍFICO DIAGRAMA DE CLASSE DIAGRAMA DE SEQUÊNCIA WORK BREAKDOWN STRUCTURE (WBS) ORÇAMENTO CRONOGRAMA INTERFACE DO SISTEMA CONCLUSÃO REFERÊNCIAS BIBIOGRÁFICAS REFERÊNCIAS ELETRÔNICAS... 62

12 12 1. INTRODUÇÃO A concorrência entre as lojas faz com que essas busquem diferenciais para atrair novos clientes e manter os já existentes, como por exemplo: um atendimento rápido, prático e a facilidade na compra de produtos. Pensando nisso e observando o dia a dia da loja foi constatado que a mesma opera sem qualquer tipo de automação. Foi sugerido o desenvolvimento de um software que permita cadastrar os clientes, os fornecedores, os produtos e armazenar também as vendas realizadas, tornando assim o atendimento ao cliente mais rápido e preciso. A Loja BIG s está localizada na cidade de Quatá SP, é uma loja de médio porte que trabalha atualmente com vendas de roupas, bicicletas e acessórios para as mesmas, possui dois funcionários, sendo um deles proprietário, o sr. José Batista da Silva, responsável pela administração e atendimento aos clientes, e devido à esse acúmulo de funções fica difícil manter um bom controle do estoque e das contas, inclusive esse último é um grande problema, pois o balanço dos gastos e lucros é feito mensalmente ou anualmente dependendo da necessidade do proprietário, que faz todo o controle sem qualquer ajuda de terceiros.

13 OBJETIVO Construir um software que facilite ao usuário realizar suas tarefas rotineiras, como consultar preços de produtos, efetuar vendas e recebimento de contas parceladas, possibilitando maior agilidade no atendimento, além da geração de relatórios gerenciais para melhor acompanhamento do setor financeiro, condições do estoque e contas a pagar e receber PÚBLICO ALVO O software destina-se a estabelecimentos comerciais de pequeno e médio porte, que necessitem automatizar o cadastro de clientes, fornecedores, produtos, vendas e ter acesso a relatórios gerenciais sem necessidade de contagem manual de estoque e contas a receber, por exemplo.

14 JUSTIFICATIVA O sistema visa uma melhor organização das informações para que o proprietário e/ou gerente do estabelecimento obtenha acesso a elas de forma mais completa, facilitando a busca pelos produtos da loja e tendo um melhor controle sobre as vendas. Essa idéia de criar um software de controle de estoque e serviço surgiu quando visitado o estabelecimento referido anteriormente e notadas às dificuldades citadas.

15 15 2. METODOLOGIA E FERRAMENTAS UTILIZADAS Este capítulo contém as tecnologias utilizadas no desenvolvimento do sistema da Loja Big s. 2.1 TECNOLOGIAS UTILIZADAS Para a elaboração desse trabalho foram utilizados conhecimentos adquiridos durante o curso e complementados por pesquisas na internet e livros específicos voltados ao desenvolvimento de aplicações na linguagem Java. O sistema será desenvolvido utilizando a ferramenta Netbeans e para persistência com o banco de dados PostgreSQL, foi utilizado o framework Hibernate Java A tecnologia Java foi criada como uma ferramenta de programação de um projeto da Sun Microsystems, chamado The Green Project, iniciado por Patrick Naughton, Mike Sheridan e James Gosling, em Esse projeto tinha como principal objetivo criar uma nova plataforma para a computação interativa, ou seja, a linguagem de programação não era o principal objetivo do projeto. No verão de 1992 foi gerada a primeira demonstração do projeto, que representou um sistema executando em um handheld com capacidade de controle remoto que ainda oferecia uma interface sensível ao toque (touchscreen) interativa. Esse handheld foi chamado de *7 (star seven), por esta ser a forma de atender (ou puxar) chamadas telefônicas entre os telefones dos integrantes da equipe.

16 16 O *7 foi capaz de controlar uma grande variedade de dispositivos de uso doméstico, enquanto apresentava uma interface com animação. O sistema criado para o handheld foi executado em um novo processador independente de linguagem de programação. A linguagem utilizada nesse sistema foi chamada de Oak ( carvalho, em Inglês), com base na paisagem que James Gosling tinha de sua janela. Em 23 de maio de 1995, John Gage, diretor da Sun Microsystems, e Marc Andreessen, um executivo da Netscape, anunciaram o lançamento da plataforma Java, composta pela Java Virtual Machine (JVM) e pela API (Application Programming Interface) Java. Tal plataforma foi, então, inserida na Netscape Navigator, o principal browser de acesso à internet usado na Época. (Mendes,Douglas Rocha 2009) PostgreSQL O PostgreSQL é um sistema de gerenciamento de banco de dados objeto relacional(sgbdor), ele foi o pioneiro em muitos conceitos objetos-relacionais que agora estão se tornando disponíveis em alguns bancos de dados comerciais. Desenvolvido no Departamento de Ciência da Computação da Universidade da Califórnia em Berkeley. O projeto POSTGRES, liderado pelo Professor Michael Stonebraker, foi patrocinado pelas seguintes instituições: Defense Advanced Research Projects Agency(DARPA); Army Research Office(ARO), National Science Foundation(NSF); e ESL. Inc. O PostgreSQL descende deste código original de Berkeley, possuindo o código fonte aberto. (Gonzaga, Jorge Luiz 2007).

17 UML A UML (Unified Modeling Language) é uma linguagem padrão para a elaboração da estrutura de projetos de software. Ela poderá ser empregada para a visualização, a especificação, a construção e a documentação de artefatos que façam uso de sistemas complexos de software. Diagramas na UML Um diagrama é a apresentação gráfica de um conjunto de elementos, geralmente representadas como gráficos de vértices (itens) e arcos (relacionamentos). São desenhados para permitir a visualização de um sistema sob diferentes perspectivas; nesse sentido, um diagrama constitui uma projeção de um determinado sistema. Em todos os sistemas, com exceção dos mais triviais, um diagrama representa uma visão parcial dos elementos que compõe o sistema. O mesmo elemento pode aparecer em todos os diagramas, em apenas alguns (o caso mais comum) ou em nenhum diagrama (um caso muito raro). Na teoria, um diagrama pode conter qualquer combinação de itens relacionamentos. Na prática, porém, aparecerá um pequeno número de combinações comuns, que são consistentes com as cinco visões mais úteis da arquitetura de um sistema complexo de software. Por isso a UML, inclui nove desses diagramas: Diagrama de classes Diagrama de objetos Diagrama de caso de uso Diagrama de sequências Diagrama de colaborações Diagrama de gráficos de estados Diagrama de atividades Diagrama de componentes Diagrama de implantação (Booch, Grady; Rumbaugh, James; Jacobson, Ivar; 2000)

18 Caso de Uso (UC) Os diagramas de caso de uso têm um papel central para a modelagem do comportamento de um sistema, de um subsistema ou de uma classe. Cada um mostra um conjunto de casos de uso e atores e seus relacionamentos, eles são importantes para visualizar, especificar e documentar o comportamento de um elemento. Esses diagramas fazem com que sistemas, subsistemas e classes fiquem acessíveis e compreensíveis, por apresentarem uma visão externa sobre como esses elementos podem ser utilizados no contexto. Os diagramas de caso de uso também são importantes para testar sistemas executáveis por meio de engenharia de produção e para compreendê-los por meio de engenharia reversa. (Booch, Grady; Rumbaugh, James; Jacobson, Ivar; 2000) Diagrama de Classes Um diagrama de classes é um diagrama que mostra um conjunto de classes, interfaces e colaborações e seus relacionamentos. Graficamente, um diagrama de classes é uma coleção de vértices e arcos. Ele é apenas um tipo especial de diagrama e compartilha as mesmas propriedades de todos os outros diagramas um nome e um conteúdo gráfico que são uma projeção em um modelo. O que diferencia os diagramas de classes dos outros tipos de diagrama é o seu conteúdo partícula. (Booch, Grady; Rumbaugh, James; Jacobson, Ivar; 2000).

19 Orientação a objeto A linguagem Java foi criada seguindo o paradigma da orientação a objetos e, por isso, traz de forma nativa a possibilidade de o programador usar os conceitos de herança, polimorfismo e encapsulamento. O paradigma da orientação a objetos existe desde a década de 70, mas somente após o sucesso da linguagem Java é que o paradigma ganhou credibilidade. O paradigma de orientação a objetos traz um enfoque diferente da programação estruturada, no sentido de adotar formas mais próximas do mundo real é visto como sendo constituído de objetos autônomos, concorrentes, que interagem entre si, e cada objeto tem seu próprio estado (atributos) e comportamento (métodos), semelhante a seu correspondente no mundo real. (Mendes,Douglas Rocha 2009) ireport O ireport é um programa Open Source, capaz de criar relatórios para aplicações Java no formato da biblioteca JasperReports. Com ele é capaz de criar qualquer tipo de relatório simples de forma rápida. (Gonçalves, Edson 2008).

20 Netbeans Segundo Gonçalves, Edson (2006, pg 23) Netbeans é um projeto open source, criado pela Sun Microsystems em junho de 2000 e é um ambiente de desenvolvimento que permite você escrever, compilar e debugar Jude JUDE/COMMUNITY é uma ferramenta de modelagem UML gratuita com funcionalidades básicas. Ele é rico em funcionalidades, oferecendo características como edição e impressão de diagramas UML2.0, importa/exporta código fonte Java, saída gráficos e disposição automática Hibernate Hibernate é um projeto audacioso que procura ter uma completa solução para o problema de gerenciamento de dados persistentes em Java. O Hibernate é um framework que se relaciona com o banco de dados, onde este relacionamento é conhecido como mapeamento objeto/relacional (ORM) para Java, deixando o desenvolvedor livre para se concentrar em problemas da lógica do negócio. Sua simplicidade em configuração dá ao desenvolvedor algumas regras para que sejam seguidas como padrões de desenvolvimento ao escrever sua lógica de negócios e suas classes persistentes. De resto o Hibernate se integra suavemente ao seu

21 21 sistema se comunicando com o banco de dados como se fosse diretamente feito por sua aplicação (Gonçalves, Edson 2008). 3. ESPECIFICAÇÃO DO SISTEMA Os requisitos foram levantados através de entrevista com o proprietário o Sr José Batista da Silva e sua funcionária Margaret Zonderico Moraes para suprir as necessidades da loja. Durante as entrevistas foram levantados alguns requisitos como: Cadastrar clientes, produtos, fornecedores e formas de pagamento,tipo do pagamento, tipo dos produtos: peças de bicicletas, roupas e bicicleta. Movimentação de compras e vendas. Controlar contas a pagar e receber.relatórios de vendas do dia à vista, cartão de crédito e a prazo, compras e vendas realizadas pela loja e aniversariantes do mês. 3.1 ANÁLISE DE REQUISITOS A partir do levantamento de requisitos foram levantadas as seguintes necessidades: Cadastrar clientes, produtos, fornecedores e formas de pagamento, tipo dos produtos: peças de bicicletas, roupas e bicicleta. Movimentação de compras e vendas. Controlar contas a pagar e receber. Relatórios de vendas do dia a vista, cartão de crédito e a prazo, compras e vendas realizadas pela loja e aniversariantes do mês.

22 LISTA DE EVENTOS Para o desenvolvimento do sistema foi verificado as seguintes necessidades: N Funcionalidades 01 Manter Usuário 02 Manter Cliente 03 Manter Tipo do Produto 04 Manter Produto 04 Manter Fornecedor 05 Manter Cidade 06 Manter Tipo Pagamento 07 Manter Pagamento 08 Manter Contas a Receber 09 Manter Contas a Pagar 10 Manter Venda 11 Manter Compra 12 Emitir Relatórios das Compras 13 Emitir Relatórios das Vendas 14 Emitir Relatórios dos Produtos do estoque 15 Emitir Relatório das Contas a Pagar 16 Emitir Relatório das Contas a Receber 17 Emitir Relatório dos Aniversariantes 18 Emitir Relatório dos Clientes 19 Emitir Relatório dos Fornecedores

23 CASO DE USO GERAL Figura 01 CSU01 Diagrama de Caso de Uso Manter

24 Figura 02 CSU02 Diagrama de Caso de Uso Emitir 24

25 CASO DE USO ESPECÍFICO Figura 03 CSU03 Diagrama de Use case Manter Usuário Nome da Use Case (CSU 03) Ator(es) Pré-Condições Cenário Principal Manter Usuário Administrador O administrado deve estar logado no sistema 1 O sistema solicita os dados necessários para o cadastro do usuário 2 O administrador informa os dados de acordo com os campos a serem preenchidos 3 O administrador clica em salvar. 4 O sistema emite a mensagem Usuário Cadastrado com Sucesso. 5 O sistema cadastra o usuário. Cenário Alternativo O Administrador poderá cancelar o processo durante o cadastro. Casos de Teste 3.1 O sistema não confirma o cadastro e emite uma mensagem de erro na tela. Tabela 01 - Manter Usuário

26 26 Figura 04 CSU04 Diagrama de Use case Manter Cliente Nome da Use Case (CSU 04) Ator(es) Pré-Condições Cenário Principal Manter Cliente Administrador O administrador deve estar logado no sistema 1 O sistema solicita os dados necessários para o cadastro do cliente 2 O administrador informa os dados de acordo com os campos a serem preenchidos 3 O administrador clica em salvar. 4 O sistema emite a mensagem Cliente Cadastrado com Sucesso. 5 O sistema cadastra o cliente. Cenário Alternativo O Administrador poderá cancelar o processo durante o cadastro. Casos de Teste 3.1 O sistema não confirma o cadastro e emite uma mensagem de erro na tela. Tabela 02 - Manter Cliente

27 27 Figura 05 CSU05 Diagrama de Use case Manter Tipo do Produto Nome da Use Case (CSU 05) Ator(es) Pré-Condições Cenário Principal Manter Tipo do Produto Administrador O administrador deve estar logado no sistema 1 O sistema solicita os dados necessários para o cadastro do tipo do produto 2 O administrador informa os dados de acordo com os campos a serem preenchidos 3 O administrador clica em salvar. 4 O sistema emite a mensagem Tipo do Produto Cadastrado com Sucesso. 5 O sistema cadastra o tipo do produto. Cenário Alternativo O Administrador poderá cancelar o processo durante o cadastro. Casos de Teste 3.1 O sistema não confirma o cadastro e emite uma mensagem de erro na tela. Tabela 03 - Manter Tipo do Produto

28 28 Figura 06 CSU06 Diagrama de Use case Manter Produto Nome da Use Case (CSU 06) Ator(es) Pré-Condições Cenário Principal Manter Produto Administrador O administrador deve estar logado no sistema 1 O sistema solicita os dados necessários para cadastrar o produto. 2 O administrador informa os dados de acordo com os campos a serem preenchidos. 3 O administrador clica em salvar. 4 O sistema emite a mensagem Produto Cadastrado com Sucesso. 5 O sistema cadastra o fornecedor. Cenário Alternativo O Administrador poderá cancelar o processo durante o cadastro. Casos de Teste 3.1 O sistema não confirma o cadastro e emite uma mensagem de erro na tela. Tabela 04 - Manter Produto

29 29 Figura 07 CSU07 Diagrama de Use case Fornecedor Nome da Use Case (CSU 07) Ator(es) Pré-Condições Cenário Principal Manter Fornecedor Administrador O administrador deve estar logado no sistema 1 O sistema solicita os dados necessários para cadastrar o fornecedor 2 O administrador informa os dados de acordo com os campos a serem preenchidos. 3 O administrador clica em salvar. 4 O sistema emite a mensagem Fornecedor Cadastrado com Sucesso. 5 O sistema cadastra o fornecedor. Cenário Alternativo O Administrador poderá cancelar o processo durante o cadastro. Casos de Teste 3.1 O sistema não confirma o cadastro e emite uma mensagem de erro na tela. Tabela 05 Manter Fornecedor

30 30 Figura 08 CSU08 Diagrama de Use case Manter Cidade Nome da Use Case (CSU 08) Ator(es) Pré-Condições Cenário Principal Manter Cidade Administrador O administrador deve estar logado no sistema. 1 O sistema solicita os dados necessários para cadastrar a cidade. 2 O administrador informa os dados de acordo com os campos a serem preenchidos. 3 O administrador clica em salvar. 4 O sistema emite a mensagem Cidade Cadastrada com Sucesso. 5 O sistema cadastra a Cidade. Cenário Alternativo O Administrador poderá cancelar o processo durante o cadastro. Casos de Teste 3.1 O sistema não confirma o cadastro e emite uma mensagem de erro na tela. Tabela 06 Manter Cidade

31 31 Figura 09 CSU09 Diagrama de Use case Cadastrar Manter Tipo de Pagamento Nome da Use Case (CSU 09) Ator(es) Pré-Condições Cenário Principal Manter Tipo de Pagamento Administrador O administrador deve estar logado no sistema 1 O sistema solicita os dados necessários para cadastrar o tipo de pagamento. 2 O administrador informa os dados de acordo com os campos a serem preenchidos. 3 O administrador clica em salvar. 4 O sistema emite a mensagem Tipo de Pagamento Cadastrado com Sucesso. 5 O sistema cadastra o tipo de pagamento. Cenário Alternativo O Administrador poderá cancelar o processo durante o cadastro. Casos de Teste 3.1 O sistema não confirma o cadastro e emite uma mensagem de erro na tela. Tabela 07 Manter Tipo de Pagamento

32 32 Figura 10 CSU10 Diagrama de Use case Manter Pagamento Nome da Use Case (CSU 10) Ator(es) Pré-Condições Manter Pagamento Administrador O administrador deve estar logado no sistema 1 O cliente deseja efetuar o pagamento. 2 O Administrador verifica o pagamento pendente. 3 O cliente realiza o pagamento. 4 O Administrador clica em Salvar. 5 O sistema emite a mensagem Pagamento Realizado com Sucesso. Cenário Principal Cenário Alternativo O sistema emite a mensagem Pagamento Cancelado. Tabela 08 Manter Pagamento

33 33 Figura 11 CSU11 Diagrama de Use case Manter Contas a Receber Nome da Use Case (CSU 11) Ator(es) Pré-Condições Cenário Principal Manter Contas a Receber Administrador O administrador deve estar logado no sistema 1 O sistema solicita dos dados necessários para movimentar contas a receber 2 O administrador informa os dados de acordo com os campos a serem preenchidos. 3 O administrador clica em Salvar. 4 O sistema emite a mensagem Operação realizada com sucesso. Cenário Alternativo O administrador poderá cancelar o processo durante a movimentação Casos de Teste 3.1 O sistema não confirma a movimentação e emite a mensagem de erro na tela. Tabela 09 Manter Contas a Receber

34 34 Figura 12 CSU12 Diagrama de Use case Manter Contas a Pagar Nome da Use Case (CSU 12) Ator(es) Pré-Condições Cenário Principal Manter Contas a Pagar Administrador O administrador deve estar logado no sistema. 1 O sistema solicita dos dados necessários para movimentar contas a receber 2 O administrador informa os dados de acordo com os campos a serem preenchidos. 3 O administrador clica em Salvar. 4 O sistema emite a mensagem Operação realizada com sucesso. Cenário Alternativo O administrador poderá cancelar o processo durante a movimentação Casos de Teste 3.1 O sistema não confirma a movimentação e emite a mensagem de erro na tela. Tabela 10 Manter Contas a Pagar

35 35 Figura 13 CSU13 Diagrama de Use case Manter Venda Nome da Use Case (CSU 13) Ator(es) Pré-Condições Cenário Principal Manter Venda Administrador O administrador deve estar logado no sistema. 1 O sistema solicita dos dados necessários para cadastrar a venda. 2 O administrador informa os dados de acordo com os campos a serem preenchidos. 3 O administrador clica em Salvar. 4 O sistema emite a mensagem Operação realizada com sucesso. Cenário Alternativo O administrador poderá cancelar a compra Casos de Teste 3.1 O sistema não confirma a movimentação e emite a mensagem de erro na tela. Tabela 11 Manter Venda

36 36 Figura 14 CSU14 Diagrama de Use case Manter Compra Nome da Use Case (CSU 14) Ator(es) Pré-Condições Cenário Principal Manter Compra Administrador O administrador deve estar logado no sistema. 1 O sistema solicita dos dados necessários para cadastrar a compra. 2 O administrador informa os dados de acordo com os campos a serem preenchidos. 3 O administrador clica em Salvar. 4 O sistema emite a mensagem Operação realizada com sucesso. Cenário Alternativo O administrador poderá cancelar a compra Casos de Teste 3.1 O sistema não confirma a movimentação e emite a mensagem de erro na tela. Tabela 12 Manter Compra

37 37 Figura 15 CSU15 Diagrama de Use case Emitir Relatórios das Compras Nome da Use Case (CSU 15) Emitir Relatórios das Compras Ator(es) Pré-Condições Administrador O administrador deve estar logado no sistema. Descrição Os relatórios deverão ser impressos conforme forem necessitados Cenário Principal 1 O administrador informa os dados necessários para gerar o relatório. 2 O administrador clica em visualizar relatório. 3 O administrador clica em imprimir. 4 O sistema imprime o relatório com sucesso. Cenário Alternativo O administrador poderá visualizar o relatório e não imprimir. Casos de Teste 4.1 O administrador cancela a operação. Tabela 13 Emitir Relatórios das Compras

38 38 Figura 16 CSU16 Diagrama de Use case Emitir Relatórios das Vendas Nome da Use Case (CSU 16) Ator(es) Pré-Condições Descrição Cenário Principal Emitir Relatórios das Vendas Administrador O administrador deve estar logado no sistema. Os relatórios deverão ser impressos conforme forem necessitados 1 O administrador informa os dados necessários para gerar o relatório. 2 O administrador clica em visualizar relatório. 3 O administrador clica em imprimir. 4 O sistema imprime o relatório com sucesso. Cenário Alternativo O administrador poderá visualizar o relatório e não imprimir. Casos de Teste 4.1 O administrador cancela a operação. Tabela 14 Emitir Relatórios de Vendas

39 39 Figura 17 CSU17 Diagrama de Use case Emitir Relatórios dos Produtos do Estoque Nome da Use Case (CSU 17) Emitir Relatórios dos de Produtos do Estoque Ator(es) Administrador Pré-Condições O administrador deve estar logado no sistema. Descrição Os relatórios deverão ser impressos conforme forem necessitados 1 O administrador informa os dados necessários para gerar o relatório dos produtos do estoque. 2 O administrador clica em visualizar relatório. 3 O administrador clica em imprimir. Cenário Principal 4 O sistema imprime o relatório com sucesso. Cenário Alternativo O administrador poderá visualizar o relatório e não imprimir. Casos de Teste 4.1 O sistema cancela a operação. Tabela 15 - Emitir Relatórios dos Produtos do Estoque

40 40 Figura 18 CSU18 Diagrama de Use case Emitir Relatório das contas a pagar Nome da Use Case (CSU 18) Ator(es) Descrição Cenário Principal Emitir Relatório das Contas a Pagar. O administrador deve estar logado no sistema. Os relatórios deverão ser impressos conforme forem necessitados 1 O administrador informa os dados necessários para gerar o relatório do relatório das contas a pagar 2 O administrador clica em visualizar relatório. 3 O administrador clica em imprimir. 4 O sistema imprime o relatório com sucesso. Cenário Alternativo O administrador poderá visualizar o relatório e não imprimir. Casos de Teste 4.1 O sistema cancela a operação. Tabela 16 - Emitir Relatório de Contas a Pagar

41 41 Figura 19 CSU19 Diagrama de Use case Emitir Relatório das Contas a Receber Nome da Use Case (CSU 19) Ator(es) Descrição Cenário Principal Emitir Relatório das Contas a Receber O administrador deve estar logado no sistema. Os relatórios deverão ser impressos conforme forem necessitados 1 O administrador informa os dados necessários para gerar o relatório do relatório de contas a receber. 2 O administrador clica em visualizar relatório. 3 O administrador clica em imprimir. 4 O sistema imprime o relatório com sucesso. Cenário Alternativo O administrador poderá visualizar o relatório e não imprimir. Casos de Teste 4.1 O sistema cancela a operação. Tabela 17 - Emitir Relatório de Contas a Receber

42 42 Figura 20 CSU20 Diagrama de Use case Emitir Relatório dos Aniversariantes Nome da Use Case (CSU 20) Ator(es) Descrição Cenário Principal Emitir Relatório dos Aniversariantes O administrador deve estar logado no sistema. Os relatórios deverão ser impressos conforme forem necessitados 1 O administrador informa os dados necessários para gerar o relatório do relatório dos aniversariantes. 2 O administrador clica em visualizar relatório. 3 O administrador clica em imprimir. 4 O sistema imprime o relatório com sucesso. Cenário Alternativo O administrador poderá visualizar o relatório e não imprimir. Casos de Teste 4.1 O sistema cancela a operação. Tabela 18 - Emitir Relatório dos Aniversariantes

43 43 Figura 21 CSU21 Diagrama de Use case Emitir Relatório dos Clientes Nome da Use Case (CSU 21) Ator(es) Descrição Cenário Principal Emitir Relatório dos Clientes O administrador deve estar logado no sistema. Os relatórios deverão ser impressos conforme forem necessitados 1 O administrador informa os dados necessários para gerar o relatório dos Clientes. 2 O administrador clica em visualizar relatório. 3 O administrador clica em imprimir. 4 O sistema imprime o relatório com sucesso. Cenário Alternativo O administrador poderá visualizar o relatório e não imprimir. Casos de Teste 4.1 O sistema cancela a operação. Tabela 19 - Emitir Relatório dos Clientes

44 44 Figura 22 CSU22 Diagrama de Use case Emitir Relatório dos Fornecedores Nome da Use Case (CSU 21) Ator(es) Descrição Cenário Principal Emitir Relatório dos Clientes O administrador deve estar logado no sistema. Os relatórios deverão ser impressos conforme forem necessitados 1 O administrador informa os dados necessários para gerar o relatório dos Fornecedores. 2 O administrador clica em visualizar relatório. 3 O administrador clica em imprimir. 4 O sistema imprime o relatório com sucesso. Cenário Alternativo O administrador poderá visualizar o relatório e não imprimir. Casos de Teste 4.1 O sistema cancela a operação. Tabela 20 - Emitir Relatório dos Fornecedores

45 DIAGRAMA DE CLASSE Figura 23 Diagrama de Classe

46 Diagrama de sequência Figura 24 - Diagrama de Sequência Manter Cidade

47 47 Figura 25 Diagrama de Sequência Manter Produto Figura 26 - Diagrama de Sequência Manter Fornecedor

48 48 Figura 27 Diagrama de Sequência Manter Cidade Figura 28 Diagrama de Sequência Manter Pagamento

49 49 Figura 29 - Diagrama de Sequência Manter Contas a Pagar Figura 30 - Diagrama de Sequência Manter Contas a Receber

50 50 Figura 31 - Diagrama de Sequência Manter Venda Figura 32 - Diagrama de Sequência Manter Compra

51 51 Figura 33 - Diagrama de Sequência Emitir Relatório das Compras Figura 34 - Diagrama de Sequência Emitir Relatório das Vendas

52 52 Figura 35 - Diagrama de Sequência Emitir Relatório dos Aniversariantes Figura 36 - Diagrama de Sequência Emitir Relatório dos Produtos do Estoque

53 53 Figura 37 - Diagrama de Sequência Emitir Relatório de contas a Pagar Figura 38 - Diagrama de Sequência Emitir Relatório de contas a Receber

54 54 4. WORK BREAKDOWN STRUCTURE (WBS) Figura 39 - WBS

55 55 5. ORÇAMENTO Serão necessários para o desenvolvimento do projeto, os recursos descritos a seguir: 01 Analista de Sistemas 01 Programador 01 Notebook 01 Impressora Orçamento do Projeto: Estimativa de custos para as atividades e custos para recursos. Pessoal Analista Qtde de Horas Somar as horas relativas ao trabalho do analista Custo/hora(R$) Total(R$) Mayquel 60 30, ,00 Custo Analista 1800,00 Programador Qtde de Horas Somar as horas relativas ao trabalho do analista Custo/hora(R$) Total(R$) Mayquel 90 22, ,00 Total do Custo Pessoal 3780,00

56 56 Equipamentos 01 Notebook Valor unitário = R$ 2450,00 Dias de uso = 30 dias (considerar 120h/4 de trabalho/dia = 30) Depreciação = R$ 2450,00 / 12 meses (01 ano tempo de depreciação = R$ 204,17 ao mês) Custo dia = 204,17/30(dias) = R$ 6.81 ao dia Custo de cada computador = R$ 6,81 * 120 (total de horas do projeto) = R$ 817,20 01 Impressora Valor = R$ 150,00 Dias de uso = 30 Depreciação = R$150,00/12 = R$ 12,50 Custo dia = R$ 12,50 / 26 = R$ 0,42 Custo de impressora = R$ 0,42 * 120h = 50,40 Custo Total do Equipamento = 817, ,40 = 867,60

57 57 6. CRONOGRAMA Tarefas Fev Mar Abr Maio Jun jul Ago Set Out Nov Levantamento de Requisitos Análise de Requisitos Elaboração do Diagrama dos casos de uso Diagramas de classe e sequencia Implementação Testes Implantação Treinamento

58 58 7. INTERFACE DO SISTEMA Figura 40 - Interface do Sistema Manter Cidade Figura 41 - Interface do Sistema Manter Compra

59 59 Figura 42 - Interface do Sistema Manter Cliente Figura 43 - Interface do Sistema Manter Produto

60 60 8. CONCLUSÃO Com o sistema desenvolvido, o proprietário terá controle total das informações da loja como: contas a pagar, contas a receber clientes, fornecedores e produtos. O sistema da loja BIG s busca melhorar o atendimento aos clientes além de facilitar as consultas e as movimentações financeiras. A etapa de análise facilitou o entendimento do sistema, embora tenha sido percebida uma falta de experiência do orientando e do proprietário da loja, mas que foi bem suprida pelo orientador. O diagrama de classes foi muito importante para o desenvolvimento da implementação. No desenvolvimento do software foram encontradas muitas dificuldades, pela falta de conhecimento na linguagem Java, tais dificuldades foram supridas com pesquisas na internet, livros, conversa com professores e colegas.

61 61 9. REFERÊNCIAS BIBIOGRÁFICAS Booch, Grady; Rumbaugh, James; Jacobson, Ivar; UML Guia do Usuário. 2. ed. Tradução de Fábio Freitas da Silva e Cristina de Amorim Machado. Rio de Janeiro: Editora Elsevier, Gonçalves, Edson; Dominando Netbeans, Rio de Janeiro: Editora Ciência Moderna Ltda, 2006 Gonçalves Edson; Desenvolvendo Aplicações Web com Netbeans IDE 6, Rio de Janeiro:Editora Ciência Moderna Ltda,2008. Gonzaga, Jorge Luiz; Dominando o PostgreSQL, Rio de Janeiro:Editora Ciência Moderna Ltda, Mendes, Douglas Rocha; Programação Java com Ênfase em Orientação a Objetos 1. ed. São Paulo: Editora Novatec, 2009.

62 REFERENCIAS ELETRÔNICAS Jude Design & Comunication; IDE Jude; Acesso em: 26 de outubro