Modelagem - Sistema de Controle de Estoque

Prévia do material em texto

1 
 
 
UNIP – Universidade Paulista (Sede Fátima) 
Curso Técnico em Gestão da Tecnologia da Informação 
Disciplina: Modelagem de Sistemas de Informação 
Professor: Haelio Márcio Gomes Ferreira 
Aluno: Alexandre Norberto Barbosa 
Matr.: UP19119855 
 
 
 
 
 
SISTEMA DE CONTROLE DE ESTOQUE COM 
DIAGRAMAS DE CASO DE USO E DE CLASSES 
EMPRESA AVALIADA: JV BRASIL PURIFICADORES 
 
 
 
 
 
 
 
 
 
Fortaleza, CE 
Maio, 2020 
2 
 
ALEXANDRE NORBERTO BARBOSA 
 
 
 
 
 
 
 
 
 
 
 
SISTEMA DE CONTROLE DE ESTOQUE COM 
DIAGRAMAS DE CASO DE USO E DE CLASSES 
EMPRESA AVALIADA: JV BRASIL PURIFICADORES 
 
 
 
 
 
 
 
 
 
 
Fortaleza, CE 
Maio, 2020 
3 
 
 
 
 
 
 
 
 
 
Sumário 
 
1. Introdução 04 
2. Justificativa 05 
3. Objetivos 05 
3.1. Objetivos Gerais 05 
3.2. Objetivos Específicos 05 
4. Fundamentação Teórica – A Importância do Controle de Estoque 06 
5. Principais Dados do Projeto 07 
6. Principais Fases do Projeto 08 
7. Requisitos de Software 09 
8. Requisitos Funcionais 10 
9. Requisitos Não Funcionais 13 
10. Diagrama de Caso de Uso 14 
11. Especificação dos Casos de Uso 15 
12. Diagrama de Classes 20 
13. Diagramas de Atividade 21 
14. Diagramas de Transição de Estado 23 
15. Diagrama de Sequência 24 
16. Conclusão 25 
4 
 
 
 
 
 
 
 
 
1. Introdução 
 
O papel da tecnologia da informação (TI) tem mudado nos últimos anos, uma vez que seu uso como diferencial 
competitivo permite novas estratégias empresarias. Entretanto, no contexto das pequenas e médias empresas a 
TI é amplamente utilizada para resolução de questões operacionais, porém pouco aplicada como parte do 
processo de definição das estratégias empresariais. 
 
Estudos mostram que a incorporação de recursos tecnológicos alinhados à necessidade do negócio pode 
contribuir para que as pequenas e médias empresas obtenham vantagem competitiva frente aos seus 
concorrentes. Esse alinhamento evita a visão parcial das necessidades da organização e transforma as ações 
da área de TI em importantes aliadas à execução das estratégias de negócio. 
 
Dentre os modelos de serviços de Tecnologia da Informação que podem ser agregados as empresas está o de 
Softwares que podem ser inseridos para controlar e gerenciar praticamente todos os processos desenvolvidos 
dentro de qualquer modelo de negócios. Entre esses Softwares podemos citar os famosos ERPs, CRMs, SAPs 
e outras siglas bem conhecidas por seus produtos de excepcional qualidade e sofisticação, e que cobram um 
preço por isso, o que os torna aquém das possibilidades financeiras de muitas empresas. 
 
Entretanto, o mundo do Software não é feito somente de grandes nomes, existem também os pequenos e médios 
desenvolvedores, as chamadas “Software Houses” que desenvolvem pequenos aplicativos que executam tarefas 
especificas ou grupos de tarefas que são acessíveis aos pequenos e médios empresários. Entre essas 
aplicações, destacam-se os “Sistemas de Controle de Estoque” que será o assunto abordado neste trabalho. 
 
O Sistema em questão está em implantação na empresa onde trabalho, sendo parte dos dados aqui 
apresentados retirados da Documentação liberada pelo Desenvolvedor que gentilmente a cedeu para elaboração 
deste presente Trabalho da Disciplina de Modelagem de Sistemas de Informação do Curso de Gestão da 
Tecnologia da Informação da Universidade Paulista (UNIP). Por questões de sigilo, alguns nomes, incluindo o 
da Empresa não serão apresentados, sendo usado um nome fantasia para representa-la. 
5 
 
2. Justificativa 
A Internet é um dos meios de comunicação com maior crescimento nos últimos anos e assim evolui e se adapta 
cada vez mais as necessidades das pessoas. Surgem assim várias oportunidades de negócios voltada para 
empresas que buscam aumentar sua rentabilidade e também a qualidade de serviço a seus clientes. O B2C, 
sigla para “Business To Consumer” oferece então uma maneira de realizar negócios entre empresa e cliente 
onde o processo de transação do pedido é efetuado através do chamado “ambiente web” facilitando e agilizando 
vários processos de negociação. 
Isso facilita muito as vendas, uma vez que automatiza todo o processo e a negociação, tornando a transação 
transparente para ambos os lados do negócio. Então devemos presumir que seria bom as demais operações da 
empresa seguissem o mesmo caminho, automatizando seus processos de forma eficiente e transparente para 
os usuários, minimizando ao máximo as margens de erro e possibilitando que a gestão tenha um posicionamento 
o mais próximo possível da realidade das operações da Empresa. 
No presente trabalho iremos estudar um ponto especifico de uma operação de negócio, com caso de uma 
empresa que comercializa produtos de purificação e tratamento de água, a saber, bebedouros residenciais, 
comerciais, industriais e os insumos necessários para o correto funcionamento, tais como filtros, mangueiras de 
reposição, peças e acessórios. A empresa em questão também oferece assistência técnica, mas essa operação 
não será abordada no presente documento. 
3. Objetivos 
3.1. Objetivos Gerais 
Desenvolver um sistema com interface Web, ou seja, executada em navegadores comuns no mercado que 
permita aos colaboradores manusear o estoque de produtos, peças e insumos de forma simples e 
transparente, sendo o processo hospedado localmente em servidores de banco de dados dedicados e com 
backups locais e remotos. 
3.2. Objetivos Específicos 
 Definir as expressões e linguagens PHP; 
 Diagramação do Caso de Uso e Diagrama de Classes; 
 Estruturar o modelo de dados para o Sistema Gerenciador de Banco de Dados, que poderá ser o 
PostgreSQL ou o Microsoft SQL Server, rodando em uma plataforma Windows Server R2018; 
 Definir Técnicas de Mineração de Dados, a fim de oferecer aos Administradores do Sistema, índices 
de entrada e saída, no caso vendas de produtos, peças e insumos. 
6 
 
4. Fundamentação Teórica – A Importância do Controle de Estoques 
Os estoques têm papel importante nas empresas, pois funcionam como reguladores do fluxo dos negócios, 
como enfatizam Martins e Alt (2009). Os autores destacam que a necessidade de reposição dos estoques 
está relacionada à velocidade entre a entrada e a saída dos itens, ou seja, quanto maior o nível de saída, 
maior será a necessidade de entrada e quanto menor o nível de saída, menor será a necessidade do nível 
de entrada. Conseguir manter um nível constante entre a entrada e a saída de itens pode ser uma vantagem 
competitiva, pois, com isso, os estoques podem ser considerados praticamente nulos (filosofia just-in-time3). 
Segundo Martins (2008), quando comprar, quanto comprar, fixar lotes econômicos de aquisição e definir 
estoques mínimos de segurança são decisões que podem afetar os resultados de uma organização. 
Para Chopra e Meindl (2003), se a empresa não tiver o produto ou mercadoria para oferecer ao cliente, 
poderá obter um lucro menor, assim como, se mantiver estoques altos, correrá o risco de vendê-los com 
descontos e ter prejuízos. Conforme Beulke e Bertó (2001), os estoques das empresas industriais costumam 
se apresentar sob três formas: 
 Materiais adquiridos e ainda não utilizados; 
 Produtos em fase de elaboração; 
 Produtos prontos. 
Já para Martins e Alt (2009), os estoques são normalmente divididos em cinco grandes grupos: 
 Estoques de materiais – são os materiais utilizados no processo de transformação dos produtos 
acabados, mais conhecidos como matéria prima; 
 Estoques de produtos prontos em processo – são as matérias-primas que estão no processo 
produtivo, mas ainda não se transformaram em produtos acabados; 
 Estoques de produtos acabados – são os produtos prontos para comercialização; 
 Estoques em trânsito – são ositens que estão em trânsito entre as unidades fabris e ainda não 
chegaram a seu destino final; 
 Estoques em consignação – são os materiais ou produtos que ainda pertencem ao fornecedor até 
que sejam consumidos ou vendidos. 
Martins e Alt (2009) afirmam que a necessidade de as empresas se tornarem mais enxutas faz com que a 
participação da matéria-prima no custo dos produtos seja cada vez maior. Isso também faz com que a relação 
cliente-fornecedor seja uma relação de parceria, em que um ajuda o outro para que ambos tenham êxito nos 
seus negócios. Os autores ainda destacam que altos níveis de estoque podem ser importantes para a área 
comercial devido às questões como a flexibilidade na hora de vender e atender os clientes de forma imediata, 
porém trabalhar com estoques muito acima do ideal pode ser prejudicial para os negócios. 
Na visão de Beulke e Bertó (2001), o acompanhamento do fluxo de entrada, estocagem e consumo/saída 
dos estoques é algo básico e de suma importância, pois a falta desse controle pode ocasionar ociosidade 
dos estoques, desperdícios, maus usos, desvios, etc. Consequentemente isso se reflete em prejuízos para 
a organização, tais como o desembolso desnecessário de recursos financeiros para manutenção dos 
estoques, assim como possível perda de competitividade no mercado devido à influência direta nos custos 
dos produtos e mercadorias. 
 
7 
 
5. Principais Dados do Projeto 
 
5.1. Título do Projeto: 
Desenvolvimento de Software para Controle de Estoque da Empresa Brasil Purificadores Ltda. 
 
5.2. Patrocinador: 
Núcleo Gestor Financeiro da Empresa JV Brasil Purificadores 
 
5.3. Ambiente Responsável pelo Gerenciamento do Projeto: 
Setor de T.I. (Tecnologia da Informação) com consultoria da M2K Mobile Solutions 
 
5.4. Pessoal alocado no Projeto: 
Gerente de Projetos Coordenador Técnico Analistas de Sistemas 
Desenvolvedores Equipe de Testes analista de Negócios 
 
5.5. Resumo do Projeto: 
Desenvolvimento e posterior implantação de Software de Sistema de Controle de Estoque para 
informatização do gerenciamento de produtos, peças e insumos da JV Brasil Purificadores. 
 
5.6. Motivação: 
A empresa utiliza um sistema antigo baseado em DOS, herdado de outra empresa, o qual se 
mostra ineficiente complexo e limitado para a realidade atual do mercado. 
 
5.7. Produto deste Projeto: 
A empresa irá receber um Software de Sistema de Controle de Estoque atualizado, modular, de 
fácil interação e manutenção, bem como treinamento de usuários e documentação do sistema. 
 
5.8. Cronograma do Projeto: 
A estimativa é que o projeto tenha duração de aproximadamente quatro (04) meses, prevendo uma 
jornada diária das equipes de 8h/d de segunda a sexta. 
 
5.9. Premissas do Projeto: 
Desenvolvimento em plataforma Open Source. 
Implantação em Servidores Open Source (Linux) ou Proprietário (Windows Server) 
 
5.10. Necessidade de Suporte da Empresa Cliente: 
Profissional Certificado em JAVA (SCJP) para dar suporte interno durante e após a implantação do 
Sistema, sendo que o mesmo deverá se possível acompanhar o desenvolvimento do Projeto. 
 
8 
 
6. Principais Fases do Projeto 
 
6.1. Fase I – Levantamento de Requisitos: 
Documentos de Especificação: Elaboração de Questionários, Realização de Entrevistas e 
Homologação dos Documentos de Especificação. 
 
6.2. Fase II – Análise de Requisitos: 
Documentos de Análise de Requisitos: Análise das Regras de Negócios, Elaboração do 
Diagrama UML (Caso de Uso, Classes e Atividades), Definição da Modelagem do Banco de 
Dados, Elaboração e Homologação do Documento de Análise de Requisitos. 
 
6.3. Fase III - Implementação: 
Código Fonte do Sistema: Instalação da plataforma de Desenvolvimento e Implementação do: 
 Módulo de Cadastro de Usuários; 
 Módulo de Cadastro de Produtos; 
 Módulo de Cadastro de Entrada de Produtos; 
 Módulo de Cadastro de Saída de Produtos. 
 
Desenvolvimento do Design da Aplicação (Telas) e Integração das Camadas da Aplicação. 
 
6.4. Fase IV - Testes: 
Sistema Testado e Plotagem do Relatório de Erros. Testes efetuados nos seguintes itens: 
 Módulo de Cadastro de Usuário. 
 Módulo de Cadastro de Produto. 
 Módulo de Cadastro de Entrada de Produto. 
 Módulo de Cadastro de Saída de Produto. 
Elaboração e Homologação do Relatório de Erros 
6.5. Fase V - Implantação: 
 Software instalado; 
 Manual do Usuário Documentado e entregue; 
 Treinamento de Usuários certificado. 
 
9 
 
7. Requisitos de Software 
Requisitos é um termo utilizado em todas as áreas, e que de uma forma geral descreve uma necessidade ou 
desejo, às vezes pessoal, às vezes de uma organização. Tais desejos nem sempre são explícitos, documentados 
ou até mesmo claro para quem o deseja. 
É necessário muito diálogo e discussão sobre os Requisitos. Identificar e definir os requisitos, um papel que na 
área de informática é exercida pelo Analista de Requisitos e requer compreender as necessidades e o querer do 
negócio. 
Podemos dizer então Requisitos são as ações que o software deve executar, possuindo características e 
condições próprias, de forma a automatizar uma tarefa de um processo de negócio. Aqui definimos os requisitos 
funcionais e não funcionais, e, conforme o método IRON, Requisitos de Dados e Regras de Execução. 
Antigamente dizia-se que requisitos eram sinônimos de funções, ou seja, tudo que o software deveria fazer 
funcionalmente. No entanto, atualmente assumiu-se que requisitos de software é muito mais do que apenas 
funções. Requisitos são, além de funções, objetivos, propriedades, restrições que o sistema deve possuir para 
satisfazer contratos, padrões ou especificações de acordo com o (s) usuário (s). 
De forma mais geral um requisito é uma condição necessária para satisfazer um objetivo. Portanto, um requisito 
é um aspecto que o sistema proposto deve fazer ou uma restrição no desenvolvimento do sistema. 
Vale ressaltar que em ambos os casos devemos sempre contribuir para resolver os problemas do cliente e não 
o que o programador ou um arquiteto deseja. Dessa forma, o conjunto dos requisitos como um todo representa 
um acordo negociado entre todas as partes interessadas no sistema. Isso também não significa que o 
programador, arquiteto ou um analista bem entendido no assunto de tecnologia não possam contribuir com 
sugestões e propostas que levem em conta o desejo do cliente. Além disso, ainda temos um documento de 
requisitos que é uma coleção dos requisitos. 
Por fim, os requisitos possuem alguns objetivos centrais como estabelecer e manter uma concordância com os 
clientes e outros envolvidos sobre o que o sistema deve fazer, deve oferecer aos desenvolvedores, projetistas e 
testadores do sistema uma compreensão melhor dos requisitos do sistema, definir fronteiras do sistema definindo 
o que deve ser incluído e o que não deve fazer parte do sistema e assim oferecer uma base para estimar o custo 
e o tempo de desenvolvimento do sistema e por fim definir uma interface de usuário para o sistema. 
Existem dois tipos de classificação de requisitos, são eles: Requisitos Funcionais (RF) e Requisitos Não-
Funcionais (RNF). Os requisitos funcionais referem-se sobre o que o sistema deve fazer, ou seja, suas funções 
e informações. 
Os requisitos não funcionais referem-se aos critérios que qualificam os requisitos funcionais. Esses critérios 
podem ser de qualidade para o software, ou seja, os requisitos de performance, usabilidade, confiabilidade, 
robustez, etc. Ou então, os critérios podem ser quanto a qualidade para o processo de software, ou seja, 
requisitos de entrega, implementação, etc. 
Evidentemente que as prioridades podem variar conforme a natureza do software. Isso quer dizer que um 
software para uma plataforma de celular terá diferentes requisitos de um software que roda num browser na web. 
Assim como um software de tempo real que precisa ser executado em 1 segundo é diferentede outro software 
que pode ter um tempo maior para execução de uma determinada tarefa. 
 
Portanto, Requisitos Funcionais preocupam-se com a funcionalidade e os serviços do sistema, ou seja, as 
funções que o sistema deve fornecer para o cliente e como o sistema se comportará em determinadas situações. 
 
Já, os Requisitos Não Funcionais definem propriedades e restrições do sistema como tempo, espaço, 
linguagens de programação, versões do compilador, SGBD, Sistema Operacional, método de desenvolvimento, 
etc. Uma dica importante é que os requisitos não funcionais são geralmente mensuráveis e assim devemos 
preferencialmente associar uma medida ou referência para cada requisito não funcional. 
 
10 
 
8. Requisitos Funcionais 
Dentro da Categoria de Requisitos Funcionais, os seguintes itens foram levantados pela equipe de 
desenvolvimento do Projeto junto ao Cliente. 
8.1. RQF 001 – Manter Usuário 
O sistema deve permitir realizar operações de consulta, inserção, atualização e exclusão dos dados dos usuários. 
Cada usuário terá um Login e Senha de Acesso ao sistema, além de um perfil. 
8.2. RQF 002 – Características de Usuário 
O software deve organizar os usuários do sistema em 3 grupos a seguir descritos: 
8.2.1. Administrador 
Neste grupo de usuário estão todos aqueles responsáveis pelas operações administrativas do sistema, tendo 
acesso completo a todas as funcionalidades. 
8.2.2. Usuário Padrão 
Neste grupo de usuário estão aqueles responsáveis pelas operações padrões do sistema, tendo acesso de 
inserção e atualização de alguns dados, porém não sendo permitida a exclusão de informações. Neste caso, o 
próprio caso de uso determinará os privilégios de acesso para este grupo de usuários. 
8.2.3. Usuário Restrito 
Neste grupo de usuário estão aqueles que necessitam visualizar certas informações do sistema, sem direitos de 
criação, alteração ou exclusão de dados. Neste caso, o próprio caso de uso determinará os privilégios de acesso 
para este grupo de usuários. 
8.3. RQF 003 – Manter Produtos 
Os produtos consistem em todos os itens que o sistema irá controlar separando-os em Bens permanentes e 
Bens de consumo, assim possibilitando o Tombamento. 
8.4. RQF 004 – Manter Tombamento 
O tombamento é um identificador único que é gerado pelo sistema com um código alfa numérico que será 
cruzado com o código do produto para que haja um controle dos bens permanentes. 
8.5. RQF 005 – Manter Pedido 
Os pedidos consistem na gravação dos itens solicitados do pedido. Deve-se guardar a data e hora do pedido e 
o respectivo funcionário que fez o pedido. 
8.6. RQF 006 – Faturar Pedidos 
Os pedidos dos produtos em falta no estoque poderão ser enviados já faturados para o Sistema de Faturamento 
da Empresa. 
8.8. RQF 007 – Manter Ajustes 
Os ajustes consistem em um controle de devolução dos produtos de consumo para que se possa ajustar os itens 
de estoque. 
11 
 
8.8. RQF 008 – Manter Fornecedor 
Deve-se ter um cadastro de todos os fornecedores dos produtos. Podendo incluir, excluir e alterar este cadastro. 
8.9. RQF 009 – Relatório de Balanço semestral 
O Relatório de Balanço deverá ser informado de acordo com o período solicitado pelo Setor Comercial, para 
comparação e metas de vendas. 
8.10. RQF 010 – Relatório de Balanço anual 
Esse é emitido para conferencia e balanço (contagem) ano a ano. Pois normalmente nesse intervalo de tempo 
existe uma rotatividade de funcionários. 
8.11. RQF 011 – Validação do Fornecedor 
Para a efetivação do cadastro do Fornecedor deverá ser feita a validação do CNPJ do fornecedor. 
8.12. RQF 012 – Relatório Validação do Fornecedor 
Para a efetivação do cadastro do Fornecedor deverá ser feita a validação do CNPJ do fornecedor. 
8.13. RQF 013 – Relatório de Divergência 
Para a comparação de número de estoque de os usuários (padrão, administrador), assim dando informações 
homogêneas de produtos. 
8.14. RQF 014 – Relatório de produtos recebidos por período 
Geração de produtos que deram entrada ou saída com base em uma data ou intervalos de datas. 
8.15. RQF 015 – Relatório de Produtos por Descrição 
Nesse é emitido um estoque mais analítico de produtos, permitindo saber quais produtos tem mais ou menos 
entrada e/ou saída. 
8.16. RQF 016 – Relatório de Produtos Devolvidos 
Esses são emitidos para produtos com uma grade frequência de devoluções seja por defeitos ou por erro de 
quantidades. 
8.18. RQF 017 – Relatório de Bens Tombados 
O relatório de bens tombados traz um demonstrativo dos bens que se tornaram patrimônio da empresa. 
8.18. RQF 018 – Relatório de Bens Doados 
O relatório de bens doados com a descrição do bem patrimonial que foi doado, e nome dos que os receberam. 
8.19. RQF 019 – Relatório de Usuários e Permissão 
O relatório de usuário e permissão, mostra a prioridade de acesso dos usuários e suas atribuições. 
8.20. RQF 020 – Relatório de Fornecedor por Faturamento 
No Relatório de fornecedor for faturamento, é mostrado o valor do faturamento mensal de cada fornecedor em 
ordem crescente, com base no valor. 
12 
 
8.21. RQF 021 – Relatório de Notas Fiscais Estornadas 
O Relatório mostra todas as Notas Fiscais estornadas, de qualquer natureza. 
8.22. RQF 022 – Relatório de Produtos por Fabricantes 
O Relatório demonstra uma listagem dos produtos divididos em grupos de cada fabricante. 
8.23. RQF 023 – Relatório de Pedidos Faturados 
O Relatório mostra os pedidos faturados, por fornecedor e/ou por intervalo de datas. 
8.24. RQF 024 – Cadastro de Produtos Defeituosos 
Tela que recebe as informações de todos os produtos recebidos com defeitos de fábrica. 
8.25. RQF 025 – Relatório de Acesso/Atividade no Sistema 
Este relatório possibilita ao Administrado do Sistema visualizar todos os acessos e atividades executadas por 
todos os usuários. 
 
 
13 
 
9. Requisitos Não Funcionais 
Dentro da Categoria de Requisitos Não Funcionais, os seguintes itens foram levantados pela equipe 
de desenvolvimento do Projeto junto ao Cliente. 
9.1. RNF 01 - Padronização dos Cadastros 
Todos os cadastros do sistema deverão obedecer um mesmo padrão de usabilidade, os quais permitam: 
 Acesso direto ao registro pelo seu ID; 
 Acesso ao registro através de uma Pesquisa avançada; 
 Operação de Inserir, permitindo a inserção de um novo registro; 
 Operação de Alterar, permitindo a alteração do registro selecionado; 
 Operação de Excluir, permitindo a exclusão do registro selecionado; 
 Operação de Salvar, permitindo a conclusão do processo de inserção ou de alteração, persistindo os dados; 
 Operação de Cancelar, permitindo a desistência do processo de inserção ou de alteração, descartando os 
dados até então inseridos; 
 Operação de Fechar, permitindo a saída da tela de cadastro; 
A tela de Pesquisa Avançada deverá ser padrão para todos os cadastros, permitindo filtragem por qualquer 
campo do registro, de 3 formas: 
 Início: somente registros cujo campo selecionado inicia com o valor informado são retornados; 
 Meio: somente registros cujo campo selecionado contém o valor informado são retornados; 
 Fim: somente registros cujo campo selecionado termina com o valor informado são retornados; 
Se algum dos campos do registro for uma data, a pesquisa avançada ainda permitirá a filtragem de registros 
através do fornecimento de um intervalo de datas, através do qual será possível filtrar registros cujo campo de 
data selecionado esteja no dado intervalo. 
9.2. RNF 02 – Acesso a dados via ODBC 
Todo acesso a dados deverá ser realizado via ODBC de forma a reduzir o acoplamento entre código e banco de 
dados instalado (BD). 
9.3. RNF 03 - Manual de Instalação 
O sistema deve vir acompanhado com um manual de instalação em formato PDF de distribuição, com um original 
em formato .docx padrão do Microsoft Word. 
9.4. RNF 04 - Manual de Usuário 
O sistema deve vir acompanhado com um manual de operação para o usuário final, em formato PDF de 
distribuição,com um original em formato .docx do Microsoft Word. 
9.5. RNF 05 - Acesso autenticado 
Todo acesso ao sistema deverá ser autenticado através do fornecimento de Login e Senha válidos. Tais dados 
de acesso deverão estar armazenados no banco de dados da aplicação. 
 
14 
 
9.6. RNF 06 - Senhas criptografadas 
As senhas dos usuários da aplicação devem ser armazenadas de forma criptografada no banco de dados da 
aplicação. 
9.7. RNF 07 - Ambiente 
O sistema, composto de 2 partes, tem os seguintes requisitos de ambiente: 
 Aplicação Cliente deverá ter como alvo principal o Windows 10 Home, com .NET 4.0 ou superior instalado; 
 Banco de Dados: Deverá ser empregado qualquer sistema operacional que suporte o padrão “Oracle 8i” 
O Sistema deverá funcionar em qualquer rede TCP/IP que permita comunicação remota através de ODBC da 
Aplicação Cliente ao Servidor de Banco de dados. Quaisquer Firewalls devem ser configurados para permitir 
essa comunicação. 
9.9. RNF 08 - Hardware 
O sistema, composto de 2 partes, tem os seguintes requisitos de hardware: 
 Aplicação Cliente: Mínimo de 128mb de Memória livres para a operação do sistema; 
 Banco de Dados: Os mesmos requisitos de hardware do Oracle 8i. 
9.9. RNF 09 - Ferramentas de Desenvolvimento 
O sistema deverá ser desenvolvido utilizando o Visual Studio 2015, aproveitando suas funcionalidades de testes 
de unitários e cobertura de código. Para banco de dados, será utilizado o Microsoft SQL Server, com Backup e 
Migração para o PostgreSQL no futuro a critério do Cliente. 
9.10. RNF 10 - Crystal Reports 
O sistema fará uso do “Crystal Reports for Visual Studio 2015” para a geração dos relatórios, permitindo assim 
a exportação dos relatórios para formatos XLS e PDF. 
10. Diagrama de Caso de Uso 
 
15 
 
11. Especificação dos Casos de Uso 
 
11.1. Especificação: CSU 01- Manter Produto 
Objetivo 
O operador usa o sistema para controlar os produtos do estoque, e os bens permanentes na entrada, saída, 
estorno e tombamento. 
Atores Envolvidos 
Usuário Padrão e Administrador do Sistema (SysAdmin) 
Pré-Condições 
O produto à ser cadastrado, deve ser oriundo de uma Nota Fiscal válida, ou seja, de um Fornecedor cadastrado. 
Fluxo Principal 
1. O operador faz Logon no Sistema. 
2. O operador escolhe no menu qual ação deve ser realizada: 
 Alterar 
 Incluir 
 Excluir. 
3. Se o operador escolher a opção “Alterar”: 
3.1.É solicitado código do produto para que seja efetuada a sua devida alteração. 
3.2. Após feita a alteração, os novos dados são salvos. 
4. Se o operador escolher a opção “Excluir”: 
4.1.É solicitado o código do produto para que seja efetuada a sua devida exclusão. 
4.2. Após a exclusão, o cadastro do produto é apagado do sistema. 
5. Se o operador escolher a Opção Incluir: 
5.1 O sistema solicita os dados do novo produto. 
5.2 O sistema verifica se o fornecedor do produto já é cadastrado no sistema. 
5.3 Depois de validado o produto, o produto é incluído no estoque. 
6. O sistema registra as informações fornecidas. 
Pós Condições 
O Sistema deve mostrar a quantidade do produto no estoque. 
 
16 
 
11.2. Especificação: CSU 02 - Manter Fornecedor 
Objetivo 
O operador usa o sistema para fazer a inclusão, exclusão e alteração no cadastro de Fornecedores. 
Atores Envolvidos 
Usuário Padrão e Administrador do Sistema (SysAdmin). 
Pré-Condições 
O usuário deve ser identificado pelo sistema. 
Fluxo Principal 
1. O operador faz Logon no Sistema. 
2. O operador escolhe no menu qual ação deve ser realizada: 
 Alterar 
 Incluir 
 Excluir. 
3. Se o operador escolher a opção “Alterar”: 
3.1. É solicitado o CNPJ do fornecedor para que seja efetuada a sua devida alteração. 
3.2. Após feita a alteração, os novos dados são salvos. 
4. Se o operador escolher a opção “Excluir”: 
4.1. É solicitado o CNPJ do fornecedor para que seja efetuada a sua devida exclusão. 
4.2. Após a exclusão, o cadastro do fornecedor é apagado do sistema. 
5. Se o operador escolher a Opção “Incluir”: 
5.1.O sistema solicita os dados do novo fornecedor. 
5.2.O sistema verifica se o CNPJ do fornecedor é um número válido. 
5.3.O fornecedor é incluso no cadastro de fornecedores. 
6. O Sistema registra as informações fornecidas. 
Pós Condições 
O fornecedor foi cadastrado, alterado ou excluído no sistema. 
17 
 
11.3. Especificação: CSU_03 - Manter Usuário 
Objetivo 
O Administrador usa o sistema para fazer a inclusão, exclusão e alteração dos usuários do sistema e suas 
devidas prioridades de acesso. 
Atores Envolvidos 
Administrador do Sistema (SysAdmin). 
Pré-Condições 
O usuário deve ser identificado pelo sistema. 
Fluxo Principal 
1. O operador faz Logon no Sistema. 
2. O operador escolhe no menu qual ação deve ser realizada: 
 Alterar 
 Incluir 
 Excluir. 
3. Se o operador escolher a opção “Alterar”: 
3.1. É solicitado o nome do usuário para que seja efetuada a sua devida alteração. 
3.2. Após feita a alteração, os novos dados são salvos. 
4. Se o operador escolher a opção “Excluir”: 
4.1. É solicitado o nome do usuário para que seja efetuada a sua devida exclusão. 
4.2. Após a exclusão, o cadastro do fornecedor é apagado do sistema. 
5. Se o operador escolher a Opção “Incluir”: 
5.1. O sistema solicita os dados do novo usuário. 
5.2. É escolhida a prioridade de acesso ao sistema: 
 Usuário Padrão 
 Usuário Restrito 
 Administrador 
5.3. É definida senha de acesso. 
6. O sistema registra as informações fornecidas. 
Pós Condições 
O usuário foi cadastrado, alterado ou excluído no sistema. 
 
18 
 
11.4. Especificação: CSU 04 - Consultar Produto 
Objetivo 
O operador usa o sistema para consultar os produtos do estoque, e os bens permanentes na entrada, saída, 
estorno e tombamento. 
Atores Envolvidos 
Usuário Restrito, Usuário Padrão e Administrador do Sistema. 
Pré-Condições 
O usuário deve ser identificado pelo sistema. 
Fluxo Principal 
1. O operador faz Logon no Sistema. 
2. O sistema solicita informações do produto à ser consultado. 
3. O usuário faz a digitação dos dados do produto. 
4. A consulta é realizada e as informações do produto são exibidas na tela. 
5. O sistema oferece ao usuário a opção de impressão. 
6. O sistema fecha a tela de exibição. 
Pós Condições 
A consulta ao produto foi realizada. 
11.5. Especificação: CSU 05 - Consultar Fornecedor 
Objetivo 
O operador usa o sistema para consultar os Fornecedores da empresa. 
Atores Envolvidos 
Usuário Restrito, Usuário Padrão e Administrador do Sistema. 
Pré-Condições 
O usuário deve ser identificado pelo sistema. 
Fluxo Principal 
1. O operador faz Logon no Sistema. 
2. O sistema solicita CNPJ do fornecedor à ser consultado. 
3. O usuário faz a digitação dos dados do fornecedor. 
4. A consulta é realizada, e os dados do fornecedor são exibidos na tela. 
5. O sistema oferece ao usuário a opção de impressão. 
6. O operador fecha a tela de exibição. 
Pós Condições 
A consulta aos dados do fornecedor foi realizada. 
19 
 
11.6. Especificação: CSU 06 - Gerar Relatório para Balanço 
Objetivo 
O operador usa o sistema para gerar um relatório para balanço, de todos os produtos do estoque. 
Atores Envolvidos 
Setor Comercial 
Pré-Condições 
O usuário deve ser identificado pelo sistema. 
Fluxo Principal 
1. O operador faz Logon no Sistema. 
2. O sistema solicita a data ou período. 
3. O usuário faz a digitação do período. 
4. O relatório é exibido na tela. 
5. O sistema oferece ao usuário a opção de impressão. 
6. O operador fecha a tela de exibição. 
Pós Condições 
O relatório para balanço por período, foi gerado. 
 
20 
 
12. Diagrama de Classes 
 
 
 
 
21 
 
13. Diagramas de Atividade 
 
13.1. DA 01 – CASO DE USO MANTER USUÁRIO 
 
13.2. DA 02 – CASO DE USO MANTER FORNECEDOR 
 
22 
 
13.3. DA 02 – CASO DE USO GERAR RELATÓRIO PARA BALANÇO23 
 
14. Diagramas de Transição de Estado 
 
14.1. DTE 01 – MANTER TOMBAMENTO 
 
14.2. DTE 02 – MANTER AJUSTE 
 
 
14.3. DTE 03 – MANTER CONSULTAR PRODUTO 
 
24 
 
 
15. Diagramas de Sequência 
 
15.1. DS 01 – MANTER USUÁRIO 
 
 
15.2. DS 02 – CONSULTAR PRODUTO 
 
 
25 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
CONCLUSÃO 
 
Podemos concluir que, a Internet é um dos meios de comunicação com maior crescimento nos últimos anos, 
cada vez mais pessoas procuram usufruir das facilidades da grande rede, tendo em vista a agilidade e eficiência 
do processo. A informação está cada vez mais acessível as pessoas, com os avanços globais da tecnologia o 
uso de computadores é praticamente inevitável, assim com esta popularização, a Internet também ganhou seu 
espaço, e hoje em dia os programadores procuram explorar com maior frequência este recurso, sendo assim é 
comum ver vários sistemas rodando em ambiente web. 
A facilidade das linguagens de programação como o PHP, e linguagens de marcação e formatação de texto 
como o CSS e HTML respectivamente, proporcionam ao desenvolvedor um ambiente amigável de programação 
onde é possível localizar facilmente os códigos de acordo com os padrões web. 
Como consequência o desenvolvimento de um sistema web torna-se menos trabalhoso e de fácil implantação. 
Tendo em vista o projeto apresentado, os usuários poderão através de um ambiente web, controlar o estoque da 
empresa de forma simples e transparente, usando uma interface de fácil leitura e entendimento, minimizando a 
curva de aprendizado. 
Da mesma forma, os Gestores poderão ter dados sobre a movimentação de produtos e itens diversos no estoque, 
ou seja, as entradas e saídas, devolução e doação desses itens, através de relatórios gerenciais gerados de 
forma simples, com uma ampla capacidade modular do banco de dados visando a ampliação das operações e 
implementação de novos recursos.