Tese Final Arilton de Oliveira e Jelson Neto

INSTITUTO DE TECNOLOGIAS DE INFORMAÇÃO E
COMUNICAÇÃO
SISTEMA DE GESTÃO DE INFORMAÇÃO DE ESTOQUE E

FACTURAÇÃO PARA A GRÁFICA DART
TRABALHO DE FIM DE CURSO DE LICENCIATURA EM

ENGENHARIA DE INFORMÁTICA.
AUTORES: ARILTON DE OLIVEIRA E JELSON NETO
Luanda, 2021
INSTITUTO DE TECNOLOGIAS DE INFORMAÇÃO E
COMUNICAÇÃO
SISTEMA DE GESTÃO DE INFORMAÇÃO DE ESTOQUE E

FACTURAÇÃO PARA A GRÁFICA DART
TRABALHO DE FIM DE CURSO DE LICENCIATURA EM

ENGENHARIA DE INFORMÁTICA.
AUTORES: ARILTON DE OLIVEIRA E JELSON NETO
ORIENTADOR:
MSc. JOSÉ GOMES FIGUEIREDO
Luanda, 2021
Dedicatória
Dedicamos às nossas famílias, em especial aos nossos pais Anastácio Nunes e
Elizandra Nunes e Fátima Cândido e Adérito Neto. Que por nós tudo fizeram, fazem e
continuarão a fazer, dedicamos por todo amor, força e apoio incondicional.
III
Agradecimentos
Agradecemos a Deus por nos conceder a dádiva da vida e nos proporcionar sempre a
força de vontade de a cada dia vencer.
Agradecemos aos nossos familiares, aos nossos pais, irmãos, primos, tios e avos por
nos apoiarem sempre durante estes 5 anos da nossa formação.
Agradecemos a todos os nossos professores pelos ensinamentos e orientações que

recebemos ao longo da nossa formação académica pois muitos deles serviram para
moldar a personalidade e os profissionais que hoje somos, e de uma maneira muito
especial agradecemos aos nossos professores cubanos, que largaram as suas famílias
para poderem partilhar um pouco de si mesmos durante todo esse período.
Agradecemos especialmente aos professores Pedro Alvarez Barreras, Yurisbel Ortiz

Veja, Mario Romero, Lindsay Gomez Beltran, Tomas Junco Velasquez, Miguel Garay,
Walber Mengana, Neyisis Hernández Días, Geidis Sánchez Michel, Yoenis Pantoja,
Yamila Miguel, Yoan Parra, Yirka Boch Caspédes e de todos os outros que fizeram parte
dessa trajectória académica de nossas vidas.
Agradecemos aos nossos colegas das turmas A e B do ano académico de 2016-2020

que iniciaram connosco essa jornada, agradecemos por todos os momentos partilhados
tanto de entretenimento como de aprendizado.
Agradecemos a todos que de forma directa ou indirecta contribuíram para a realização

do presente trabalho.
Que Deus cuide de vocês e abençoe de agora para todo o sempre.
IV
Resumo
O dia-a-dia das actividades desenvolvidas pelo ser humano em sua jornada de trabalho
dentro das organizações tem tornando-se cada vez mais complexo e no mercado
competitivo que se enfrenta nos tempos actuais, exige-se uma maior e mais eficaz
controlo de todo o funcionamento da gerência do negócio de uma simples à grande
organização, nos diversos ramos existentes. Actualmente o mercado oferece um grande
número de recursos computacionais voltados para serviços gráficos, visto que o mesmo
apresenta diversas características a nível de infra-estrutura, marketing e operações
comerciais.
A medida que se elaborava o presente trabalho investigou-se sistemas que visavam

solucionar o problema, mas estes mostraram-se ineficientes por não corresponderem as
necessidades apresentadas pela Gráfica Dart.
Desta feita a proposta deste projecto consiste na apresentação de um sistema de

informação de gestão de estoque e facturação para auxiliar nos processos de gestão da
Gráfica Dart. De acordo com os levantamentos efectuados foi possível desenvolver o
sistema de informação em causa cumprindo com os objectivos estabelecidos.
Palavras chaves: facturação, gestão de negócio, gestão de estoque, serviços gráficos,

sistema de informação.
V
Abstract
The day-to-day activities carried out by human beings in their workday within the
associations has become increasingly complex and in the competitive market that is
faced nowadays, greater and more effective control of the whole is required. the
functioning of the business organization of a simple organization, in the various existing
branches. Currently, the market offers a large number of computational resources aimed
at graphic services, as the graphic market has several characteristics in terms of
infrastructure, marketing and commercial operations.
As the present work was being elaborated, systems that aimed to solve the problem were
investigated, but these proved to be inefficient because they did not correspond to the
needs presented by Gráfica Dart.
This time the proposal of this project consists in the presentation of an information
system for stock management and invoicing to assist in the management processes of
Gráfica Dart. According to the surveys carried out, it was possible to develop the system
in question complying with the data produced.
Keywords: invoicing, business management, inventory management, graphic services,

information system.
VI
Índice geral
Introdução............................................................................................................................1
Capítulo 1: Fundamentação teórica.....................................................................................7
1.1. Principais conceitos associados ao objecto de estudo.............................................7
1.2. Estado da arte............................................................................................................8
1.2.1. Internacional........................................................................................................8
1.2.2. Nacional.............................................................................................................10
1.3. Metodologia utilizada...............................................................................................11
1.3.1. Metodologias robustas......................................................................................12
1.3.2. Metodologias ágeis............................................................................................12
1.4. Ferramentas nas quais se apoia para a solução....................................................15
1.4.1. Linguagem de programação.............................................................................15
1.4.2. Editor de texto e IDE (Integrated Development Environment)..........................15
1.4.3. Framework.........................................................................................................16
1.4.4. Bibliotecas.........................................................................................................17
1.4.5. Sistema de gestão de banco de dados.............................................................17
1.4.6. Ferramentas de modelagem com UML.............................................................19
1.4.7. Ferramentas auxiliares para o desenvolvimento..............................................20
1.5. Conclusões parciais do capítulo..............................................................................21
Capítulo 2: Características do sistema..............................................................................22
2.2. Objecto de automação.............................................................................................22
2.3. Modelagem do negócio...........................................................................................22
2.3.1. Modelo de domínio............................................................................................22
2.3.2. Descrição dos trabalhadores e atores do negócio............................................24
2.3.3. Diagrama de casos de uso do negócio.............................................................25
VII
2.3.4. Descrições de casos de uso do negócio...........................................................25
2.4. Modelagem do sistema............................................................................................27
2.4.1. Requisitos funcionais........................................................................................27
2.4.2. Requisitos não funcionais.................................................................................29
2.4.3. Diagrama de casos de uso do sistema.............................................................30
2.4.4. Descrição de casos de uso do sistema.............................................................31
Capítulo 3: Desenho, implementação e provas do sistema..............................................36
3.1. Diagrama de classes...............................................................................................36
3.2. Arquitectura do sistema...........................................................................................37
3.3. Padrão de desenho utilizado...................................................................................39
3.4. Análise e desenho do banco de dados...................................................................42
3.4.1. Modelo logico do banco de dados....................................................................42
3.5. Diagrama de implantação........................................................................................43
3.5.1. Descrição do modelo de implantação do sistema............................................44
3.6. Validação do sistema mediante provas...................................................................44
3.6.1. Prova de caixa branca.......................................................................................45
3.6.2. Prova de caixa preta.........................................................................................47
Resultado das provas de software..............................................................................51
Conclusões.........................................................................................................................52
Recomendações................................................................................................................53
Referências bibliográficas..................................................................................................54
Anexos...............................................................................................................................57
VIII
Índice de figuras
Figura 1.2 – Diagramas UML.............................................................................................19
Figura 2.1 – Diagrama de domínio. Fonte: (Elaboração própria)......................................23
Figura 2.2 – Diagrama de casos de uso de negócio. Fonte: (Elaboração própria)...........25
Figura 2.3 – Diagrama de casos de uso de sistema. Fonte: (Elaboração própria)...........31
Figura 3.1 – Diagrama de classes. Fonte: (Elaboração própria).......................................37
Figura 3.2 – Arquitetura MVC (Modelo Vista Controlador)................................................38
Figura 3.3 – Demonstração da aplicação da arquitetura MVC..........................................39
Figura 3.4 – Código fonte da classe Funcionário. Fonte: (Elaboração própria)................40
Figura 3.5 - Código fonte da classe Produto. Fonte: (Elaboração própria).......................41
Figura 3.6 – Código fonte da classe VisualizarController (Método Pesquisar). Fonte:

(Elaboração própria)..........................................................................................................42
Figura 3.7 – Modelo lógico do banco de dados. Fonte: (Elaboração própria)..................43
Figura 3.8 – Diagrama de implantação. Fonte: (Elaboração própria)...............................44
Figura 3.9 – Código fonte Guardar fatura. Fonte: (Elaboração própria)...........................46
Figura 3.10 – Gráfico do fluxo da prova de caixa branca. Fonte: (Elaboração própria). . .46
Figura 3.11 – Gráfico do resultado as provas de software................................................52
IX
Índice de tabelas
Tabela 2.1 - CUN: Solicitar produto...................................................................................25
Tabela 2.2 - CUN: Solicitar serviço....................................................................................26
Tabela 2.3 - Requisitos funcionais.....................................................................................27
Tabela 2.4 - Requisitos não funcionais..............................................................................30
Tabela 2.5 - Descrição do caso de uso do sistema - Autenticar.......................................31
Tabela 2.6 - Descrição do caso de uso do sistema – Gerenciar cliente...........................32
Tabela 2.7 - Descrição do caso de uso do sistema – Gerenciar vendas..........................33
Tabela 3.1 - Descrição dos dispositivos do diagrama de implantação.............................44
Tabela 3.2 - Descrição dos conectores do diagrama de implantação..............................44
Tabela 3.3 - Descrição das provas de caixa preta............................................................48
X
Lista de Abreviaturas e Símbolos
SI – Sistema de informação.
SIG – Sistema Informação para Gestão.
JVM – Java Virtual Machine.
IDE – Integrated Development Environment.
PHP – Hypertext Preprocessor.
HTML – HyperText Markup Language.
XML – Extensible Markup Language.
AWT – Abstract Window Toolkit.
GUI – Graphical User Interface.
CSS – Cascading Style Sheets.
LESS – Which Stands for Leaner Style Sheets.
SGBD – Sistema de Gerenciamento de Banco de Dados.
SQL – Structured Query Language.
OpenUp – Open Unified Process.
PNG – Portable Network Graphics
RF – Requisito Funcional.
UML – Unified Modeling Language.
RF – Requisito Funcional.
RNF – Requisito Não Funcional.
GRASP – General Responsibility Assignment Software Patterns.
ISO – International Organization Standard.
ANSI – American National Standards Institute.
SMS – Short Message Service.
XI
Introdução
Com o passar dos anos e com o evoluir da tecnologia na gestão de empresas de forma
marcante, tanto para gestores de organizações como para os seus clientes, reunir
informações sobre o funcionamento do negócio ao longo dos anos como cadastro de
clientes, cadastro de produtos, controlo de estoque, fluxo de caixa e outras é um factor
de grande importância para uma prestação de serviços melhor aos clientes e como
consequência o crescimento do negócio.
Actualmente é indispensável o uso de um Sistema de Informação para apoio nas

diferentes áreas de trabalho. O grande desafio que os administradores enfrentam
actualmente é o de prever os problemas e conceber soluções práticas a eles, a fim de
realizar os anseios objectivos pela organização. Os administradores precisam estar
muito bem informados, pois a informação é a base para toda e qualquer tomada de
decisão. Os sistemas de informação (SI) têm um papel fundamental e cada vez maior
em todas as organizações de negócios, pois quando eficazes, podem ter um impacto
enorme na estratégia corporativa e no sucesso organizacional. (Dalfovo, 2000).
Os SI são vários elementos combinados da melhor maneira, para atingir determinado
objectivo. Estes elementos são a informação, os recursos humanos, as tecnologias de
informação e as práticas de trabalho. (Prates, 1994). Os SI são uma forma de
proporcionar aos executivos informações precisas e actualizadas. Estes sistemas trazem
uma visão integrada de todas as áreas da empresa, sem necessitar de muito tempo ou
maiores conhecimentos de cada área. Um SI colecta dados, manipula e armazena estes
dados, produz informações úteis e proporciona um mecanismo de feedback (Dafolvo,
2001).
Os SI são a última moda no mercado, ou seja, é utilizado nas estruturas de decisões da
empresa e, quando correctamente aplicados, trarão, certamente, resultados positivos às
empresas. Caso contrário, torna-se difícil sua implementação até mesmo por seu alto
custo. Com isso, os SI são divididos de acordo com as funções administrativas, que
foram sendo tratadas de forma individualiza, resultando na criação de vários sistemas
para ajudarem os executivos, nos vários níveis hierárquicos a tomarem decisões,
destacando-se os Sistemas de Informação para Gestão (SIG). (Oliveira, 1992).
1
Sistema de Informação para Gestão (SIG) é o processo de transformação de dados que
são utilizadas na estrutura decisória da empresa. Suas características são métodos
organizados para prover informações passadas, presentes e futuras, relacionadas com
as operações internas e o serviço de inteligências externa. Serve de suporte para as
funções de planeamento, controle e operação de uma empresa através do fornecimento
de informações no padrão de tempo apropriado para assistir o tomador de decisão.
(Oliveira, 1992).
Um SIG é um conjunto de pessoas, equipamentos, procedimentos que colecta, valida,
executa operações, armazena, recupera dados para o uso no planeamento, orçamento,
contabilidade e controle de processos gerências para vários propósitos administrativos.
(Cruz, 1998).
Um SIG deve ser muito bem desenvolvido, implementado e ter uma efectiva colaboração
na adequação das organizações perante os pontos inerentes a um cenário provável para
a economia nacional e mundial. Um SIG pode representar o insumo e o resultado do
tratamento de cada uma das actividades da organização para que estas trabalhem, de
forma interactiva com a administração. O SIG tem grande importância para as
organizações, pois oferece condições para que as mesmas possam executar desde uma
pequena melhoria na produtividade até uma redução da centralização das tomadas de
decisões da organização.
Situação problemática
Localizada na província de Luanda, município do Cazenga, a Gráfica Dart é uma

empresa que actua mercado Angolano, e tem como missão oferecer a melhor solução
em artes gráficas para atender as necessidades dos clientes, com tecnologia de ponta,
qualidade, rapidez, e confiabilidade dos serviços, pretendendo a total satisfação dos
seus clientes, colaboradores e fornecedores, com responsabilidade e respeito agregar
valor à sociedade. Nela são fornecidas soluções gráficas a clientes particulares e
corporativos. Após serem feitas pesquisas sobre o funcionamento da gestão do estoque
e facturação na Gráfica Dart foram constatados alguns problemas que têm causado
objecções à gráfica a cumprir com aquela que é a sua missão no mercado angolano, que
dentre os quais podemos destacar:
2
 O que controle do estoque é feito a partir de planilhas do Excel, o que faz com
que se perca muito tempo com os erros humano, como dupla entrada de dados
ou perca de dados;
 Não registar todas as movimentações de entrada e saída gera inconsistência no
controle do estoque, o que tem causado consequências negativas à gráfica, como
comprar de maneira desnecessária ou ainda causar rupturas no estoque;
 Falta de actualização do estoque tem causado incumprimento de prazos de
entregas dos produtos solicitados pelos clientes, porque às vezes não se sabe
quais produtos existem em estoque;
 As facturas emitidas em blocos de papel estão ultrapassadas e podem ser
facilmente adulteradas;
 Perda de lucros porque os relatórios financeiros não são elaborados com dados
exactos, porque os blocos de facturas as vezes são danificados por diversos
motivos.
Problema de investigação
Descrita a situação problemática que se vive na Gráfica Dart é identificado o problema

da investigação como: Como melhorar a gestão de estoque e facturação na Gráfica
Dart?
Objecto de estudo
Tendo sido identificado o problema da investigação, então é definido como objecto de

estudo da investigação a gestão de estoque e facturação.
Campo de acção
A investigação terá como seu campo de acção a gestão de estoque e facturação para a
Gráfica Dart.
Objectivo geral
Em resposta ao problema identificado na Gráfica Dart se estabelece como objectivo

geral desta investigação desenvolver um sistema de gestão de informação de estoque e
facturação com o intuito de melhorar a gestão de estoque e facturação da Gráfica Dart.
Objectivos específicos
3
Para que seja cumprido o objectivo definido acima são estabelecidos como objectivos
específicos os seguintes:
1- Realizar o desenho teórico metodológico da gestão de estoque e facturação;

2- Seleccionar as ferramentas, linguagens e metodologias a serem usadas no
desenvolvimento do sistema de gestão de estoque e facturação;
3- Desenvolver o sistema de gestão de estoque e facturação;
4- Implantar o sistema de gestão de estoque e facturação na Gráfica Dart;
5- Validar o sistema de gestão de estoque e facturação mediante provas as provas
de software.
Tarefas de investigação
As tarefas de investigação propostas para dar solução ao problema de investigação

identificado são:
1- Descrição do funcionamento da gestão de estoque e facturação das gráficas em

Angola;
2- Realização de entrevistas ao gerente e funcionários da gráfica;
3- Identificação dos principais sistemas existentes que integram gestão de estoque e

facturação;
4- Selecção das ferramentas, linguagens de programação e metodologias de

desenvolvimento de software;
5- Desenho dos modelos do sistema de informação de acordo com a metodologia de

desenvolvimento de software seleccionada;
6- Implantação da solução proposta;
7- Validação a solução proposta mediante provas de software.
Ideia a defender
Com a implantação de um sistema de gestão de estoque e facturação se poderá

melhorar a gestão de estoque e facturação na Gráfica Dart.
Métodos científicos
São aplicados para a concepção da investigação científica os seguintes métodos de

investigação:
4
 Métodos teóricos.
 Métodos empíricos;
Dos métodos empíricos foram seleccionados para a investigação:
1. Analítico-Sintético: É utilizado para analisar a informação e documentações

relevantes para o desenvolvimento do sistema informático, enfatizando os
elementos mais importantes que se relacionam com o objecto de estudo.
2. Histórica-Lógico: Utiliza-se para conhecer os antecedentes e elementos da
investigação referidos aos processos de planeamento e controle e a determinação
das tendências actuais sobre a temática que se estuda. Seu emprego permitiu
pesquisar a respeito dos sistemas de gestão, existentes a nível nacional e
internacional que gerem as compras e vendas nos mercados.
Dos métodos empíricos foram seleccionados para a investigação:

1. Entrevista: Realizaram-se a determinados trabalhadores que se vêem imersos ou
estão ligados no funcionamento da Gráfica Dart com o objectivo de obter
informações sobre o funcionamento do negócio como mostra o Anexo 1.
2. Observação: Utilizado para observar o funcionamento interno como propósito de
como são processadas as informações na gestão do estoque e da facturação na
Gráfica Dart.
Resumo dos capítulos
O presente trabalho está estruturado pelas seguintes partes: Introdução, três (3)
capítulos, conclusões, recomendações, referências bibliográficas e anexos.
Capítulo1: Fundamentação teórica - Neste capítulo se especificam os principais

conceitos relacionados com o tema da investigação; realiza-se o estudo do estado da
arte a nível nacional e internacional sobre os sistemas de gestão de estoque e
facturação existentes. Também se definem as ferramentas, metodológicas e
tecnológicas a utilizar durante o desenvolvimento do sistema.
Capítulo 2: Características do sistema - Neste capítulo é feita a apresentação da

modelagem de negócio e do sistema. Na modelagem de negócio é feito a apresentação
do modelo conceptual, diagrama de caso de uso de negócio e a devida descrição do
caso de uso. Na modelagem do sistema é feita a apresentação dos requisitos funcionais,
5
requisitos não funcionais, protótipos de interface, diagrama de caso de uso de sistema
bem como a devida descrição do caso de uso de sistema.
Capítulo 3: Desenho, implementação e provas do sistema - Neste capítulo é

apresentado o diagrama de classes, o desenho do banco de dados e o arquitectura de
desenvolvimento. No desenho do banco de dados é feita a apresentação do modelo
lógico onde será armazenada os dados da empresa. Para a validação do sistema é feita
a apresentação das técnicas utilizadas para provar a garantia da confidencialidade e
detectar possíveis falhas no sistema.
6
Capítulo 1: Fundamentação teórica
Este capítulo apresentará os conceitos fundamentais que constituem a base teórica do
problema de investigação. Será feito um estudo de sistemas de gestão de estoque e
facturação a nível nacional e internacional. As metodologias de desenvolvimento de
software, as tecnologias e as ferramentas actuais de desenvolvimento de software serão
analisadas e as mais adequadas serão seleccionadas para serem usadas durante o
desenvolvimento da solução proposta.
1.1. Principais conceitos associados ao objecto de estudo
A seguir se descrevem os principais conceitos relacionados com o marco teórico da

investigação para uma boa compreensão com o objectivo de aprofundar os distintos
pontos de vistas e assumir uma posição a respeito.
Sistema
Um sistema é um conjunto ordenado de elementos que se encontram interligados e que

interagem entre si. O conceito é utilizado tanto para definir um conjunto de conceitos
como objectos reais dotados de organização. (Conceito.De, 2018).
Sistema de informação
Os sistemas de informação são componentes inter-relacionados que trabalham juntos

para colectar, processar, armazenar e disseminar informações para apoiar a tomada de
decisão, coordenação, controle, análise e visualização em uma organização.
(Pressbooks, 2019).
Gestão
Gestão refere-se a acção e ao efeito de gerir ou de administrar. Gerir consiste em

realizar diligências que conduzem à realização de um negócio ou de um desejo
qualquer. (Conceito.De, 2018).
Estoque
Estoque ou inventario é o material mantido num estado inactivo ou incompleto,

aguardando futura venda, utilização ou transformação. (Tersine, 1994).
7
Os estoques mantêm um papel crucial numa empresa mantendo o equilíbrio entre a
oferta e a procura. Estes também protegem o incumprimento dos prazos de entrega,
evitam a ocorrência de rupturas, satisfazem a procura irregular e contribuem activamente
na criação de valor para o cliente. (Chikán, 2007).
Facturação
Definições de facturação extraídas do dicionário online (Inforpédia, 2018):
1. Acto de facturar; acto de lançar em factura;

2. Acto de processar facturas de bens ou serviços;
3. Determinação quantitativa do que se vai pagar;
4. Serviço de empresa que processa factura;
5. Valo total das vendas de uma empresa durante um dado intervalo de tempo.
1.2. Estado da arte
A seguir são expostas algumas soluções existentes que se destinam à gestão de

estoque e facturação para gráficas a nível internacional e nacional o que permitirá
conhecer as características dos sistemas destinados a esse tipo de serviço.
1.2.1. Internacional
A nível internacional foram encontrados por nós dois sistemas informação de gestão de
estoque e facturação que possuem similaridades com o sistema em estudo, estes
sistemas são: QuantoSobra e Lexos.
QuantoSobra
O QuantoSobra é um software de vendas e estoque que automatiza todos os processos

internos de uma empresa. Ele integra a gestão do controle de estoque com a sua frente
de caixa por meio do leitor de código de barras e, ainda, faz a gestão do sei controle de
vendas. Além disso, o software de vendas e estoque QuantoSobra ainda faz o controle
de fluxo de caixa da sua empresa, também fazendo a emissão dos mais variados tipos
de notas fiscais eletrónicas. (AWISE, 2020).
Segundo (AWISE, 2020) as funcionalidades do QuantoSobra são:
 Controle de estoque;
 Controle financeiro (fluxo de caixa, contas a receber e a pagar etc.);
8
 Gerenciamento de compras por prestações;
 Geração de etiquetas com código de barras;
 Controle de pré-vendas, condicionais e geração de recibos;
 Emissão de documentos fiscais;
 Relatórios gerenciais.
Lexos
Lexos é um software de gestão vendas e controle de estoque que permite ter o controlo
total das entradas e saídas dos produtos, importar a nota fiscal do seu fornecedor de
forma automática, além de possibilitar o cadastro manual dos produtos e de forma
rápida, gerar código de barras, preço de venda, preço de custo e todas as informações
fiscais. Além da integração entre o estoque e a venda, o sistema também é totalmente
integrado ao controle financeiro da sua empresa, que você poderá analisar diversos
relatórios gerenciais para acompanhar os resultados da sua empresa. (Lexos, 2021).
Segundo (Lexos, 2021) as funcionalidades do Lexos são:
 Controle de estoque;
 Relatórios de estoque (por custo, por investimento, quantidade actual e produtos
mais relevantes na loja);
 Cadastro dos produtos;
 Geração de código de barras;
 Markup;
 Geração de etiquetas;
 Montagem de kits;
 Tabela de preços;
 Abertura e fecho de caixa;
 Controle de vendas;
 Relatório de vendas;
 Cadastro de clientes;
 Cadastro de fornecedores.
Com base a pesquisa realizada no âmbito internacional os sistemas acima mencionados

foram analisados para saber como gerenciam a informação relacionada com a gestão de
9
estoque e facturação. Os dois sistemas permitem fazer a entrada e saída de produtos e
também geram relatórios, mas dada a dificuldade que o país vive para a realização de
pagamentos internacionais, a empresa prefere optar por um fornecedor nacional.
1.2.2. Nacional
Nesta secção se apresenta dois sistemas de informação de gestão de estoque e
facturação a nível nacional denominados por KwanzaGest e WinMarket.
KwanzaGest
(kwanzagest, 2020) O KwanzaGest é um sistema de facturação simples, rápido e

intuitivo que funciona em plataforma web e desenvolvido especificamente para Angola.
Esta solução integra os módulos de Gestão Comercial, Tesouraria e Bancos,

Encomendas e Estoques e Inventários. Para que a sua empresa possa facturar com
rapidez, registar as compras, gerir os estoques com eficácia e simplificar os movimentos
de tesouraria.
Também, através de uma aplicação para o seu telemóvel, poderá controlar a evolução
do seu negócio, sempre que quiser, esteja onde estiver.
Segundo (kwanzagest, 2020) as funcionalidades do KwanzaGest são:
 Gestão Comercial e Facturação;

 Encomendas e Estoques;
 Help Center;
 Sistema Easy SMS.
WinMarket
O WinMarket é um sistema desenhado e desenvolvido para dar resposta aos mais

variados processos que circulam num estabelecimento comercial de pequena, media e
grande escala. O WinMarket é um software 100% Angolano, desenvolvido pela
Ramossoft capaz de cobrir todas as necessidades que um estabelecimento comercial
pode encontrar em termos administrativos e comerciais. Este software tem um Front-
Office simples e rápido de ser usado e um Back-Office robusto e eficaz, pelo que os
direitos do autor estão totalmente reservados a Ramossoft. (RamosSoft, 2019).
Segundo (RamosSoft, 2019) as funcionalidades do WinMarket são:
10
 Gestão de produtos;
 Gestão de vendas (facturação);
 Gestão de fornecedores;
 Gestão de relatórios.
Com base a pesquisa realizada no âmbito nacional os sistemas acima mencionados

foram analisados para saber como gerenciam a informação relacionada com a gestão de
estoque e facturação. Os dois sistemas permitem fazer a entrada e saída de produtos e
também geram relatórios, quanto ao KwanzaGest, é uma solução viável, mas a grande
dificuldade é que ele funciona baseado em serviços Cloud e necessita que o utilizador
esteja sempre conectado a internet, e relativamente ao WinMarket este é um software
que se dedica apenas a dar soluções para a área comercial e não de prestação de
serviços, por tanto os dois softwares apresentados não poderão ser utilizados como
parte da proposta de solução do Sistema de informação de gestão de estoque e
facturação para a Gráfica Dart. A Figura 1.1 mostra alguns dos critérios levados em
conta para o desenvolvimento de um novo sistema de raiz que se adequa as
necessidades da Gráfica Dart.
Figura 1.1 – Tabela ilustrativa sobre o estudo da arte. Fonte: (Elaboração própria).
1.3. Metodologia utilizada
Entende-se por metodologia, como a maneira – forma – de se utilizar um conjunto

coerente e coordenado de métodos para atingir um objectivo, de modo que se evite,
tanto quanto possível, a subjectividade na execução do trabalho. Fornecendo um roteiro,
11
um processo dinâmico e interactivo para desenvolvimento estruturado de projectos,
sistemas ou software, visando à qualidade e produtividade dos projectos. (Leite, 2006).
O dicionário (Inforpédia, 2018) define metodologia como um conjunto de métodos, regras

e postulados empregados por uma disciplina: Um procedimento particular ou conjuntos
de procedimentos.
É objectivo de uma metodologia definir de forma clara “quem” faz “o que”, “quando”,
“como”, e até mesmo “onde”, para todos os que estejam envolvidos directamente ou não
com o desenvolvimento de software. Deve definir também qual o papel dos técnicos, dos
usuários, e o da administração da empresa no processo de desenvolvimento. Com isso,
evita-se a situação a qual o conhecimento sobre o sistema é de poucos, comummente
apelidados, de “os donos do sistema”. Além disso, deve instruir um conjunto de padrões
preestabelecidos, de modo a ser evitar a subjectividade na abordagem, a fim de garantir
fácil integração entre os sistemas desenvolvidos. (Leite, 2006).
1.3.1. Metodologias robustas
As metodologias robustas são conhecidas pela maneira tradicional de desenvolver

software e são baseados em um processo unificado, com um óptimo fluxo de trabalho,
obtendo uma ampla documentação e um planeamento inicial detalhado que deve ser
seguido estritamente. Elas também são adaptáveis a projectos de longo prazo. Entre as
metodologias robustas destacam-se: MSF (pela sua sigla em inglês, Microsoft Solution
Framework), RUP (pela sua sigla em inglês, Rational Unified Process), entre outras.
Estas metodologias incluem grandes fases para a especificação de requisitos, análise e
desenho, fazendo a correcção de erros, muito cara por serem metodologias pouco
flexíveis as mudanças, pelo facto de que o cliente e a equipa de desenvolvimento não
mantêm uma relação directa. (Palomeque, et al., 2015).
1.3.2. Metodologias ágeis
O desenvolvimento ágil é uma abordagem em que softwares são desenvolvidos de

forma colaborativa, com equipes multidisciplinares que têm um bom nível de autonomia
na execução de seus trabalhos. (FIA, 2019).
No princípio da década de 1990, foram criados os “processos leves” com o objectivo de

eliminar ou diminuir o processo que era excessivo no desenvolvimento do software.
12
Alguns métodos de processos foram criados como o Scrum, Extreme Programming (XP),
OpenUp, entre outros. (Gomes, 2013).
XP (Extreme Programing)
A Extreme Programming (XP) é uma metodologia ágil para equipas pequenas e médias
que desenvolvem software baseado em requisitos vagos e que se modificam
rapidamente. (Soares, 2004). Dentre as principais diferenças da XP em relação às outras
metodologias estão:
 Feedback constante;
 Abordagem incremental;
 A comunicação entre as pessoas é encorajada.
Fases XP:
 Exploração;
 Planeamento;
 Iterações. Produção;
 Manutenção;
 Morte do projecto.
Práticas do XP:
Pequenas entregas: A ideia é produzir rapidamente versões do sistema que são

operacionais, embora obviamente não tenham todas as funcionalidades pretendidas
para o sistema. Uma entrega não deve demorar mais de 3 meses.
Design simples: Você deve projectar a solução mais simples que pode funcionar e ser
implementada em um momento específico no projecto. A complexidade desnecessária e
o código extra devem ser removidos imediatamente.
Testes: A produção do código é conduzida por testes unitários. Os testes de unidade

são estabelecidos antes de escrever o código e são executados constantemente antes
de cada modificação do sistema. Os clientes escrevem os testes funcionais para cada
história de usuário que deve ser validada.
OpenUp
13
O OpenUp é um projecto open source, actualmente mantido pelo Projecto Eclipse, que
define um framework de processo de desenvolvimento de software. Possui uma
abordagem iterativa e incremental dentro de um ciclo de vida estruturado. Além disso, é
um processo que pode ser estendido para direccionar uma grande variedade de tipos de
projecto, está em conformidade com os princípios do Manifesto do Desenvolvimento de
Software Ágil e é baseado em casos de uso. (Silva, 2014).
É um processo de baixa cerimónia que não está associado a nenhuma ferramenta

específica, considerado Mínimo, Completo e Extensível, valorizando a colaboração entre
a equipe e os benefícios aos interessados ao invés da formalidade e entregas
improdutivas. (Silva, 2014).
Princípios do OpenUp
OpenUp é orientado a quatro princípios listados abaixo. Os princípios capturam a

intenção geral por trás do processo e cria a fundação para interpretar papéis e produtos
de trabalho, e realizar tarefas:
 Colaboração para alinhar interesse e compartilhar entendimento. Este

princípio promove práticas para fomentar um ambiente saudável entre a equipa,
permitindo a colaboração e desenvolvimento de um entendimento compartilhado
do projecto.
 Balanceamento de prioridades concorrente para maximizar o valor do
cliente. Este princípio promove práticas que permitem os participantes do projecto
e stakeholders desenvolver uma solução que maximize os benefícios dos
stakeholders e está de acordo com as restrições do projecto.
 Foco antecipado na arquitectura para minimizar os riscos e organizar o
desenvolvimento. Este princípio promove práticas que permitem a equipe focar
numa arquitectura para minimizar os riscos e organizar o desenvolvimento.
 Desenvolver para continuamente obter feedback e melhorar. Este princípio
promove práticas que permitem a equipa obter feedback contínuo e antecipado
dos stakeholders, e demonstrar valor incremental a eles.
Das duas metodologias ágeis que foram citadas, a escolhida é a OpenUp pelo princípio
que apresenta baseado no foco antecipado na arquitetura para minimizar os riscos e
14
organizar o desenvolvimento, por promover práticas que permitem que a equipa esteja
focada numa arquitetura para minimizar os ricos e organizar o desenvolvimento.
1.4. Ferramentas nas quais se apoia para a solução
Para o desenvolvimento da proposta de solução, se faz necessário o uso de algumas

ferramentas, tais como: Linguagem de programação, editor de texto, framework,
bibliotecas e sistemas de gerenciamento de banco de dados.
1.4.1. Linguagem de programação
Uma linguagem de programação é uma linguagem de computador que os

programadores usam para desenvolver programas de software, scripts ou outros
conjuntos de instruções para os computadores executarem. Embora muitas linguagens
compartilham semelhanças, cada uma tem sua própria sintaxe. Depois que um
programador aprende as regras, sintaxe e estrutura da linguagem, ele escreve o código-
fonte em um editor de texto ou IDE. Então, o programador frequentemente compila o
código em linguagem de máquina que pode ser entendida pelo computador. Linguagens
de script, que não requerem um compilador, usam um interpretador para executar o
script. (ComputerHope, 2021).
Java 8
A linguagem de programação Java é uma linguagem considerada simples porque

permite o desenvolvimento de sistemas em diferentes sistemas operacionais e
arquitecturas de hardware, sem que o programador tenha que se preocupar com
detalhes de infraestrutura. Dessa forma, o programador consegue desempenhar seu
trabalho de forma mais produtiva e eficiente. (Mendes, 2009).
A versão usada para desenvolver o sistema é o Java 8 que é uma versão revolucionária
da plataforma de desenvolvimento nº 1 do mundo. Inclui uma grande actualização do
modelo de programação Java e uma evolução coordenada da JVM (Java Virtual
Machine), linguagem Java e bibliotecas. Java 8 inclui recursos para produtividade,
facilidade de uso, programação poliglota aprimorada, segurança e desempenho
aprimorado. Bem-vindo à mais recente iteração da maior plataforma aberta, baseada em
padrões e voltada para a comunidade. (Oracle, 2014).
15
1.4.2. Editor de texto e IDE (Integrated Development Environment)
Os ambientes de desenvolvimento integrado ajudam os desenvolvedores a programar

novas aplicações de forma rápida, já que os vários utilitários não precisam ser ajustados
e integrados manualmente durante a configuração. Os desenvolvedores também não
precisam passar horas aprendendo a usar cada uma das diferentes ferramentas, porque
cada utilitário está localizado no mesmo Workbench. Isso é especialmente útil quando há
desenvolvedores novos em um projecto. Eles podem contar com o IDE para se
actualizar em relação às ferramentas e fluxos de trabalho da equipe. (RedHat, 2021).
NetBeans v12.3
A IDE NetBeans é um ambiente de desenvolvimento multiplataforma, uma ferramenta

que auxilia programadores a escrever, compilar, depurar e instalar aplicações, foi
arquitectada em forma de uma estrutura reutilizável que visa simplificar o
desenvolvimento e aumentar a produtividade pois reúne em uma única aplicação todas
estas funcionalidades. Totalmente escrita em Java o NetBeans também funcionará
perfeitamente em qualquer plataforma operacional, sem a necessidade de ajustar o
esquema de codificação dos usuários. Ele também fornece um grande número de
ferramentas de edição que podem funcionar em diferentes linguagens, como JavaScript,
XML e HTML. (Wielenga, 2015).
1.4.3. Framework
Framework é uma definição que vai além do mercado de software. Em outros contextos,
refere-se a uma série de acções e estratégias que visam solucionar um problema bem
específico. Assim, quando se deparam com esse cenário, os profissionais recorrem a um
conjunto pronto de abordagens e optimizam os seus resultados. Na área de tecnologia, a
definição é semelhante, mas de acordo com os aspectos técnicos de programação de
sistemas. Trata-se de uma série de bibliotecas e classes — ou seja, códigos prontos —
que oferecem alguma funcionalidade específica. Em outras palavras, é um padrão que
pode ser incorporado a sistemas para agilizar a codificação de certas partes. (Noleto,
2020).
JavaFX v11
16
O JavaFX é o ambiente GUI (Graphical User Interface) mais recente que o Java usa.
Seus predecessores incluem AWT e Swing. Swing é um kit de ferramentas GUI que
tornou a criação de GUIs com Java muito mais fácil. Ainda é muito usado no mundo de
hoje, mas não está mais sendo desenvolvido activamente. (Ball, 2017).
(Ball, 2017) Afirma que de acordo com a Oracle, JavaFX é “um conjunto de pacotes
gráficos e de mídia que permite aos desenvolvedores projectar, criar, testar, depurar e
implantar aplicativos cliente ricos que operam consistentemente em diversas
plataformas.” Em outras palavras, o JavaFX é a forma mais recente de criar Aplicativos
GUI com Java.
1.4.4. Bibliotecas
FontAwesome v4.7.0-9.1.2
FontAwesome é um conjunto de ferramentas de fontes e ícones com base em CSS e

LESS. Foi feito por Dave Gandy para uso com o Twitter Bootstrap e mais tarde foi
incorporado no BootstrapCDN. FontAwesome tem uma participação de mercado de 20%
entre os sites que usam Font Scripts de terceiros em sua plataforma, classificando o
segundo lugar após o Google Fonts. (FontAwesome, 2017).
Os ícones FontAwesome podem ser usados nas aplicações desktop. Adicione ícones a
seus modelos de design, apresentações e outros lugares. Tentamos tornar isso muito
fácil com nossos novos arquivos de fonte baseados em ligadura. E para os momentos
em que você precisa de mais, incluímos versões SVG de vector polido de cada ícone
separadamente. (FontAwesome, 2017).
JFeonix 8.0.7
JFoenix é uma biblioteca Java de código aberto, que implementa o Google Material
Design usando componentes Java. (JFeonix, 2017).
1.4.5. Sistema de gestão de banco de dados
Um SGBD - Sistema de Gerenciamento de Banco de Dados é uma colecção de

programas que permitem ao usuário definir, construir e manipular Bancos de Dados para
as mais diversas finalidades. (Milani, 2006).
MySQL v8.0.21
17
O MySQL é um sistema de gestão de bases de dados relacionais, suporta SQL, é Open
Soure e é um dos SGBDs para utilização profissionais mais utilizados (conta com mais
de 5 milhões de instalações activas) e mais conhecido a nível mundial. O MySQL foi
desenvolvido e é disponibilizado pela empresa MySQL AB Limited Company, que
actualmente vende um conjunto de serviços e produtos relacionados com a tecnologia
MySQL. (Neves, et al., 2005).
Para (Milani, 2006) as principais características do MySQL são:
a) O servidor de banco de dados MySQL é extremamente rápido, confiável, e fácil de

usar. O Servidor MySQL também tem um conjunto de recursos muito práticos
desenvolvidos com a cooperação dos próprios usuários.
b) O Servidor MySQL foi desenvolvido originalmente para lidar com bancos de dados
muito grandes de maneira muito mais rápida que as soluções existentes, e tem
sido usado em ambientes de produção de alta demanda por vários anos de
maneira bem-sucedida. Apesar de estar em constante desenvolvimento, o
Servidor MySQL oferece hoje um rico e proveitoso conjunto de funções. A
conectividade, velocidade, e segurança fazem com que o MySQL seja altamente
adaptável para acessar bancos de dados na Internet.
c) MySQL é um Sistema de Gerenciamento de Bancos de Dados relacional. Um
banco de dados relacional armazena dados em tabelas separadas em vez de
colocar todos os dados em um só local. Isso proporciona velocidade e
flexibilidade. SQL é a linguagem padrão mais comum usada para acessar bancos
de dados e é definida pelo Padrão ANSI/ISO SQL. (O padrão SQL vem evoluindo
desde 1986 e existem diversas versões disponibilizadas).
d) MySQL é um software cujo código fonte é aberto. Código fonte aberto significa
dizer que é possível para qualquer um usar e modificar o programa. Qualquer
pessoa pode fazer download do MySQL pela Internet e usá-lo sem pagar nada (o
MySQL só é cobrado em alguns poucos casos). Se você quiser pode estudar o
código fonte e alterá-lo para adequá-lo às suas necessidades. O MySQL usa a
GPL (GNU General Public License - Licenca Pública Geral GNU) para definir o
que você pode e não pode fazer com o software em diferentes situações. Se você
sentir desconforto com a GPL ou precisar embutir o MySQL em uma aplicação
comercial você pode adquirir a versão comercial licenciada.
18
e) O MySQL suporta diferentes plataformas, tais como: Windows, Linux, Mac OS,
Unix, entre outros.
O MySQL é um bom sistema gestor de banco de dados, possui diversos recursos, além
de ser fácil integrar com o Java, razão pela qual será usado como SGBD.
1.4.6. Ferramentas de modelagem com UML
A UML (Unified Modeling Language) é uma linguagem para especificação, construção,

visualização e documentação de artefactos de um sistema de software intensivo. É uma
linguagem gráfica para análise, especificação e construção de sistemas para representar
projectos orientados a objectos utilizando uma notação comum. (Booch, et al., 2005).
Além de flexível, a UML é extensível e independente de processos ou linguagens de

programação, o que garante a liberdade para o desenvolvedor adaptar qualquer
processo, metodologia ou linguagem de programação sem deixar de expressar-se
claramente para os seus usuários e outros desenvolvedores, pois utiliza uma notação
padrão, comum a todos os ambientes.
A UML possui quinze diagramas, divididos em dois grupos:
 Diagramas estruturais, que descrevem os elementos estruturais que compõem o

sistema, representando suas partes e seus relacionamentos;
 Diagramas de comportamento, ou dinâmicos, que descrevem o
comportamento dos elementos e suas interacções.
19
Figura 1.2 – Diagramas UML. Fonte: (Elaboração própria).
Visual Paradigm
Visual Paradigm é uma ferramenta CASE voltada para UML (Unified Modeling
Language), sendo possível através dela trabalhar com os diversos diagramas da UML
2.0, como diagramas de caso de uso, diagramas de classes e diagramas de sequência,
dentre outros. Além disto, a Visual Paradigm, nas versões Professional e Enterprise,
possui ferramentas de auxílio ao mapeamento do modelo de classes para o modelo de
dados relacional sendo, inclusive, capaz de gerar suas tabelas (Paradigm, 2017).
Por ser uma ferramenta com o conceito de projecto, dá a possibilidade de trabalhar com
diversos diagramas, os quais serão usados para compor a documentação do projecto. A
Visual Paradigm apresenta algumas vantagens que são:
 Tem uma interface muito intuitiva e de fácil aprendizagem para os

desenvolvedores.
 Permite a geração automática de diagramas a partir da descrição de casos de
uso.
 Permite fazer descrição dos casos de usos fornecendo uma grande variedade das
janelas predeterminadas permitindo personalizá-las.
20
 Combina as funcionalidades de todas as edições em uma ampla plataforma da
modelagem visual.
1.4.7. Ferramentas auxiliares para o desenvolvimento
Para podermos rodar o MySQL de forma local em um computador pessoal é escolhido o

usar o Xampp, porque é fácil de executar, funciona para os mais diversos sistemas
operativos e tem um óptimo suporte para quem trabalha com o MySQL.
XAMPP v3.3.0
XAMPP é um software de código aberto desenvolvido pela Apache Friends. O pacote

de software XAMPP contém distribuições Apache para servidor MySQL, Apache,
MariaDB, PHP e Perl. E é basicamente um host local ou um servidor local. Este servidor
local funciona em seu próprio computador desktop ou laptop. O uso do XAMPP é para
testar os clientes ou seu site antes de enviá-lo para o servidor web remoto. Este software
de servidor XAMPP oferece um ambiente adequado para testar projectos MYSQL, PHP,
Apache e Perl no computador local. (Ganesan, 2021).
As tecnologias e ferramentas de desenvolvimento de software supracitadas foram

seleccionadas pelas vantagens, potencialidades, facilidades que estas apresentam.
1.5. Conclusões parciais do capítulo
A realização de um estudo dos principais conceitos que constituem a base teórica do

tema de investigação permitiu ter uma melhor percepção e discernimento dos conceitos
arrolados ao objecto de estudo.
A análise de outros sistemas existentes a nível nacional e internacional, e tendências

actuais permitiu perceber que os sistemas analisados não possuem as características
necessárias para a gestão de estoque e facturação na Gráfica Dart.
A análise das ferramentas e tecnologias nas quais se apoia para a solução, permitiu
escolher as tecnologias, metodologia de desenvolvimento de software e ferramentas que
mais se adequam para o desenvolvimento da solução proposta. Escolheu-se como
SGBD o MySQL e como servidor local o Xampp para rodar o MySQL, a linguagem de
programação será o Java, a modelagem dos diagramas será feita com o Visual
21
Paradigm, a metodologia de desenvolvimento será o OpenUp e o ambiente de
desenvolvimento será o NetBeans.
22
Capítulo 2: Características do sistema
Este capítulo é responsável por explicar e informar sobre os artefactos usados para a
concepção do sistema, descrever os requisitos funcionais e não funcionais do sistema, e
por fim descrever o fluxo dos processos através dos diagramas e modelos, ilustrando
assim a estrutura interna do sistema.
2.2. Objecto de automação
O sistema proposto tem a finalidade automatizar os processos de gestão de estoque e

faturação bem como a emissão de relatórios fiáveis para auxiliar no processo de
administração da Gráfica Dart. Daí a necessidade de antes de ser iniciado o processo de
desenvolvimento da solução proposta procurar conhecer de forma minuciosa em qual
especialidade de negócio o mesmo será implementado, a análise e modelagem do
negócio é o processo pelo qual se consegue fazer o que foi referido.
2.3. Modelagem do negócio
A modelagem de sistemas de negócio é uma área que tem sido fortemente sugerida pela
comunidade de Engenharia de Software, na busca de minimizar as discrepâncias
existentes entre a visão dos especialistas de tecnologias de informação, na construção
dos produtos de software, e as reais necessidades do negócio, vista pela óptica dos
stakeholders na obtenção de um produto. (Monteiro, 2003).
Desse modo, existe uma considerável motivação na aplicação de técnicas de

modelagem de sistemas de negócio com o intuito de claramente retratar e direcionar a
construção de produtos de software com qualidade.
Métodos de modelagem de sistemas de negócio representam um negócio e capturam as

suas operações sem considerar as limitações técnicas da tecnologia da informação.
Nesse contexto, para cada modelo. (Monteiro, 2003).
2.3.1. Modelo de domínio
É uma representação visual de classes conceituais ou objetos do mundo real em um

domínio de interesse. Usa a notação UML, o modelo de domínio é ilustrado com um
23
conjunto de diagramas de classes nos quais não são definidas operações.
(Baranauskas, 2018). Ele deve mostrar:
 Objetos do domínio ou classes conceituais;

 Associações entre classes conceituais;
 Atributos de classes conceituais.
O modelo de domínio é fundamentalmente representado por diagramas de classes em

UML.
O objetivo da modelagem de domínio é compreender e descrever as classes mais

importantes dentro do contexto do sistema.
Figura 2.1 – Diagrama de domínio. Fonte: (Elaboração própria)
Descrição das classes do modelo de domínio:
 Estoque: Representa a quantidade física existente na Gráfica Dart.

24
 Gerente: Representa a entidade que efectua os registros das compras e controle
de vendas.
 Fornecedor: Representa as empresas que vendem os produtos à Gráfica Dart.
 Produto: Representa os materiais existentes em estoque.
 Clientes: Representa os compradores dos produtos da Gráfica Dart.
 Entrada: Representa o registo dos produtos comprados ao fornecedor.
 Saída: Representa o registo dos produtos solicitados pelo caixa a serem vendidos
aos clientes.
 Caixa: Representa os operadores que fazem o registros das vendas.
2.3.2. Descrição dos trabalhadores e atores do negócio
Trabalhador do negócio
Um trabalhador de negócio representa uma abstracção de um humano que atua dentro

do negócio. Um objecto trabalhador de negócios interage com outros objectos
trabalhadores de negócios e manipula os objectos de entidades de negócios para
realizar uma instância de casos de uso de negócios. (Walderson, 2006).
As características de um trabalhador de negócio:
 Seu nome e a descrição são claros e podem ser entendidos.

 Cada trabalhador de negócios tem uma associação com as entidades de negócios
que precisa conhecer.
 Cada trabalhador de negócios tem um link com os outros trabalhadores de
negócios com os quais deve se comunicar.
 As relações de um trabalhador de negócios não dependem umas das outras.
 Cada trabalhador de negócio participa de pelo menos uma realização de caso de
uso de negócios.
 Cada relacionamento é usado no fluxo de trabalho de pelo menos uma realização
de caso de uso de negócios.
 Cada operação do trabalhador de negócio é executada no fluxo de trabalho de
pelo menos uma realização de caso de uso de negócios.
Actores do negócio
25
Actores são usuários e/ou outros meios externos que desenvolvem algum papel em
relação ao sistema. Os meios externos são hardwares e/ou softwares que, assim como
os usuários, geram informações para o sistema ou necessitam de informações geradas a
partir do sistema. (Nogueira, 2021).
2.3.3. Diagrama de casos de uso do negócio
Os casos de uso são uma técnica de descoberta de requisitos introduzida inicialmente

no método Objectory (Jacobson, et al., 1993). Eles já se tornaram uma característica
fundamental da linguagem de modelagem unificada (UML). Em sua forma mais simples,
um caso de uso identifica os atores envolvidos em uma interação e dá nome ao tipo de
interação. Essa é, então, suplementada por informações adicionais que descrevem a
interação com o sistema. A informação adicional pode ser uma descrição textual ou um
ou mais modelos gráficos, como diagrama de sequência ou de estados da UML.
(Sommerville, 2011).
Os casos de uso são documentados por um diagrama de casos de uso de alto nível. O
conjunto de casos de uso representa todas as possíveis interações que serão descritas
nos requisitos de sistema. Atores, que podem ser pessoas ou outros sistemas, são
representados como figuras ‘palito’. Cada classe de interação é representada por uma
elipse. Linhas fazem a ligação entre os atores e a interação. (Sommerville, 2011).
Figura 2.2 – Diagrama de casos de uso de negócio. Fonte: (Elaboração própria)
2.3.4. Descrições de casos de uso do negócio
A Tabela 2.1 mostra a descrição do caso de uso para o negócio. No caso de uso, o ator
cliente e o trabalhador do operador de caixa interagem, para realizar a ação de venda
de um produto, o que permite explicar qual é o objetivo do caso de uso.
Tabela 2.1 - CUN: Solicitar produto
26
Caso de uso: Solicitar produto
Atores: Cliente
Trabalhadores: Operador de caixa
Resumo: O processo de compra de um produto é dado pala interação entre o Cliente e o
Agente de caixa da gráfica.
Fluxo normal de eventos
Ator Trabalhador
1. Solicita o produto. 1. 2. Seleciona os produtos, adiciona ao carrinho e
pergunta a forma de pagamento.
2. 3. Diz o método de pagamento e efectua 3.
o 4. Entrega os produtos e finaliza a venda.
pagamento.
Fluxo alternativo de eventos
Ator Trabalhador
1. 1. Solicita o produto. 2. 2. Pede os dados pessoais do cliente.
3. 2. Entrega os dados pessoais. 4. 3. Efectua o cadastro do cliente, adiciona os
produtos no carrinho e pergunta a forma de
pagamento.
pagamento.
A Tabela 2.2 mostra a descrição do caso de uso para o negócio. No caso de uso, o ator
cliente e o trabalhador do operador de caixa interagem, para realizar a ação de venda
de um serviço, o que permite explicar qual é o objetivo do caso de uso.
Tabela 2.2 - CUN: Solicitar serviço

Caso de uso: Solicitar serviço
Atores: Cliente
Trabalhadores: Operador de caixa
Resumo: O processo de compra de um serviço é dado pala interação entre o Cliente e o
Agente de caixa da gráfica.

Ator Trabalhador
1. Solicita o serviço 4. 2. Seleciona os serviços, adiciona ao carrinho e
pergunta a forma de pagamento.
pagamento.
Fluxo alternativo de eventos
Ator Trabalhador
7. 1. Solicita o serviço. 8. 2. Pede os dados pessoais do cliente.
9. 2. Entrega os dados pessoais. 10. 3. Efectua o cadastro do cliente, adiciona os
produtos no carrinho e pergunta a forma de
pagamento.
27
pagamento.
2.4. Modelagem do sistema
Modelagem de sistema é o processo de desenvolvimento de modelos abstractos de um

sistema, em que cada modelo apresenta uma visão ou perspectiva, diferente do sistema.
A modelagem de sistema geralmente representa o sistema com algum tipo de notação
gráfica, que, atualmente, quase sempre é baseada em notações de UML (linguagem de
modelagem unificada, do inglês Unified Modeling Language). Os modelos são usados
durante o processo de engenharia de requisitos para ajudar a extrair os requisitos do
sistema; durante o processo de projecto, são usados para descrever o sistema para os
engenheiros que o implementam; e, após isso, são usados para documentar a estrutura
e a operação do sistema. (Sommerville, 2011).
Você pode desenvolver modelos do sistema existente e do sistema a ser desenvolvido:
 Modelos do sistema existente são usados durante a engenharia de requisitos.

Eles ajudam a esclarecer o que o sistema existente faz e podem ser usados como
ponto de partida para discutir seus pontos fortes e fracos. Levam, então, os
requisitos para o novo sistema.
 Modelos do novo sistema são usados durante a engenharia de requisitos para
ajudar a explicar os requisitos propostos para outros stakeholders do sistema. Os
engenheiros usam esses modelos para discutir propostas de projecto e
documentar o sistema para a implementação. Em um processo de engenharia
dirigida a modelos, é possível gerar uma implementação completa ou parcial do
sistema a partir do modelo de sistema.
2.4.1. Requisitos funcionais
Na engenharia de software, um requisito funcional define um sistema ou seu

componente. Ele descreve as funções que um software deve executar. Uma função nada
mais é do que entradas, seu comportamento e saídas. Pode ser um cálculo,
manipulação de dados, processo de negócios, interação com o usuário ou qualquer
outra funcionalidade específica que defina a função que um sistema provavelmente
desempenhará. (Krishna, 2019).
28
A Tabela 2.3 mostra os requisitos do sistema.
Tabela 2.3 - Requisitos funcionais
Categoria Requisitos funcionais Complexidade Prioridade
Produto RF1. Cadastrar produto Média Alta
RF2. Editar produto Média Alta
RF3. Eliminar produto Alta Baixa
RF4. Consultar produto Média Média
Funcionário RF5. Cadastrar funcionário Média Alta
RF6. Editar funcionário Média Alta
RF7. Eliminar funcionário Baixa Média
RF8. Consultar funcionário Média Média
Cliente RF9. Cadastrar cliente Alta Média
RF10. Editar cliente Baixa Alta
RF11. Eliminar cliente Média Baixa
RF12. Consultar cliente Média Média
Fornecedor RF13. Cadastrar fornecedor Alta Média
RF14. Editar fornecedor Baixa Média
RF15. Eliminar fornecedor Média Baixa
RF16. Consultar fornecedor Baixa Alta
Serviço RF17. Cadastrar serviço Alta Alta
RF18. Editar serviço Baixa Média
RF19. Eliminar serviço Média Baixa
RF20. Consultar serviço Alta Alta
Despesa RF21. Cadastrar despesa Média Média
RF22. Editar despesa Baixa Média
RF23. Eliminar despesa Alta Baixa
29
RF24. Consultar despesa Alta Média
RF25. Cadastrar usuário Alta Alta
Usuário RF26. Editar usuário Baixa Média
RF27. Eliminar usuário Média Média
RF28. Consultar usuário Baixa Baixa
RF29. Autenticar usuário Baixa Média
Caixa RF30. Abertura de caixa Alta Alta
RF31. Efectuar venda Alta Alta
RF32. Fecho de caixa Média Alta
RF33. Anular venda Alta Média
RF34. Devolução Média Média
Estoque RF35. Entrada de quantidades Média Média
RF36. Saída de quantidades Alta Alta
RF37. Consultar estoque Média Alta
RF38. Verificar movimentações Alta Alta
RF39. Verificar facturas de compras Média Média
Relatórios RF40. Visualizar vendas diário Média Alta
RF41. Visualizar vendas Mensal Alta Alta
RF42. Visualizar venda Anual Média Baixa
RF43. Visualizar vendas por operador de caixa Média Média
RF44. Visualizar vendas por cliente Média Baixa
RF45. Visualizar existência em estoque Média Baixa
RF46. Visualizar compras ao fornecedor Média Baixa
2.4.2. Requisitos não funcionais
Um requisito não funcional define o atributo de qualidade de um sistema de software.

Eles representam um conjunto de padrões usados para julgar a operação específica de
um sistema. Exemplo, quão rápido o site carrega? Um requisito não funcional é
30
essencial para garantir a usabilidade e eficácia de todo o sistema de software. Deixar de
atender aos requisitos não funcionais pode resultar em sistemas que não atendem às
necessidades do usuário. (Krishna, 2019).
A Tabela 2.4 mostra os requisitos não funcionais do sistema.
Tabela 2.4 - Requisitos não funcionais

Tempo de resposta
 RNF1 - O Sistema não deverá fazer mais de 10 segundos para iniciar a sessão de usuário.
 RNF2 - Ao efetuar uma consulta, o sistema não deve demorar mais de 10s
Segurança
 RNF3 - Confidencialidade: O Acesso a informação do sistema está limitado a usuários

autorizados.
 RNF4 - Integridade: Os dados do sistema só poderão ser apagados ou modificados por
usuários autorizados.
 RNF5 - O acesso a dados em um período razoável de tempo
 é garantido para usuários autorizados.
Usabilidade
 RNF6 - O sistema deve ser intuitivo e fácil de utilizar.

Aparência
 RNF7 - A boa organização das informações é garantida para permitir a interpretação correta.
Hardware
 RNF8 - Servidores de Aplicação e banco de dados: O servidor onde será implantada a

aplicação e o banco de dados deverá ser um Intel Core I3, com uma velocidade de 1.90GHz,
3GB de RAM e 240 GB de disco duro.
 RNF9 - Computador Cliente: os requisitos mínimos para o cliente são: Processador Intel
Celeron 1,80 GHz, com 2 GB de RAM e 120 GB de disco duro.
Software
 RNF10 - Foi desenvolvido usando o Java, na sua versão 8.

 RNF11 - O sistema gerenciador de base de dados deve ser o MySQL.
 RNF12 - Deve ter instalado o Xampp, para poder rodar o servidor de banco de dados de
forma local.
31
2.4.3. Diagrama de casos de uso do sistema
Diagrama de caso de uso do sistema é uma técnica de representação gráfica usada para
descrever os requisitos funcionais do sistema. Estão representados em termos de
actores externos ao sistema e casos de usos. Os actores do sistema representam o
papel de uma entidade externa ao sistema como um usuário, um hardware ou outro
sistema que interaja com o sistema modelado e o caso de uso do sistema representa
uma sequência de acções realizadas pelo sistema e recebe do actor que o utiliza dados
tangíveis de um tipo e formato já conhecido e o valor da resposta da execução de um
caso de uso é também um tipo já conhecido. É por meio do caso de uso que os actores
iniciam a comunicação com o sistema (Burgués, 2016).
O diagrama de casos de uso do sistema tem como objectivo ilustrar as principais

funções do sistema de modo geral, depois de feita a análise e levantamentos dos
requisitos do sistema.
Figura 2.3 – Diagrama de casos de uso de sistema. Fonte: (Elaboração própria).
2.4.4. Descrição de casos de uso do sistema

Tabela 2.5 - Descrição do caso de uso do sistema – Autenticar usuário
Caso de uso: Autenticar usuário
Atores: Gerente e operador de caixa.
Resumo: Permite ao usuário acessar o sistema.
32
Pré-condição Deve estar cadastrado no sistema.
Referência RF RF29
Prioridade Alta
Resposta do sistema Acção do ator
1. O sistema exibe a tela de autenticar (Inicio de
1. 2. O usuário preenche os dados de autenticação
sessão). (nome de usuário e senha). O usuário clica no botão
login (E1).
Fluxo de exceção E1
2. 1. O sistema exibe que a senha ou o usuário está
3. 2. Se o usuário e a senha estiverem correctos, é
errado, mostrando uma mensagem de erro. redirecionado a tela do sistema.
Protótipo de interface
Tabela 2.6 - Descrição do caso de uso do sistema - Gerenciar cliente

Caso de uso: Gerenciar cliente
Atores: Gerente
33
Resumo: Permite ao gerente efectuar no sistema as operações de: inserir cliente, editar
cliente, eliminar cliente, pesquisar cliente.
Pré-condição O gerente deve ter a sessão iniciada no sistema
Referencia RF RF9 à RF12
Acções do sistema Acção do ator
1. O sistema exibe a tela principal. 4. 2. O gerente clica no menu “Clientes”, de seguida
será mostrado tabelas com clientes já cadastrados e
opções de cadastrar, editar e pesquisar e o gerente
clica em “Cadastrar”.
3. O sistema abre um formulário de cadastro. 5. 4. O gerente preenche o formulário com os dados
pessoais do cliente e clica em “Cadastrar” (E1).
5. O sistema mostra uma mensagem de que o cliente
6. 6. O gerente clica em “Ok” e termina o caso de Uso.
foi cadastrado com sucesso.
Fluxo de exceção(E1)
7. 1. O sistema exibe mensagens de erro e não permite
8. 2. Se os dados estiverem completos mostra uma
cadastrar se os dados estiverem incompletos. mensagem de que o cliente foi cadastrado com
sucesso.
Tabela 2.7 - Descrição do caso de uso do sistema - Gerenciar vendas

Caso de uso: Gerenciar vendas
34
Atores: Gerente e operador de caixa
Resumo: Permite ao operador de caixa efectuar no sistema as operações de: inserir venda,
anular venda, pesquisar venda.
Pré-condição O operador de caixa deve ter a sessão iniciada no sistema
Referencia RF RF31
Acções do sistema Acção do ator
1. O sistema exibe a tela principal de vendas. 9. 2. O operador de caixa clica em “Novo documento”.
3. O sistema exibe uma tabela com os vários tipos de
10. 4. O operador de caixa seleciona um tipo de
documento (“…”) que ele pode efectuar. documento de venda que pode efectuar e clica em
“Ok”.
5. O sistema mostra a tabela “escolher produtos” com
11. 6. O operador de caixa adiciona os produtos ao
(código, quantidade, nome, preço). carrinho do cliente e clica em pagamento.
7. O sistema exibe uma tabela com os métodos de
12. 8. O operador de caixa seleciona o método de
pagamento. pagamento e finaliza a venda.
13.
Com a elaboração deste capítulo obteve-se as seguintes conclusões parciais:
 Com a modelagem do negócio que permitiu se obter um melhor entendimento dos

processos realizados pela Gráfica Dart e com isto, identificar os actores do
35
negócio, caso de uso do negócio e descrever os casos de uso de negócio, que
culminou com a determinação sobre a abrangência do problema de modos a se
buscar uma solução de acordo com a situação apresentada;
 Com a modelagem e especificação dos requisitos do sistema permitiu definir as
funcionalidades do sistema e determinar as características e o comportamento do
sistema.
36
Capítulo 3: Desenho, implementação e provas do sistema
Neste capítulo serão abordados assuntos relacionados com o desenho, desenvolvimento
e provas do sistema, desta feita se realizou a modelação detalhada com a aplicação de
padrões de desenho e a construção da estrutura do sistema informático obtendo como
artefactos o diagrama de classes, arquitectura do sistema, modelo logico do banco de
dados, diagrama de implantação, e finalmente documentam-se as provas realizadas
sobre o sistema, feita para verificar se o sistema corresponde ao que foi especificado e
detectar possíveis falhas no sistema informático.
3.1. Diagrama de classes
O diagrama de classes é utilizado na construção do modelo de classes desde o nível de

análise até o nível de especificação. De todos os diagramas da UML, esse é o mais rico
em termos de notação (Bezzera, 2004).
O diagrama de classes é o principal bloco de construção da modelagem orientada a

objetos. Ele é usado para modelagem conceitual geral da estrutura do aplicativo e para
modelagem detalhada traduzindo os modelos em código de programação. (Sparks,
2011).
As classes são representadas de forma ilustrada por uma caixa dividida em três partes,
sendo a primeira o nome da classe, a segunda os atributos e por último as operações.
Os atributos correspondem às informações que um objeto armazena e as operações são
as ações que o mesmo realiza.
De seguida a figura 3.1 é apresenta o diagrama de classes modelado para o sistema

informático:
37
Figura 3.1 – Diagrama de classes. Fonte: (Elaboração própria).
3.2. Arquitectura do sistema
A arquitetura de um sistema é a estrutura de componentes de um programa/sistema, os

relacionamentos entre esses componentes, os princípios e diretrizes que governam os
projectos e a evolução dos softwares (Nakagawa, 2013).
É a estrutura ou as estruturas do sistema, que incluem componentes do software, as

propriedades visíveis externamente desses componentes e as relações entre eles
(Pressman, 2011).
Arquitectura por camadas
Para o desenvolvimento do Sistema a arquitectura a utilizar será a arquitectura por

camadas distribuídas por camada de Modelo, camada de Vista e camada de
Controlador. Este padrão de camadas permite dividir a aplicação em três componentes:
o Modelo, a Vista e o Controlador. O Modelo se encarrega de administrar o
comportamento e os dados do domínio de aplicação, responder as requisições de
informação sobre seu estado e as instruções de mudança do mesmo. A Vista maneja a
visualização da informação, em quanto o Controlador analisa as mensagens de eventos
que recebe do sistema, modifica ou obtém dado do componente Modelo em resposta as
petições do usuário (Rodrigues, 2008).
38
 Modelo: Essa classe também é conhecida como Business Object Model (objeto
modelo de negócio). Sua responsabilidade é gerenciar e controlar a forma como
os dados se comportam por meio das funções, lógica e regras de negócios
estabelecidas.
 Vista: Essa camada é responsável por apresentar as informações de forma visual
ao usuário.
 Controlador: A camada de controle é responsável por intermediar as requisições
enviadas pela Vista com as respostas fornecidas pelo Model, processando os
dados que o usuário informou e repassando para outras camadas.
O objectivo do padrão é separar as classes que descrevem o modelo e a lógica de

negócios das classes que realizam a interface com o usuário, permitindo que ambas
evoluem de forma independente. Com esta separação, é possível conceber uma
aplicação que se torne independente da sua apresentação.
Figura 3.2 – Arquitetura MVC (Modelo Vista Controlador). Fonte: (Elaboração própria).
Durante o desenvolvimento a arquitetura para estruturação do sistema foi usado da

seguinte forma como nos apresenta à Figura 3.3.
39
Figura 3.3 – Demonstração da aplicação da arquitetura MVC. Fonte: (Elaboração própria).
3.3. Padrão de desenho utilizado
Um Padrão de Projecto (Design Pattern), é uma solução geral para um problema que
ocorre com frequência dentro de um determinado contexto no projecto de software. Um
padrão de projecto não é um projecto finalizado que pode ser diretamente transformado
em código fonte ou de máquina, ele é uma descrição ou modelo (template) de como
resolver um problema que pode ser usado em muitas situações diferentes. Padrões são
melhores práticas formalizadas que o programador pode usar para resolver problemas
comuns quando projetar uma aplicação ou sistema. (CanalTI, 2017).
Um padrão de desenho é uma descrição de classes e objetos comunicando-se entre si,

adaptada para resolver um problema de desenho geral em um contexto particular.
40
Para o projecto da aplicação, foram utilizados diferentes padrões de projecto,
classificados em dois grupos, padrões GRASP (General Responsibility Assignment
Software Patterns):
Padrões GRASP
São formados por princípios/padrões que servem de base para a atribuição de

responsabilidades em um projecto orientado a objetos. (Craig, 2007).
Criador (Creator)
O padrão criador faz a atribuição a uma classe a responsabilidade de criação de objetos

de outra classe. O padrão do criador foi utilizado na criação de objectos Funcionários em
um momento específico, a classe Funcionário é responsável por inserir o objecto do tipo
funcionário através do registro na camada de persistência e retorno de um resultado
booleano (true), caso o método seja invocado. O padrão criador faz a atribuição a uma
classe a responsabilidade de criação de objetos de outra classe. O padrão do criador foi
utilizado na criação de objectos Funcionários em um momento específico, a classe
Funcionário é responsável por inserir o objecto do tipo funcionário através do registro na
camada de persistência e retorno de um resultado booleano (true), caso o método seja
invocado.
Figura 3.4 – Código fonte da classe Funcionário. Fonte: (Elaboração própria).
41
Benefício:
 Não aumenta o acoplamento, pois a visibilidade entre as classes envolvidas já

existia.
Alta coesão (High Cohesion)
Trata-se do conceito onde uma classe deve fazer apenas o que faz sentido para ela. A
alta coesão no projeto foi garantida através da grande modularização em suas classes,
garantindo assim que cada classe tem a responsabilidade única de comunicar os dados
da sua entidade referente da aplicação para o banco de dados e vice-versa. Como por
exemplo, a classe Produto (que cuida somente de funções relacionadas a ela, como por
exemplo, listar todos os produtos existentes).
A alta coesão é aplicada no trabalho, e como podemos ver na classe produto como nos
apresenta a figura 3.5.
42
Figura 3.5 - Código fonte da classe Produto. Fonte: (Elaboração própria).
Benefícios:
 Clareza e facilidade de compreensão do projecto.

 Simplificação das atividades de manutenção.
 Favorecimento indireto do baixo acoplamento.
 Facilidade de reutilização, graças à classe ser muito específica.
Polimorfismo (Polymorphism)
É o princípio do qual as subclasses de uma hierarquia são capazes de invocar métodos

com mesma assinatura, mas com comportamentos diferentes. Atribuir responsabilidades
as classes usando o polimorfismo é indicado quando o comportamento varia de acordo
com as classes. Como por exemplo a classe VisualizarController. Ela determina o
43
método pesquisar onde é feita a pesquisa de um produto, passando para isso, qualquer
objecto que seja uma instância de produto, é dessa forma que o polimorfismo é utilizado.
O polimorfismo é aplicado no trabalho no desenvolvimento de algumas classes, e como

podemos ver na classe VisualizarController como nos apresenta a figura 3.6.
Figura 3.6 – Código fonte da classe VisualizarController (Método Pesquisar). Fonte: (Elaboração própria)
Benefício:
 Facilidade de manutenção.
 Facilidade de inserção de um novo tipo de autorização.
3.4. Análise e desenho do banco de dados
3.4.1. Modelo logico do banco de dados
Um modelo de banco de dados mostra a estrutura lógica de um banco de dados,

incluindo as relações e restrições que determinam como os dados podem ser
armazenados e acessados. Modelos de banco de dados individuais são projetados com
base nas regras e nos conceitos do modelo de dados mais abrangente que os designers
44
adotam. A maioria dos modelos de dados pode ser representada por um diagrama de
banco de dados acompanhante. (Lucidchart, 2019).
Para o desenvolvimento da proposta de solução foi seleccionado o modelo relacional de

banco de dados porque é um modelo de dados representativo (ou de implementação),
adequado a ser o modelo subjacente de um Sistema Gerenciador de Banco de Dados,
que se baseia no princípio de que todos os dados estão armazenados em tabelas (ou,
matematicamente falando, relações).
Figura 3.7 – Modelo lógico do banco de dados. Fonte: (Elaboração própria).
3.5. Diagrama de implantação
No contexto da Linguagem de Modelagem Unificada (UML), um diagrama de

implementação faz parte da família de diagramação estrutural pois descreve o aspecto
do sistema em si. Neste caso, o diagrama de implementação descreve a implementação
física de informações geradas pelo programa de software em componentes de hardware.
(Lucidchart, 2019).
45
Figura 3.8 – Diagrama de implantação. Fonte: (Elaboração própria).
3.5.1. Descrição do modelo de implantação do sistema

Tabela 3.1 - Descrição dos dispositivos do diagrama de implantação
Nós/Dispositivos Descrição
PC Cliente Acedem a aplicação através de um computador, onde é executada

mediante um navegador disponível no computador, que tenha um sistema
operativo.
Servidor de banco de É o local onde os dados poderão ser armazenados, ele usa um sistema
dados gerenciador de banco de dados para este caso o MySQL.
Impressora Dispositivo usado para impressão de faturas, relatórios, e toda a

documentação ou arquivos.
Tabela 3.2 - Descrição dos conectores do diagrama de implantação
Conectores Descrição
USB Porta universal em português, permite a conexão da impressora com o PC

Cliente, e com os demais periféricos.
TCP/IP De uma forma simples, o TCP/IP é o principal protocolo de envio e

recebimento de dados MS. TCP significa protocolo de controle de
transmissão) e o IP, Internet Protocol (protocolo de internet).
46
3.6. Validação do sistema mediante provas
A metodologia ágil OpenUp precisa de um processo no fim da execução do sistema que

é o TDD (Test Driven Development), que permite fazer muita ênfase nas provas tanto de
unidade, como de integração e aceitação, ainda que permite qualquer outro tipo. Um
programador extremo deve sempre provar seu código de forma unitária, integrar
continuamente e fazer provas de aceitação com certa regularidade, cada vez que una
funcionalidade esta pronta.
Existem muitas maneiras de se testar um software, mas as técnicas de teste que serão
aplicadas são a técnica estrutural também conhecida como Prova de Caixa Branca e a
técnica funcional também conhecida como Prova de Caixa Preta.
3.6.1. Prova de caixa branca
A prova de caixa branca é um método de projecto de casos de testes voltado a testar a

estrutura interna do software. A prova de caixa branca, ao contrário da prova de caixa
preta, se preocupa em como o código fonte foi construído e a lógica de programação
utilizada no desenvolvimento dos métodos. A prova é totalmente realizada na estrutura
interna do software. (Pressman, 2005).
O teste de caixa branca (ou orientado por lógica), permite que você examinar a estrutura
interna do programa. Esta estratégia deriva teste dados de um exame da lógica do
programa (e muitas vezes, infelizmente, com a negligência da especificação). (Myers, et
al., 2012).
47
Figura 3.9 – Código fonte Guardar fatura. Fonte: (Elaboração própria).
Figura 3.10 – Gráfico do fluxo da prova de caixa branca. Fonte: (Elaboração própria)
O número máximo de casos de prova é calculado pela fórmula V(G)=A-N+2, onde A é o

número de arestas e N o número de nós do grafo.
V(G)= 10–9+2 = 3
Caminho: [1, 7, 8, 9]
48
Entrada: O usuário adiciona um novo produto.
Resultado: O sistema lança uma mensagem de alerta (“A data de entrega não pode
estar vazia”).
Caminho: [1, 2, 3, 4, 9]
Resultado: O sistema guarda o produto adicionado.
Caminho: [1, 2, 3, 5, 6, 9]
Resultado: O sistema lança uma mensagem de alerta (“O documento seleccionado está
invalido”).
3.6.2. Prova de caixa preta
Uma estratégia de teste importante é o teste de caixa preta (também conhecido como
teste orientado a dados ou orientado a entrada / saída). Para usar este método, veja o
programa como uma caixa preta. Seu objetivo é ficar completamente despreocupado
com o comportamento interno e a estrutura do programa. Em vez disso, concentre-se em
encontrar circunstâncias em que o programa não se comporta de acordo com suas
especificações. Nesta abordagem, os dados de teste são derivados exclusivamente das
especificações (ou seja, sem tirar proveito do conhecimento da estrutura interna do o
programa). (Myers, et al., 2012).
Prova de caixa preta também conhecido como teste comportamental, focaliza os

requisitos funcionais do software. As técnicas de teste de caixa preta permitem derivar
series de condições de entradas que utilizaram todos os requisitos funcionais para um
programa. O teste de caixa preta não é uma alternativa ao teste de caixa branca, em vez
disso é uma abordagem complementar, com possibilidade de descobrir uma classe de
erros diferente daquela obtida com métodos caixa branca (Pressman, 2005).
O teste de caixa preta tenta encontrar erros nas seguintes categorias:
 Funções incorretas ou faltando;

 Erros de interface;
 Erros de comportamentos ou desempenho;
49
 Erros de inicialização e término.
Tabela 3.3 - Descrição das provas de caixa preta.
Condições de entrada Classes de equivalência Válidas Classes de equivalências não válidas
O campo “Quantidade” Qtd. = “1” Qtd. =””

deve estar preenchido com
Qtd. =” -1”
um valor numérico
Qtd. =” Um”
positivo.
O campo “Desconto” é Desconto = “1000” Desconto = “-1000”

preenchido se existe
algum desconto.
Resultado da prova válida: O sistema apresenta o valor que o cliente deve pagar.
Resultados da prova não válida: O sistema apresenta uma mensagem de alerta para o usuário nos
casos em que: Quantidade e desconto com letras ou números negativos, e quando a quantidade é
superior ao estoque existente.
50
51
52
Resultado das provas de software
O gráfico acima ilustrado, mostra o resultado da aplicação das provas de software, com
objectivo de validar a funcionalidade “Adicionar produtos” e “Guardar produto”. Durante o
teste de caixa realizou-se cinco (5) iterações onde na primeira iteração foram detectadas
cerca de vinte e quatro (22) não conformidades, foram corrigidas quatro (4) não
conformidades, na segunda iteração, foram detectadas dezasseis (18) não
conformidades dentre estas oito (8) foram corrigidas, durante a terceira iteração,
detectou-se dez (10) não conformidades dentre estas seis (6) foram corrigidas, na quarta
iteração detectou-se quatro (4) não conformidades que foram corrigidas, foi possível
resolver todas as não conformidades, o que permitiu observar as funcionalidade testada,
para fosse possível a certificação da conclusão desta prova realizou-se a quarta e a
quinta iteração onde demostrou-se que a funcionalidade foi aprovada, pois não foram
detectadas inconformidade durante as iterações.
Figura 3.11 – Gráfico do resultado das provas de software
Neste capítulo foi analisado aspectos técnico ligados ao tema de investigação aonde
procurou-se demonstrar o funcionamento do sistema mediante diagramas de classe,
desenho do modelo lógico do banco de dados onde serão armazenados todos os dados
do sistema e consequentemente a demonstração do ambiente de implementação na
qual o sistema deve ser inserido.
53
Conclusões
Depois de elaborado o presente trabalho de investigação, realizou-se pesquisas com
enfoque aos objectivos específicos e nas tarefas propostas para a investigação, foram
tomadas as seguintes conclusões:
 Foi possível realizar o desenho teórico metodológico, o que permitiu sistematizar

os elementos teóricos e práticos relacionado ao processo de gestão de estoque e
faturação.
 O sistema desenvolvido apresenta-se solido as necessidades da gráfica, e para
isso utilizou-se algumas ferramentas e linguagens seleccionadas e como
metodologia ágil o OpenUp, seguindo os artefactos descritos pela metodologia,
com o objectivo de fazer o sistema em menos tempo, mas garantindo a sua
qualidade.
 Com o desenho e a implementação das funcionalidades requeridas para o
desenvolvimento do sistema de gestão de estoque e fatura, foi possível dar
resposta aos principais requisitos funcionais do sistema.
 Sugerimos a implementação do sistema o que poderá trazer para a Gráfica Dart
um maior controle sobre o fluxo dos processos de gestão de estoque e faturação.
 Com as provas de caixa branca e caixa preta foi possível validar o sistema para
que esse cumprisse com as exigências necessárias de funcionamento.
54
Recomendações
Após a conclusão do trabalho, constatou-se que os objetivos pelos quais foi criado foram
alcançados, para a continuidade recomenda-se o seguinte:
 Ampliar o sistema para as outras áreas de gestão da empresa como

contabilidade, recursos humanos e outras.
 Implantar o sistema na sua integra na Gráfica Dart.
 Desenvolver uma versão do sistema que funcione baseado na Web.
55
Referências bibliográficas
1. AWISE. 2020. QuantoSobra. QuantoSobra. [Online] AWISE SOLUÇÕES
TECNOLÓGICAS, 2020. https://www.quantosobra.com.br/.
2. Ball, Robert. 2017. Intruduction to JavaFX for Biginner Programmers. 2017.
3. Baranauskas. 2018. unicamp.br. unicamp.br. [Online] 2018.

https://www.ic.unicamp.br/~ariadne/mc436/1s2017/Lar10ModDom.pdf.
4. Booch, G., Rumbaugh, J. e Jacobson, I. 2005. The Unified Modeling Language

User Guid. 2nd ed. s.l. : Addison-Wesley Professional, 2005.
5. Chikán. 2007. The new role of inventories in business: Real world changes and
research consequences. Corvinus University of Budapest, Hungary : International
Journal od production Economics, 108(1-2), 2007.
6. Conceito.de. 2020. Conceito.de. Conceito.de. [Online] 2020. [Citação: 09 de

Junho de 2021.] https://conceito.de/gestao.
7. Conceito.De. 2020. Conceito.De. [Online] [Citação: 12 de 06 de 2021.]

https://conceito.de/sistema.
8. Conceito.De. 2018. Conceito.De. conceito.de. [Online] 2018. [Citação: 12 de

Junho de 2021.] https://conceito.de/sistema.
9. ComputerHope. 2021. Programming language. ComputerHope. [Online]

Computer Hope, 2021. https://www.computerhope.com/jargon/p/programming-
language.htm.
10. FIA. 2019. fia. fia. [Online] FIA - Fundação Instituto de Administração, 2019.
https://fia.com.br/blog/desenvolvimento-agil/.
11. FontAwesome. 2017. FontAwesome. FontAwesome. [Online] Fonticons, Inc,

2017. https://fontawesome.com/v5.15/how-to-use/on-the-web/referencing-icons/
basic-use.
12. Ganesan, Prabhu. 2021. What is Xampp. wpblogx. 2021, Vol. I.
56
13. Gomes, André Faria. 2013. Agile: Desenvolvimento de softeware com entregas
frequentes e foco no valor de negócios. São Paulo : Casa do Código, 2013.
14. Inforpédia. 2018. Inforpédia. Inforpédia. [Online] Porto Editora, 2018.

https://www.infopedia.pt/dicionarios/lingua-portuguesa/metodologia.
15. JFeonix. 2017. JFeonix. JFeonix. [Online] JFoenix, 2017.

http://www.jfoenix.com/documentation.html.
16. kwanzagest. 2020. kwanzagest. kwanzagest. [Online] GloboSoft LDA, 2020.

https://www.kwanzagest.co.ao/.
17. Lexos. 2021. Lexos. Lexos. [Online] Lexos Solução em Tecnologia LTDA , 2021.
https://www.lexos.com.br/.
18. Leite, Alessandro. 2006. devmedia. devmedia. [Online] DevMedia, 2006.

https://www.devmedia.com.br/metodologia-de-desenvolvimento-de-software/1903.
19. Leite. 2016. devmedia. devmedia. [Online] DevMedia, 2016.

https://www.devmedia.com.br/metodologia-de-desenvolvimento-de-software/1903.
20. Mendes, Douglas Rocha. 2009. Programação Java com Ênfase em Orientação a
Objectos. São Paulo : Novatec Editora Ltda, 2009. 978-85-7522-176-1.
21. Milani, André. 2006. MySQL Guia do Programador. São Paulo : Novatec Ltda ,
2006. 85-7522-103-5.
22. Monteiro, Ana Alice Spreafico do Nascimento. 2003. attena.ufpe. attena.ufpe.

[Online] Fevereiro de 2003.
https://attena.ufpe.br/bitstream/123456789/2476/1/arquivo4650_1.pdf.
23. Neves, Predo e Ruas, Rui. 2005. O Guia Prático do MySQL. Lisboa : Centro
Atlântico, Lda, 2005. 972-615-006-0.
24. Noleto, Cairo. 2020. Framework: o que é, como ele funciona e para que serve?
Betrybe. 2020, Vol. I.
25. Oracle. 2014. Oracle. Oracle. [Online] Oracle, 2014.

https://www.oracle.com/java/technologies/java8.html.
57
26. Pressbooks. 2019. Pressbooks. Pressbooks. [Online] Pressbooks, 2019.
[Citação: 12 de Junho de 2021.] https://bus206.pressbooks.com/chapter/chapter-
1/#footnote-5-3.
27. Palomeque, Condori, Condori, Raquel y Ticona e Fabiola, Shirley. 2015.

Comparación de metodologias. 2015.
28. Paradigm, Visual. 2017. Visual Paradigm. Visual Paradigm. [Online] Visual
Paradigm, 6 de Novembro de 2017. www.visualparadigm.com.
29. RamosSoft. 2019. ramossoft. ramossoft. [Online] RamoSoft Tecnologias, 2019.

https://www.ramossoft.com/product/winmarket-gestao-comercial/.
30. RedHat. 2021. RedHat. RedHat. [Online] RedHat, 2021.

https://www.redhat.com/pt-br/topics/middleware/what-is-ide.
31. Soares, Michel dos Santos. 2004. Metodologias Ágeis Extreme Programming e
Scrum para o Desenvolvimento de Software . Revista Electronica de Sistemas de
Informação. 2004.
32. Silva, Luciane da. 2014. OpenUp: um processo integrado e ágil. Medium. 2014.
33. Tersine. 1994. Principles of inventory and materials managment . New Jersey,
United States : PEARSON HIGHER EDUCATION, 1994. 0134578880.
34. Wielenga, Geertjan. 2015. Beginning NetBeans IDE for Java Developers.
Amsterdam, Noord-Holland : s.n., 2015. 978-1-6842-12-57-8.
58
Anexos
Anexo 1: Entrevista realizada
Entrevista com o dono da Gráfica Dart
Nome: José Filipe da Cunha
Função: Director Geral
1. Como é tratada a informação na Gráfica Dart?
R: Toda a informação é tratada de forma manual.
2. Como é feito o processo de vendas?
R: O processo de vendas é feito através de bloco de faturas.
3. Como é feito o processo de gestão de estoque?
R: As facturas dos fornecedores são guardadas e o registo de entradas e saídas são

feitos em Excel.
4. Quais são as principais dificuldades que têm enfrentado?
R: Dificuldade no controlo dos produtos, controlo dos clientes e relatórios.
5. O que têm feito para soluciona-las?
R: Pegando todos os ficheiros de Excel e os blocos de fatura para controlar todas as

entradas e saídas o que gera muita perca de dados.
6. Sabe o que é um sistema de gestão de estoque e faturação?
R: Já ouvi falar. É um sistema que faz a gestão do estoque e da faturação.
7. Sabe quais as vantagens de se utilizar um sistema de gestão?
R: Sim sei.
8. Quais são as principais dificuldades que gostaria que fossem ultrapassadas?
R: O controlo das actividades diária tais como, controlo de produtos, controlo das
vendas, controlo de clientes e dos relatórios.
59
60

Tese Final Arilton de Oliveira e Jelson Neto

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Tese Final Arilton de Oliveira e Jelson Neto

Enviado por

Direitos autorais:

Formatos disponíveis

INSTITUTO DE TECNOLOGIAS DE INFORMAÇÃO E

SISTEMA DE GESTÃO DE INFORMAÇÃO DE ESTOQUE E

TRABALHO DE FIM DE CURSO DE LICENCIATURA EM

AUTORES: ARILTON DE OLIVEIRA E JELSON NETO

SISTEMA DE GESTÃO DE INFORMAÇÃO DE ESTOQUE E

TRABALHO DE FIM DE CURSO DE LICENCIATURA EM

AUTORES: ARILTON DE OLIVEIRA E JELSON NETO

MSc. JOSÉ GOMES FIGUEIREDO

Agradecemos a todos os nossos professores pelos ensinamentos e orientações que

Agradecemos especialmente aos professores Pedro Alvarez Barreras, Yurisbel Ortiz

Agradecemos aos nossos colegas das turmas A e B do ano académico de 2016-2020

Agradecemos a todos que de forma directa ou indirecta contribuíram para a realização

Que Deus cuide de vocês e abençoe de agora para todo o sempre.

A medida que se elaborava o presente trabalho investigou-se sistemas que visavam

Desta feita a proposta deste projecto consiste na apresentação de um sistema de

Palavras chaves: facturação, gestão de negócio, gestão de estoque, serviços gráficos,

Keywords: invoicing, business management, inventory management, graphic services,

Capítulo 1: Fundamentação teórica.....................................................................................7

1.1. Principais conceitos associados ao objecto de estudo.............................................7

1.2. Estado da arte............................................................................................................8

1.3. Metodologia utilizada...............................................................................................11

1.3.1. Metodologias robustas......................................................................................12

1.3.2. Metodologias ágeis............................................................................................12

1.4. Ferramentas nas quais se apoia para a solução....................................................15

1.4.1. Linguagem de programação.............................................................................15

1.4.2. Editor de texto e IDE (Integrated Development Environment)..........................15

1.4.5. Sistema de gestão de banco de dados.............................................................17

1.4.6. Ferramentas de modelagem com UML.............................................................19

1.4.7. Ferramentas auxiliares para o desenvolvimento..............................................20

1.5. Conclusões parciais do capítulo..............................................................................21

Capítulo 2: Características do sistema..............................................................................22

2.2. Objecto de automação.............................................................................................22

2.3. Modelagem do negócio...........................................................................................22

2.3.1. Modelo de domínio............................................................................................22

2.3.2. Descrição dos trabalhadores e atores do negócio............................................24

2.3.3. Diagrama de casos de uso do negócio.............................................................25

2.4. Modelagem do sistema............................................................................................27

2.4.1. Requisitos funcionais........................................................................................27

2.4.2. Requisitos não funcionais.................................................................................29

2.4.3. Diagrama de casos de uso do sistema.............................................................30

2.4.4. Descrição de casos de uso do sistema.............................................................31

2.5. Conclusões parciais do capítulo..............................................................................34

Capítulo 3: Desenho, implementação e provas do sistema..............................................36

3.1. Diagrama de classes...............................................................................................36

3.2. Arquitectura do sistema...........................................................................................37

3.3. Padrão de desenho utilizado...................................................................................39

3.4. Análise e desenho do banco de dados...................................................................42

3.4.1. Modelo logico do banco de dados....................................................................42

3.5. Diagrama de implantação........................................................................................43

3.5.1. Descrição do modelo de implantação do sistema............................................44

3.6. Validação do sistema mediante provas...................................................................44

3.6.1. Prova de caixa branca.......................................................................................45

3.6.2. Prova de caixa preta.........................................................................................47

Resultado das provas de software..............................................................................51

3.7. Conclusões parciais do capítulo..............................................................................51

Figura 2.1 – Diagrama de domínio. Fonte: (Elaboração própria)......................................23

Figura 2.2 – Diagrama de casos de uso de negócio. Fonte: (Elaboração própria)...........25

Figura 2.3 – Diagrama de casos de uso de sistema. Fonte: (Elaboração própria)...........31

Figura 3.1 – Diagrama de classes. Fonte: (Elaboração própria).......................................37

Figura 3.2 – Arquitetura MVC (Modelo Vista Controlador)................................................38

Figura 3.3 – Demonstração da aplicação da arquitetura MVC..........................................39

Figura 3.4 – Código fonte da classe Funcionário. Fonte: (Elaboração própria)................40

Figura 3.5 - Código fonte da classe Produto. Fonte: (Elaboração própria).......................41

Figura 3.6 – Código fonte da classe VisualizarController (Método Pesquisar). Fonte: