universidade federal fluminense joÃo francisco …ƒo_francisco... · um sistema para dar apoio ao...

UNIVERSIDADE FEDERAL FLUMINENSE

JOÃO FRANCISCO FERNANDES REBELO

UM SISTEMA PARA DAR APOIO AO FUNCIONAMENTO DE UMA

BICICLETARIA

Rio de Janeiro

2016



BICICLETARIA

Trabalho de Conclusão de Curso submetido

ao Curso de Tecnologia em Sistemas de

Computação da Universidade Federal Flumi-

nense como requisito parcial para obtenção

do título de Tecnólogo em Sistemas de Com-

putação.

Orientador:

MARIANA TASCA FONTENELLE LÔBO

Rio de Janeiro

2016

Ficha Catalográfica elaborada pela Biblioteca da Escola de Engenharia e Instituto de Computação da UFF

R291 Rebelo, João Francisco Fernandes

Um sistema para dar apoio ao funcionamento de uma bicicletaria

/ João Francisco Fernandes Rebelo. – Niterói, RJ : [s.n.], 2016.

43 f.

Projeto Final (Tecnólogo em Sistemas de Computação) –

Universidade Federal Fluminense, 2016.

Orientador: Mariana Tasca Fontenelle Lôbo.

1. Sistema de computador. 2. Bicicletaria. 3. Microempresa. I.

Título.

CDD 004



BICICLETARIA

Trabalho de Conclusão de Curso submetido

ao Curso de Tecnologia em Sistemas de

Computação da Universidade Federal Flumi-

nense como requisito parcial para obtenção

do título de Tecnólogo em Sistemas de Com-

putação.

Niterói, ___ de _______________ de 2016.

Banca Examinadora :

_________________________________________

Profa. Mariana Tasca Fontenelle Lôbo, D.Sc. – Orientadora

UFF – Universidade Federal Fluminense

_________________________________________

Prof. Leandro Soares de Sousa, D.Sc. – Avaliador

UFF – Universidade Federal Fluminense

Dedico este trabalho a todos os meus amigos e

familiares que sempre me incentivaram a conclui-

lo, mas em especial a minha esposa e filho nos

quais sempre me apoiei para chegar até aqui.

AGRADECIMENTOS

À minha orientadora Mariana Tasca Fontenelle Lôbo

pelo estímulo e atenção que me concedeu durante

este trabalho.

A todos os meus familiares e amigos pelo apoio e

colaboração.

RESUMO

Este trabalho descreve um sistema que visa melhorar a produtividade do setor de ativida-de econômica ligado a bicicleta (distribuição e comércio), introduzindo facilidade de usodesta tecnologia ao segmento deste setor que, em sua maioria, não está habituado a uti -lizá-la, e abre a possibilidade de melhorar a integração dos agentes desta cadeia produti -va.

Palavras-chaves: produtividade, bicicletaria, microempresa, características de mer-

cado e público-alvo.

LISTA DE ILUSTRAÇÕES

Figura 3.1: Diagrama de casos de uso

Figura 4.1 : Diagrama de Classes

LISTA DE TABELAS

Tabela 3.1: Modelo para a especificação dos requisitos.

LISTA DE ABREVIATURAS E SIGLAS

• ABRACICLO Associação Brasileira dos Fabricantes de Motocicletas, Ciclo-motores, Motonetas, Bicicletas e Similares

• UML (Unified Modeling Language) Linguagem Unificada de Modelagem.

SUMÁRIO

RESUMO.......................................................................................................................6

LISTA DE ILUSTRAÇÕES............................................................................................7

LISTA DE TABELAS......................................................................................................8

LISTA DE ABREVIATURAS E SIGLAS.........................................................................9

1 INTRODUÇÃO....................................................................................................11

1.1 OBJETIVO DO PROJETO...........................................................................11

1.2 MOTIVAÇÃO................................................................................................11

1.3 ORGANIZAÇÃO DO TRABALHO................................................................12

2 DESCRIÇÃO DO SISTEMA................................................................................13

2.1 DESCRIÇÃO DO PROBLEMA.....................................................................13

2.2 PROPOSTA DE SOLUÇÃO.........................................................................14

3 REQUISITOS DO SISTEMA...............................................................................15

3.1 REQUISITOS FUNCIONAIS.......................................................................15

3.2 REQUISITOS NÃO FUNCIONAIS..............................................................17

3.3 CASOS DE USO.........................................................................................17

3.3.1 ATORES...............................................................................................17

3.3.2 DIAGRAMA DE CASOS DE USO........................................................19

3.3.3 DESCRIÇÃO DOS CASOS DE USO...................................................20

3.4 REGRAS DE NEGÓCIO.............................................................................36

4 ANÁLISE.............................................................................................................38

4.1 ARQUITETURA DO SISTEMA....................................................................38

4.1.1 DIAGRAMA DE CLASSES....................................................................38

4.2 TECNOLOGIA............................................................................................42

CONCLUSÕES E TRABALHOS FUTUROS..............................................................43

REFERÊNCIAS BIBLIOGRÁFICAS...........................................................................44

11

1 INTRODUÇÃO

1.1 OBJETIVO DO PROJETO

O objetivo deste projeto é a construção de um sistema que sirva como

uma ferramenta de apoio a administração de um tipo determinado de estabe-

lecimento comercial, a bicicletaria.

1.2 MOTIVAÇÃO

A bicicletaria é um segmento com características específicas, e que não

são encontradas em sistemas mais genéricos, projetados para estabelecimentos co-

merciais ou de prestação de serviço. Surge assim, a carência de uma ferramenta

que atenda estas especificidades, mas sem se tornar onerosa demais para uma mi-

croempresa (que é o tamanho de uma parcela significativa deste segmento).

12

1.3 ORGANIZAÇÃO DO TRABALHO

O trabalho está organizado da seguinte forma. O Capítulo 1 trata de es-

clarecer os objetivos e motivação deste trabalho. O Capítulo 2 apresenta as ques-

tões que definem o problema e a solução proposta. No Capítulo 3 são apresentados

os requisitos do sistema, funcionais, não funcionais e casos de uso. O Capítulo 4

trata do desenvolvimento do sistema, apresentando a etapa de Análise com a de-

mostração da Arquitetura do sistema. Por fim, são apresentadas algumas conclu-

sões e trabalhos futuros.

2 DESCRIÇÃO DO SISTEMA

2.1 DESCRIÇÃO DO PROBLEMA

Dois aspectos importantes devem ser considerados no problema que será

descrito neste trabalho: O primeiro está ligado às características do mercado da bici-

cleta e o segundo às características dos indivíduos que atuam neste mercado.

No Brasil, segundo a ABRACICLO1, o total da frota de bicicletas é de mais

de 70 milhões de unidades, e em 2015 foram vendidas 3,3 milhões de unidades. Ain-

da segundo a associação, 40% destes veículos é construído de forma artesanal, ou

seja, por microempresas que montam e vendem bicicletas. Apesar destes números

já serem expressivos, a tendência é de crescimento, pois existe hoje uma forte cons-

cientização de que o uso da bicicleta está diretamente ligado à melhora da mobilida-

de urbana, preservação do meio ambiente e à melhora na saúde de seus usuários.

Neste mercado, os empreendedores responsáveis por mais de 90% das

bicicletarias (micro e pequenas empresas) que respondem por 40% da produção e

quase 100% da manutenção das bicicletas, são indivíduos que começaram suas

empresas com muito pouco capital inicial e que não têm condição (ou intenção) de

investir em um sistema exclusivo para ela. Além disso, esses indivíduos em sua mai-

oria não se sentem muito familiarizados com esta tecnologia.

1ABRACICLO – Associação Brasileira dos Fabricantes de Motocicletas, Ciclomotores,

Motonetas, Bicicletas e Similares

13

2.2 PROPOSTA DE SOLUÇÃO

Para que o sistema proposto atinja o seu principal público-alvo é indispen-

sável que o preço deste sistema para este público seja muito baixo ou nenhum, e

também que ele seja extremamente simples de usar. Para tirar o ônus deste trabalho

do micro ou pequeno empresário, a ideia é criar um sistema que integre lojistas, ata-

cadistas (importadores) e fabricantes, sendo que estes dois últimos deverão arcar

com os custos do sistema, pois através dele, estes atacadistas e fabricantes pode-

rão expor seus produtos, passar cotações de preço, apresentar novidades e outros

de forma muito eficiente, pois estarão em um canal que os conecta diretamente a

seu público-alvo.

O que será apresentado aqui é apenas a parte que tange ao logista, pois

esta é a parte que deverá ser distribuída inicialmente, para que no futuro seja inte-

grada a outras partes e o sistema passe a funcionar de forma sustentável.

Para que tudo isto seja possível o sistema deve rodar on-line. Todos os

dados do cliente devem ser salvos em um banco no servidor e também no cliente,

para que este possa usá-los caso esteja offline. Todas as páginas de interface do

sistema com o usuário deverão ser o mais intuitivas e fáceis de aprender possível,

contendo apenas o necessário para que o sistema atinja seu objetivo.

14

3 REQUISITOS DO SISTEMA

3.1 REQUISITOS FUNCIONAIS

Estão listados a seguir os principais requisitos funcionais do sistema.

• RF1 - O sistema deve permitir o cadastro de fornecedores.

• RF2 - O sistema deve permitir inclusão ou alteração no cadastro de funcioná-

rios.

• RF3 - O sistema deve permitir inclusão, exclusão ou alteração no cadastro deprodutos.

• RF4 - O sistema deve permitir a inserção de compromisso no Contas a Pa-

gar.

• RF5 - O sistema deve permitir a exclusão de compromisso no Contas a Pa-

gar.

• RF6 - O sistema deve permitir a inserção de crédito no Contas a Receber.

• RF7- O sistema deve permitir a exclusão de crédito no Contas a Receber.

• RF8 - O sistema deve permitir alteração no cadastro de fornecedores.

• RF9 - O sistema deve permitir inclusão ou alteração no cadastro de clientes.

15

• RF10 - O sistema deve permitir inclusão ou exclusão de produtos em uma lis-ta de mercadorias a comprar.

• RF11 - O sistema deve exibir uma tabela com código, descrição e preço decada produto à venda.

• RF12 - O sistema deve oferecer método orientado para relacionar componen-tes para montagem de uma bicicleta.

• RF13 - O sistema deve oferecer método orientado para relacionar componen-tes para montagem de uma roda para bicicleta.

• RF14 - O sistema deve oferecer método orientado para realizar uma venda.

• RF15 - O sistema deve oferecer opção para emissão de Nota Fiscal de ven-

da.

• RF16 - O sistema deve promover as alterações necessárias ao Estoque cadavez que for realizada uma Venda ou montagem de uma Bicicleta Nova ouRoda Nova.

• RF17 - O sistema deve oferecer método orientado para a emissão de Ordem

de Serviço.

• RF18 - O sistema deverá impedir a impressão de Ordens de Serviço sem quetodos os seus campos de identificação estejam preenchidos.

• RF19 - O sistema deve oferecer opção para emissão de Nota Fiscal de Servi-

ços.

• RF20 - O sistema deve promover as alterações necessárias a Tabela de pre-ços cada vez que por feita uma alteração no cadastro de produtos.

• RF21 - O sistema deve permitir a exibição de relatórios de produtos, clientes,fornecedores, vendas, compras, contas a pagar e contas a receber.

16

• RF22 - O sistema deve permitir inclusão no estoque sempre que houver achegada de novos produtos.

• RF23 – O sistema deve promover as alterações na lista de mercadorias acomprar sempre que a quantidade de mercadorias em estoque ultrapassar(para mais ou para menos) o mínimo recomendado em estoque.

3.2 REQUISITOS NÃO FUNCIONAIS

A seguir, são listados alguns dos requisitos não funcionais do sistema.

• RNF1 - A interface do sistema deve ser amigável e intuitiva mesmo a umusuário inexperiente.

• RNF2 - O sistema deve ter acesso via web.

• RNF3 - O sistema deve ter segurança contra violação de dados.

• RNF4 - O sistema será hospedado em um servidor contratado.

17

3.3 CASOS DE USO

3.3.1 ATORES - A seguir será feita a apresentação de todos os atores que pode-

rão interagir com o sistema e um resumo dos principais casos de uso.

• ATOR1 - Administrador – Com acesso total ao sistema, também respon-

sável por conceder senha de autenticação aos outros atores, cadastrar funci-

onários, pedir relatórios de vendas, compras e contas a pagar.

• ATOR2 - Comprador – Cadastrar ou pesquisar fornecedores, checar lista

de mercadorias a comprar ou marcá-las como pedido feito.

• ATOR3 - Vendedor ou Balconista – Checar estoque de produtos, realizar

vendas e emitir notas fiscais de venda, emitir Ordem de Serviço e nota fiscal

de serviço, anotar mercadorias em A Comprar e relacionar e lançar bicicleta

nova ou roda nova.

• ATOR4 - Responsável pelas finanças – Acompanhar o faturamento com

vendas e prestação de serviços e realizar controle das contas a pagar e a re-

ceber.

• ATOR5 - Responsável pela oficina – Conferir ou fazer alterações em Or-

dens de Serviço.

• ATOR6 - Almoxarife – Registrar a entrada de mercadorias no estoque,

lançar ou retirar mercadorias da Relação de Mercadorias a Comprar.

18

3.3.2 DIAGRAMA DE CASOS DE USO – A ilustração a seguir exibe uma repre-

sentação gráfica dos casos de uso.

Figura 3.1: Diagrama de casos de uso

19

3.3.3 DESCRIÇÃO DOS CASOS DE USO Os casos de uso foram descri-

tos através de uma série de tópicos, padronizados segundo um modelo

para a Especificação de Requisitos, revisado em 14.11.08, de autoria dos

Professores Guilherme Travassos e Jobson Massolar, sendo a utilização

do modelo permitida pelo Grupo ESE/COOPE/UFRJ, no escopo do curso

CEDERJ. No modelo temos as informações necessárias para a compreen-

são dos diversos cenários dos casos de uso, obedecendo a uma mesma

organização de tópicos.

Tabela 3.1: Modelo para a especificação dos requisitos.

Nome: <define o nome do caso de uso introduzido na Figura 2.1>.

Objetivo: <descreve o objetivo do caso de uso>.

Requisitos: <descreve os requisitos atendidos por esse caso de uso>.

Atores: <relaciona os atores que interagem como caso de uso>.

Pré-condições: <descreve as pré-condições a serem atendidas para que o caso de uso possa ser executado>.

Trigger: <define o evento que dispara a execução desse caso de uso>.

Fluxo Principal: <descreve o funcionamento para que o caso de uso possa ser executado>.

Fluxo Alternativo: <descreve os fluxos alternativos do caso de uso, indicando que evento dispara cada um deles. Cada fluxo recebe a nomeação A1, A2, etc>.

Pós-condições: <define que produto ou resultado concreto o ator principal obterá ao final da execução do fluxo básico>

Regras de negócio: <lista as regras de negócios que devem ser respeitadas na execução do caso de uso. >.

Extensões: Cenários alternativos de sucesso ou fracasso.

20

3.3.3.1 NOME: CADASTRAR FUNCIONÁRIOS

Objetivo: Permite ao Administrador dar acesso ao sistema aos funcio-nários.

Requisitos: RF3, RNF8.

Atores: Administrador.

Pré-condições: Estar autenticado no sistema.

Trigger: Na página inicial do sistema o ator aciona o link “Cadastros”.

Fluxo Principal: 1) O sistema apresenta um menu de escolha única com os links para: “Cadastro de Clientes”; “Cadastro de Produtos”;“Cadastro de Fornecedores”; “Cadastro de Funcionários”. 2) O ator aciona o link “Cadastro de Funcionário” .3) O sistema apresenta a página com campos para dar entradanos dados necessários ao cadastro do funcionário e a opçãode salvar.

Fluxo Alternativo: Não há.

Pós-condições: O funcionário está cadastrado.

Regras de negócio: RN1 e RN5.

Extensões: No passo 3 do fluxo principal, antes de salvar, o sistema checa se o CPF do funcionário já existe no sistema, existindo seráaberta a página com os dados do funcionário já preenchidos.

3.3.3.2 NOME: GERIR CONTAS A RECEBER (RELATÓRIOS)

Objetivo: Facilitar ao ator o controle sobre os créditos da empresa.

Requisitos: RF21.

Atores: Administrador e Responsável pelas Finanças.


Trigger: Na página inicial do sistema o ator aciona o link “MovimentaçãoFinanceira”.

Fluxo Principal: 1) O sistema apresenta um menu de escolha única com os links para: “Vendas”; “Contas a Pagar”; “Contas a Receber”. 2) O ator aciona o link “Contas a Receber”.

21

3) O sistema apresenta a página solicitada com opções para“Relatórios”, “Incluir” ou “Excluir”.4) O ator aciona o link “Relatórios”.5) O sistema abre página com menus de opções para o tipo derelatório de Contas a Receber desejado:- por período;- valores máximos e mínimos;- vencidos, a vencer ou todos;- ordenados por vencimento ou ordenados por valor; e o botão “Buscar”.


Pós-condições: Será exibido o relatório com as especificações escolhidas pelo ator.

Regras de negócio: RN1.

Extensões: Não há.

3.3.3.3 NOME: GERIR CONTAS A RECEBER (INCLUIR)

Objetivo: Facilitar ao ator incluir no controle os créditos da empresa.

Requisitos: RF21.




Fluxo Principal: 1) O sistema apresenta um menu de escolha única com os links para “Vendas” , “Contas a Pagar”, e “Contas a Receber”. 2) O ator aciona o link “Contas a Receber”.3) O sistema apresenta a página solicitada com opções para“Relatórios”, “Incluir” ou “Excluir”.4) O ator aciona o link “Incluir”.5) O sistema apresenta os seguintes campos de texto:- nome do devedor;- valor do crédito;- número do título;

22

- documento que originou o crédito;- vencimento;e o botão “Incluir”.


Pós-condições: A conta será incluída no “Contas a Receber”.


Extensões: No passo 5, já existindo o título no sistema, será emitido um aviso do fato ao ator.

3.3.3.4 NOME: GERIR CONTAS A RECEBER (EXCLUIR)

Objetivo: Facilitar ao ator excluir do controle os créditos da empresa.

Requisitos: RF7




Fluxo Principal: 1) O sistema apresenta um menu de escolha única com os links para “Vendas” , “Contas a Pagar”, e “Contas a Receber”. 2) O ator aciona o link “Contas a Receber”.3) O sistema apresenta a página solicitada com opções para“Relatórios”, “Incluir” ou “Excluir”.4) O ator aciona o link “Excluir”.5) O sistema apresenta menu (tipo botões de rádio) com op-ções para o tipo de busca desejado:- por nome do devedor;- por valor do crédito;- por número do título;- por documento que originou o crédito;- por vencimento;e o botão “Buscar”.6) O ator escolhe uma das opções e aciona “Buscar”.7) O sistema apresenta relação referente a escolha do ator,com opção para marcar um ou mais títulos, e o botão “Excluir”.


23

Pós-condições: A conta será excluída no “Contas a Receber”.



3.3.3.5 NOME: GERIR CONTAS A PAGAR (RELATÓRIOS)

Objetivo: Facilitar ao ator o controle sobre os compromissos da empresa.

Requisitos: RF21.




Fluxo Principal: 1) O sistema apresenta um menu de escolha única com os links para “Vendas” , “Contas a Pagar”, e “Contas a Receber”. 2) O ator aciona o link “Contas a Pagar”.3) O sistema apresenta a página solicitada com opções para“Relatórios”, “Incluir” ou “Excluir”.4) O ator aciona o link “Relatórios”.5) O sistema abre página com menus de opções para o tipo derelatório de Contas a Pagar desejado:- por período;- valores máximos e mínimos;- vencidos, a vencer ou todos;- ordenados por vencimento ou ordenados por valor; e o botão “Buscar”.





24

3.3.3.6 NOME: GERIR CONTAS A PAGAR (INCLUIR)

Objetivo: Facilitar ao ator incluir no controle os compromissos da empresa.

Requisitos: RF4.




Fluxo Principal: 1) O sistema apresenta um menu de escolha única com os links para “Vendas” , “Contas a Pagar”, e “Contas a Receber”. 2) O ator aciona o link “Contas a Pagar”.3) O sistema apresenta a página solicitada com opções para“Relatórios”, “Incluir” ou “Excluir”.4) O ator aciona o link “Incluir”.5) O sistema apresenta os seguintes campos de texto:- nome do credor;- valor do débito;- número do título;- documento que originou o crédito;- vencimento;e o botão “Incluir”.


Pós-condições: A conta será incluída no “Contas a Pagar”.


Extensões: No passo 5, já existindo o título no sistema, será emitido um aviso do fato ao ator.

3.3.3.7 NOME: GERIR CONTAS A PAGAR (EXCLUIR)

Objetivo: Facilitar ao ator excluir do controle os compromissos da em-presa.

Requisitos: RF5



25


Fluxo Principal: 1) O sistema apresenta um menu de escolha única com os links para “Vendas” , “Contas a Pagar”, e “Contas a Receber”. 2) O ator aciona o link “Contas a Pagar”.3) O sistema apresenta a página solicitada com opções para“Relatórios”, “Incluir” ou “Excluir”.4) O ator aciona o link “Excluir”.5) O sistema apresenta menu (tipo botões de rádio) com op-ções para o tipo de busca desejado:- por nome do credor;- por valor do débito;- por número do título;- por documento que originou o débito;- por vencimento;e o botão “Buscar”.6) O ator escolhe uma das opções e aciona “Buscar”.7) O sistema apresenta relação referente a escolha do ator,com opção para marcar um ou mais títulos, e o botão “Excluir”.


Pós-condições: A conta será excluída no “Contas a Pagar”.



3.3.3.8 NOME: GERIR VENDAS (RELATÓRIOS)

Objetivo: Permitir ao Administrador ou Responsável pelas Finanças acompanhar a movimentação de vendas da empresa.

Requisitos: RF21.

Atores: Administrador, Responsável pelas Finanças.


Trigger: Na página inicial do sistema o ator aciona o link “Vendas”.

Fluxo Principal: 1) O sistema apresenta a página “Vendas” com os links para “Relatórios” e “Efetuar Venda”. 2) O Ator acione o link “Relatórios”. 3) O sistema abre página com menus de opções para o tipo derelatório de vendas desejado:- período desejado;

26

- forma de pagamento (dinheiro, cheque, cartão de crédito, car-tão de débito ou todos); e o botão “Buscar”.





3.3.3.9 NOME: GERIR VENDAS (EFETUAR VENDAS)

Objetivo: Permitir ao Balconista (vendedor) efetuar vendas.

Requisitos: RF11, RF14, RF15 e RF16.

Atores: Balconista.


Trigger: Na página inicial do sistema o ator aciona o link “Vendas”.Fluxo Principal: 1) O sistema apresenta um menu de escolha única com os

links para “Relatórios” e “Efetuar Venda”. 2) O Ator aciona o link “Efetuar Venda”.3) O sistema apresenta página com campo para busca do cli-ente por nome ou CPF e o botão “Buscar”.4) O Ator digita o CPF ou escolhe pelo nome o cliente que estáefetuando a compra e aciona o botão “Buscar”.5) O sistema apresenta página com os dados do cliente preen-chidos e campos para busca das mercadorias que irão compora venda. 6) Para cada busca um item (mercadoria) será incluído na ven-da.7) O Ator escolhe as quantidades de cada item.8) O sistema exibe o valor total por item, o total da venda e aopção de concluir a venda.9) O sistema salva a venda e inicia o aplicativo para emissãode Nota Fiscal.

27


Pós-condições: Todas as mercadorias vendidas serão baixadas do Estoque.



3.3.3.10 NOME: GERIR ORDEM DE SERVIÇO (CRIAR)

Objetivo: Permitir ao Balconista criar “Ordem de Serviço”.

Requisitos: RF17, RF18 e RF19.

Atores: Balconista.


Trigger: Na página inicial do sistema o ator aciona o link “Ordem de Serviço”.

Fluxo Principal: 1) O sistema apresenta um menu de escolha única com os links para: “Criar Ordem de Serviço”; “Modificar Ordem de Serviço”; “Fechar Ordem de Serviço”.2) O ator aciona “Criar Ordem de Serviço”.3) O sistema retorna página com campos para busca do clientepor nome ou CPF e o botão “Busca”.4) O ator preenche o campo com CPF ou nome e aciona o bo-tão “Busca”.5) O sistema retorna a página “Ordem de Serviço” com:- data e hora da emissão preenchidos;- os dados do cliente preenchidos;- campos para dados da bicicleta;- campos para descrição dos serviços; - campos para valores dos serviços;- campos para data e hora de entrega do serviço;- botão para “Emitir Ordem de Serviço”;6) O sistema oferece a possibilidade de imprimir a ordem deserviço.


Pós-condições: O sistema coloca a Ordem de Serviço em uma fila baseada na data e hora de entrega.


28

Extensões: Após o passo 4, não sendo encontrado o CPF do cliente, o ator será informado que o CPF não foi encontrado e orien-tado a cadastrar o cliente.

3.3.3.11 NOME: GERIR ORDEM DE SERVIÇO (MODIFICAR)

Objetivo: Permitir ao ator acompanhar ou alterar “Ordem de Serviço”.

Requisitos: RF18 e RF19.

Atores: Balconista e Responsável pela Oficina.



Fluxo Principal: 1) O sistema apresenta um menu de escolha única com os links para: “Criar Ordem de Serviço”; “Modificar Ordem de Serviço”; “Fechar Ordem de Serviço”.2) O ator aciona “Modificar Ordem de Serviço”.3) O sistema retorna página com campos para busca do clientepor nome ou CPF e o botão “Busca”.4) O ator preenche o campo com CPF ou nome e aciona o bo-tão “Busca”.5) O sistema retorna a página “Ordem de Serviço” correspon-dente a identificação do cliente e o botão “Atualizar”.6) O ator faz as modificações e aciona o botão “Atualizar”.7) O sistema informa ao Balconista que a ordem de serviço foimodificada e aguarda a confirmação deste para fazer a altera-ção.8) O Balconista (após pedir autorização ao cliente) confirma aalteração ou cancela o ordem de serviço.9) O sistema oferece a possibilidade de imprimir a ordem deserviço.


Pós-condições: O sistema coloca a Ordem de Serviço em uma fila baseada na data e hora de entrega.



29

3.3.3.12 NOME: GERIR ORDEM DE SERVIÇO (FECHAR)

Objetivo: Permitir ao ator concluir a “Ordem de Serviço”.

Requisitos: RF19.

Atores: Balconista.



Fluxo Principal: 1) O sistema apresenta um menu de escolha única com oslinks para:“Criar Ordem de Serviço”; “Modificar Ordem de Serviço”; “Fe-char Ordem de Serviço”.2) O ator aciona “Fechar Ordem de Serviço”.3) O sistema retorna página com campos para busca do clientepor nome ou CPF e o botão “Busca”.4) O ator preenche o campo com CPF ou nome e aciona o bo-tão “Busca”.5) O sistema retorna a página “Ordem de Serviço” correspon-dente a identificação do cliente e o botão “Concluir”.6) O ator aciona o botão “Concluir”.7) O sistema salva a ordem de serviço e inicia o aplicativo paraemissão de Nota Fiscal.


Pós-condições: Não há.



3.3.3.13 NOME: CONSULTAR TABELA DE PREÇOS

Objetivo: Prover ao Balconista um acesso rápido e simplificado a uma relação com as mercadorias a venda.

Requisitos: RF11.

Atores: Balconista.

Pré-condições: Não há.

Trigger: Na página inicial do sistema o ator aciona o link “Produtos”.

30

Fluxo Principal: 1) O sistema apresenta um menu de escolha única com oslinks para: “Tabela de Preços”; “Cadastro de Produto”; “Mercadorias a Comprar”; “Relatórios”; “Montar Produto”.2) O Ator escolhe a opção “Tabela de Preços”.3) O sistema exibe página com campo para busca por nome oucódigo do produto, e relação com todos os produtos disponí-veis para venda, com respectivos preços de venda, em ordemalfabética.



Regras de negócio: Não há.


3.3.3.14 NOME: GERIR ESTOQUE (CADASTRAR PRODUTO)

Objetivo: Permite ao Almoxarife manter atualizado controle sobre as mercadorias em estoque.

Requisitos: RF3, RF10, RF20.

Atores: Almoxarife.



Fluxo Principal: 1) O sistema apresenta um menu de escolha única com oslinks para: “Tabela de Preços”; “Cadastro de Produto”; “Mer-cadorias a Comprar”; “Relatórios”; “Montar Produto”.2) O Ator escolhe a opção “Cadastro de Produto”.3) O sistema apresenta os subtítulos “Pesquisar” e “Cadastrar”.4) O Ator escolhe a opção “Cadastrar”.5) O sistema exibe página com campos para:- nome do Produto;- código do Produto;- foto do Produto;- fornecedores;- preço atual;- preço médio;- margem de lucro;- quantidade entrando em estoque;- quantidade atual em estoque;- quantidade Mínima;- dados fiscais;

31

- botão para salvar.

Fluxo Alternativo 1: Não há.

Pós-condições: 1) O produto estará cadastrado.2) A Tabela de Preços será atualizada.3) Caso a quantidade mínima em estoque seja ultrapassada o produto será retirado da lista de Mercadorias a Comprar.



3.3.3.15 NOME: GERIR ESTOQUE (MODIFICAR CADASTRO)

Objetivo: Permite ao Almoxarife manter atualizado controle sobre as mercadorias em estoque.

Requisitos: RF3, RF10, RF20.

Atores: Almoxarife.



Fluxo Principal: 1) O sistema apresenta um menu de escolha única com oslinks para: “Tabela de Preços”; “Cadastro de Produto”; “Mer-cadorias a Comprar”; “Relatórios”; “Montar Produto”.2) O Ator escolhe a opção “Cadastro de Produto”.3) O sistema apresenta os subtítulos “Pesquisar” e “Cadastrar”.4) O Ator escolhe a opção “Pesquisar”.5) O sistema exibe página com opções para pesquisa por:- nome do Produto;- código do Produto;- fornecedores;- botão para “Pesquisar”. 6) O Ator preenche um dos campos e aciona “Pesquisar”.7) O sistema apresenta o cadastro do produto correspondestea pesquisa e o botão “Salvar”.8) O ator modifica o campo desejado e aciona o botão “Salvar”.

Fluxo Alternativo 1: Não há.

Pós-condições: 1) A Tabela de Preços será atualizada.2) Caso a quantidade mínima em estoque seja ultrapassada oproduto será retirado da lista de Mercadorias a Comprar.

32



3.3.3.16 NOME: MONTAR BICICLETA OU RODA NOVA

Objetivo: Oferecer ao Balconista (ao gosto do cliente) um método efici-ente de montar, através de uma lista de componentes essen-ciais, uma bicicleta ou roda.

Requisitos: RF12, RF13, RF16 e RF22.

Atores: Balconista.



Fluxo Principal: 1) O sistema apresenta um menu de escolha única com oslinks para: “Tabela de Preços”; “Cadastro de Produto”; “Mer-cadorias a Comprar”; “Relatórios”; “Montar Produto”.2) O Balconista aciona a opção “Montar Produto”.3) O sistema exibe lista com os subtítulos “Bicicleta Nova” e“Roda Nova”.4) O Balconista aciona uma das opções.5) O sistema exibe relação com todos os componente necessá-rios para montagem do produto.6) O Balconista clica sobre um componente da relação e umaoutra relação se abre com todos os componentes semelhantesdisponíveis para que seja escolhido um, fazendo isso em cadaum dos componentes da lista principal até que o produto estejacompleto.7) O sistema abre opção para impressão.8) O sistema abre opção para que a relação seja enviada a ume-mail.


Pós-condições: As peças utilizadas para montagem do novo produto serão baixadas do estoque e o novo produto será incluído no es-toque.



33

3.3.3.17 NOME: CADASTRAR DE CLIENTE

Objetivo: Permitir ao Balconista incluir ao banco de dados da empresa cada um de seus clientes com seus dados pessoais e carac-terísticas.

Requisitos: RF9.

Atores: Balconista.



Fluxo Principal: 1) O sistema apresenta um menu de escolha única com os links para: “Cadastro de Clientes”; “Cadastro de Produtos”;“Cadastro de Fornecedores”; “Cadastro de Funcionários”. 2) O ator aciona o link “Cadastro de Clientes”.3) O sistema exibe página com campo para o CPF do cliente ebotão “Submeter”.4) O ator preenche o campo para o CPF e aciona o botão“Submeter”.5) O sistema exibe página com:- campos para nome, telefone, endereço, e-mail e tipo de rela-ção do cliente com a empresa (Compra de peças, compra debicicleta, solicitação de serviço);- Botões de rádio para informar se o cliente deseja receber avi-so de promoções;- menu de escolha múltipla para informar a forma de pagamen-to (dinheiro, cheque, cartão de crédito ou débito);- botão “Salvar”. 6) O ator preenche os dados e aciona o botão “Salvar”.


Pós-condições: O cliente estará cadastrado.


Extensões: Após o passo 4, caso o CPF já exista no sistema, o atorserá informado que o cliente já está cadastrado e será aberta a página de cadastro com os dados preenchidos.

3.3.3.18 NOME: GERIR FORNECEDORES (CADASTRAR)

Objetivo: Permite ao Comprador manter atualizados dados sobre os fornecedores de mercadorias para a empresa.

34


Atores: Comprador.



Fluxo Principal: 1) O sistema apresenta um menu de escolha única com os links para: “Cadastro de Clientes”; “Cadastro de Produtos”;“Cadastro de Fornecedores”; “Cadastro de Funcionários”. 2) O ator aciona o link “Cadastro de Fornecedores”.3) O sistema exibe página com campo para o CNPJ do cliente,botão “Submeter” e botão “Relatórios”.4) O ator preenche o campo para o CNPJ e aciona o botão“Submeter”.5) O sistema exibe página com;- campos para nome, telefone, endereço, e-mail, produtos ofe-recidos, nome do representante, telefone do representante e e-mail do representante;- botão “Salvar”.6) O ator preenche os dados e aciona o botão “Salvar”.

Fluxo Alternativo : Não há.

Pós-condições: O cliente estará cadastrado.


Extensões: Após o passo 4, caso o CNPJ já exista no sistema, o ator será informado que o fornecedor já está cadastrado e será aberta a página de cadastro com os dados preenchidos.

3.3.3.19 NOME: GERIR FORNECEDORES (RELATÓRIOS)

Objetivo: Permite ao Comprador manter atualizados dados sobre osfornecedores de mercadorias para a empresa.

Requisitos: RF21

Atores: Comprador



35

Fluxo Principal: 1) O sistema apresenta um menu de escolha única com os links para: “Cadastro de Clientes”; “Cadastro de Produtos”; “Cadastro de Fornecedores”; “Cadastro de Funcionários”. 2) O ator aciona o link “Cadastro de Fornecedores”.3) O sistema exibe página com campo para o CNPJ do cliente,botão “Submeter” e botão “Relatórios”.4) O ator aciona o botão “Relatórios”.5) O sistema abre página com menus de opções para o tipo derelatório de fornecedores desejado:- por CNPJ;- por nome;- por produtos oferecidos;- por nome do representante;e botão “Solicitar”.6) O ator aciona o botão “Solicitar”. 7) O sistema apresenta cada um dos fornecedores corres-pondestes a pesquisa.

Fluxo Alternativo : Não há.

Pós-condições: Será apresentado relatório.



3.3.3.20 NOME: COMPRAR

Objetivo: Manter em bom nível os estoques de mercadorias e garantir que os preços praticados pelos fornecedores sejam sempre competitivos.


Atores: Comprador, Balconista e Almoxarife.



Fluxo Principal: 1) O sistema apresenta um menu de escolha única com oslinks para: “Tabela de Preços”; “Cadastro de Produto”; “Mer-cadorias a Comprar”; “Relatórios”; “Montar Produto”.2) O ator aciona a opção “Mercadorias a Comprar”.3) O sistema exibe página com relação de mercadorias acomprar com:

36

- preço médio, preço na última compra, prazo médio para ven-da, possíveis fornecedores;- campos de texto para incluir produto na lista;- botão “Incluir”;- possibilidade de selecionar cada produto individualmente; - botão “Aguardando entrega” (envia produtos selecionadospara outra lista);- botão “Excluir selecionados”;





3.3.4 REGRAS DE NEGÓCIO

A seguir serão listadas Regras de Negócio indispensáveis ao funciona-mento do Sistema.

• RN1 - O usuário deve estar logado para ter acesso ao sistema.

• RN2 - Cada usuário logado terá acesso exclusivamente as páginas corres-pondentes a seu login.

• RN3 - Cada mercadoria terá um código único e exclusivo.

• RN4 - Cada serviço terá um código único e exclusivo.

• RN5 - Todo Cadastro de Funcionário deverá ter todos os campos preenchi-dos.

• RN6 - A Ordem de Serviço não pode ser executada sem autorização préviado cliente.

• RN7 - Ao perceber a procura de clientes por um determinado produto, qual-quer Ator pode solicitar ao Almoxarife que o inclua na Relação de Mercadoriasa Comprar.

37

• RN8 - Ao ser cadastrado, o funcionário receberá uma senha única e exclusivapara autenticação.

• RN9 - Sempre que houver a chegada de uma Nota Fiscal de compra serálançado um novo compromisso no Contas a Pagar.

• RN10 - Sempre que houver o pagamento de um título será excluído o com-promisso correspondente no Contas a Pagar.

• RN11- Sempre que houver a chegada de uma venda a prazo será incluído umcrédito no Contas a Receber.

• RN12 - Sempre que houver o recebimento de um crédito, este será excluídodo Contas a Receber.

• RN13 - Sempre que for realizada uma venda será aberto um link para emis-são de nota fiscal de venda ao consumidor.

• RN14 - Sempre que for realizada um serviço será aberto um link para emis-são de nota fiscal de serviço.

• RN15 - Sempre que chegar uma nova mercadoria ela será cadastrada.

• RN16 - Sempre que chegar uma mercadoria que já existe em estoque seu ca-dastro será atualizado.

38

4 ANÁLISE

4.1 ARQUITETURA DO SISTEMA

Neste ponto serão apresentados alguns itens para uma possível solução

para a estrutura de um software que atenda os requisitos apresentados no

Capítulo 2.

4.1.1 DIAGRAMA DE CLASSES

O diagrama de classes provavelmente é o diagrama mais utilizado da

UML2. Ele descreve a visão estática do sistema em termos de classes e relaciona-

mentos. Certamente este diagrama é o mais importante em uma documentação de

software, nele pode-se visualizar informações sobre como interagem as classes,

seus atributos e métodos.

O diagrama de classes representado pela Figura 4.1, é uma demonstra-

ção da estrutura e relações das classes que irão compor este sistema descrito por

17 classes, a saber:

• Fornecedor → Responsável pelo armazenamento de dados e métodos perti-nentes aos fornecedores.

• Pessoa → Responsável pelo armazenamento de dados pertinentes às pesso-as.

• Endereço →Responsável pelo armazenamento de dados pertinentes aos en-dereços de pessoas.

2UML (Unified Modeling Language) Linguagem Unificada de Modelagem.

39

• Representante → Responsável pelo armazenamento de dados e métodospertinentes aos representantes.

• Funcionário → Responsável pelo armazenamento de dados e métodos perti-nentes aos funcionários.

• Cliente → Responsável pelo armazenamento de dados e métodos pertinentesaos clientes.

• ContasPagar → Responsável pelo armazenamento de dados e métodos perti-nentes às contas a pagar.

• Contas Receber → Responsável pelo armazenamento de dados e métodospertinentes às contas a receber.

• Transação → Responsável por produzir documentação relativa a transaçõesentre funcionários e clientes.

• FonteRecursos → Responsável pelo tratamento e armazenamento de dadospertinentes ao faturamento da empresa.

• TabelaPreçosProdutos → Responsável por exibir dados pertinentes aos pro-dutos e serviços da empresa.

• ItemVenda → Auxiliar da classe Transação, responsável por dados dos produ-tos a venda.

• Serviço → Responsável pelo armazenamento de dados e métodos pertinen-tes aos serviços.

• Produto → Responsável pelo armazenamento de dados pertinentes aos pro-dutos.

• Peça → Responsável pelo armazenamento de dados e métodos pertinentesàs peças.

• Bicicleta → Responsável pelo armazenamento de dados e métodos pertinen-tes às bicicletas.

• Roda → Responsável pelo armazenamento de dados e métodos pertinentesàs rodas.

40

Figura 4.1: Diagrama de Classes

41

4.2 TECNOLOGIA

Com a finalidade de reduzir o custo inicial do projeto, preferencialmente

serão utilizadas tecnologias open source ou gratuitas. Sendo assim as tecnologias

usadas para o desenvolvimento do sistema, sites e banco de dados serão:

• Java Web;

• JavaScript;

• PostgreSQL;

• HTML.

42

CONCLUSÕES E TRABALHOS FUTUROS

O objetivo desta monografia é apresentar documentação pertinente ao

desenvolvimento de um sistema de informação que servirá como guia para a cons-

trução de um produto de software. Como este produto será bastante extenso, este

trabalho apresenta apenas a parte que tange a um produto menor, que tem por obje-

tivo abrir espaço para a introdução do produto completo no mercado.

Mesmo tratando-se apenas deste bloco menor, o ciclo de vida de desen-

volvimento prossegue, pois a noção geral é de um ciclo de vida incremental e evolu-

tivo e este é apenas um primeiro passo.

Um fato observado durante o desenvolvimento deste trabalho é o quanto

oneroso pode ser a construção de uma peça de software de boa qualidade, entre-

tanto, não e difícil perceber que essa qualidade e indispensável para que este produ-

to, como qualquer produto de software, seja bem sucedido.

Pretende-se implementar e implantar, inicialmente, a parte do software

proposta neste trabalho. Como trabalho futuro, tem-se como objetivo dar continuida-

de ao desenvolvimento deste projeto, que ao se completar, deverá ter como usuários

não somente lojistas, mas toda a cadeia produtiva ligada a bicicleta. Este projeto

completo pretende ter como principal atrativo a interatividade no setor.

Assim sendo, é de interesse do autor prosseguir em seus estudos, visando

obter maior conhecimento, afim de aprimorar este trabalho e também desenvolver

outros nesta área.

43

REFERÊNCIAS BIBLIOGRÁFICAS

1. ABRACICLO, Associação Brasileira dos Fabricantes de Motocicletas, Ciclomotores,

Motonetas, Bicicletas e Similares, http://www.abraciclo.com.br, acessado em 02 de maio

de 2016.

2. PFLEEGER, Shari Lawrence. Engenharia de Software – Teoria e Prática.

Prentice Hall do Brasil, 2a Edição, 2004.

3. Pressman, Roger S (2011). “Engenharia de software: uma abordagem

profissional”. 7ª edição. Porto Alegre: AMGH, 2011.

44

http://www.abraciclo.com.br/

universidade federal fluminense joÃo francisco …ƒo_francisco... · um sistema para dar apoio ao...

Documents