FACULDADE DE TECNOLOGIA DE PRESIDENTE PRUDENTE

ANDRÉ LUIZ JAMARINO ABEKAWA

MANUAL DO SISTEMA

APÊNDICE A

PRESIDENTE PRUDENTE 2011

2

SUMÁRIO 1.! INTRODUÇÃO .......................................................................................... 3!

1.1 Objetivo .................................................................................................. 3!1.2 Escopo ................................................................................................... 3!1.3! Definições, siglas e abreviações ......................................................... 4!1.4! Referências ......................................................................................... 4!1.5! Visão geral ........................................................................................... 4!

2.! DESCRIÇÃO GLOBAL .............................................................................. 5!2.1 Considerações iniciais ........................................................................... 5!2.2 Perspectivas do produto ........................................................................ 5!2.3! Funções do Produto ............................................................................ 5!

2.3.1 Funções Básicas ............................................................................. 6!2.3.2 Funções Fundamentais ................................................................... 8!

2.4! Características do Usuário .................................................................. 9!2.5! Limites, dependências e suposições ................................................. 10!2.6! Requisitos adiados ............................................................................ 10!

3.! REQUISITOS ESPECÍFICOS ................................................................. 11!3.1 Diagrama de Casos de Uso ................................................................. 11!

3.1.1 Especificação de Casos de Uso .................................................... 12!3.1.2 DIAGRAMA DE ATIVIDADES ....................................................... 23!

3.2 MODELO CONCEITUAL ...................................................................... 24!3.3! INTERFACES EXTERNAS ............................................................... 25!

3.3.1 Método de desenvolvimento .......................................................... 25!3.3.2 Ambiente de Desenvolvimento ...................................................... 25!3.3.3 Interfaces com outros ambientes .................................................. 25!3.3.4 Padronização de Interfaces Visuais .............................................. 25!3.3.5 Ambiente em Rede ........................................................................ 25!

4.! Projeto de Software ................................................................................. 26!4.1 Arquitetura lógica do software .............................................................. 26!

4.1.1 Sumário de Classes ...................................................................... 27!4.2 Diagrama de Interação ......................................................................... 29!

4.2.1 Diagrama de Interação (Venda) .................................................... 29!4.2.2 Diagrama de Interação (Compra) .................................................. 30!4.2.3 Diagrama de Interação (Finalizar Caixa) ....................................... 30!4.2.4 Diagrama de Interação (Recebimento de Contas) ........................ 31!

4.3 Diagrama de Classes ........................................................................... 32!4.3.1 Diagrama de Classe (business Cliente) ........................................ 32!4.3.2 Diagrama de Classes (business Fornecedor) ............................... 33!4.3.3 Diagrama de Classes (business Produto) ..................................... 34!4.3.4 Diagrama de Classe (business Usuário) ....................................... 35!4.3.5 Diagrama de Classes (Fachada de Venda) .................................. 36!4.3.6 Diagrama de Classes (Fachada de Compra) ................................ 37!

4.4! Mapeamento OO-Relacional ............................................................. 38!4.5! Layout de Telas ................................................................................. 41!

3

1. INTRODUÇÃO

1.1 OBJETIVO Este documento tem o objetivo de apresentar os requisitos de sistema do produto SMART que tem como função auxiliar a gestão de pequenas e micro empresas do segmento comércio e serviços automatizando os processos básicos dos departamentos vendas, compras e estoque. É direcionado aos analistas, projetistas e desenvolvedores fornecendo subsídios durante a implementação e futuras manutenções.

1.2 ESCOPO O produto nomeado SMART é um ERP compacto focado em atender necessidades básicas para as pequenas e micro empresas do ramo comercial, e deve auxiliar durante as seguintes tarefas:

• Cadastro e manutenção de usuários; • Cadastro e manutenção de clientes; • Cadastro e manutenção de produtos; • Cadastro e manutenção de fornecedores; • Cadastro e manutenção de orçamentos; • Cadastro e manutenção de cotações; • Gerência de vendas; • Gerência de compras; • Gerência de finanças; • Gerência de clientes (CRM); • Interface Web (SITE); • Manutenção do Site (CMS).

O sistema não contemplará as seguintes tarefas:

• Gerência Fiscal; • Gerência Financeira.

O sistema tem como objetivos:

• Minimizar erros de entrada e controle no estoque; • Auxiliar processo de compra de produtos; • Auxiliar atendimento e fornecimento ao cliente; • Aproximar clientes e conquistar novos.

4

1.3 DEFINIÇÕES, SIGLAS E ABREVIAÇÕES

• CRM – Costumer Relationship Management (Gestão de Relacionamento com Cliente)

• ERP – Enterprise Resource Planning (Sistema Integrado de Gestao Empresarial)

• SMART – Acrônimo das Palavras: Specific, Messurable, Achievable, Realistic, Time-Based. Conceito introduzido por Peter Drucker para auxilio no desenvolvimento de metas onde diz que toda meta deve ser SMART.

• IDE – Integrated Development Environment (Ambiente Integrado de Desenvolvimento)

• MDI – Multiple Document Interface (Interface de Multiplos Documentos)

• CMS – Content Management System (Sistema de Controle de Conteúdo)

• IEEE – Institute of Eletrical and Eletronics Engineers (Instituto dos Enegnheiros Elétricos e Eletrônicos)

• JVM – Java Virtual Machine (Máquina Virtual Java) • DML – Data Manipulation Language (Linguagem de Manipulação de

Dados)

1.4 REFERÊNCIAS

• IEEE Std 830-1998 - IEEE Recommended Practice for Software Requirements Specifications

1.5 VISÃO GERAL Este documento está dividido em capítulos, conforme a norma IEEE Std 830-1998, apresentando:

• Capítulo 2 – As descrições globais do sistema, sendo elas, considerações iniciais, perspectivas do produto, funções do produto, características do usuário, limites, suposições e dependências, requisitos adiados.

• Capítulo 3 – Detalhamento dos requisitos específicos do sistema sendo eles: os diagramas de casos de uso, diagramas de atividade, modelo conceitual e interfaces externas.

• Capítulo 4 – Apresenta os diagramas de interação, diagramas de classes, mapeamento objeto relacional e layout de telas.

5

2. DESCRIÇÃO GLOBAL

2.1 CONSIDERAÇÕES INICIAIS

Devido não haver um cliente específico para o sistema desenvolvido, mas sim o alvo, que são as micro e pequenas empresas, não foram apresentadas soluções alternativas para o estudo de viabilidade.

2.2 PERSPECTIVAS DO PRODUTO O SMART deverá possuir uma aplicação desktop capaz de ser executada em Sistemas Operacionais distintos tais como: MS Windows XP/Vista/7; GNU/Linux e MAC OS X. Desde que possuam suporte a aplicações JAVA, ou seja, possuir uma JVM instalada. Esta aplicação desktop deverá possuir meios para a administração/gestão da organização. O SMART irá possuir também um website padrão capaz de fornecer informações para os clientes via Web. Esta aplicação será desenvolvida em linguagem de programação JAVA utilizando como Interface de Desenvolvimento a IDE NetBeans 6.9.x sendo executada sobre o Sistema Operacional MAC OS X 10.7 Lion. Para persistência de dados será utilizado o Sistema de Gerenciamento de Banco de Dados MySQL Server. Para Interface do Usuário foi adotado o comportamento e concepção de “Look and Fell” para que o usuário tenha a sensação de estar operando dentro do Sistema Operacional. Esta concepção inclui formas e cores, bem como a disposição dos elementos (o “Look”), bem como o comportamento dinâmico dos elementos tais como botões, caixas e menus (o “Feel”). Para isso o SMART será padronizado utilizando o Windows Aero, conceito conhecido como flavours (sabores). Todos os usuários poderão realizar as operações diretamente em um computador comum. O SMART irá possuir interface com hardwares para impressão e leitura sendo estes: impressoras e leitores de código de barra. Para comunicação de dados será utilizado redes TCP/IPv4 com suporte a redes locais (LAN) e redes de longo alcance (WAN).

2.3 FUNÇÕES DO PRODUTO Este tópico descreve as funções básicas e fundamentais que integram o SMART.

6

2.3.1 Funções Básicas FB1 – Cadastro e manutenção de usuário: Permite a inclusão, exclusão e alteração de usuários do sistema e os campos de preenchimento serão:

• Código: automático (Gerado pelo SMART) • Nome Completo • RG • CPF • Data Nascimento • Endereço: {Rua, Numero, CEP, Cidade, Estado} • Telefone: {Residencial , Celular, FAX} • Nível de acesso: {Compras, Vendas, Clientes, Produtos, Estoque,

Ferramentas, Fornecedores} permite associar mais de um nível. • Nome de usuário: alpha numérico 4 à 10 caracteres • Senha: obrigatoriamente de 6 a 8 caracteres

FB2 – Cadastro e manutenção de clientes: Permite a inclusão, exclusão e alteração de clientes e os campos de preenchimento são:

• Tipo: {Pessoa Física, Pessoa Jurídica} Seleção Pessoa Física: • Código: Automático • Nome Completo • RG • CPF • Data Nascimento • Endereço: {Rua, Numero, CEP, Cidade, Estado} • Telefone: {Residencial, Celular, FAX} • Email • MSN • SKYPE • Site • Limite de crediário*

*Limite de crediário se aplicável (Habilitar crediário) Pessoa Jurídica:

• Código: Automático • Nome fantasia • Razão social • CNPJ • IE – Inscrição estadual • Tempo de atividade • Endereço: {Rua, Numero, CEP, Cidade, Estado} • Telefone: {Residencial, Celular, FAX} • Email • MSN • SKYPE • Site • Limite de crediário

7

FB3 – Cadastro de categorias: Permite a inclusão, exclusão e alteração de categorias de produtos e serviços. Os campos de preenchimento são:

• Categoria principal • Subcategoria

FB4 – Cadastro de produtos: Permite a inclusão, exclusão e alteração de produtos. Os campos de preenchimento são:

• Código: Automático, formado pelas categorias • Código de Barras: Capturado pela embalagem do fabricante quando

possível, em caso de não preenchimento será utilizado o código incremental.

• Categoria: Seleção • Subcategoria: Seleção • Descrição: Breve descrição do produto • Unidade de medida • Peso em Quilogramas • Dimensões {Altura, Largura, Comprimento} em Centímetros • Preço de custo variável unitário • Preço de Venda • MCu%: Margem de contribuição percentual (Calculado pelo sistema) • Markup: Markup multiplicador calculado pelo sistema • Lucro desejado%: Fator percentual de lucro desejado • Comissão%: Fator percentual de comissão ao vendedor • IPI %: Imposto sobre produto industrializado • ICMS%: Imposto sobre circulação de mercadorias e serviços • Estoque: {Quantidade Atual, Máxima, Mínima} Permite inserir valores

de estoque mínimo e máximo do produto • Observações: Observações extras do produto/serviço

FB5 – Cadastro de fornecedores: Permite a inclusão, exclusão e alteração de fornecedores, os campos de preenchimento são:

• Nome fantasia • Razão social • CNPJ • IE – Inscrição Estadual • Ramo de atividade • Tempo de atividade • Endereço: {Rua, Numero, CEP, Cidade, Estado} • Telefone: {Residencial, Celular, FAX} • Email • MSN • SKYPE • Site •

8

2.3.2 Funções Fundamentais FF1 – Configurações do Sistema: Permite a configuração do sistema

• IP do servidor: Endereço identificando a máquina onde encontra-se o banco de dados

• Custo Fixo Total: Valor de Custo Fixo Total para cálculo de preço de produto

• Valor de abertura padrão do caixa FF2 – Acesso ao sistema: Realiza o acesso do usuário ao sistema

• Informando ao sistema nome de usuário e senha o usuário recebe as permissões pertinentes ao seu nível de acesso. No caso de vendedores ele inicia o caixa durante o primeiro acesso do dia.

FF3 – Efetuar venda: Permite efetuar vendas dinâmicas de

• Selecionar cliente: permite a seleção do cliente por código, nome, registro de pessoa (física/jurídica) ou caso não exista, cadastrar.

• Seleção de produtos: Seleciona produtos dinamicamente por código, descrição e relaciona similares para auxílio durante a negociação.

• Relaciona itens anteriormente solicitados ou pesquisados pelo cliente (Data Mining)

• Permite gerar orçamentos para futuras negociações • Permite gerar pedidos de vendas: Gera a partir do orçamento o pedido

de vendas. • Permite a conclusão da venda: seleção de forma de pagamento,

concessão de descontos e gera registro da venda e parcela(s) FF4 – Administrar caixa: Permite à cada vendedor finalizar o caixa e suas atividades.

• Exibe as vendas concretizadas e sua respectiva comissão • Permite a impressão de relatório simplificado de suas movimentações • Possui campo para registro do valor do caixa (Soma(Dinheiro,

Cheques, Comprovantes)) • Registra discordância entre valores obtidos e movimentados pelo

sistema, permitindo rastreio. FF5 – Relacionamento com cliente:

• Permite administrar reclamações identificadas de um cliente especifico: inserir, excluir e alterar o status.

• Permite administrar sugestões de clientes: inserir, excluir e alterar status.

• Permite administrar necessidades dos clientes: cadastro e manutenção de necessidades dos clientes tais como produtos pesquisados e solicitados

FF6 – Gerenciar produtos (Compras): Permite realizar cotações e orçamentos de produtos.

9

• Orçamento/Cotação: Por meio de produtos previamente cadastrados é possível obter suporte do sistema para processos de compra de produtos obtendo assim um gerenciamento de estoque adequado aos níveis de consumo médio mensal.

• Permite a impressão dos orçamentos e cotações. • Permite gerar pedidos de compra para fornecedores: A partir destes

pedidos são geradas contas a pagar de acordo com a forma de pagamento especificada.

• Entrada de produtos: Permite realizar a entrada dos produtos de acordo com a nota fiscal do fornecedor, realiza a baixa do pedido de compras (se informado), permite também a conferência entre produtos solicitados e entregue. O saldo dos produtos em estoque é automaticamente atualizado.

• Consulta de pedidos: É possível realizar a consulta dos pedidos e selecionados por filtro (Aberto/Entregue)

FF7 – Gerência de receita/despesas: Permite gerenciar as receitas e despesas geradas pelo sistema.

• Consulta de contas à pagar: Permite realizar consultas de contas à pagar por meio de filtros: período, data, fornecedor.

• Consulta de contas à receber: Permite realizar consultas de contas à receber geradas por vendas à prazo.

2.4 CARACTERÍSTICAS DO USUÁRIO

Esta seção detalha os níveis necessários de conhecimento para os futuros usuários do SMART para averiguar as necessidades de treinamento. Administrador: Desejável conhecimento em estruturas organizacionais e processos administrativos e também conhecimento avançado em informática, tais como:

• Instalação de aplicativos • Estruturas de redes • Bancos de dados • Sistemas operacionais

Gerente: Conhecimentos básicos em informática tais como operações com as interfaces de hardware (Mouse, Teclado, Impressora), Sistema Operacional (Windows). Desejável conhecimentos em estruturas organizacionais e processos administrativos. Vendedor: Conhecimentos básicos em informática tais como operações com as interfaces de hardware (Mouse, Teclado, Impressora), Sistema Operacional (Windows). Desejável compreensão de nomenclaturas da área de administração de empresas.

10

Comprador: Conhecimentos básicos em informática tais como operações com as interfaces de hardware (Mouse, Teclado, Impressora), Sistema Operacional (Windows). Desejável conhecimentos de nomenclaturas e processos de compras. Estoquista: Conhecimentos básicos em informática tais como operações com as interfaces de hardware (Mouse, Teclado, Impressora), Sistema Operacional (Windows). Desejável conhecimento em processos de estoque (entrada e saída de produtos).

2.5 LIMITES, DEPENDÊNCIAS E SUPOSIÇÕES O SMART conta com suporte a algumas tecnologias que serão detalhadas para averiguar os limites, dependências e suposições pertinentes ao seu uso.

• Backup: O backup do sistema é feito a partir do banco de dados sendo necessário conhecimento avançado em informática ficando por conta do cliente a contratação do suporte ou o treinamento de funcionário para realizar a operação.

• Leitor de código de barras: O SMART possui suporte a utilização de código de barras para operações de produtos e fica por conta do cliente a aquisição. É possível a utilização sem este recurso.

• O SMART não conta com impressão de notas fiscais. • Relatórios: Todos os relatórios e impressões de telas geradas por

funções do sistema geram arquivos com extensão PDF que pode ser lido pelo software Adobe Acrobat Reader e possui versão gratuita. A partir deste documento digital o cliente poderá imprimir em uma impressora comum.

2.6 REQUISITOS ADIADOS O SMART durante sua fase de desenvolvimento pode receber funções não previstas na fase de levantamento de requisitos, porém as especificadas serão contempladas. Mecanismos de controle de dados serão futuramente implementados.

11

3. REQUISITOS ESPECÍFICOS

3.1 DIAGRAMA DE CASOS DE USO

12

3.1.1 Especificação de Casos de Uso

Caso de Uso: Manter Cliente Data Versão Descrição Autor 20/05/2011 1.0 Criação do Artefato André Abekawa Breve Descrição: Este caso de uso permite ao vendedor inserir, alterar e excluir clientes no sistema. Ator Principal: Vendedor Interessados e Interesses: Vendedor: Realiza cadastro de dados informados pelo cliente para futuras operações. Cliente: Informa dados pessoais para futuras operações. Pré-condições: O Usuário deverá estar autenticado no sistema e possuir permissão de clientes. Garantia de Sucesso: Os dados serão armazenados na base de dados e uma mensagem será exibida confirmando a operação. Cenário de Sucesso Principal: 1 – Este caso de uso inicia quando o Vendedor consegue adquirir os dados necessários para um cadastro ou atualização do cliente. 2 – O Vendedor informa ao sistema os dados do cliente. 3 – O sistema realiza operações de verificação e validação dos dados. 4 – O sistema realiza a operação de manipulação dos dados (DML/Persistência). 5 – O sistema exibe uma mensagem informando o sucesso do Caso de Uso. Fluxos Alternativos: 2 – Os dados adquiridos pelo Vendedor são insuficientes para prosseguir (Retornar ao Passo 1). 3 – Os dados são rejeitados pelo sistema, e a natureza da rejeição é exibida ao Vendedor (Retornar ao Passo 1) 4 – Ocorre alguma exceção durante as operações de persistência dos dados e uma mensagem é exibida ao Vendedor que por sua vez deverá informar ao Administrador (Sistema Indisponível) 1 à 4 – O Vendedor poderá cancelar a operação.

13

Caso de Uso: Manter Produto Data Versão Descrição Autor 20/05/2011 1.0 Criação do Artefato André Abekawa Breve Descrição: Este caso de uso permite ao comprador inserir, alterar e excluir produtos no sistema. Ator Principal: Comprador Interessados e Interesses: Comprador: Realiza cadastro/manutenção de dados dos produtos Pré-condições: O usuário deverá estar autenticado no sistema e possuir permissão de compras. Garantia de sucesso: Os dados dos produtos são armazenados e o sistema exibe uma mensagem informando o sucesso da operação. Cenário de Sucesso Principal: 1 - Esse caso de uso inicia quando existe a necessidade de cadastro/manutenção de produtos. 2 – O comprador seleciona a operação a ser executada (Novo/Alterar/Excluir). 3 – O comprador informa ao sistema os dados do produto. 4 - Sistema realiza a verificação e validação dos dados informados. 5 - Sistema realiza a verificação e validação da operação. 6 - Sistema realiza a operação de manipulação dos dados (DML/Persistência). 7 - Sistema exibe uma mensagem informando o sucesso do cenário. Fluxos Alternativos: 4 – O sistema rejeita os dados informados e informa ao comprador a natureza da rejeição (Retornar ao passo 3). 5 – O sistema nega a operação selecionada e informa o motivo da negação (Retornar ao passo 2). 6 – Ocorre alguma exceção durante as operações de persistência de dados e uma mensagem é exibida ao comprador que por sua vez deverá informar ao Administrador (Sistema Indisponível). 2 à 6 – O Comprador poderá cancelar a operação.

14

Caso de Uso: Login no Sistema Data Versão Descrição Autor 20/05/2011 1.0 Criação do Artefato André Abekawa Breve Descrição: Este caso de uso permite um usuário devidamente cadastrado no sistema efetuar operações pertinentes ao seu nível de acesso. Ator Principal: Vendedor/Comprador/Gerente Interessados e Interesses: Vendedor: Obter acesso ao sistema e abrir o caixa. Comprador: Obter acesso ao sistema. Gerente: Obter acesso ao sistema. Pré-condições: Nenhum erro indicado na tela de login. Garantia de Sucesso: Os atores obterem o acesso devido ao sistema. Cenário de Sucesso Principal: 1 – Este caso de uso tem início quando existe a necessidade de utilização do sistema. 2 – O Ator digita na tela de login seu nome de usuário e sua senha. 3 – O sistema realiza operações de verificação e validação dos dados. 4 – O sistema realiza a operação de manipulação dos dados (DML/Persistência). 5 – O sistema exibe uma mensagem informando o sucesso do Caso de Uso. Fluxos Alternativos: 3 – Os dados informados pertencem a um usuário da classe vendedor (incluir caso de uso Abrir Caixa no caso de ser o primeiro acesso durante o expediente) 3 – Os dados são rejeitados pelo sistema, e a natureza da rejeição é exibida ao Ator (Retornar ao Passo 2) 4 – Ocorre alguma exceção durante as operações de persistência dos dados e uma mensagem é exibida ao Vendedor que por sua vez deverá informar ao Administrador (Sistema Indisponível) 1 à 4 – O Ator poderá cancelar a operação.

15

Caso de Uso: Efetuar Venda Data Versão Descrição Autor 20/05/2011 1.0 Criação do Artefato André Abekawa Breve Descrição: Este caso de uso permite ao vendedor realizar orçamento e venda de produtos. Ator Principal: Vendedor Interessados e Interesses: Vendedor: Realiza as operações para vender produtos. Cliente: Informa suas necessidades. Pré-condições: O usuário deverá estar autenticado no sistema e possuir permissão de vendas. Garantia de sucesso:

• A venda é registrada no caixa do dia; • No caso de vendas a prazo um registro de contas a receber é gerado; • Produtos vendidos são debitados do estoque; • Informações relevantes durante a negociação são registradas.

Cenário de Sucesso Principal: 1 – Esse caso de uso tem inicio quando existe uma negociação em andamento. 2 – O Sistema verifica Orçamento de Venda. 3 – Vendedor informa ao sistema forma de pagamento escolhida pelo cliente. 4 – Sistema realiza operações de verificação e validação da transação. 5 – Vendedor recebe pagamento. 6 – Sistema processa a transação. Fluxos Alternativos: 2 – Incluir caso de uso: Criar Orçamento de Venda; no caso de não encontrar no sistema. 3 – Sistema realiza verificação e validação dos produtos/serviços solicitados e encontra restrições quanto à quantidade disponível em estoque e informa opções:

a) Excluir produtos com quantidades insuficientes do orçamento (Retorna ao Passo 4).

b) Realizar pesquisa de produtos similares (Retorna ao Passo 3). c) Retornar ao orçamento em modo de edição (Retorna ao Passo 3).

4 – Cliente não concorda com valores do orçamento ou formas de pagamento e vendedor realiza:

a) Conceder descontos: Orçamento em modo de edição (Retorna ao Passo 3).

16

b) Forma de pagamento personalizada: Orçamento em modo de edição Retorna ao Passo 3).

6 – Sistema verifica e valida à transação e encontra a restrição: a) Forma de pagamento requer identificação do cliente (Retornar ao

passo 2). b) Forma de pagamento não permitida (Retorna ao Passo 5). c) Crédito do cliente insuficiente (Retorna ao Passo 5).

2 à 6 – Vendedor poderá cancelar a operação.

Caso de Uso: Realizar Compra Data Versão Descrição Autor 21/05/2011 1.0 Criação do Artefato André Abekawa Breve Descrição: Este caso de uso permite ao comprador realizar os procedimentos para aquisição de produtos. Ator Principal: Comprador Interessados e Interesses: Comprador: Suprir necessidades em relação a produtos necessários para a organização. Pré-condições:

• O comprador deverá estar autenticado no sistema; • Os produtos devem ser previamente cadastrados no sistema; • O fornecedor deverá constar no sistema.

Garantia de Sucesso: Os dados da compra são armazenados no sistema, é gerado um registro de contas a pagar e é gerado um pedido de compras. Cenário de Sucesso Principal: 1 – Este caso de uso tem início quando existe a necessidade da aquisição de produtos. 2 – Deve ser selecionado o orçamento no sistema. 8 – Comprador recebe orçamento do fornecedor. 9 – Comprador gera pedido de compra e envia ao fornecedor. Fluxos Alternativos: 2 – Caso não exista o orçamento estender caso de uso: Criar Orçamento de Compra. 8 – Fornecedor não retorna orçamento ou retorna o orçamento com alguma discordância do solicitado.

a) Adequar o orçamento (Retornar ao passo 2). b) Realizar orçamento com outro fornecedor (Retornar ao passo 2) c) Cancelar a compra.

17

Caso de Uso: Criar Orçamento de Venda Data Versão Descrição Autor 20/05/2011 1.0 Criação do Artefato André Abekawa Breve Descrição: Este caso de uso permite ao vendedor realizar orçamento. Ator Principal: Vendedor Interessados e Interesses: Vendedor: Realiza as operações para vender produtos. Cliente: Informa suas necessidades. Pré-condições: O Vendedor deverá estar autenticado no sistema. Garantia de sucesso:

• É gerado um registro com os dados do orçamento; • Uma mensagem é exibida ao vendedor informando o sucesso da

operação. Cenário de Sucesso Principal: 1 – Esse caso de uso tem inicio quando existe uma negociação em andamento. 2 – Vendedor seleciona o cliente no sistema. 3 – Vendedor informa ao sistema a solicitação do cliente (Registra Orçamento). 4 – Sistema calcula valores totais para informar ao cliente e formas de pagamento. 5 – Sistema armazena o orçamento. Fluxos Alternativos: 2 – Sistema informa que o cliente não está cadastrado e solicita a escolha entre cadastrar novo cliente* e utilizar venda sem cadastro**. *novo cliente: O caso de uso manter cliente será inicializado (Passo 3). **venda sem cadastro: A venda irá prosseguir com ausência de cliente identificado. 3 – Sistema realiza verificação e validação dos produtos/serviços solicitados e encontra restrições quanto a quantidade disponível em estoque e informa opções:

a) Excluir produtos com quantidades insuficientes do orçamento (Retorna ao Passo 4).

b) Realizar pesquisa de produtos similares (Retorna ao Passo 3). c) Retornar ao orçamento em modo de edição (Retorna ao Passo 3).

4 – Cliente não concorda com valores do orçamento ou formas de pagamento e vendedor realiza:

a) Conceder descontos: Orçamento em modo de edição (Retorna ao Passo 3).

18

b) Forma de pagamento personalizada: Orçamento em modo de edição Retorna ao Passo 3).

2 à 4 – Vendedor poderá cancelar a operação.

Caso de Uso: Criar Orçamento de Compra Data Versão Descrição Autor 21/05/2011 1.0 Criação do Artefato André Abekawa Breve Descrição: Este caso de uso permite ao comprador realizar os procedimentos para gerar orçamentos de compra. Ator Principal: Comprador Interessados e Interesses: Comprador: Relacionar preços para compras Pré-condições:

• O comprador deverá estar autenticado no sistema; • Os produtos devem ser previamente cadastrados no sistema; • O fornecedor deverá constar no sistema.

Garantia de Sucesso: Os dados do orçamento são registrados no sistema. Cenário de Sucesso Principal: 1 – Este caso de uso tem início quando existe a necessidade de relacionar preços de produtos com fornecedores. 2 – Comprador informa ao sistema o fornecedor. 3 – Comprador informa ao sistema os produtos e suas respectivas quantidades. 4 – Comprador informa ao sistema o prazo de entrega. 5 – Comprador informa ao sistema forma de pagamento. 6 – Comprador informa observações ao sistema. 7 – Sistema gera orçamento e envia ao fornecedor. Fluxos Alternativos: 2 à 6 – Comprador pode cancelar a operação.

19

Caso de Uso: Abrir Caixa Data Versão Descrição Autor 21/05/2011 1.0 Criação do Artefato André Abekawa Breve Descrição: Este caso de uso permite ao vendedor realizar abertura do caixa. Ator Principal: Vendedor Interessados e Interesses: Vendedor: Realizar e armazenar os dados das vendas. Pré-condições:

• O Vendedor deverá estar autenticado no sistema. Garantia de Sucesso: Permissão ao vendedor gerenciar as vendas. Cenário de Sucesso Principal: 1 – Este caso de uso tem início quando o vendedor efetua o login no sistema. 2 – O Sistema efetua as operações de abertura do caixa 3 – O Sistema informa a abertura do caixa ou seu status. Fluxos Alternativos: Não se aplica.

20

Caso de Uso: Fechar Caixa Data Versão Descrição Autor 21/05/2011 1.0 Criação do Artefato André Abekawa Breve Descrição: Este caso de uso permite ao vendedor realizar fechamento do caixa. Ator Principal: Vendedor Interessados e Interesses: Vendedor: Apurar o caixa do dia. Pré-condições:

• O Vendedor deverá estar autenticado no sistema. Garantia de Sucesso: Mensagem será exibida informando o sucesso da transação. Cenário de Sucesso Principal: 1 – Este caso de uso tem início quando existe a necessidade do fechamento do caixa. 2 – O Vendedor confere os comprovantes de venda (Dinheiro, Cheque entre outros de mesma natureza) 3 – O Valor é informado ao sistema. 4 – Sistema calcula as entradas e saídas do caixa. 5 – Um relatório é exibido com as movimentações é exibido. 6 – Vendedor entrega os comprovantes das vendas e saídas ao gerente. Fluxos Alternativos: 2 à 6 – Comprador pode cancelar a operação.

21

Caso de Uso: Recebimento de Vendas a Prazo Data Versão Descrição Autor 21/05/2011 1.0 Criação do Artefato André Abekawa Breve Descrição: Este caso de uso permite ao vendedor receber pagamentos de vendas a prazo. Ator Principal: Vendedor Interessados e Interesses: Vendedor: Realizar operações de recebimento de vendas. Pré-condições:

• O Vendedor deverá estar autenticado no sistema. • A venda deverá estar registrada.

Garantia de Sucesso: Mensagem será exibida informando o sucesso da transação. Cenário de Sucesso Principal: 1 – Este caso de uso tem início quando cliente realiza o pagamento de alguma divida. 2 – O Vendedor confere o valor pago e sua forma de pagamento. 3 – Vendedor informa ao sistema o valor pago. 4 – Sistema altera o status da venda para pago. 5 – Um registro é adicionado ao caixa referente ao pagamento da divida. Fluxos Alternativos: 2 à 4 – Vendedor pode cancelar a operação

22

Caso de Uso: Recebimento de Produtos Data Versão Descrição Autor 21/05/2011 1.0 Criação do Artefato André Abekawa Breve Descrição: Este caso de uso permite ao responsável pelo estoque receber mercadorias adquiridas a partir de pedidos de compras. Ator Principal: Estoquista Interessados e Interesses: Estoquista: Receber os produtos e conferi-los. Pré-condições:

• O Estoquista deverá estar autenticado no sistema • Pedido de compras deverá estar presente no sistema •

Garantia de Sucesso: • Mensagem será exibida informando o sucesso da transação. • A Quantidade dos produtos será atualizada no estoque.

Cenário de Sucesso Principal: 1 – Este caso de uso tem início quando algum agente solicita o recebimento de materiais para a empresa. 2 – O Estoquista confere os produtos e verifica se está de acordo com o pedido de compra. 3 – O Estoquista verifica os valores e formas de pagamento do pedido com os da nota fiscal de compra. 4 – Estoquista responde ao sistema que os produtos, valores e pagamento estão de acordo com o pedido de compras. 5 – Estoquista recebe os materiais. Fluxos Alternativos: 2 – Os produtos não estão de acordo com o solicitado pelo pedido de compras e solicita permissão ao comprador:

a) Comprador permite o recebimento e altera o pedido de compras; b) Comprador rejeita materiais entregues e cancela o pedido.

3 – Os valores/formas de pagamento estão em desacordo com o pedido de compras e solicita ao comprador instruções.

a) Comprador permite o recebimento e altera pedido de compras; b) Comprador rejeita a entrega e cancela o pedido.

2 à 3 – Estoquista pode cancelar a operação.

23

3.1.2 DIAGRAMA DE ATIVIDADES

3.1.2.1 Diagrama de Atividade: Atividade de Venda

24

3.2 MODELO CONCEITUAL

25

3.3 INTERFACES EXTERNAS

3.3.1 Método de desenvolvimento O SMART foi desenvolvido utilizando modelo em quatro camadas viabilizando reaproveitamento de código e organização do mesmo. Sendo as seguintes camadas: Persistência, Negócio, Dados, Interface Gráfica. Não serão utilizadas funções nativas de Sistemas Operacionais possibilitando assim um nível de portabilidade alto entre os Sistemas Operacionais mais utilizados no mercado. O Padrão de Projeto (Design Patterns) adotado para o desenvolvimento é conhecido como Facade (Fachada) objetivando a separação da Lógica de Negócios para melhor compreensão e leitura de código fonte.

3.3.2 Ambiente de Desenvolvimento Para o desenvolvimento do SMART foram utilizados os seguintes softwares:

• MAC OS X 10.6.7 Snow Leopard (Sistema Operacional) • IDE Netbeans 6.9/7.0 (Ambiente de Desenvolvimento Integrado) • Mysql Server (Sistema Gerenciador de Bancos de Dados) • Apache Tomcat (Web Server) • Mysql WorkBench (Modelagem de Banco de Dados)

3.3.3 Interfaces com outros ambientes Não se aplica.

3.3.4 Padronização de Interfaces Visuais As Interfaces Gráficas do SMART utilizam um recurso da linguagem de programação JAVA conhecido como Look and Fell que faz uso de tool kits (Conjuntos de Ferramentas) da classe nativa do JDK (Java Development Kit) javax.swing que é responsável pela criação de Interfaces Gráficas e o Look and Fell possibilita que as interfaces se assemelhem ao Sistema Operacional vigente ou de acordo com o gosto do usuário. Além da padronização visual o SMART será desenvolvido com comportamento de interface padrão, ou seja, a utilização em todas as telas será executada da mesma forma permitindo assim uma rápida familiarização com o sistema.

3.3.5 Ambiente em Rede Para funcionamento em ambientes com redes de computadores o SMART utiliza o protocolo TCP (Transmission Control Protocol) para

26

transmissão de dados em redes locais (LAN) e podendo ser utilizado em conjunto com TCP/IP (Transmission Control Protocol/Internet Protocol) para utilização via WEB (World Wide Web) desde que o servidor de bancos de dados esteja preparado para realizar conexões deste tipo.

4. PROJETO DE SOFTWARE

4.1 ARQUITETURA LÓGICA DO SOFTWARE O SMART foi desenvolvido em camadas e estão dispostas da seguinte maneira:

27

4.1.1 Sumário de Classes As Classes estão dispostas em suas camadas seguindo o sumário de classes abaixo. Layer: UI (Interface Gráfica) addItem @author andreluizjamarinoabekawa filtroPro @author andreluizjamarinoabekawa frmBaixarTitulo @author andreluizjamarinoabekawa frmBaixaT @author andreluizjamarinoabekawa frmCadUsuario @author andreluizjamarinoabekawa frmCliente @author andreluizjamarinoabekawa frmCompras @author andreluizjamarinoabekawa frmEntradaNF @author andreluizjamarinoabekawa frmFiltroCli @author andreluizjamarinoabekawa frmFiltroCompras @author andreluizjamarinoabekawa frmFiltroFornecedor @author andreluizjamarinoabekawa frmFiltroProduto @author andreluizjamarinoabekawa frmFiltroRelCli @author andreluizjamarinoabekawa frmFornecedores @author andreluizjamarinoabekawa frmListCli @author andreluizjamarinoabekawa frmLogin @author andreluizjamarinoabekawa frmPDV @author andreluizjamarinoabekawa frmProduto @author andreluizjamarinoabekawa frmTitulos @author andreluizjamarinoabekawa lst_produto @author andreluizjamarinoabekawa lstAddProdutos @author andreluizjamarinoabekawa lstCompra @author andreluizjamarinoabekawa main @author andreluizjamarinoabekawa Operations @author andreluizjamarinoabekawa Search @author andreluizjamarinoabekawa splash @author andreluizjamarinoabekawa TableColumnAdjuster @author andreluizjamarinoabekawa teste @author andreluizjamarinoabekawa Utils @author andreluizjamarinoabekawa Layer: business (Lógica de Negócio) barcode @author andreluizjamarinoabekawa caixa @author andreluizjamarinoabekawa Categoria @author andreluizjamarinoabekawa CFOP @author andreluizjamarinoabekawa cidade @author abekawa Cliente @author andreluizjamarinoabekawa ClienteBO @author andreluizjamarinoabekawa Cotacao @author andreluizjamarinoabekawa CotacaoCompraBO @author andreluizjamarinoabekawa

28

CotacaoVendaBO @author andreluizjamarinoabekawa Endereco @author andreluizjamarinoabekawa estado @author abekawa fcCaixa @author andreluizjamarinoabekawa fcCompras @author andreluizjamarinoabekawa fcEntradaProduto @author andreluizjamarinoabekawa fcFornecedor @author andreluizjamarinoabekawa fcLogin @author andreluizjamarinoabekawa fcManterCliente @author andreluizjamarinoabekawa fcProduto @author andreluizjamarinoabekawa fcTitulos @author andreluizjamarinoabekawa fcVenda @author andreluizjamarinoabekawa Fornecedor @author andreluizjamarinoabekawa FornecedorBO @author andreluizjamarinoabekawa itens_NF @author andreluizjamarinoabekawa itens_pro @author andreluizjamarinoabekawa itens_venda @author andreluizjamarinoabekawa movimentacao @author andreluizjamarinoabekawa NotaFiscal @author andreluizjamarinoabekawa NotaFiscalEntradaBO @author andreluizjamarinoabekawa Pessoa @author andreluizjamarinoabekawa PessoaFisica @author andreluizjamarinoabekawa PessoaJuridica @author andreluizjamarinoabekawa Produto @author andreluizjamarinoabekawa ProdutoBO @author andreluizjamarinoabekawa prospectarVenda @author andreluizjamarinoabekawa prospectBO @author andreluizjamarinoabekawa prospects @author andreluizjamarinoabekawa SubCategoria @author andreluizjamarinoabekawa Titulo @author andreluizjamarinoabekawa usuario @author andreluizjamarinoabekawa UsuarioBO @author andreluizjamarinoabekawa venda @author andreluizjamarinoabekawa Layer: dados (Manipulação de dados) Conditions @author abekawa DataManipulation @author abekawa FrameWork @author abekawa ResultSetTableModel @author abekawa Layer: persistencia (Persistência de dados) Persist @author abekawa

29

4.2 DIAGRAMA DE INTERAÇÃO

4.2.1 Diagrama de Interação (Venda)

30

4.2.2 Diagrama de Interação (Compra)

4.2.3 Diagrama de Interação (Finalizar Caixa)

31

4.2.4 Diagrama de Interação (Recebimento de Contas)