Computing">
Tese Final Arilton de Oliveira e Jelson Neto
Tese Final Arilton de Oliveira e Jelson Neto
Tese Final Arilton de Oliveira e Jelson Neto
COMUNICAÇÃO
Luanda, 2021
INSTITUTO DE TECNOLOGIAS DE INFORMAÇÃO E
COMUNICAÇÃO
ORIENTADOR:
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.
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.
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.
VI
Índice geral
Introdução............................................................................................................................1
1.2.1. Internacional........................................................................................................8
1.2.2. Nacional.............................................................................................................10
1.4.3. Framework.........................................................................................................16
1.4.4. Bibliotecas.........................................................................................................17
VII
2.3.4. Descrições de casos de uso do negócio...........................................................25
Conclusões.........................................................................................................................52
Recomendações................................................................................................................53
Referências bibliográficas..................................................................................................54
Anexos...............................................................................................................................57
VIII
Índice de figuras
Figura 1.2 – Diagramas UML.............................................................................................19
Figura 3.10 – Gráfico do fluxo da prova de caixa branca. Fonte: (Elaboração própria). . .46
IX
Índice de tabelas
Tabela 2.1 - CUN: Solicitar produto...................................................................................25
X
Lista de Abreviaturas e Símbolos
SI – Sistema de informação.
RF – Requisito Funcional.
RF – Requisito Funcional.
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.
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
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
Objecto de estudo
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
Objectivos específicos
3
Para que seja cumprido o objectivo definido acima são estabelecidos como objectivos
específicos os seguintes:
Tarefas de investigação
Ideia a defender
Métodos científicos
4
Métodos teóricos.
Métodos empíricos;
Dos métodos empíricos foram seleccionados para a investigação:
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.
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.
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.
Sistema
Sistema de informação
Gestão
Estoque
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
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
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).
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.
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
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.
WinMarket
10
Gestão de produtos;
Gestão de vendas (facturação);
Gestão de fornecedores;
Gestão de relatórios.
Figura 1.1 – Tabela ilustrativa sobre o estudo da arte. Fonte: (Elaboração própria).
11
um processo dinâmico e interactivo para desenvolvimento estruturado de projectos,
sistemas ou software, visando à qualidade e produtividade dos projectos. (Leite, 2006).
É 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).
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:
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.
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).
Princípios do OpenUp
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.
Java 8
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)
NetBeans v12.3
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
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).
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).
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.
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:
20
Combina as funcionalidades de todas as edições em uma ampla plataforma da
modelagem visual.
XAMPP v3.3.0
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.
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).
23
conjunto de diagramas de classes nos quais não são definidas operações.
(Baranauskas, 2018). Ele deve mostrar:
Trabalhador do negócio
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).
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).
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.
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.
5. 4. Diz o método de pagamento e efectua 6.
o 5. Entrega os produtos e finaliza a venda.
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.
27
11. 4. Diz o método de pagamento e efectua 12.
o 5. Entrega os produtos e finaliza a venda.
pagamento.
28
A Tabela 2.3 mostra os requisitos do sistema.
29
RF24. Consultar despesa Alta Média
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).
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
RNF7 - A boa organização das informações é garantida para permitir a interpretação correta.
Hardware
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
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).
32
Pré-condição Deve estar cadastrado no sistema.
Referência RF RF29
Prioridade Alta
Fluxo normal de eventos
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
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
Fluxo normal de eventos
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.
Protótipo de interface
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
Fluxo normal de eventos
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.
Protótipo de interface
13.
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.
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.
37
Figura 3.1 – Diagrama de classes. Fonte: (Elaboração própria).
Figura 3.2 – Arquitetura MVC (Modelo Vista Controlador). Fonte: (Elaboração própria).
39
Figura 3.3 – Demonstração da aplicação da arquitetura MVC. Fonte: (Elaboração própria).
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).
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
Criador (Creator)
41
Benefício:
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:
Polimorfismo (Polymorphism)
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.
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.
44
adotam. A maioria dos modelos de dados pode ser representada por um diagrama de
banco de dados acompanhante. (Lucidchart, 2019).
45
Figura 3.8 – Diagrama de implantação. Fonte: (Elaboração própria).
Nós/Dispositivos Descrição
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.
Conectores Descrição
46
3.6. Validação do sistema mediante provas
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.
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)
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]
Caminho: [1, 2, 3, 5, 6, 9]
Resultado: O sistema lança uma mensagem de alerta (“O documento seleccionado está
invalido”).
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).
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.
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:
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:
55
Referências bibliográficas
1. AWISE. 2020. QuantoSobra. QuantoSobra. [Online] AWISE SOLUÇÕES
TECNOLÓGICAS, 2020. https://www.quantosobra.com.br/.
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.
10. FIA. 2019. fia. fia. [Online] FIA - Fundação Instituto de Administração, 2019.
https://fia.com.br/blog/desenvolvimento-agil/.
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.
17. Lexos. 2021. Lexos. Lexos. [Online] Lexos Solução em Tecnologia LTDA , 2021.
https://www.lexos.com.br/.
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.
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.
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.
28. Paradigm, Visual. 2017. Visual Paradigm. Visual Paradigm. [Online] Visual
Paradigm, 6 de Novembro de 2017. www.visualparadigm.com.
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
R: Sim sei.
R: O controlo das actividades diária tais como, controlo de produtos, controlo das
vendas, controlo de clientes e dos relatórios.
59
60