REPÚBLICA DE ANGOLA

INSTITUTO POLITECNICO PRIVADO ULUMBO

CURSO TÉCNICO DE INFORMÁTICA

PROVA DE APTIDÃO PROFICIONAL

13ª CLASSE

SISTEMA DE GESTÃO DE ESTOQUE PARA MERCADOS SGM

LÉURIO ANDRÉ

RAFAEL TAVARES

ELIZANDRO MIGUEL

JOSÉ MANUEL

LUANDA, 2021/2022
 INSTITUTO POLITECNICO PRIVADO ULUMBO

CURSO TÉCNICO DE INFORMÁTICA

PROVA DE APTIDÃO PROFICIONAL

13ªCLASSE

SISTEMA DE GESTÃO DE ESTOQUE PARA MERCADOS SGM

GRUPO Nº 07

LÉURIO ANDRÉ

RAFAEL TAVARES

ELIZANDRO MIGUEL

JOSÉ MANUEL

I13T

TURNO: TARDE

ORIENTADOR: LAURIANO MANUEL

DEDICATÓRIA
Dedicamos essa trabalho aos nossos encarregados de educação, que nos apoiaram moralmente
e economicamente, desde o momento que começamos a cursar na instituição todo o nosso
esforço e dedicação foi para compensar o vosso esforço e dedicação para connosco.

Dedicamos também aos nossos professores, que sempre nos apoiaram. A todos que directa ou
indirectamente nos deram a sua força.

i
AGRADECIMENTOS

Agradecemos primeiramente a Deus pelo fôlego de vida, porque se nós chegamos

aqui é porque o senhor permitiu, é sabido que a vida não é previsível, mas com o senhor tudo
é possível.

Agradecemos aos nossos pais pelo empenho a nossa formação acádemica , e por nos
apoiarem na realização dos nossos sonhos. Eles não medem esforço quando se trata da nossa
educação, e nós somos gratos por tudo isso e muito mais. Vocês são os melhores!

Aos nossos professores do curso de informática pelos ensinamentos transmitidos ao

longo desse tempo todo.

Ao nosso tutor Lauriano Manuel pelas dicas e motivação na realização desse projecto.

ii
SiglaS e Abreviaturas
SGM – ( Sistema de Gestão de Mercado )

HTML – ( Hyper Text Markup Language )

RUP – ( Rational Unified Process )

UML – ( Unified Modelling Language )

PMBOK – ( Project Management Body of Knowledge )

MVC – ( Model View Controller )

ADM – ( Administrador )

iii
ÍNDICE DE FIGURAS

Figura 01 - Diagrama de Caso de Uso de Negócio. ...................................21

Figura 1 - Diagrama De Caso De Uso Do Sistema .............23

Figura 2- Diagrama De Classe .............................................26
Figura 04 - Diagrama de Classe de Análise ..................................... 27

Figura 05 pagina inicial ............................................................................... 29

Figura 06 de cadastro de categoria ...............................................................29

Figura 07 Cadastro de produto ....................................................................30

Figura 08 cadastro e cliente ........................................................................30

Figura 9 - Estrutura Do Menu .........................................................31

Figura 10 - Diagrama De Implantação ..........................................38

Figura 11 – extractos de código ..................................................40

iv
v
ÍNDICE DE TABELAS

Tabela 1 – Materias Necessários.....................................................................................pag 14

Tabela 2 – Custos gerais.................................................................................................pag 14

Tabela 3 – Principais utilizadores do sistema.................................................................pag 18

Tabela 4 – Descrição dos atores do caso de uso do negócio...........................................pag 12

Tabela 5 – Especificação do caso de uso fazer login.......................................................pag 24

Tabela 6 – Especificação do caso de uso fazer cadastro...................................................pag 25

Tabela 7 – Ferramentas utilizados ...................................................................................pag 34

vi
ÍNDICE
DEDICATÓRIA...................................................................................i
AGRADECIMENTOS........................................................................ii
SiglaS e Abreviaturas.......................................................................iii
ÍNDICE DE FIGURAS......................................................................iv
ÍNDICE DE TABELAS......................................................................v
SUMÁRIO....................................................................................viii
INTRODUÇÃO..............................................................................7
JUSTIFICATIVA.............................................................................8
OBJECTIVO....................................................................................8
OBJECTIVO GERAL.......................................................................8
OBJECTIVOS ESPECÍFICOS..........................................................8
GESTÃO DE ESTOQUE..................................................................9
GESTÃO DE SAÍDA.......................................................................9
GESTÃO DE ENTRADA.................................................................9
METODOLOGIA UTILIZADA........................................................9
METODOLOGIA PARA OBTENÇÃO DOS REQUISITOS DO
SISTEMA......................................................................................10
ESTRUTURA DO TRABALHO.....................................................10
CAPÍTULO I - DOMÍNIO DO PROBLEMA...................................11
DELIMITAÇÃO DO ESTUDO...................................................12
OBJECTO DE ESTUDO.............................................................12
OBJECTIVO DA INSTITUIÇÃO................................................12
UTILIZADORES........................................................................12
ÁREAS DE AUTOMATIZAÇÃO................................................12
SITUAÇÃO ATUAL..................................................................13
PROBLEMA A SEREM RESOLVIDOS......................................13
SOLUÇÃO PROPOSTA.............................................................13
ORÇAMENTO..........................................................................14
CAPÍTULO II - ANÁLISE DE REQUISITOS.................................16
vii
 DIAGRAMA DE CLASSE.............................................................26
DIAGRAMA DE SEQUÊNCIA......................................................27
FLUXO DE TRABALHO: ANÁLISE..............................................27
DIAGRAMA DE CLASSE DE ANÁLISE.......................................27
CAPÍTULO III – DESENHOS............................................................28
ESTRUTURA DO MENU..........................................................29
MODELO LÓGICO DE DADOS.................................................31
CAPÍTULO IV - TECNOLOGIA E FERAMENTAS UTILIZADAS 33
CAPÍTULO V – IMPLEMENTAÇÃO.............................................36
5.1.1. Fase De Construção.........................................................37
CONCLUSÃO...............................................................................41
GLOSSÁRIO.................................................................................42
APÊNDICE...................................................................................44

viii
 SUMÁRIO

O presente projecto tem como tema Desenvolvimento de um Sistema de Gestão De

Estoque, que aborda sobre a criação de um sistema de gestão de produtos e matérias prima.
Ele traz consigo resoluções de problemas identificados actualmente nos mercados informais
localizados nas nossas comunidades.

O SGM surge com o intuito de inovar a capacidade de gestão nos mercados de vendas
informais. A importância do controle de estoque para mercado é simples: um controle de
estoque bem feito garante que você sempre vai ter nas suas prateleiras os produtos que o seus
clientes estão procurando. Além disso, você sempre vai saber com antecedência quais
produtos precisa repor e quando é o melhor momento para contatar os seus fornecedores.

Prática essa chamada de upgrade de algum ambiente de desenvolvimento,sendo a nova

versão capaz de resolver problemas que a anterior não foi capaz de resolver.

Palavras-Chave: SGM, PRODUTO e VENDA.

ix
INTRODUÇÃO

Os estoques são acumulações de recursos materiais, processados ou não, em um

sistema de transformação. Estas acumulações são necessárias uma vez que a demanda e a
capacidade de fornecimento não são plenamente harmoniosas.

O objetivo principal de uma empresa(Loja, mercado) é, sem dúvida, maximizar o

lucro sobre o capital investido, sejam em financiamentos de vendas, reserva de estoques. Para
atingir lucro máximo, ela deve usar o capital da melhor forma possível para que não
permaneça inactivo. Espera-se, então, que o dinheiro investido em estoques seja o
componente necessário para produção e o atendimento das necessidades da empresa (Loja).
Os estoques ocupam espaço e necessitam de gerenciamento tanto na entrada como na saída.

Um dos grandes desafios enfrentados atualmente pelos administradores das empresas,

independente do porte se refere ao equilíbrio dos estoques com a demanda. O sucesso ou
fracasso de muitas organizações encontra-se através da gestão de estoque, que é constituída
por administração de materiais, recursos humanos e financeiros.

7
JUSTIFICATIVA
A gestão de estoques tornou-se fundamental para os resultados financeiros e
competitivos da organização. Por envolver várias áreas como vendas, produção, compras e
contabilidade essa atividade é bastante complexa devido à dificuldade de coordenação. Na
maioria das empresas, os estoques são o principal foco de problemas por isso se torna
necessário o seu estudo.

OBJECTIVO
Com a Elaboração deste projecto, procura-se melhorar (facilitar) o gerenciamento de
estoques de pequenos mercados, lojas e micro-empresas, com a criação de um sistema
Desktop para gerenciamento de estoque, mudando de forma inovadora e utilizando recursos
que melhoram o seu funcionamento.

OBJECTIVO GERAL
Este trabalho tem como objectivo geral desenvolver um Sistema De Gestão De
Estoque De Mercado a partir de algo já existente.

OBJECTIVOS ESPECÍFICOS
 Recolher informações úteis para análise das mesmas;
 Elaborar os deagramas dos dados (informações) recolhidos e analisados em funções da
metodologia de desenvolvimento “RUP”;
 Códificar o Banco de Dados para obtenção do modelo físico que servirá para o
armazenamento das informações;
 Fazer uma interface intuitiva, dinâmica e de fácil acesso com base as necessidades do
cliente, utilizando o Visual Studio como ferramenta e o C# como tecnologia;
 Testar o sistema para apuração de sua implementação;
 Implementar o sistema.

8
GESTÃO DE ESTOQUE
A gestão de estoque passa por uma série de atividades e ações, comandadas por dados,
que permitem a auditoria de uma boa utilização doscrecursos, se eles estão estrategicamente
localizados, se são adequadamente bem manuseados, permitindo assim o acompanhamento e
controle. A programação e o planejamento das necessidades de um estoque, o controle das
compras realizadas para o mesmo, a localização do produto armazenado, a forma com que
será movimentado, devem ser coerentes e otimizadas para que os custos do produto não sejam
aumentados e repassados aos consumidores finais. (FILHO,2006).

GESTÃO DE SAÍDA
A saída de produtos em estoque se dará na compra do produto partir de um de um
balcão. O sistema dará baixa no produto.

GESTÃO DE ENTRADA
A gestão de entrada só poderá ser realizada pelo proprietário ou gerente da loja ou
mercado, onde será necessário de primeira a criação de uma conta local com nome de usuário
e senha para evitar fraudes e garantir a segurança (opcional).

METODOLOGIA UTILIZADA
A implentação de uma metodologia de gestão de estoques, objetivo geral da presente
dissertação, é vital para empresas que buscam constante aprimoramento dos processos de
gerenciamento como um todo. Estas empresas vislumbram na gestão dos estoques mais um
ponto responsável pelo diferencial competitivo do mercado. A administração pública deve ter
como preocupação a eficiência de suas operações da mesma forma que as empresas privadas,
não tendo apenas na eficácia o seu foco de atenções, uma vez que o público deve ser
administrado dentro do princípio da economicidade, ou seja, buscando-se a minimização de
custos.

Quanto ao procedimento fez – se o uso da pesquisa bibiográfica.

9
METODOLOGIA PARA OBTENÇÃO DOS REQUISITOS DO
SISTEMA
Para a obtenção dos requisitos do SGM utilizamos o método de entrevista e o de
investigação.

É de grande importância ao grupo conhecer o que é feito no trabalho de fim de curso,

para que seja feito um Software ( Programa ) à medida. Então ouve muitas pesquisas da nossa
parte que fez com que o grupo tivesse o maximo de imformações para a concretização do
presente trabalho.

ESTRUTURA DO TRABALHO
O trabalho esta apresentado por 5 capítulos, onde cada capítulo tem papel importante,
o primeiro é uma introdução do trabalho, onde vamos mostrar os objetivos e a motivação para
a realização do trabalho.

No 1 CAPÍTULO, vamos apresentar o dominio do problema. Introduzem-se

considerações quanto o objetivo de estudo, os utilizadores, áreas de automatização, soluções e
propostas, de estudo de Sistema de Desktop.

No 2 CAPÍTULO, mostra-se à análise de requisitos, explicando detalhadamente a

composição do sistema, desde as funcionalidades contidas no sistema as tecnologias
implementadas.

No 3 CAPÍTULO, vamos abordar o desenho, mostrando à interface

gráfica de baixa fidelidade para o utilizador, modelo lógico de dados e a
arquitectura lógica da aplicação.

No 4 CAPÍTULO, é onde apresentamos as tecnologias e ferramentas

utilizadas para a elaboração do sistema.

No 5 CAPÍTULO, é o de implementação.Representa a topologia física do

sistema, e opcionalmente os componentes que são executados nessa topologia.

10
CAPÍTULO I - DOMÍNIO DO PROBLEMA

11
DELIMITAÇÃO DO ESTUDO
O nosso estudo está direcionado ao Mercado Talho, localizado na provincia de
Luanda, no bairro golf1, subzona 15.

OBJECTO DE ESTUDO
Os objctos de estudos deste sistema são os mercados de vendas presentes em luanda e
na sua de gestão de estoque.

OBJECTIVO DA INSTITUIÇÃO
O objectivo da instituição com a elaboração deste projecto, é de facilitar o
gerenciamento de estoque de uma empresa e instituição de pequeno porte, com o uso da
tecnologia com métodos simples e científicos que garantem bons resultados e maior lucro.

UTILIZADORES
Os utilizadores que terão acesso ao sistema são:

Administrador: é o utilizador que trata da gestão técnica do sistema e tem acesso a todos os
objectos do sistema.

Gerente: é o utilizador responsável pelo cadastro de entrada de produtos.

Funcionário: utilizador que gere as baixas de produtos (saída de produtos).

Gestor financeiro: é o responsável pela gerencia de dinheiros e bens da empresa (Trata do

dinheiro gasto e dinheiro arrecadado no negócio).

ÁREAS DE AUTOMATIZAÇÃO
Área de Automatização é presisamente os mercados de vendas presente na província
de Luanda.

12
SITUAÇÃO ATUAL
Actualmente temos visto que alguns mercados do nosso estado Angolano, tem
apresentado alguma difilculdades na quilo que é o controlo de estoque nos nossos mercados
difilcultade de gerir a entrada e saida dos produtos.

No mercado Talho não possue sistema de estoque. No nosso sistema poderão

cadastrar os seus produtos e fazer a gestão do estoque.

PROBLEMA A SEREM RESOLVIDOS

Os problemas a serem resolvidos são:

 O atraso de cadastramento de produto;

 A limitação de produtos a serem registrados;
 As informações concernentes aos produtos;
 Perca de informação por uso excessivo de materia prima ( papel ).

SOLUÇÃO PROPOSTA
A solução proposta é a implementação do nosso sistema de gestão de estoque , que é
capaz de suprir a necessidade do mercado Talho que não têm sistema de gestão. Permitir que
todos os membros da empresa desde o Gerente aos Funcionários possam ter fácil acesso
naquilo que é o controlo dos produtos.

13
ORÇAMENTO

Materias Nessesário

Materias nessesário o gestor de estoques está sempre em busca de soluções para os

problemas e dificuldades do seu cotidiano e precisa de uma abordagem prática, porque a
aplicação de conceitos teóricos excessivamente sofisticados criaria mais barreiras do que
resultados, impedindo-o de adotar técnicas que aumentariam a competitividade do seu
negócio.

Tipos de ferramenta Quantidade Designação

1 2 Computadores

Hardware

2 Impressora

3 Ferramenta de amalise de Astah Comunity

desenho ( software )

4 Ferramenta de Visual Studio

Desenvolvimento

Tabela 1 – Materiais necessários

Estimativa De Custo

Custo Preço
Custo da construção do sistema 500.999.00kz
Custo de manutenção por mês 200.000.00kz
Custo de implantação 100.900.00kz
Total 801.899.00kz

Tabela 2 - Custos Gerais

14
15
Viablidade Do Projeto

No SGM Tendo em vista a alta competitividade do mercado, empresas estão cada vez
mais buscando acentuar seus diferenciais diante da concorrência, o que também envolve
voltar a sua atenção para suas estruturas internas, atividades essas que podem melhorar sua
lucratividade.

Beneficios Tangiveis

Permite que as pessoas associadas a empresa possam utilizar o SGM para adquerir
conhecimnetos, e também devido a transação do sistema DESKTOP.

16
CAPÍTULO II - ANÁLISE DE REQUISITOS

17
METODOLOGIA APLICACIONAL

AS FASES E ACTIVIDADES DO RUP

A proposta do trabalho era saber se o RUP e o PMBOK podem ser utilizados de forma
integrada. Para responder esta pergunta foi feito um estudo exploratório do RUP, do PMBOK
e do relacionamento entre eles. O trabalho mostra que o uso combinado destas metodologias é
possível, viável e em muitos casos recomendável, uma vez que a gestão de projetos do RUP
foi escrita com base no PMBOK. O RUP cobre bem integração, escopo, tempo e qualidade;
cobre parcialmente recursos humanos, comunicações e riscos; e cobre muito pouco custos,
aquisições e partes interessadas. O trabalho também mostra que existem alguns equívocos na
literatura sobre a utilização conjunta do RUP com o PMBOK.

TIPO DE APLICAÇÃO

O tipo de aplicação do projecto é “DESKTOP”, por ser mais confiáveis e seguras pois
é difícil acessar o código interno da aplicação, diferente da aplicação web, que correm um
risco maior de serem modificadas por um usuário mal intencionado.

Por fim temos a base de dados. Essa parte está relacionada com as informações
utilizadas pelo sistemas a fim de executar sua tarefa principal. A base de dados cuida das
relações entre tabelas e a modelagem do mundo real para garantir que a aplicação consiga
administrar esses dados de forma organizadas. Uma linguagem popular para esse
gerenciamento é o SQL Sever.

18
UTILIZADORES DO SISTEMA

Atores Utilizadores Descrição

O administrador é o utilizador que trata da
Administrador gestão técnica do sistema e tem acesso a
todos os objectos do sistema.
Utilizador responsável pelo cadastro de
Gerente entrada de produtos.
Utilizador que gere as baixas de produtos
Funcionário (saída de produtos).
O responsável pela gerencia de dinheiros e
Gestor financeir bens da empresa (Trata do dinheiro gasto e
dinheiro arrecadado no negócio).

Tabela 3 - Principal utilizadores do sistema

PROCESSO DE DESENVOLVIMENTO

Escolhemos a metodologia de desenvolvimento RUP, fizemos a descrição dos casos

de usos de negócio rematando assim os casos de uso candidatos e as regras de negócio,
levando-nos a construção de casos de uso do sistema e a descrição do mesmo. Assim sendo,
segue-se a elaboração dos diagramas que afectam outras fases do projecto como o diagrama
de classe persistente, sequência, componente, implantação, componentes e outros.

2.1. CAPTURA DE REQUISITOS

No presente artigo apresenta-se a aplicação web SVEN com o objetivo de suportar os

processos de uma empresa de pequeno porte, de forma a aumentar a sua produtividade. A
aplicação possibilita a gestão de produtos ofertados, pedidos recebidos, compras a serem
realizadas, produtividade dos vendedores, entre outras funcionalidades. E foi construída
utilizando um conjunto de novas APIs da plataforma web chamados Web Components, que
permitem a criação de novas tags HTML reutilizáveis, personalizadas e encapsuladas.

19
REQUISITOS FUNCIONAIS

Requisitos Funcionais são todas as necessidades, características ou funcionalidades

esperadas em um processo que podem ser atendidos pelo software.

De forma geral, um Requisito Funcional expressa uma ação que deve ser realizada
através do sistema, ou seja, um requisito funcional é “o que sistema deve fazer“.

REQUISITOS NÃO FUNCIONAIS

Requisitos não funcionais são os requisitos relacionados ao uso da aplicação em

termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenção e
tecnologias envolvidas. Estes requisitos dizem respeito a como as funcionalidades serão
entregues ao usuário do software.

Requisitos Não funcionais:

 2Demonstram qualidade acerca dos serviços ou funções disponibilizadas pelo

sistema. Ex.: tempo, o processo de desenvolvimento, padrões, etc.
 Surgem conforme a necessidade dos usuários, em razão de orçamento e outros
fatores.
 Podem estar relacionados à confiabilidade, tempo de resposta e espaço nas mídias
de armazenamento disponíveis.
 Caso ocorra falha do não atendimento a um requisito não funcional, poderá tornar
todo o sistema ineficaz. Ex.: requisito confiabilidade em um sistema de controle de
voos.

20
2.2. DESCRIÇÃO DOS PROCESSOS DE NEGÓCIO PROPOSTOS
2.2.1. Regras de Negócio:

O presente trabalho tem como objetivo apresentar Regras do Negócio

como uma forma de ajudar a resolver o problema da má definição de requisitos,
mostrando que elas representam um importante conceito na fase de definição de
requisitos organizacionais, facilitando modificações no sistema de informação
quando essas regras mudam, e proporcionam oportunidade para as pessoas do
negócio avaliarem a execução de cada processo.

21
2.3. DIAGRAMA DE CASO DE USO DE NEGÓCIO

O modelo de caso de uso de negócio no SGM especifica todas aquelas que são as
actividades do trabalho.

figura 01 - Diagrama de Caso de Uso de Negócio.

22
DEFINIÇÃO DOS ACTORES E DOS CASOS DE USOS DE NEGÓCIO

Os actores do caso de uso de sistema são aqueles que vão interagir

somente com as funcionalidades do sistema, funcionalidades estas que têm origem
nos casos de uso de negócio.

2.3.1. Definição dos Atores

Atores Descrição

Pessoa responsalvel pela a gestão do

Adminitrador sistema.
Pessoa que gere, que dirige pessoa
Gerente responsável pela gestão de uma empresa
ou de uma onganização; ADM.
Pessoa que exerce as acções do sistema
Funcionario no mercado, de acordo as instruções do
Gerente.

Tabela 4 – descrição dos atores do caso de uso do negócio.

23
2.4. DIAGRAMA DE CASO DE USO DO SISTEMA

Figura 3 - Diagrama De Caso De Uso Do Sistema

24
2.5. ESPECIFICAÇÃO DOS CASOS DE USOS

Para melhor compreensão dos casos de uso, vamos apresentar tabelas que
permitem descrever o que cada um deles faz. No entanto não existe um formato
específico de documentação para casos de uso definido pela UML. A equipa
adoptou este modelo de documentação, por ser de fácil compreensão. Segue-se a
descrição do caso de uso.

Nome do Caso de Uso Login

Caso de Uso Geral -

Actores Administrador, Gerente, Funcionário

Resumo Este caso de uso é encarregado de verificar a

autenticidade “Existência” dos dados dos usuários
que utilizam o sistema.

Pré-Condição O actor deve estar registado no sistema.

Pós-Condição Cada usuário tem o acesso somente ao ambiente de

trabalho em função dos previlégios que lhe forem
atribuidos.

FLUXO DE EVENTOS
Fluxo Principal 1. É apresentado uma tela com dois campos
principais;
2. O usuário preenche os campos com seus
credenciais;
3. O sistema valida os dados e efectua o login do
utilizador.

Fluxo Alternativo 1. Mostrar uma mensagem de erro caso o login

não for efectuado com sucesso;
2. O utilizador deve voltar à executar a linha 2 do
fluxo principal.

25
 Tabela 5 - Especificação do caso de uso fazer Login.

Nome do Caso de Uso Fazer cadastro: Produto, Categoria, Sub-categoria,

unidade...

Caso de Uso Geral -

Actores Gerente

Resumo Este caso de uso permite que os dados sejam

cadastrados no sistema por um Gerente.

Pré-Condição O Gerente deve estar antes cadastrado no sistema.

Pós-Condição O Gerente deverá preencher os campos e

posteriormente cadastrar as informações no banco
de dados.

FLUXO DE EVENTOS
Fluxo Principal 1. Acessar a area de menu e escolher o tipo de
cadastro a fazer;
2. Preencher os campos que lhe forem informado
e só depois efectua o cadastro;
3. O sistema armazena os dados no banco de
dados..

Fluxo Alternativo 4. Mostrar uma mensagem de erro caso o

Cadastro não for efectuado com sucesso;
5. O utilizador deve voltar à executar a linha 2 do
fluxo principal.

Tabela 6 - Especificação do caso de uso fazer Cadastro.

26
DIAGRAMA DE CLASSE
Diagramas de classes estão entre os tipos mais úteis de diagramas UML
pois mapeiam de forma clara a estrutura de um determinado sistema ao modelar
suas classes, seus atributos, operações e relações entre objetos. Por meio do nosso
software de criação de diagramas UML, criar estes tipos de diagramas não é tão
assustador como pode parecer. Este guia lhe mostrará como entender, planejar e
criar seus próprios diagramas de classes.

27
Figura 4- Diagrama De Classe

28
DIAGRAMA DE SEQUÊNCIA
Em síntese: o Diagrama de Sequência é uma das ferramentas UML usadas
para representar interações entre objetos de um cenário, realizadas através de
operações ou métodos (procedimentos ou funções). Este diagrama é construído a
partir do Diagrama de Casos de Usos. Primeiro, define-se qual o papel do sistema
(Use Cases), depois, é definido como o software realizará seu papel (Sequência de
operações).

FLUXO DE TRABALHO: ANÁLISE

A análise do fluxo de trabalho envolve a revisão de todos os processos em um
negócio, com o objetivo de identificar ineficiências e recomendar melhorias. O trabalho
começa com o estabelecimento dos resultados desejados da análise com os gerentes seniores
de uma empresa. Os analistas interagem com os funcionários da empresa para documentar o
estado atual dos processos de negócios da empresa. O estágio final é a recomendação de
processos que precisam ser alterados, automatizados ou deixados no local de acordo com as
metas estabelecidas.

DIAGRAMA DE CLASSE DE ANÁLISE

Figura 04 - Diagrama de Classe de Análise

29
CAPÍTULO III – DESENHOS

30
ESTRUTURA DO MENU
O prototipo de baixa fidelidade do sistema representa a interface grafica do mesmo.

Figura 05 pagina inicial

Figura 06 de cadastro de categoria

31
Figura 07 Cadastro de produto

Figura 08 cadastro e cliente

32
MODELO LÓGICO DE DADOS

Figura 9 - Estrutura Do Menu

33
3.1. A ARQUITECTURA MVC

É um padrão de arquitetura de aplicações que divide a aplicação em três camadas: a

visão (view), o modelo (model), e o controlador (controller). Traduzido para o português, a
expressão significa: modelo-visão-controlador.

O padrão MVC foi desenvolvido em 1979 por Trygve Reenskaug com a finalidade de ser
utilizado como arquitetura para aplicativos desketop. Entretanto, o padrão se popularizou para
uso em sistemas web, a partir da adesão de milhares de Frameworks de mercado.

Model-View-Controller (MVC) na Prática

Em termos práticas, e de forma resumida, utilizar do padão MVC significa:

Dividir a aplicação em camadas: uma da interface do usuário denominada View, uma

para manipulação lógica de dados chamada Model, e uma terceira caama de fluxo da
aplicação chamada ( Control ).
Criar a possibilidade de exibir uma mesma lógica de negócios através de várias interfaces.
Isolar a camada de negócios (Model) das demais camadas do sistema, de forma a facilitar a
sustentabilidade do código.

A implementação do controlador deve permitir que esta camada receba os eventos da

interface e e os converta em ações no modelo. A arquitetura MVC é uma arquitetura de
aplicativo de software bem estabelecida que organiza aplicativos em três camadas de
computação lógica e física: a camada de apresentação ou interface do usuário; a camada do
aplicativo, onde os dados são processados; e a camada de dados, em que os dados associados
ao aplicativo são armazenados e gerenciados.

Camada de Apresentação: É a camada na qual o usuário interage com o nosso

programa. Nesta camada temos os formulários de uma aplicação desktop. Nesta camada
encontramos o programa que sera executado pelo usuário ( ADM – FUNCIONARIO ).

Camada de Lógica de Negócio: É a camada onde estão os objetos de negócio. Esta

camada é usada para a comunicação entre a camada de apresentação e a camada de acesso a
dados.

Camada de Acesso a Dados: É a camada onde estão os objetos responsáveis pelo

armazenamento dos dados da aplicação.

34
CAPÍTULO IV - TECNOLOGIA E FERAMENTAS UTILIZADAS

35
TECNOLOGIA UTILIZADAS

SQL SERVER: Trata-se de um Sistema Gerenciador de Bancos de Dados,

Relacionais, SGBDR, que funciona unicamente sob sistema operacional Windows NT.
propriamente dito, entre a camada de conexão a bancos de dados e o Web Server, será
realizado via ODBC.

VISUAL STUDIO: Como já foi dito, ele é uma ferramenta da Microsoft, conhecida
como uma IDE — Integrated Development Environment. Ou seja, é basicamente um software
editor de texto que possibilita aos usuários escreverem seus códigos em uma determinada
linguagem para, então, serem traduzidos em comandos para os computadores.

Com o Visual Studio é possível desenvolver aplicativos da Web ASP.NET, serviços

Web XML, aplicativos desktop e aplicativos móveis. Quer conhecer mais sobre essa
ferramenta? Continue lendo.

Como funciona o Visual Studio?

O Visual Studio é um assistente para desenvolvimento. Independentemente da

linguagem que você utiliza, ele mostra os atalhos de APIs disponíveis, além de fazer
preenchimento automático dos comandos para agilizar a construção do seu código.

ASTAH COMMUNITY: Utilizada nos diagramas dinâmicos, essa ferramenta já é

bastante consolidada, voltada para a modelagem de sistemas utilizando a UML, utiliza como
recurso adicional a modelagem MAS ML.

36
FERRAMENTAS UTILIZADA

Ferramentas/ Versão Referência Objetivo

Tecnologia
Astah Community 7.0.0 http://astah.net/editions/community Documentação da
modelagem
baseada na UML.
Visual Studio 17.1.6 http://VisualStudio/editions/community Criação do código.
Microsoft SQL 18.10 http:// Criação de base de
Server MicrosoftSQLServerManagementStudi dados.
Management o /editions/community
Studio

Tabela 7 – ferrramentas utilizadas

37
CAPÍTULO V – IMPLEMENTAÇÃO

38
ARQUITETURA FISICA DO SISTEMA

5.1.1. Fase De Construção

A fase de comstrução de uma determinada forma foi um processo de confecção com ênfase na
gestão de recursos para optmizar os custos.

Ainda nesta fase, providenciamos a incorporação de todos os modulos do projeto para que
tenhamos o sistema no todo.

FASE DE TRANSIÇÃO

5.1.2. Implementação

O diagrama de implementação representa a topologia física, e opcionalmente os

componentes que são executados nesta topologia. Pode-se dizer que esse diagrama apresenta
um mapeamento entre os componentes de software e o hardware utilizado pelo sistema.

O SGM pode poderá ser acedido por qualquer um tipo de computador. a autenticação
é um factor obrigatório para que o utilizador tenha acesso as funcionalidades que o sistema
oferece, tendo em conta o sgm é uma aplicação restrita para os usuarios autorizados.

DIAGRAMA DE IMPLANTAÇÃO

O diagrama de Implantação foi desenvolvido de acordo os seguintes critérios:

 Os utlizadores acedem ao SGM apartir de suas máquinas.

 O sistema dará acesso as funcionalidades disponíbilizadas para o usuário.
 Consequentemente é acedida a base de dados, que contém os dados existentes
no SGM.

39
 Figura 10 - Diagrama De Implantação

5.2. MODELO FÍSICO DE DADOS

CREATE TABLE [cliente]

(
[cli_cod] int NOT NULL IDENTITY ( 1,1 ) ,
[cli_nome] varchar(95) NULL ,
[cli_cpfcnpj] varchar(95) NULL ,
[cli_rgie] varchar(95) NULL ,
[cli_rsocial] varchar(95) NULL ,
[cli_tipo] varchar(20) NULL ,
[cli_cep] varchar(20) NULL ,
[cli_endereco] varchar(95) NULL ,
[cli_bairro] varchar(95) NULL ,
[cli_fone] varchar(95) NULL ,
[cli_cel] varchar(95) NULL ,
[cli_email] varchar(95) NULL ,
[cli_endnumero] varchar(10) NULL ,
[cli_cidade] char(18) NULL ,
[cli_estado] char(18) NULL
)
go

ALTER TABLE [cliente]

ADD CONSTRAINT [XPKcliente] PRIMARY KEY NONCLUSTERED ([cli_cod]
ASC)
go

CREATE TABLE [compra]

(
[com_cod] int NOT NULL IDENTITY ( 1,1 ) ,
[com_data] datetime NULL ,
[com_nfiscal] int NULL ,

40
 [com_total] money NULL ,
[com_nparcelas] int NULL ,
[com_status] varchar(95) NULL ,
[for_cod] int NULL ,
[tpa_cod] int NULL
)
go

ALTER TABLE [compra]

ADD CONSTRAINT [XPKcompra] PRIMARY KEY NONCLUSTERED
([com_cod] ASC)
go

CREATE TABLE [fornecedor]

(
[for_cod] int NOT NULL IDENTITY ( 1,1 ) ,
[for_nome] varchar(95) NULL ,
[for_rsocial] varchar(95) NULL ,
[for_ie] varchar(95) NULL ,
[for_cnpj] varchar(95) NULL ,
[for_cep] varchar(95) NULL ,
[for_endereco] varchar(95) NULL ,
[for_bairro] varchar(95) NULL ,
[for_fone] varchar(95) NULL ,
[for_cel] varchar(95) NULL ,
[for_email] varchar(95) NULL ,
[for_endnumero] varchar(95) NULL ,
[for_cidade] varchar(95) NULL ,
[for_estado] varchar(95) NULL
)
go

ALTER TABLE [fornecedor]

ADD CONSTRAINT [XPKfornecedor] PRIMARY KEY NONCLUSTERED
([for_cod] ASC)
go

CREATE TABLE [itenscompra]

(
[itc_cod] int NOT NULL ,
[itc_qtde] float NULL ,
[itc_valor] money NULL ,
[com_cod] int NOT NULL ,
[pro_cod] int NOT NULL
)
go

ALTER TABLE [itenscompra]

ADD CONSTRAINT [XPKitenscompra] PRIMARY KEY NONCLUSTERED
([itc_cod] ASC,[com_cod] ASC,[pro_cod] ASC)

41
go

CREATE TABLE [itensvenda]

(
[itv_cod] int NOT NULL ,
[itv_qtde] float NULL ,
[itv_valor] money NULL ,
[ven_cod] int NOT NULL ,
[pro_cod] int NOT NULL
)
go

ALTER TABLE [itensvenda]

ADD CONSTRAINT [XPKitensVenda] PRIMARY KEY NONCLUSTERED
([itv_cod] ASC,[ven_cod] ASC,[pro_cod] ASC)
go

5.3. EXTRACTOS DE CÓDIGOS

Figura 11 – extractos de código

42
CONCLUSÃO
A implementação de procedimentos de controle de estoque adequados pode ajudar a
garantir que um negócio esteja funcionando em níveis financeiros ideais e que os produtos
atendam às necessidades e expectativas dos clientes.

Outras áreas onde as empresas incorrem em despesas ou perdem vendas que as

práticas e métodos de controle de estoque podem abordar incluem: Deterioração, Estoque
morto, Excesso de custos de armazenamento, Eficiência de custos, Vendas diminuídas, Perder
clientes fiéis, Excesso de estoque, Perda de controle de estoque, Perda de mercadorias no
armazém.

Quanto ao objetivo desta obra, chegamos a conclusão que só será saciada com a
implementação de um sistema informático de controle de estoque para a loja modelo.

43
GLOSSÁRIO
Aplicação Descktop – é qualquer software que pode ser instalado em um computador
e usado para executar tarefas específicas. Algumas aplicações desktop também podem ser
usadas por vários usuários em um ambiente com rede.

Upgrade – sinônimo deactualização ou melhoria, normalmente utilizado

para fazer referência a actualização de uma versão antiga para uma mais recente
de um determinado produto.

Diagrama – é uma representação gráfia usada para demostrar um esquema

simplificado ou um resumo sobre um assunto. Normalmente é formado por
palavras – chaves ou conceitos que são ligados por linhas e setas que definem o
raciocínio a ser seguido para que seja possível entendero tema.

SQL Sever – um dos recursos mais conhecidos do mundo, a linguagem SQL

( Structured Query Language ) é usada para executar comando em bancos de dados
relacionais, isto é, baseado em tabelas.

44
REFERÊNCIAS BIBIOGRÁFICAS
https://scholar.google.com/scholar?hl=pt-PT&as_sdt=0%2C5&as_vis=1&q=-
diagrama+de+uso+de+dados&btnG#d=gs_qabs&t=1651553535640&u=%23p
%3DCYvYV7QQKBAJ

JOÃO PAULO FERRARESI DULLIUS, LEANDRO BUSS BECKER, CARLOS

EDUARDO PEREIRA. Diagrama De Sequência, Salão de Iniciação Científica (13.: 2001:
Porto Alegre). Livro de resumos. Porto Alegre: UFRGS, 2001., 2001.

ANA CRISTINA MARTINS FERREIRA: Diagramas De Classes, Faculdade de Ciências e

Tecnologia, 2009.

KARINE DIAS, CRISTIANO TOLFO. Diagramas De Casos De Uso: uma abordagem para
transformação de modelos de negócio para diagramas de casos de uso
Anais do Salão Internacional de Ensino, Pesquisa e Extensão 6 (2), 2014.

DEISYMAR BOTEGA TAVARES. Diagrama De Classes, Universidade Federal de Viçosa,

2008

45
APÊNDICE
Produtos Podem Ser Retirados Sem A Permissão Do Adminstrador ?

Há Monitoramento Das Pessoas Que Usam O Sistema ?

Há Um Planejamento Na Empresa De Quando Vai Chegar Os Produtos E Como Cadastrar ?

Os Registros São Informatizados ?

Os Produtos Possuem Codigo De Barra ?

Todos Produtos E Materias Primas São Contados ?

A Disposição Da Mercadoria Favorece A Contagem ?

Quantos Funcionarios Usam O Sistema ?

Quantidade De Produtos Que Entram E Saem Semanalmente ?

Estoque De Segurança ?

Entrada De Pedidos ?

A Informações São Bem Guardadas ?

Quem Pode Fazer Alterações no sistema ?

46