INSTITUTO SUPERIOR DE TECNOLOGIAS DE INFORMAÇÃO

E COMUNICAÇÃO

SISTEMA DE GESTÃO DE VENDA DA BOUTIQUE BCH-LDA

(SIGV-BCH)

TRABALHO DE FIM DE CURSO EM ENGENHARIA DE

INFORMÁTICA

Autor: Laurindo Augusto Cakoyi

Luanda, 2019
I
INSTITUTO SUPERIOR DE TECNOLOGIAS DE INFORMAÇÃO
E COMUNICAÇÃO

SISTEMA DE GESTÃO DE VENDA DA BOUTIQUE BCH-LDA

(SIGV-BCH)

TRABALHO DE FIM DE CURSO EM ENGENHARIA DE

INFORMÁTICA

Autor: Laurindo Augusto Cakoyi.

Orientador: MSc. Walber Mengana Cuesta.

Luanda, 2019

II
DEDICATÓRIA E AGRADECIMENTOS
Em primeiro lugar gostaria de agradecer a Deus por tudo que têm feito em minha vida,
gostaria de agradecer ao corpo directivo e de docentes do Instituto Superior De
Tecnologias de Informação e Comunicação (ISUTIC), por ter acreditado sempre neste
projecto que agora ao fim de muito tempo e várias contrariedades, vê a luz do dia e que
representa a concretização do desafio que nos foi lançado de criar um sistema de gestão
de vendas para a boutique (BCH-Lda).

Gostaria de agradecer ao Professor MSc Walber Mengana Cuesta, pelo apoio dado ao
longo da realização da tese, que este gesto se repita, em prol do ensino.

Quero deixar aqui uma palavra de apreço aos meus colegas pelo ambiente de riqueza
intelectual que me proporcionaram ao longo desses cinco (5) anos da minha formação.

Costuma-se dizer que a família e os amigos são os que de mais importantes temos na
vida. Começando pelos últimos, o nosso muito obrigado especial e sentido aos meus bons
amigos que, de alguma forma, acreditaram em nós e nos incentivaram no avanço do
projecto. Por último, obrigado Esposa, Pais e de mais familiares por tudo, e acima de tudo
por nos terem apoiado moralmente e financeiramente para que concluíssemos os estudos.

Muito Obrigado.

III
Resumo
Este trabalho fala sobre a necessidade de controlar e agilizar o processo de gestão de
vendas, atravéz de um sistema infromático desktop. Se notou que muitas lojas não
possuem um controlo exacto dos seus dados, o que dificulta no processo de vendas.

Ao longo da pesquisa sobre o tema, estudaram-se sistemas informáticos relacionados ao

problema, conseguindo identificar as características principais que deve ter um sistema de
gestão de vendas.

Sendo assim, o sistema de gestão vendas poderia cobrir as necessidades de gestão de

vendas, cadastros, consultas, bem como os relatórios.

Mais adiante foram mostradas toda a documentação onde poderão constar todos os
requisistos funcionais e não funcionais, modelagens do sistema, principais ferramentas
utilizadas e as metodologias que vão nos guiar até ao término do projecto. Do mesmo
modo faremos os testes de software com maior realçe nas provas de caixa preta e provas
de caixa branca, visto que se fez correções de erros no sistema.

Palavras-chave: Boutiques, Controlo de informações, Gestão de vendas, Relatórios.

IV
ABSTRACT
This work talks about the need to control and streamline the sales management process,
through an informatic desktop system. It has been noted that many stores do not have
exact control of their data, which makes it difficult in the sales process.

Throughout the research on the subject, computer systems were studied related to the
problem, being able to identify the main characteristics that a sales management system
should have.

Thus, the sales management system may cover the needs of sales management, records,
queries, as well as reports.

Later on, all the documentation will be shown where all the functional and non-functional
requirements, system modeling, main tools used and the methodologies that will guide us
to the end of the project will be shown. Likewise, we will carry out the most important
software tests on the black box tests and the white box tests, in order to correct the system
errors.

Keyword: Boutiques, Information control, Sales management, Reports.

V
INTRODUÇÃO .................................................................................................................. 1

CAPÍTULO I: FUNDAMENTAÇÃO TEÓRICA ................................................................... 4

Introdução ......................................................................................................................... 4

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

1.2 Estudo dos sistemas de gestão de vendas. ................................................... 8

1.3 Metodologia de desenvolvimento de software.............................................. 12

1.4 Ferramentas e tecnologias de desenvolvimento .......................................... 15

1.5 Conclusões parciais ..................................................................................... 20

CAPÍTULO II: CARACTÉRISTICAS DO SISTEMA ......................................................... 21

2.1 Modelagem do negócio ................................................................................ 21

2.2 Modelo conceitual e descrição do negócio ................................................... 22

2.3 Modelagem do Sistema ................................................................................ 26

2.4 Conclusão parcial ......................................................................................... 33

CAPÍTULO III: DESENHO, IMPLEMENTAÇÃO DO SISTEMA E PROVAS.................... 34

3.1 Arquitectura do Sistema e Padrão de Desenho ........................................... 34

3.2 Padrões de Desenho.................................................................................... 36

3.3 Modelo lógico do Banco de Dados. .............................................................. 39

3.4 Diagrama de Implantação. ........................................................................... 40

3.5 Protótipos de Interfaces ............................................................................... 42

3.6 Validação do sistema com provas de software ............................................ 44

3.7 Conclusões Parciais ..................................................................................... 49

CONCLUSÕES ............................................................................................................... 50

RECOMENDAÇÕES ....................................................................................................... 51

REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................ 52

ANEXOS ......................................................................................................................... 55

VI
ÍNDICE DE FIGURA
Figura 1: Modelo Conceitual do Negócio......................................................................... 23

Figura 2: Diagrama do Caso de Uso do Negócio. ........................................................... 25

Figura 3: Diagrama do Caso de Uso do Sistema. ........................................................... 30

Figura 4: Arquictetura modelo vista controladora ............................................................ 35

Figura 5: Diagrama de classes do sistema...................................................................... 36

Figura 6: Aplicação do padrão Criador na classe UserDao ............................................. 37

Figura 7: Aplicação do padrão Alta coesão na classe Tipo_AutenticarDao .................... 38

Figura 8: Aplicação do padrão Polimorfismo na subclasse pesquisar ............................. 39

Figura 9: Modelo lógico do banco de dados .................................................................... 40

Figura 10: Diagrama de implantação do sistema. ........................................................... 41

Figura 11: Tela Iniciar Sessão ......................................................................................... 42

Figura 12: Tela Principal.................................................................................................. 42

Figura 13: Tela pesquisar produto ................................................................................... 43

Figura 14: Tela cadastro de cliente ................................................................................. 43

Figura 15: Código fonte salvar produto ........................................................................... 47

Figura 16: Gráfico Fluxo Prova de caixa branca ............................................................. 48

Figura 17: Resultado das provas de software ................................................................. 49

VII
ÍNDICE DE TABELA
Tabela 1: Deferenças entre metodologias pesadas e ágeis Fonte:(Nerur, Mahaptra e
Mangalaraj, 2015). .......................................................................................................... 13

Tabela 2: Ator de Negócio ............................................................................................... 22

Tabela 3: DCUN comprar produto. .................................................................................. 25

Tabela 4: DCUN efectuar pagamento ............................................................................. 26

Tabela 5: DCUN cadastrar produtos. .............................................................................. 26

Tabela 6: DCUS – Autenticar. ......................................................................................... 30

Tabela 7: DCUS – Gerenciar Cliente .............................................................................. 31

Tabela 8: Gerenciar Vendas............................................................................................ 31

Tabela 9: Gerenciar Produto ........................................................................................... 32

Tabela 10: Descrição dos dispositivos do diagrama de implantação .............................. 41

Tabela 11: Descrição dos conectores do diagrama de implantação ............................... 41

Tabela 12: Prova de caixa preta...................................................................................... 46

VIII
Lista de Abreviatura
API .............................................................................. Application Programming Interface

CSS ……………………………………………………………………. .... Cascade Style Sheet

CASE …………………………………………………. Computer-Aided Software Engineering

CRM ........................................................................... Customer Relationship Management

CUN .............................................................................................. Caso de Uso do Negócio

CUS .............................................................................................. Caso de Uso do Sistema

DCUN ...................................................................... Diagrama de Caso de Uso do Negócio

DCUS ....................................................................... Diagrama de Caso de Uso do Sistema

ERP ...................................................................................... Enterprise Resource Planning

ERD ...................................................................Diagrama de Relacionamento de Entidade

GUI ......................................................................................... Interface Gráfica do Usuário

GRASP ............................ Padrões de Software de Atribuição Geral de Responsabilidades

HTML .................................................................................... Hyper Text Markup Language

HTTP ...................................................................................... Hyper Text Transfer Protocol

HTTPS ....................................................................... Hyper Text Transfer Protocol Secure

IDE…………………………………………….......... Ambiente de Desenvolvimento Integrado

JVM ..................................................................................................... Maquina Virtual Java

JS……………………………………………………………………. ........................ JavaScript

JRE ........................................................................................... Java Runtime Environment

JPA ..................................................................................................... Java Persistence API

MVC ............................................................................................ Modelo Visão Controlador

OpenUp .............................................................................................Open Unified Process

RF……………………………………………………………………. .......... Requisito Funcional

RNF……………………………………………………….……………. Requisito Não Funcional

IX
RUP ........................................................................................ Processo Unificado Racional

UI ....................................................................................................... Interfaces de Usuário

UML ............................................................................................... Unified Model Language

USB ................................................................................................... Universal Serial Base

SGBD ....................................................................... Sistema de Gestão de Base de Dados

SysML ..................................................................... Linguagem de Modelação de Sistemas

SI ..................................................................................................... Sistema de informação

TICs ................................................................... Tecnologia de Informação e Comunicação

OpenUp………………........................................................................Open Unified Process

OOP ................................................................................ Programação orientada a objecto

XML ....................................................................................... eXtensible Markup Language

WYSIWYG …………………………………………………….. What You See Is What You Get

XP .................................................................................................... Extreme Programming

MVC ............................................................................................ Modelo Visão Controlador

X
INTRODUÇÃO
Boutique é um estabelecimento comercial, normalmente, pequeno e caracterizado
pela venda de artigos de modas, roupas finas, joias ou bijuterias particulares,
especializadas ou importadas (Dicio, 2016).

O estabelecimento comercial é o conjunto de bens que o empresário utiliza para

exercer sua actividade econômica. Trata-se de todo o conjunto de bens que o
empresário adquiriu para assim poder exercer sua actividade (Aline Duarte, 2017).

Roupas é o nome que designa qualquer peça do vestuário pessoal ou do vestuário de

cama, mesa e banho. Bem como Traje ou vestimenta (Dicionario informal, 2019).

Joias são as peças nobres, geralmente produzidas por designers próprios. Elas são
feitas de ouro, prata, titânio ou platina (Vivi Scramin, 2019).

Semijoia são peças similares às joias. O que muda é a sua resistência. A sua base
(estrutura) é feita em material “não” nobre (exemplo: latão, estanho, bronze e até
mesmo a prata) e recebem uma espécie de cobertura/banho de material nobre (ouro,
prata, ródio ou rose). As peças ficam bonitas e com durabilidade grande, mas não são
100% nobres. Visualmente é difícil distinguir uma semijoia de uma joia (Vivi Scramin,
2019).

Bijuterias são as peças que possuem menor durabilidade. São feitas com materiais
“não” nobres e raramente possuem banho. Algumas peças podem vir com um banho,
que é chamado “flash”, ou seja, recebem uma camada extremamente fina de ouro ou
prata que é utilizada somente para dar cor à peça. As bijuterias geralmente são
usadas como enfeites mais simples, lembrando joias. Elas possuem um brilho natural
menor e uma forte tendência à oxidação. Elas podem ser encontrados com uma
diferença muito grande entre os preços de cada loja (Vivi Scramin, 2019).

Moda vem do latim modus, designa a maneira de fazer, compartilhando nesse caso o
sentido do termo inglês fashion, que deriva do francês façon, feitio. Moda é, portanto,
a maneira ou a forma de fazer alguma coisa, e em particular de vestir-se, comer, falar.
Moda é um fenômeno que surge com a chamada “modernidade” ocidental e ilustra o
fim do consumo de actual e sua substituição pelo consumo do novo. Do ponto de vista
histórico, ela surge no âmbito do vestuário, mas hoje se encontra instalada em quase
todas as áreas da vida social (Godart, 2018).
1
A boutique BCH-Lda é um estabelecimento comercial que presta serviços no ramo de
vendas, esta localizada na província de Luanda, município de Cacuaco. Oferece
diversos produtos como roupas masculinas, femeninas, e acessórios de moda, a
boutique BCH-Lda não possui um sistema de gestão de vendas que controla e agiliza
as suas actividades diarias, como cadastro de produtos, controle das vendas, e isto
acontece devido aos custos elevados das soluções existentes, por esta razão faz com
que o gerente da boutique BCH-Lda tenha soluções de forma manual, como o
apontamento a um caderno e as vendas são feitas por intermédio de blocos de
facturas para ajudar na gestão de vendas.

Todo o processo de vendas é feito de forma manual, utilizando blocos de facturas que
geram dificuldades no controlo dos produtos, baixa produção, acúmulo de papeis,
perda de informações, desvios de mercadorias e demora no atendimento. A boutique
BCH-Lda, tem muitas dificuldades no tocante a gestão de vendas, pois não possuem
um software específico para tal, sendo que muitos clientes sentem-se insatisfeitos
pela demora no atendimento, e com isso tem gerado muita perca dos clientes. Com
base a situação problemática apresentada acima, obteve-se o seguinte: problema de
investigação: Como controlar a gestão de vendas da boutique BCH-Lda?

Segundo o problema identificado, se define como objecto de estudo: os processos

de gestão de vendas, centrado no campo de acção: os sistemas de gestão de vendas
para a boutique BCH-Lda.

O objectivo geral deste trabalho é: Desenvolver um sistema informático para a

boutique BCH-Lda, que possa controlar o processo de gestão de vendas de produtos.

Do objectivo geral acima citado se identificaram os seguintes objetivos específicos:

1. Sistematizar os aspectos teórico-práticos referentes aos sistemas de gestão de
vendas em Angola e no mundo.
2. Desenhar o sistema informático de gestão de vendas para a boutique BCH-
Lda.
3. Implementar o sistema informático de gestão de vendas para a boutique BCH-
Lda.
4. Validar o sistema informático de gestão de vendas para a boutique BCH-Lda.

2
Defende-se a ideia de investigação de que: Com o desenvolvimento de um sistema
informático para boutique BCH-Lda, garante-se o controle e a agilidade na gestão das
vendas da boutique BCH-Lda.
Para dar solução ao problema levantado se propõem as seguintes tarefas de
investigação:
1. Análise dos principais conceitos associados aos processos de gestão de
vendas para boutiques, para obter uma base teórica para o desenvolvimento
da solução.
2. Estudo de soluções existentes no campo da gestão de vendas de boutiques.
3. Definição das ferramentas informáticas e da metodologia a utilizar para o
desenvolvimento do sistema de gestão de vendas para a boutique BCH-Lda.
4. Definição dos requisitos funcionais e não funcionais do sistema de gestão de
vendas da boutique BCH-Lda.
5. Desenho do sistema de gestão de vendas da boutique BCH-Lda.
6. Implementação do sistema de gestão de vendas para a boutique BCH-Lda.
7. Aplicação de provas de softwares em função da validação da solução proposta.

Para o desenvolvimento da investigação, foram utilizados os seguintes métodos de

investigação:
Nível teórico:
o Lógico-Histórico: Este método é usado para analisar como o desenvolvimento
de tecnologias evoluiu nos sistemas de gestão de vendas (Ronaldo Bastos,
2017).
o Analítico-Sintético: Utiliza-se para analisar a informação e a documentação
relevante para o desenvolvimento do sistema informático de gestão de vendas,
enfatizando os elementos mais importantes que se relacionam com o objeto de
estudo (Ronaldo Bastos, 2017).

Nível empírico:
o Entrevista: Realizaram-se entrevistas aos trabalhadores afetos as vendas que
nos permitiu entender a situação existente e obter os requisitos para o
desenvolvimento do sistema informático de gestão de vendas (Adriano Padilha,
Talita Carvalho, 2016).

Resumo de cada capítulo:

3
O presente trabalho está estruturado em três capítulos, cujo o conteúdo é
sucintamente apresentado a seguir:
o Capítulo I: Fundamentação teórica: Neste capítulo se pontualizam os
principais conceitos relacionados com o tema, realiza-se o estudo dos sistemas
similares a nível nacional e internacional sobre os sistemas de gestão de
vendas. Também se definem as ferramentas, metodologias e tecnologias a
utilizar durante o desenvolvimento do sistema informático.
o Capítulo II: Características do sistema: Neste capítulo se faz uma descrição
geral da solução proposta e seu funcionamento, identificam-se os requisitos
funcionais e não funcionais e outros elementos importantes dentro do processo
de desenvolvimento.
o Capítulo III: Desenho, implementação do sistema e provas de software:
Neste capítulo se abordam aspectos relacionados com o desenho e a
implementação do sistema. Elaboram-se os diagramas de classes e de base
de dados, assim como outros elementos importantes dentro do processo de
desenvolvimento do sistema informático de gestão de vendas para a boutique
BCH-Lda. A demais realiza-se as provas de software para verificar que
responda a um correcto funcionamento, garantir a confidencialidade e detectar
falhas no sistema proposto.

CAPÍTULO I: FUNDAMENTAÇÃO TEÓRICA

Introdução
Neste capítulo é feita uma explicação sobre o estudo, por meio de pesquisas, dos
sistemas de gestão de vendas similares a nível nacional e internacional. Diferentes
conceitos relevantes relacionados ao sistema serão definidos, também serão
explicadas as ferramentas, metodologias e diferentes tecnologias que serão usadas
para a construção do sistema proposto.

1.1 Principais conceitos associados ao objecto de estudo

Vendas, do latim vendĭta, venda é a acção e o efeito de vender (transferir a
propriedade de algo para outra pessoa mediante o pagamento de um preço
estipulado). O tema é usado tanto para fazer referência à operação (transacção) em
si como à quantidade de coisas que se vendem. A venda também é o contrato através

4
do qual se transfere uma coisa própria a domínio alheio pelo preço pactuado. A venda
pode ser um acto potencial (um produto que está à venda mas que ainda não foi
comprado) ou uma operação já concretizada ou realizada (neste caso, implica
necessariamente a compra) (Paulo Ferreira, 2017).

É hábito falar-se de contrato de compra e venda para fazer alusão à operação bilateral
em que o vendedor entrega uma determinada coisa ao comprador, o qual, por sua
vez, paga um preço pela mesma. Regra geral, esse pagamento é realizado em
dinheiro, pois optando-se por outro objecto, estaríamos perante uma situação de troca
(ou permuta) (Emmanuel Ferreira, 2017).

A venda de produtos ou serviços constitui a base das operações das empresas.

Através destas vendas, as empresas obtêm lucro. Quanto ao facto de estas serem
rentáveis, irá depender de muitos factores, como a gestão de custos (Emmanuel
Ferreira, 2017).

Convém destacar que se podem vender coisas materiais (como um computador ou

uma bola, por exemplo) ou simbólicas (como o passe de um jogador de futebol), mas
no caso da boutique BCH-Lda trata-se da vendas de vestuário, calçados e alguns
acessórios de moda.

Em função das definições mencionadas acima, vendas é um conjunto de métodos e

técnicas que o vendedor utiliza na troca de produtos ou bens de serviço por um valor
monetário. Como também é a relação que existe entre o vendedor e o cliente, sendo
que o vendedor oferece produtos e o cliente adquiri atravéz do pagamento.

Gestão: é uma área das ciências humanas que se dedica à administração de

empresas e de outras instituições visando fazer com que alcancem os seus objectivos
de forma efectiva, eficaz e eficiente. O conceito de gestão possui ligação direita com
a administração dos recursos disponíveis na organização. Esses recursos podem ser
tanto materiais e financeiros como humanos, tecnológicos ou de informação (7 Graus
Lda, 2017).

Em suma, gestão é a forma como se geri e se administra algum recurso, quando se

trata das vendas, envolve o planeamento de como serão realizadas até o alcançe de
resultados.

5
Gestão de Vendas: desenvolvido para tornar o trabalho da equipe de vendas mais
organizado, rápido e eficiente, o sistema de vendas é uma ferramenta de
gerenciamento de contactos e controlo de processos capaz de reduzir o esforço das
oportunidades de negócios da empresa (Devitecnologia, 2017).

A gestão de vendas é o acto de organizar, administrar, criar e implementar tudo que

diz respeito às vendas de uma empresa. Por exemplo, podemos pensar no
desenvolvimento de novas estratégias para aumentar a quantidade de saída de
produtos, isso fará parte da gestão de vendas. Empresários tendem a cometer o erro
de simplificar a gestão de vendas, trabalhando apenas com a parte administrativa, ou
seja, análise de números. É facto que o mercado e o público consumidor sofrem
mudanças em curtos períodos de tempo, inclusive, estuda-se o ciclo da compra e ciclo
do cliente, aprimorando cada vez mais as vendas. Por isso, podemos dizer que gestão
de vendas é todo o processo, desde a escolha do produto até ao serviço de
atendimento ao cliente (SAC) (Casa da consultoria, 2019).

Sistemas de Gestão de Vendas (SGV): é uma ferramenta de gerenciamento de

contactos, controlo de processos capaz de reduzir o esforço e aumentar as
oportunidades de negocios da empresa (Devtecnologia, 2017).

Além disso, o sistema de vendas também é conhecido pelo termo em inglês Customer
Relationship Management que em português quer dizer, Gestão de Relacionamento
com o Cliente (CRM). O ápice da tendência desse tipo de programa aconteceu em
meados da década de 1980, mas naquele tempo a maior parte dos profissionais
utilizava-o para melhorar as estratégias de divulgação, obtendo suas primeiras noções
de marketing. Pouco se falava em adotar um CRM para desenvolver actividades
relacionadas a vendas. Hoje em dia, a realidade é bem diferente. A implementação
de um sistema de vendas é considerada uma forma inteligente de optimizar os
resultados do negócio, pois é possível tornar a gestão de relacionamento com o cliente
muito mais produtiva, além de manter o negócio mais competitivo diante dos
concorrentes (Devitecnologia, 2017).

Vantagens de se adotar um sistema de vendas

Os mecanismos de gerenciamento de um estabelecimento comercial são essenciais
para garantir o bom funcionamento do negócio e garantir a lucratividade. É a gestão
que integrará todas as partes que envolvem uma loja: contacto com fornecedores,
6
recursos humanos, sector administrativo, controle financeiro, marketing, venda de
produtos e serviços, entre outros. Uma falha na relação entre sectores prejudica a
productividade e tem consequências no funcionamento do seu empreendimento
(Marinho Silva, 2019).

A tecnologia é uma grande aliada nos diversos sectores econômicos. Uma loja pode
fazer o uso de um software de gestão empresarial ou enterprise resource planning
(ERP). Esse sistema procura integrar todos os processos de uma loja de maneira a
facilitar a comunicação interna do estabelecimento, optimizar as ações e minimizar as
dificuldades de gestão. Tudo isso melhora a productividade e garante acesso a dados
que podem ser usados estrategicamente para tornar a sua loja mais eficiente (Marinho
Silva, 2019).

Abaixo mencionamos as principais vantagens em se adoptar um software de gestão

de vendas na boutique:

Frente de caixa:
Um software de gestão alinhado com o seu frente de caixa permite que a emissão de
facturas ou notas fiscais estejam adequadas de acordo a legislação do País em que
actua.. Outra funcionalidade que esse tipo de software garante é o armazenamento
seguro das informações que passam pela frente de caixa. Portanto, a tecnologia
contribui para o controlo e agilidade desse processo e a segurança de dados (Marinho
Silva, 2019).

Planeamento:
Um software de gestão integrado em sua empresa permite reunir um grande número
de informações e avaliar diversos dados que, se bem empregados, deixam o seu
negócio mais ágil e com os seus processos mais produtivos (Marinho Silva, 2019).

Controle de estoque:
Um software de gestão tornará esse processo mais eficiente, alertando quando deve
renovar o estoque, quais produtos estão em falta e quais têm pouca saída.
Informações estratégicas que vão orientar todo o seu sector de vendas (Marinho Silva,
2019).

Controle financeiro:

7
Um software de gestão consegue integrar diversos sectores da sua empresa criando
um canal único de informação. Você tem os dados da frente de caixa e de vendas,
controle do seu estoque e os dados necessários para planear as suas estratégias de
mercado. Logo não é de se estranhar que esses sistemas te forneçam relatórios
detalhados com informações exactas. De posse dessas informações fica mais fácil
planear e ajustar o sector financeiro fazendo controle de gastos e reduzindo custos
(Marinho Silva, 2019).

1.2 Estudo dos sistemas de gestão de vendas.

Com base no estudo da arte do tema tratado a nível internacional, nacional e de
universidade, verificou-se quatro soluções existentes, três a nível internacional e uma
a nível nacional.

1.2.1 Nível Internacional

1.2.1.1 Freshsales
O Freshsales é a uma ferramenta geral de gerenciamento de relacionamento com o
cliente (CRM) e software de vendas, pois permite que os gerentes de vendas
priorizem e atribuam os melhores leads e monitorem e avaliem as chamadas de
vendas com seus recursos de gravação de chamadas. Além disso, o que o torna único
é o aplicativo móvel, o sistema telefônico interno e a capacidade de oferecer suporte
à venda baseada em território. Portanto, é uma boa opção para gerentes de vendas
com equipes baseadas em território que sejam práticas e forneçam feedback sobre
as chamadas de vendas (Sheena Jones, 2018).

Freshsales tem preço acessível, mas também há uma versão gratuita que oferece
funcionalidade básica de gerenciamento de leads e contactos para usuários
ilimitados. À medida que as suas necessidades crescem e você precisa de
ferramentas mais avançadas, seus preços são altamente competitivos em
comparação com sistemas de rastreamento de vendas com características
semelhantes (Sheena Jones, 2018).

Vantagens:
o A capacidade de personalizar tudo em torno dos negócios e das necessidades
é óptima.

8
 o As configurações padrão já existentes já são ótimas, dão inspiração sobre
como eu quero que meu sistema seja.
o O facto de poder fazer relatórios em praticamente qualquer categoria que eu
escolher. Isso é particularmente bom para actualizar clientes diferentes em
seus casos.

Desvantagens:
Dificuldades ao carregar arquivos para casos, ele só pode ser feito um por um e não
se pode carregar arquivos em massa. Também seria ótimo se tivesse um recurso de
arrastar e soltar para arquivos.

1.2.1.2 Gestão Click

Gestão click é um programa para boutique que possui funcionalidades que permite
automatizar funções burocráticas, resguardando o tempo do empreendedor, com
emissão de notas fiscais (de produto, de serviço e eletrônica), boletos bancários,
importar XML (eXtensible Markup Language), além de oferecer controle
de estoque, financeiro, permite o cadastro de fornecedores, clientes, emissão
de relatórios (Gestão click, 2019).

Ademais, o GestãoClick é o ideal para lojas, já que também tem a funcionalidade de

venda balcão PDV, auxiliando de forma práticas aqueles estabelecimentos que lidam
com um grande fluxo diário de clientes que precisam realizar vendas vendas rápidas
e ágeis (Gestão click, 2019).

Todas as transações em Pontos de Vendas é integrado com o controle de estoque e

o controle financeiro, assim, a gestão do seu negócio será optimizada e você terá um
controle mais completo das actividades de sua empresa (Gestão click, 2019).

Recursos do gestão Click:

o Controle Financeiro
o Controle de Estoque
o Frente de Caixa
o Orçamentos e Vendas
o Emissão de Notas
o Emissão de Boletos
o Controle de Compras

9
 o Atendimentos

Desvantagens:
O sistema é 100% online, o que quer dizer que sem internet não poderá funcionar.

1.2.1.3 Hiper
O Hiper gestão é um sistema online de gestão, que permite acessar todos os dados
da sua loja, de onde quiser. Confere as vendas realizadas, controla o estoque e cria
relatórios de forma rápida e sem complicação (Hiper, 2019).

Ideal para negócios que estão começando e também para quem já possui mais de
uma loja e quer centralizar a gestão em um só aplicativo.

Principais funcionalidades:
Utilizando o pedido de venda do hiper, você consegue montar orçamentos, informar a
validade para o orçamento, definir uma negociação, enviar por e-mail e ainda fatura-
los em nota fiscal ou cupom fiscal.

Realiza uma pré-venda e diminui as filas no caixa de uma loja. Ainda pode definir uma
negociação, um desconto e uma tabela de preço especial para o cliente.

Com o frente de caixa do hiper se pode utilizar a solução de frente de caixa e tráz
mais agilidade em suas vendas. Outro recurso disponível é a emissão de documentos
fiscais. E ainda se pode integrar o frente de caixa com o windows ou online (Hiper,
2019).

Permite acompanhar todas as vendas realizadas. Com o Hiper, você consegue

acompanhar suas vendas através de relatórios de vendas, operações de caixa e o fita
de caixa (Hiper, 2019).

Permite lançar o retorno da mercadoria, emitir uma nota de consignação e ainda

transformar a consignação em um pedido de venda (Hiper, 2019).

1.2.2 Nível nacional

1.2.2.1 Sistemas de Aplicações Comerciais (SAC)

O SAC é um software de gestão empresarial “made in Angola”, criado pela empresa
NCR Corporate, que desde 1990 apoia as mais de 3000 empresas angolanas, seja

10
qual for o seu sector de actividade, a responder com garantias às necessidades das
empresas e do mercado (NCR Corporate, 2018).

O software SAC integra soluções a nível operacional, fiscal, administrativo, financeiro,

recursos humanos e gestão de clientes capazes de dar resposta às necessidades de
pequenas e médias empresas. Estas aplicações adaptam-se a várias áreas dentro de
uma empresa, sempre com vista a melhorar os processos organizacionais (NCR
Corporate, 2018).

Ao implementar um software de gestão, a sua organização ganhará uma melhor

gestão do tempo no trabalho, facilidade de organização dos processos de uma
empresa, um melhor funcionamento do fluxo de trabalho, ao mesmo tempo que ajuda
a acelerar os processos organizacionais e negócios (NCR Corporate, 2018).

Conseguirá de uma forma mais eficaz armazenar todas as informações de clientes.

Posteriormente, com os relatórios vai conseguir ter uma visão geral de todos os dados
e informação sobre os seus clientes e o seu mercado (NCR Corporate, 2018).

O SAC oferece soluções na área de gestão administrativa, contabilidade, controlo de

tesouraria, gestão de petrimónio, gestão comercial, encomendas a fornecedores,
controlo de stocks, gestão de recursos humanos, controlo de pessoal, e
processamento de salários (NCR Corporate, 2018).

1.2.2.2 Resumo dos sistemas estudados

Os sistemas acima estudados a nível nacional e internacional, se adaptam ao negócio
do cliente, mas não foram utilizados por possuirem um custo elevado, visto que o
cliente não possui valores suficiente para adquirir uma liçenca dos respectivos
softwares. Mais algumas funcionalidades importantes que podemos tirar dos
softwares estudados para pudermos implementar no sistema a ser implementado
foram, gestão dos clientes cadastrados, emissão de relatórios, assim como emissão
de facturas.

Por esta razão houve a necessidade de se criar um sistema que se adaptasse ao

processo do negócio e a realidade do cliente, é por esta razão que surge o SIGV-BCH.

Outro ponto a salientar sobre os demais sistemas do sector presentes no mercado, é

que ele será implementado na sua totalidade com ferramentas livres, e usará
tecnologias actuais que futuramente através de actualizações poderá obter novas

11
funcionalidades acrescentadas através das necessidades que o cliente demonstrar
sobre o uso do sistema.

1.3 Metodologia de desenvolvimento de software

Metodologias de desenvolvimento é a maneira de se utilizar um conjunto coerente e
coordenado de métodos para atingir um objectivo. Em outras palavras, a metodologia
deve definir quais as fases de trabalho previstas no desenvolvimento de sistemas
(Walteno Júnior, 2016).

Metodologias ágeis têm sido apontadas como uma alternativa às abordagens

tradicionais para o desenvolvimento de software. As metodologias tradicionais,
conhecidas também como pesadas ou orientadas a planeamentos, devem ser
aplicadas apenas em situações em que os requisitos do sistema são estáveis e
requisitos futuros são previsíveis. Entretanto, em projectos em que há muitas
mudanças, em que os requisitos são passíveis de alterações, onde refazer partes do
código não é uma actividade que apresenta alto custo, as equipes são pequenas, as
datas de entrega do software são curtas e o desenvolvimento rápido é fundamental,
não pode haver requisitos estáticos, necessitando então de metodologias ágeis. Além
disso o ambiente das organizações é dinâmico, não permitindo então que os requisitos
sejam estáticos. Processos orientados a documentação para o desenvolvimento de
software são, de certa forma, factores limitadores aos desenvolvedores e muitas
organizações não possuem recursos ou inclinação para processos pesados de
produção de software. Por esta razão, as organizações pequenas acabam por não
usar nenhum processo. Isto pode levar a efeitos desastrosos na qualidade do produto
final, além de dificultar a entrega do software nos prazos e custos predefinidos (Michel
Soares, 2016).

Uma metodologia define estados, etapas e fases de desenvolvimento do software.

Também define tarefas, actividades. As metodologias podem ser pesadas ou ágeis.

1.3.1 Metodologias pesadas

As metodologias pesadas dominaram a forma de desenvolvimento de softwares até o
início da década de 90, estas metodologias devem ser aplicadas apenas em situações
em que os requisitos do sistema são estáveis e os requisitos futuros são previsíveis
(Alessandro, 2016).

12
As metodologias pesadas são, de certa forma, barreiras impostas ao
desenvolvimento, pois muitas organizações não possuem recursos para processos
pesados de produção de software. Por esta razão, as organizações pequenas acabam
por não usar nenhum processo. Isto pode trazer efeitos negativos no que diz respeito
a qualidade do produto final, além de dificultar a entrega do software nos prazos,
custos e funcionalidades previamente definidas (Daniel, 2017).

1.3.2 Metodologias ágeis

A expressão “metodologias ágeis” tornou-se conhecida em 2001, quando
especialistas em processos de desenvolvimento de software representando entre
outros, os métodos SCRUM (não tem sigla, é o nome de um framework que tem como
princípio o manifesto ágil) e Extreme Programming (XP), foram estabelecidos
princípios e características comuns destes métodos. Assim foi criada a “Aliança Ágil”
e efectuou-se o estabelecimento do “Manifesto Ágil” (Daniel, 2017).

Principais conceitos da metodologia ágil

o Pessoas e interações, ao contrário de processos e ferramentas.
o Software executável, ao contrário de documentação extensa e confusa.
o Colaboração do cliente, ao contrário de constantes negociações de contratos.
o Respostas rápidas para as mudanças, ao contrário de seguir planos
previamente definidos.

Algumas metodologias ágeis são:

o XP( Extreme Programming), que em português siginifica programação extrema.
o SCRUM não tem sigla, é o nome de um framework que tem como princípio o
manifesto ágil, é um framework muito utilizado no desenvolvimento e gestão de
um produto de software ágil).
o OpenUp (Unified Process) em português significa processo unificado.

Abaixo se tem uma comparação entre as metodologias pesadas e ágeis, conforme

na tabela 1.
Tabela 1: Deferenças entre metodologias pesadas e ágeis Fonte:(Nerur, Mahaptra e Mangalaraj, 2015).

Funcionalidades Pesadas Àgil

13
 Software de alta qualidade
Sistemas são bem específicos pode ser desenvolvido por
Premissas fundamentais e podem ser construidos pequenas equipas que usam
através de planeamento princípios da melhoria
meticuloso e estensivo contínua em design e testes,
sendo baseados em feedback
rápidos e posíveis
Controlo Centrado em processos Centrado em pessoas
Estilo de Gestão Comando e controle Liderança e colaboração
Gestão do conhecimento Explícito Tácito
Atribuição de Papéis Individuais - favorecem Equipas autogeridos –
especialização encorajam troca de papeis
Comunicação Formal Informal
Papel do Cliente Importante Crítico
Ciclo do Projecto Guaido por tarefas ou Guiado por funcionalidades do
actividades produto
Modelo de desenvolvimento Modelo do ciclo de vida Modelo de entrega evolutiva
(cascata, aspiral ou alguma
variação destes)
Estrutura ou forma Mecânica(burocrática, com Orgânica(flexivel, participativa,
organizacional desejada alta formalização) encorajando ação social
cooperativa)
Tecnologia Sem restrições Favorece a tecnologia
orientada a objectos

1.3.2.1 Metodologia usada

Das metodologias de desenvolvimento de software existentes, decidiu -se utilizar a
metodologia ágil, particularmente o OpenUp, por estar baseado em quatro princípios
fundamentais: Colaboração, Equilíbrio, Foco e Evolução. Esses princípios definem o
processo por completo através da participação dos actores envolvidos, dos artefactos
a serem produzidos e das tarefas a serem cumpridas no decorrer do ciclo de vida de
desenvolvimento.

Processo unificado aberto OpenUp

A IBM liberou o processo unificado rational (RUP) para o pessoal do eclipse
customizar e gerar o seu próprio processo. Surge assim a metodologia OpenUp, ou,
Processo Unificado Aberto, uma metodologia ágil de desenvolvimento de software,
baseada nas principais características do RUP. A OpenUp, por si só, é um processo
unificado leve que aplica as abordagens iterativa e incremental em um ciclo de vida
estruturado, abordando uma filosofia ágil e pragmática que foca na natureza
colaborativa do desenvolvimento de software. A OpenUp é uma metodologia livre de

14
ferramentas e de baixo formalismo que pode ser estendido a uma variada gama de
tipos de projectos e não apenas desenvolvimento de software (Eclipse, 2016).

O OpenUp, assim como o RUP é um processo iteractivo incremental de

desenvolvimento de software e está estruturado em 3 camadas distintas:

1.4 Ferramentas e tecnologias de desenvolvimento

Existem diversas ferramentas e tecnologias para o desenvolvimento de software,
nesta secção serão apresentadas as principais ferramentas e tecnologias usadas para
o desenvolvimento do projecto, tendo em conta as necessidades do software, e
escolhendo aquelas que mais se adequam com o sistema proposto, e com maior
destaques no mundo das tecnologias de informação e comunicação (TICs).

1.4.1 Netbeans IDE 8.2

A IDE netbeans é um ambiente de desenvolvimento multiplataforma, uma ferramenta
que auxilia programadores a escrever, compilar, debugar e instalar aplicações, foi
arquictetada em forma de uma estrutura reutilizável que visa simplificar o
desenvolvimento e aumentar a productividade pois reúne em uma única aplicação
todas estas funcionalidades. Totalmente escrita em java, mas que pode suportar
qualquer outra linguagem de programação ou linguagem que desenvolva com swing,
algumas das linguagens que o netbeans suporta são o C, C++, Ruby, PHP, XML e
linguagens HTML (Apache Software Foundation, 2019).

Actualmente está distribuído em diversos idiomas e isto tem o tornado cada vez mais
popular, facilitando o acesso a iniciantes em programação e possibilitado o
desenvolvimento de aplicativos (Apache Software Foundation, 2019).

Como o netbeans é escrito em java, é independente de plataforma, funciona em

qualquer sistema operacional que suporte a máquina virtual java (JVM) (Apache
Software Foundation, 2019).

1.4.2 Java 8
O Java é uma tecnologia usada para desenvolver aplicações que tornam a web mais
divertida e útil. O java não é a mesma coisa que o javascript., que é uma tecnologia
simples usada para criar páginas web e só é executado no seu browser (Oracle, 2019).

15
O java permite executar jogos, fazer upload de fotos, bater papo on-line, e usar
serviços, como treinamento on-line, transações bancárias on-line e mapas
interactivos. Se você não tiver o java, muitas aplicações e websites simplesmente não
funcionarão (Oracle, 2019).

Por defeito, o java avisará a você automaticamente que novas atualizações estão
prontas para serem instaladas. Para manter-se actualizado e proteger seu
computador, é importante aceitar e instalar essas actualizações. Se você for avisado
sobre uma actualização do java no computador windows e não lembrar de ter feito
download dela e instalado, pode ser que o java tenha vindo pré-carregado com seu
novo computador (Oracle, 2019).

Java é uma linguagem de programação desenvolvida pela empresa sun microsystems

que mais tarde foi comprada por outra empresa chamada oracle. O propósito da java
foi criar uma linguagem que fizesse com que o internauta pudesse interagir a partir
deste sistema operacional instalado, seja windows em qualquer de suas versões
modernas, mac, linux, etc ( Oliveira, Andrade, e Yanover, 2019).

1.4.3 JavaFX Scene Builder 8.5.0

O javafx scene builder fornece um ambiente de layout visual que permite projectar
rapidamente interfaces de usuário (UI) para aplicativos javafx sem precisar escrever
nenhum código. Ele permite o posicionamento simples de arrastar e soltar de
componentes da interface gráfica do usuário (GUI) em uma cena javafx. À medida que
você cria o layout da sua interface do usuário, o código FXML do layout é gerado
automaticamente. O javafx scene builder fornece uma interface simples, porém
intuitiva, que pode ajudar até mesmo os não programadores a criar rapidamente
protótipos de aplicativos interativos que conectam componentes GUI à lógica do
aplicativo (Oracle, 2014).

Características principais:
O javafx scene builder inclui os seguintes recursos principais:
o Uma interface WYSIWYG ( “What You See Is What You Get” e quer dizer “O
que você vê é o que você obtém”), de arrastar e soltar permite que você crie
rapidamente um layout de GUI sem a necessidade de gravar o código-

16
 fonte. Você pode adicionar, combinar e editar os controles GUI do javafx no
layout usando a biblioteca de controles da GUI e o painel de conteúdo.
o A geração automática de código FXML ocorre quando você cria e modifica seu
layout de GUI. O código FXML gerado é armazenado em um arquivo separado
da fonte lógica do aplicativo e dos arquivos da folha de estilo.
o Os recursos de edição e visualização ao vivo permitem visualizar rapidamente
as alterações no layout da GUI que você faz sem precisar compilar. Esses
recursos ajudam a minimizar o tempo de desenvolvimento do seu
aplicativo. Você também pode atribuir folhas de estilo em cascata (CSS) ao
layout da GUI e visualizar a aparência e a aparência resultantes que são
aplicadas.
o O javafx scene builder kit é fornecido com o scene builder 2.0. O kit é uma
interface de programação de aplicações (API) que permite a integração de
painéis e funcionalidades do scene builder directamente na GUI de um
aplicativo maior, ou um IDE java, como netbeans, intellij e eclipse.
o O suporte CSS permite o gerenciamento flexível da aparência da interface do
usuário do seu aplicativo.

1.4.4 Ferramenta CASE de modelagem com UML

Ferramentas CASE (do inglês Computer-Aided Software Engineering) é uma
classificação que abrange todas as ferramentas baseadas em computadores que
auxiliam atividades de engenharia de software, desde análise de requisitos e
modelagem até programação e testes. Podem ser consideradas como ferramentas
automatizadas que tem como objetivo auxiliar o desenvolvedor de sistemas em uma
ou várias etapas do ciclo, de desenvolvimento de software (Netbeans, 2016) Não há
um padrão definido para a categorização das CASE, no entanto os termos abaixo são
os que melhor o identificam (Juliana, 2015).

1. Front end ou upper case: apoia as etapas iniciais de criação dos sistemas: as
fases de planejamento, análise e projeto do programa ou aplicação.
2. Back end ou lower case: dão apoio à parte física, isto é, a codificação, testes
e manutenção da aplicação.

17
 3. I-case ou integrated case: classifica os produtos que cobrem todo o ciclo de
vida do software, desde os requisitos do sistema até o controle final da
qualidade.

Objectivos:
o Melhorias da qualidade de software
o Aumento da produtividade no processo de software

Vantagens do uso de ferramentas case:

o Qualidade no produto final
o Produtividade
o Agilizar o tempo para tomada de decisão
o Menor quantidade de códigos de programação
o Melhoria e redução de custos na manutenção
o Agilidade no retrabalho do software
o Maior facilidade para desenvolvimento

Desvantagens do uso de ferramentas case:

o Incompatibilidade de ferramentas
o Formação para utilização

Para a modelagem deste sistema, se vai utilizar o visual paradigm, visto que é
uma ferramenta que além do suporte à modelagem, ele fornece recursos de geração
de relatórios e engenharia de código, incluindo geração de código . Ele
pode reverter diagramas de engenharia a partir do código e fornecer engenharia de
ida e volta para várias linguagens de programação ou ainda é uma ferramenta que
suporta o ciclo de vida completo do projecto (Juliana, 2015).

1.4.5 Visual Paradigm 15.1

Visual paradigm for UML é uma ferramenta CASE com várias opções de modelagem
com os diagramas da UML2 e que também oferece suporte a diagramas de requisitos
Linguagem de modelação de sistemas (SysML) e a diagramas entidades
relacionamentos (ER). A ferramenta possui um bom ambiente de trabalho, o que
facilita a visualização e manipulação do projeto de modelagem. É uma ferramenta
comercial e também oferece suporte a transformações específicas para códigos-fonte

18
de algumas linguagens de programação como, por exemplo, C++ e Java (Visual
Paradigm, 2014).

Vantagens que apresenta:

o Tem uma interface muito intuitiva e é fácil de aprender.
o Permite a geração automática de diagramas a partir da descrição de casos de
uso.
o Permite a descrição dos casos de uso que de uma variedade de modelos
padrão que permitem a personalização
o Ele combina a funcionalidade de todos os problemas em uma plataforma de
modelagem visual de comprimento.

O suporte a perfis UML é oferecido, sendo também permitida a utilização de notação

gráfica para os estereótipos. Na implementação de um perfil, ao adicionar os
estereótipos, já se escolhe a metaclasse que ele vai estender. É possível, também,
efectuar importação/exportação de modelos usando o formato padrão de intercâmbio
de modelos XMI (Visual Paradigm, 2014).

1.4.6 PostgreeSQL 9.4

O postgresql é um sistema de código aberto de gerenciamento de banco de dados. É
um sistema que já está a longo tempo no mercado e vem ganhando cada vez mais
confiabilidade. Suas características lhe conferem grande integridade e conformidade
a padrões (postgresql, 2014).

Este sistema de gestão de base de dados (SGBD) oferece muitas funcionalidades

modernas e tem suporte a comandos complexos como junções, chaves estrangeiras,
visões, integridade transacional e procedimentos armazenados em múltiplas
linguagens. Por ser um sistema de código aberto o usuário pode acrescentar e ampliar
o código adicionando novos tipos de dados, funções, operadores, etc. (Postgresql,
2014).

Postgresql é um sistema multiplataforma, que roda em diferentes sistemas

operacionais. Inclui a maioria dos tipos de dados entre eles: integer, numeric, boolean,
varchar, char, date, interval e timestamp e suporta o armazenamento de objectos
binários, incluindo figuras, sons ou vídeos (Luvizon, 2016).

19
1.4.7 Jasper Report 6.2.0
A biblioteca jasper report é um mecanismo de relatórios mais popular open source do
mundo. É totalmente escrito em java e é capaz de usar dados provenientes de
qualquer tipo de fonte de dados e produzir documentos de pixel -perfeito que podem
ser visualizados, impressos ou exportados em uma variedade de formatos de
documentos, incluindo HTML, PDF, Excel, Open Office e Word (Jaspersoft Comunity,
2019).

1.5 Conclusões parciais

Sendo que explicou-se o funcionamento das boutiques, bem como sistemas de gestão
de vendas a nível nacional e internacional, pelo que serviu de apoio na criação do
sistema de gestão de vendas, com base no que foi apresentado, vimos que a
tendência das boutiques é adquirir um sistema de gestão de vendas para controlar o
processo de negócio, podemos esperar que a boutique BCH-Lda possa gerenciar
suas informações da melhor maneira possível e que possa obter êxitos no processo
de negócio daqui para frente.

20
2 CAPÍTULO II: CARACTÉRISTICAS DO SISTEMA
Introdução
Este capítulo descreve os processos que ocorrem na boutique BCH-Lda, análise de
negócios que surge em cada um dos processos mencionados e a seguir são
identificados os requisitos funcionais e não funcionais do sistema.

São elaborados e descritos os diagramas de casos de uso do negócio e de casos de

uso de sistema; as regras de negócio são bem definidas e o protótipo do sistema é
elaborado.

2.1 Modelagem do negócio

A Modelagem de negócio pode ser vista como uma disciplina que envolve um conjunto
de conceitos, modelos e técnicas com o objetivo de desenvolver o modelo de negócio
de uma organização. Para isso, a modelagem de negócios vai se basear nos
processos de negócio da organização. Sommerville define esses processos como
sendo processos usados para atingir algum objectivo de negócio. Podemos tornar
essa definição mais clara se definirmos esses processos como sendo aqueles ligados
à área fim da organização (Somerville, 2014).

O resultado da modelagem de negócio são os modelos de negócio. Esses modelos

refletem a representação de um conjunto de actividades, tanto internas (como
planeamento), quanto externas (como tomada de acção), que são executadas para
transformar entradas em saídas, produzindo trabalho (produto/serviço) nas
organizações (Somerville, 2014).

A adoção das actividades de modelagem de negócio como parte dos processos de

construção de software traz inúmeros benefícios às organizações. Além de sugerir a
otimização das rotinas organizacionais, a modelagem de negócio apóia a
especificação do software que será produto do projecto, através da análise e do
entendimento do negócio. Podemos citar, como sendo os principais objectivos da
modelagem de negócio:
o Entender o negócio.
o Entender os problemas actuais e identificar as possibilidades de melhoria.

21
 o Documentar os processos de negócio e capturar a relação entre os seus
conceitos.
o Derivar os requisitos de sistema necessários para sustentar a organização.

Sendo assim, neste capítulo faz-se a abordagem de conteúdos ligados a análise e

desenho dos sistemas de gestão de vendas (SIGV-BCH). Se vai descrever a
solução geral e o seu funcionamento, desde os requisistos funcionais, e não
funcionais e outros componentes importantes ligados ao processo de
desenvolvimento do software, assim como os casos de usos do sistema e de
negócio, e alguns diagramas não menos importantes.

2.1.1 Ator de negócio

Um ator é quem fará a execução do caso de uso (quem executará a funcionalidade
que está especificada no caso de uso). Atores podem ser de dois
tipos: humano e sistêmico (BetterStudio, 2019).

O ator interveniente nesta pesquisa é o ator de negócio.

Tabela 2: Ator de Negócio

Ator de Negócio Justificação

Cliente É o indivíduo que solicita um determinado
produto na Boutique
Balconista É o actor que efectua o processo de venda

Gerente É o actor responsável pelo cadastro de

produtos e toda a gestão da boutique
Funcionário É todo o indivíduo que faz parte do processo
de negócio

2.2 Modelo conceitual e descrição do negócio

Modelo conceitual mostra todos os conceitos importantes no domínio do sistema, bem
como as associações entre esses conceitos. A idéia é fazer com que o usuário que
tem acesso a esse modelo entenda os principais elementos do domínio que estão
envolvidos no sistema a ser desenvolvido. O modelo conceitual ajuda a esclarecer a
terminologia ou vocabulário do domínio. Em algumas bibliografias o modelo conceitual
também é chamado de modelo de domínio, modelo de objectos ou Diagrama de
classes de análise (Blr data, 2019).
22
Um modelo de domínio é amplamente utilizado para projectar objectos de software e
será um dado de entrada requerido por vários artefactos subsequentes. O modelo de
domínio ilustra as classes conceituais significativas em um domínio de problema; é o
artefacto mais importante a ser criado durante a análise (Pressman, 2017).

Figura 1: Modelo Conceitual do Negócio.

A boutique BCH-Lda, é uma pequena loja comercial com apenas três(3) funcionários,
dos quais um gerente, um balconista, e outro vigilante. A boutique possui uma sala de
atendimento(loja), tem um estoque de armazenamento de produtos. O balconista é o
responsável na realização de vendas.

O gerente da boutique é o responsável por adicionar os produtos e clientes no sitema,

para que o balconista faça a gestão dos mesmos no sistema.

Para se cadastrar os produtos são necessários os seguintes dados: Nome do produto,

fornecedor, preço de compra, preço de venda, quantidade em estoque, quantidade a
adicionar, data de aquisição
23
Para se cadastrar os clientes são necessários os seguintes dados: nome, morada,
telefone, e BI.

Para o processo de vendas são necessários os seguintes dados: Selecionar o cliente,

selecionar o produto desejado, adicionar a quantidade desejada e efectuar o
pagamento.

Em seguida serão definidos outros elementos que fazem parte do modelo de domínio:
o Vendas: processo que consiste em atender o cliente.
o Produtos: são bens disponíveis na boutique, com a finalidade de serem
vendidos.
o Funcionários: Pessoas que trabalham na boutique.
o Clientes: Pessoas que fazem compra de produtos na Boutique.
o Balconista: é o trabalhador da boutique responsável pelas vendas, que
interage com o sistema para atender as solicitações dos clientes.
o Gerente: é o trabalhador da boutique responsável pelo cadastramento e
atualização dos produtos.
o Loja: é o estabelecimento comercial se fazem a comercialização dos produtos

2.2.1 Diagrama de Caso de Uso do Negócio

Diagrama documenta o que o sistema faz do ponto de vista do usuário, o objectivo é
representar um requisito do sistema que será automatizado. Em outras palavras, ele
descreve as principais funcionalidades com os usuários do mesmo sistema
(Devtecnologia, 2017).

Caso de uso é tipicamente relacionados a “Atores”. Um ator é um humano ou entidade

máquina que interage com o sistema para executar um trabalho.

Diagrama de caso de uso, são compostos por quatro partes:

o Cenário: Sequência de eventos que acontece quando um usuário interage com
o sistema.
o Ator: Usuário do sistema, ou melhor, um tipo de usuário.
o Use Case: É uma tarefa ou uma funcionalidade realizada pelo ator.
o Comunicação: é o que liga o ator com um caso de uso.

Na engenharia de software, um caso de uso é um tipo de classificador representando

uma unidade funcional coerente provida pelo sistema, subsistema, ou classe

24
manifestada por sequências de mensagens intercambiáveis entre os sistemas e um
ou mais atores.

Casos de uso são narrativas em texto, descrevendo a unidade funcional, e são

amplamente utilizados para descobrir e registrar requisitos de sistemas. Os diagramas
de casos de uso são representações dos casos de uso e podem ser representados
por uma elipse contendo, internamente, o nome do caso de uso (Debastiani, 2016).

Figura 2: Diagrama do Caso de Uso do Negócio.

2.2.2 Descrição do Diagrama de Caso de Uso de Negócio

Tabela 3: DCUN comprar produto.

Caso de Uso: Comprar Produto

Ator: Cliente
Trabalhador: Balconista
Resumo: O caso de uso inicia-se quando o cliente
chega na boutique e faz um pedido
Fluxo normal de eventos
Ação Ator Resposta de Negócio
1. Solicita o produto 2. Verifica-se se o produto existe.
2.1 Se existe o produto, se pede os dados
do cliente, para a compra.

25
 3. Fornece os dados do cliente (nome, 4.Se faz o cadastro do cliente.
morada, telefone.
3. Efectua a compra 6. Se conclui a compra.
Fluxo alternativo: Produtos acabados.
2.2 se não tiver o produto que o cliente
deseja no pedido, informa-se ao cliente e
termina o caso de uso.
Tabela 4: DCUN efectuar pagamento

Caso de Uso: Efectuar pagamento

Ator: Cliente.
Trabalhador: Balconista.
Resumo: O caso de uso tem o seu início quando o
cliente chega a loja e conclui o seu pedido.
Fluxo normal de eventos
Ação Ator Resposta de Negócio
1. Solicitar pagamento. 2. Informa o preço do produto.
3. Solicita a quantidade desejada. 4. Exige o pagamento.
5. Efectua o pagamento. 6. efectua a venda.
7.Solicita a factura. 8. Imprime a factura.
9. Recebe a factura. 10. Termina o caso de Uso
Fluxo alternativo: Se não tiver a quantidade desejada.
4.1 Se não tiver a quantidade desejada,
informa-se ao cliente e termina o caso de
uso.
Tabela 5: DCUN cadastrar produtos.

Caso de Uso: Efectuar vendas

Ator: Gerente.
Trabalhador: Forncedor.
Resumo: Se inicia o caso de uso se há um produto
novo para ser cadastrado
Fluxo normal de eventos
Ação Ator Resposta de Negócio
1. Solicita o produto. 2. Faz a entrega de todos os produtos
disponíveis.

2.3 Modelagem do Sistema

As falhas em requisitos estão entre as principais razões para o fracasso de um
software. Entre as principais razões destacam-se os requisitos mal organizados,
requisitos mal expressos, requisitos desnecessários para os clientes e a dificuldade
para lidar com requisitos frequentemente mutáveis.

Portanto, um requisito é um aspecto que o sistema proposto deve fazer ou uma

restrição no desenvolvimento do sistema. Vale ressaltar que em ambos os casos

26
devemos sempre contribuir para resolver os problemas do cliente e não o que o
programador ou um arquiteto deseja. Dessa forma, o conjunto dos requisitos como
um todo representa um acordo negociado entre todas as partes interessadas no
sistema. Isso também não significa que o programador, arquicteto ou um analista bem
entendido no assunto de tecnologia não possam contribuir com sugestões e propostas
que levem em conta o desejo do cliente (Pressman, 2019).

2.3.1 Requisitos Funcionais

Os requisitos funcionais são a descrição das diversas funções que clientes e usuários
querem ou precisam que o software ofereça. Eles definem a funcionalidade desejada
do software. O termo função é usado no sentido genérico de operação que pode ser
realizada pelo sistema, seja através de comandos dos usuários ou seja pela
ocorrência de eventos internos ou externos ao sistema (Jair Leite, 2000).

A especificação de um requisito funcional deve determinar o que se espera que o

software faça, sem a preocupação de como ele faz. É importante diferenciar a
actividade de especificar requisitos da actividade de especificação que ocorre durante
o design do software. No design do software deve-se tomar a decisão de quais
funções o sistema ecfetivamente terá para satisfazer àquilo que os usuários querem.

Para que o sistema se execute os seguintes requisitos funcionais foram identificados:

o RF-1: Autenticar usuário

o RF-2: Inserir cliente.

o RF-3: Eliminar cliente.

o RF-4: Editar cliente.

o RF-5: Imprimir Cliente.

o RF-6: Pesquisar Cliente.

o RF-7: Inserir produto.

o RF-8: Eliminar produto..

o RF-9: Editar produto.

o RF-10: Imprimir produto.

o RF-11: Pesquisar produto.

27
 o RF-12: Inserir venda.

o RF-13: Eliminar venda.

o RF-14: Editar venda.

o RF-15: Imprimir venda.

o RF-16: Pesquisar Vendas

o RF-17: Imprimir relatórios

o RF-18: Inserir Usuário

o RF-19: Modificar Usuário

o RF-20 : Eliminar Usuário.

2.3.2 Requisitos Não Funcionais

Requisitos não funcionais são aqueles que não estão directamente relacionados à
funcionalidade de um sistema. O termo requisitos não funcionais é também chamado
de atributos de qualidade. Os requisitos não funcionais têm um papel de suma
importância durante o desenvolvimento de um sistema, podendo ser usados como
critérios de seleção na escolha de alternativas de projecto, estilo arquictetural e forma
de implementação. Desconsiderar ou não considerar adequadamente tais requisitos
é dispendioso, pois torna difícil a correção uma vez que o sistema tenha sido
implementado (Sommervile, 2010).

Os requisitos não funcionais abordam aspectos de qualidade importantes em sistemas

de software. Se tais requisitos não são levados em consideração, então o sistema de
software poderá ser inconsistente e de baixa qualidade, conforme discutido acima.
Para tanto, quanto mais cedo forem definidos os critérios arquitecturais, mais cedo o
projectista pode identificar o estilo, ou combinação de estilos, mais apropriado ao
sistema considerado (Devmedia, 2017).

Para que o sistema se execute os seguintes requisitos não funcionais foram

identificados:
o Usabilidade.
✓ RNF-1: A noção de usabilidade vem do facto que qualquer sistema projetado
para ser utilizado pelas pessoas deveria ser fácil de aprender e fácil de usar,
tornando assim fácil e agradável a realização de qualquer tarefa.

28
 ✓ RNF-2: Acessível em modo desktop.
o Confiabilidade.
✓ RNF-3: É a probabilidade de o software não causar uma falha num sistema
durante um determinado período de tempo sob condições especificadas.
o Confiabilidade.
✓ RNF-4: Uma característica das engenharias é fazer uso de projectos
existentes a fim de reutilizar componentes já desenvolvidos, objectivando
minimizar o esforço em novos projectos. Dessa forma, componentes que já
tenham sido desenvolvidos e testados podem ser reutilizados.
o Segurança
✓ RNF-5: Este requisito não funcional caracteriza a segurança de que acessos
não autorizados ao sistema e dados associados não serão permitidos.
Portanto, é assegurada a integridade do sistema quanto a ataques
intencionais ou acidentes.
✓ RNF-6: Apenas pessoas que tenham sido autenticadas por um componente
de controle acesso e autenticação poderão visualizar informações dado que
a confidencialidade permite esse tipo de acesso apenas às pessoas
autorizadas.
✓ RNF-7: Identifica o nome do usuário, informando ao sistema quem está
utilizando-o
o Aparência ou interface externa

✓ RNF-8. Utiliza uma interface simples, intuitiva e de fácil interpretação.

o Apoio.
✓ RNF-9: O sistema deve ser instalado e testado.
o Hardware.
✓ RNF-10: O servidor de aplicação deve ter pelo menos 1.65 GHz e 4 GB de
RAM e disco rígido de 80 GB, para um funcionamento razoável do sistema.
✓ RNF-11: Os requisitos mínimos para dispositivos clientes: qualquer
dispositivo que tenha instalado o sistema operativo Windows.

2.3.3 Diagrama de Casos de uso do Sistema

O diagrama de casos de uso do sistema tem por finalidade mostrar as principais
funções do sistema de modo geral, depois da fase de levantamentos e análise de
29
 requisitos do sistema. É uma linguagem simples, que possibilita ao usuário ter uma
compreensão de todo o comportamento externo do sistema por qualquer pessoa. Na
Figura 3 mostra-se as principais funções do sistema gestão de vendas da boutique
BCH-Lda.

Figura 3: Diagrama do Caso de Uso do Sistema.

2.3.3.1 Descrição de casos de uso do sistema

Tabela 6: DCUS – Autenticar.

Nome: Autenticar
Finalidade/Objetivo: Permite ao utilizador acessar no sistema.
Atores: Todo o tipo de utilizadores.
Pré-condições: Deve estar cadastrado no sistema.
Evento Inicial: O sistema apresenta a tela de autenticar(inicio de sessão).
Fluxo princípal
Ações do Sistema Ações do Ator
1. O sistema mostra a tela de autenticar(inicio de 2. O utilizador preenche os dados de
sessão). autenticação (utilizador e senha).O
utilizador clica no botão autenticar ou
pressiona a tecla enter.
Fluxo de Exceção(E1)
1. O sistema mostra que a senha está incorrecta 2. Se o utilizador e a senha estiverem
ou o utilizador não esta cadastrado, mostrando correctos, é direcionado ao menu
uma mensagem de erro. principal

30
 Tabela 7: DCUS – Gerenciar Cliente

Nome Gerenciar Cliente.

Finalidade/Objetivo: Permite ao administrador efectuar as seguintes
operações no sistema: inserir cliente, eliminar
cliente, editar cliente, imprimir cliente, pesquisar
cliente.
Atores: Balconista.
Pré-condições: O balconista deve ter sessão iniciada no
sistema ou deve estar logado.
Evento Inicial: O sistema mostra tela princípal.
Fluxo princípal
Ações do Sistema Ações do Ator
1. O sistema mostra tela princípal. 2. O balconista clica no menu “clientes”, abrir-
se-á as tabelas “escolha o cliente” e “dados dos
clientes”.
3. O sistema mostra a tela de cadastro de 4. O balconista clica na tabela “pesquisar
clientes com as seguintes opções(cadastrar clientes”.
clientes, pesquisar clientes).
5. O sistema mostra os clientes ja cadastrados. 6.O balconista clica na tabela “cadastrar
clientes”.
7. O sistema mostra a tabela “cadastrar 8. O balconista preenche os dados da tabela
clientes” com os seguintes campos (nome, “cadastrar clientes” e clica no botão salvar do
morada, telefone e B.I). sub-menu acções.
9. O sistema salva os dados preenchidos pelo 10. Termina o caso de uso
administrador.
Tabela 8: Gerenciar Vendas

Nome: Gerenciar Vendas.

Finalidade/Objetivo: Permite ao balconista fazer as seguintes
operações no sistema: inserir venda, eliminar
venda, editar venda, imprimir venda, pesquisar
venda, imprimir relatórios.
Atores: Balconista.
Pré-condições: O balconista deve iniciar sessão ou estar logado
no sistema.
Evento Inicial: O sistema apresenta tela princípal.
Fluxo princípal
Ações do Sistema Ações do Ator
1. O sistema mostra a tela princípal. 2. O balconista clica no menu “nova”.
3. Mostra o menu “cliente”, “escolha o produto”, 4. O balconista clica no botão “novo”.
“quantidade” e “pagamento” e os botões “novo”,
“salvar”, “imprimir” e “cancelar”

31
5. Mostra a tabela cliente com os seguintes 6. O recepcionista preenche os campos e clica
campos (processo, nome), mostra a tabela no botão “salvar”.
“escolha o produto” com os seguintes campos
(código, quantidade, nome, preço), mostra a
tabela “quantidade” com os seguintes campos
(preço, quantidade, subtotal), mostra a tabela
“pagamento” com os seguintes campos (pago e
troco), mostra a tabela “produtos na factura com
os seguintes campos (codigo, preço, nome,
quantidade subtotal)”.
7. O sistema verifica se os campos estão bem
preencidos (E1), (E2).
Fluxo de Exceção(E1)
1. Se os campos estão vazios, o sistema mostra
uma mensagem do tipo “erro, verifique os dados
inseridos”. O sistema retorna ao 6º passo do
fluxo princípal.
Fluxo de Exceção(E2)
2. Se os campos estão preenchidos 3. O balconista imprime a factura de venda.
correctamente, o sistema fornece a factura de
venda”.
8. O sistema mostra a tela principal 9. O balconista clica no menu “relatórios”.
10. mostra o submenu “todos”, os botões “dia”, 11. O balconista clica no botão “dia”.
“més”, “ano”, “imprimir” e o “total”, a tabela de
“resultados da pesquisa” com os seguintes
campos (código, cliente, data, total, pago, troco,
alteração, estado)
12. o sistema mostra o relatório de venda do dia 13. O balconista clica no botão “més”.
14. o sistema mostra o relatório de venda do 15. O balconista clica no botão “ano”.
més
16. o sistema mostra o relatório de venda do 17. O balconista clica no botão “imprimir”.
ano.
18. o sistema exibe o relatório em uso. 19. O balconista imprime o relatório de venda

Tabela 9: Gerenciar Produto

Nome: Gerenciar Produto.

Finalidade/Objetivo: Permite ao gerente fazer as seguintes
operações no sistema: inserir produto, eliminar
produto, editar produto, imprimir produto,
pesquisar produto
Atores: Gerente
Pré-condições: O gerente deve ter sessão iniciada ou logado
no sistema.
Evento Inicial: O sistema apresenta tela princípal.
Fluxo princípal.
Ações do Sistema Ações do Ator
1. O sistema mostra a tela principal 2. O gerente clica no menu “novo”

32
3. O sistema mostra a tabela de “dados dos 4. O gerente clica no botão “Novo”, preenche a
produtos” com os seguintes campos (nome, tabela “Dados do Produto” e clica no botão
fornecedor, preço de compra, preço de venda, “salvar” ou “cancelar”
quantidade em estoque, quantidade a
adicionar, data de aquisição) com o menu
acções com os seguintes botões: “novo”,
“salvar” e “cancelar.”
5. O sistema mostra a tela princípal . 6. O gerente clica no menu “consultar”, de
seguida abrir-se-á uma tabela de “escolha o
produto” com a opção “procure o produto
desejado”.
7. O sistema mostra a tela de produtos 8. O gerente seleciona o produto desejado e
cadastrados, com os seguintes campos (id, clica “eliminar”.
nome, fornecedor, preço de compra, preço de
venda, quantidade e data de aquisição). E os
botões “pesquisar”, “eliminar” e “imprimir”.
9. O sistema verifica se o produto faz parte de
uma venda (E1), (E2).
Fluxo de Exceção(E1)
1. Se o produto que se quer “eliminar” faz parte 2. O gerente confirma a mensagem e seleciona
de uma venda, o sistema mostra uma outro produto e tenta novamente.
mensagem de erro.
Fluxo de Exceção(E2)
1. Se o produto não faz parte de uma venda, o 2. Termina o caso de uso de sistema
sistema elimina o produto.

2.4 Conclusão parcial

Este capítulo nos possibilitou compreender as caracteristicas do sistema, bem como

a modelagem do negócio de sistema de gestão de vendas. Com isso percebeu-se a
necessidade de implementação de um sistema de gestão de vendas para a gestão
das informações da boutique. Sendo assim conseguiu-se alcançar os objectivos que
foram definidos ao longo do projecto.

33
3 CAPÍTULO III: DESENHO, IMPLEMENTAÇÃO DO
SISTEMA E PROVAS
Introdução
Neste capítulo, vai retratar do processo de desenvolvimento do software, vai se
detalhar acerca do desenho e construção do software, assim como todos os
diagramas de classes, diagramas de componentes, diagrama de implantação,
ademais o modelo físico de dados, bem como a validação através das provas de
funcionamento de software. Provas estas que serão documentadas para verificar o
funcionamento correcto do sistema e detectar possíveis falhas no sistema.

3.1 Arquitectura do Sistema e Padrão de Desenho

Arquitectura de software, de um programa, ou sistema computacional são as
estruturas de sistemas que abrangem os componentes de software, as propriedades
externamente visíveis desses e as relações entre eles (Pressman, 2011).

No contexto do desenho arquitectural, um componente pode ser algo tão simples

quanto um módulo de programa ou uma classe orientada a objectos, mas também
pode ser ampliado para incluir bancos de dados e middleware (Prodabel, 2019).

O desenho permite representar os componentes em sistemas convencionais e

definições de classes ( encapsulando atributos e métodos ) em sistemas orientados a
objetos.

O desenho arquitectural focaliza a representação da estrutura de componentes de

software, suas propriedades e interações (Prodabel, 2019).

3.1.1 Modelo Visão Controladora (MVC)

O Padrão MVC é utilizado em muitos projectos devido à arquitectura que possui, o
que possibilita a divisão do projecto em camadas muito bem definidas. Cada uma
delas, o modelo, visão e a controladora, executa o que lhe é definido e nada mais do
que isso. Uma das características de um padrão de projecto é poder aplicá-lo em
sistemas distintos. O padrão MVC pode ser utilizado em vários tipos de
projectos como, por exemplo, desktop, web e mobile (Higor, 2015).

34
 Figura 4: Arquictetura modelo vista controladora

Assim o padrão MVC é composto por 3 camadas:

o O modelo que representa os dados e não deve incluir detalhes de
implementação podendo ter muitas visões associadas; como exemplo temos
as seguintes classes que fazem parte da respectiva camada: Tipo_login,
Cliente, User, etc.
o A visão que representa um componente de interface de usuário que esta
vinculado a um modelo. Ela pode exibir os dados e permitir que a modificação
dos dados pelo usuário. A visão deve sempre reflectir o estado do modelo.
Como exemplo temos as seguintes classes que fazem parte da respectiva
camada: Encomendas, Clientes, etc.
o Controladora: que fornece um mecanismo para o usuário interagir com o
sistema definindo como a interface do usuário vai reagir a ação do usuário. Ele
é responsável por trocar e interpretar mensagens entre a visão e o modelo.
Como exemplo temos as seguintes classes que fazem parte da respectiva
camada: EncomendasController, ClientesController, etc.

3.1.2 Diagrama de classes

Um diagrama de classes é uma representação da estrutura e relações das classes
que servem de modelo para objectos. Podemos afirmar de maneira mais simples que
seria um conjunto de objectos com as mesmas características, assim saberemos
identificar objectos e agrupá-los, de forma a encontrar suas respectivas classes. Na
unified modeling language (UML) em diagrama de classe, uma classe é representada
35
por um retângulo com três divisões, são elas: O nome da classe, seus atributos e por
fim os métodos (Douglas, 2016).

Figura 5: Diagrama de classes do sistema

3.2 Padrões de Desenho

Padrões de desenho são princípios e soluções usados durante a criação do software,
codificados em um formato estruturado, descrevendo o problema e a respectiva
solução adotada. Eles podem ser aplicados a novos contextos, e trazem orientações
sobre como podem ser utilizados e suas implicações (como deve ser implementado,
análise de custo-benefício) (Github, 2019).

Os padrões seguem um formato típico, com um nome, problema onde deve ser
utilizado e o detalhe da solução, como implementá-la e suas variações e vantagens.

Os princípios e o raciocínio utilizado para atribuir responsabilidades (fazer e conhecer)

de objectos podem ser descritos de modo metódico, explicável e repetível. Esses

36
princípios são os Padrões GRASP (do inglês General responsibility asignment
software patterns).

Para que haja maior qualidade no sistema que esta a ser desenvolvido, utilizamos os
seguintes padrões:
o Criador: 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 usuário em um momento específico, ou seja, a classe ClienteDao é
responsável por inserir o objecto do tipo cliente através do registro na camada
de persistência e retorno deste objeto, caso o método inserir cliente seja
invocado.

Figura 6: Aplicação do padrão Criador na classe UserDao

o Alta coesão: 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 login (que cuida somente do login do usuario).

37
 Figura 7: Aplicação do padrão Alta coesão na classe Tipo_AutenticarDao

o Polimorfismo: é 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 pesquisar. A classe search determina o
método get_type_search onde é analisado qual a pesquisa será analisada, é
dessa forma que o polimorfismo é utilizado.

38
 Figura 8: Aplicação do padrão Polimorfismo na subclasse pesquisar

3.3 Modelo lógico do Banco de Dados

Os modelos de banco de dados são usados para descrever, mais detalhadamente, a
estrutura de um banco de dados. Os modelos também são baseados em três níveis:
conceitual, lógico e físico (Fábio dos Reis, 2018).

Descreve como os dados serão armazenados no banco de dados e também seus

relacionamentos. Esse modelo adota alguma tecnologia, pode ser: relacional,
orientado a objetos, orientado a colunas, entre outros (Fábio dos Reis, 2018).

Os modelos lógicos basicamente determinam se todos os requisitos foram reunidos.

Ele é revisado pelos desenvolvedores, pelo gerenciamento e, por fim, pelos usuários
finais para ver se é necessário colectar mais informações antes do início da modelo
físico (Fábio dos Reis, 2018).

39
 Figura 9: Modelo lógico do banco de dados

3.4 Diagrama de Implantação

O diagrama de implantação é o diagrama estrutural responsável por estabelecer a
relação entre os recursos de infraestrutura e artefatos do sistema, em outras palavras,
ele mapeia arquitetura do hardware às necessidades do software a ser implantado.
Esse diagrama é basicamente implementado com “nós”, “associações entre nós”. Os
“nós” são formas ou containers de UML, usadas para representar um item de
hardware, como um servidor físico, seja ele de armazenamento ou execução da
aplicação ou de módulos isolados, ou ainda um “nó” pode significar o ambiente de
execução do software ou parte dele (Silva, 2017).

O propósito deste modelo de diagrama é documentar os itens envolvidos a fim de

tornar ágil o processo de implantação de software.

40
 Figura 10: Diagrama de implantação do sistema.

3.4.1 Descrição do modelo de implantação do sistema

Tabela 10: Descrição dos dispositivos do diagrama de implantação

Nós / Dispositivos Descrição

PC cliente Pc do cliente, é o dispositivo pelo qual a
aplicação é acessada.
Servidor de banco de dados Repositório de dados, é onde se armazenam
os dados. E o sistema de gestão de base de
dados é o postgreeSQL
Impressora Dispositivo usado para impressão de
facturas, relatórios, e toda a documentação
ou arquivos.
Tabela 11: 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)

41
3.5 Protótipos de Interfaces

Figura 11: Tela Iniciar Sessão

Figura 12: Tela Principal

42
Figura 13: Tela pesquisar produto

Figura 14: Tela cadastro de cliente

43
3.6 Validação do sistema com provas de software
Os testes representam uma etapa de extrema importância no processo de
desenvolvimento de software, pois visam validar se a aplicação está funcionando
corretamente e se atende aos requisitos especificados.

Um processo de teste de software tem como objetivo estruturar as etapas, as

actividades, os artefactos, os papéis e as responsabilidades do teste, permitindo
organização e controle de todo o ciclo do teste, minimizando os riscos e agregando
valor ao software (Devmedia, 2019).

A estruturação do processo tem o propósito de reduzir o número de erros

apresentados no projecto. Mas para que isso seja possível, a definição dos objectivos
do teste deve ser bem clara, as melhores técnicas devem ser selecionadas. e uma
equipe de pessoas treinadas e qualificadas deve estar apta para desempenhar os
respetivos papéis dentro do processo (Devmedia, 2019).

Nesse contexto existem diversas técnicas que podem ser aplicadas em diferentes
momentos e de diferentes formas para validar os aspectos principais do software.

3.6.1 Tipos de Provas

Existem diversos tipos de provas que se aplicam no processo de desenvolvimento de
software, dependentemente do contexto das aplicações. Neste projecto se vai utilizar
as seguintes provas:

Provas unitárias: as provas unitárias têm por objectivo validar pequenas partes do
software com base em suas entradas possíveis e saídas esperadas. As unidades
usadas nesse tipo de provas são as menores partes testáveis de um sistema,
normalmente funções, que recebem argumentos e retornam um determinado valor ou
efectuam alguma acção cujo resultado pode ser analisado (Devmedia, 2019).

Provas funcionais: Além dos tipos de software que avaliam o código dos programas,
existem alguns que visam analisar seu comportamento externo: os provas funcionais.
Normalmente esse tipo de provas se baseiam nos requisitos do sistema e consiste de
realizar ações de uso real no sistema, entrando com dados e avaliando seu retorno
(Devmedia, 2019).

44
3.6.1.1 Provas Funcionais

Provas funcionais é a técnica de teste em que o componente de software a ser testado

é abordado como se fosse uma caixa preta, ou seja, não se considera o
comportamento interno do mesmo. Os dados de entrada são fornecidos, o teste é
executado e o resultado obtido é comparado a um resultado esperado previamente
conhecido. Haverá sucesso no teste se o resultado obtido for igual ao resultado
esperado. O componente de software a ser testado pode ser um método, uma função
interna, um programa, um componente, um conjunto de programas ou componentes
ou mesmo uma funcionalidade (Luís Renato Dos Santos, 2017).

Ao efectuarem-se o método de caixa preta, encontramos os seguintes erros:

o Erros de início e finalização
o Funções incorretas ou faltando
o Erros de desempenho
o Erros de Interface
Em seguida se fez o tratamento dos erros encontrados.

Partição equivalente: Trata-se de uma técnica de testes que propõe a separação das
possíveis entradas em categorias diferentes. Partições de equivalência podem ser
encontradas em dados válidos e inválidos (valores que deveriam ser rejeitados, por
exemplo). As partições podem ser identificadas para valores de saída, valores
relativos ao tempo (antes ou depois de um evento), bem como valores internos ao
processo (Rafael Goulart, 2019).

Desenho de casos de prova de caixa preta:

Na tabela 12 é mostrada as provas de caixa preta correspondente ao caso de uso
iniciar sessão.
o Caso de Uso: Iniciar Sessão
o Descrição Geral: O caso de uso tem o seu início quando usuário pretende
iniciar sessão no sistema.
o Condições de execução: o usuário deve estar autenticado no sistema e ter a
permissão de usuário.
o Cenário de Prova: na tabela asseguir, são apresentadas as condições de
entrada, posteriormenta as avaliações das classes de equivalências válidas e
não válidas, assim como os respectivos resultados.
45
 Tabela 12: Prova de caixa preta

Condições de entrada Classes de Classes de equivalências

equivalência Válidas não válidas
O campo utilizador deve Utilizador = “Laurindo” Utilizador = “”
estar preenchido
O campo senha deve estar Senha= “laurindo” Senha = “”
devidamente preenchido.
Resultado da prova válida: o sistema direciona o utilizador ao menu principal

Resultado de Prova não válida: O sistema não direciona o utilizador ao menu

principal.

46
3.6.1.2 Provas de Unitárias
Provas unitárias: é a técnica de teste que avalia o comportamento interno do
componente de software. Trabalha directamente sobre o código-fonte do componente
de software para avaliar aspectos tais como: teste de condição, teste de fluxo de
dados, teste de ciclos e testes de caminhos lógicos. O testador tem acesso ao código
fonte da aplicação e pode construir códigos para efectuar a ligação de bibliotecas e
componentes (Pressman, 2010).

Provas de caixa branca: Esse tipo de teste, também conhecido como teste estrutural,
é projectado em função da estrutura do componente e permite uma averiguação mais
precisa do comportamento dessa estrutura (Barcelar, 2015).

Caminho básico é uma técnica de teste caixa branca, onde calcula se a

complexidade lógica do software e utiliza esta medida como base para descobrir os
caminhos básicos do software e exercendo o teste de modo que todos os caminhos
sejam efetuados (Pressman, 2010).

Na figura 15, mostra um fragmento do código do botão salvar, para mostrar como foi
aplicada a técnica de caminho básico no sistema implementado.

Figura 15: Código fonte salvar produto

47
 Figura 16: Gráfico Fluxo Prova de caixa branca

A complexidade ciclomática tem fundamento na teoria dos grafos e fornece uma

métrica de software extremamente útil. A complexidade é calculada da seguinte forma:
V(G) = A - N + 2

Onde A corresponde ao número de arestas, e N corresponde aos nós do grafo.

Logo se tem: V(G) = 4 – 4 + 2 onde V(G) = 2

Caminhos: 1 - 2 -4:
o Caso de prova: Salvar Produto
o Entrada: O usuário adiciona um novo produto
o Resultado: O sistema apresenta uma mensagem de alerta (´Produto salvo com
sucesso`).

Caminhos: 1 – 3 – 4:
o Caso de prova: Atualizar produto
o Entrada: Quando se cadastra um novo produto
o Resultado: o sistema apresenta uma mensagem de alerta (Produto atualizado
com sucesso).

48
3.6.2 Resultados das provas
Ao aplicar as provas de software, foram elaborados vinte e cinco (25) cenários de
provas, em três (3) iterações. A partir da primeira iteração foram detectadas 15
inconformidades, dentre as incorfomidades encontradas nove (9) eram erros lógicos
e pressuposições incorrectas, seis (6) eram erros ortográficos ou erros de escrita, dos
quais se fez a correção de todas. Depois de se terem feitas as correções se fez
novamente todos os casos de prova na segunda iteração e com o resultado tivemos
cinco (5) inconformidades, das quais três (3) de erros lógicos e duas (5) de erros de
escrita, se fez a correção na totalidade. Ao realizarmos a terceira (3) iteração não se
obteve alguma inconformidade, como se representa no gráfico abaixo (Figura 17).

Figura 17: Resultado das provas de software

3.7 Conclusões Parciais

Ao finalizarmos este capítulo, possibilitou-nos fazer uma análise de como um sistema
melhorou a gestão de vendas de uma boutique, e com as provas de softwares nos
possibilitou fazer a detecção de erros no funcionamento do sistema o que garantiu
qualidade ao longo do processo de deenvolvimento do aplicativo para a gestão das
vendas da boutique BCH-Lda.

49
CONCLUSÕES
Com a realização deste projecto, podemos afirmar que se resolveu o problema de
investigação que foi definido no início, assim como a resolução dos objectivos
específicos. Sendo que, chegou-se as seguintes conclusões:

O estudo dos sistemas de gestão de vendas a nível nacional e internacional nos

permitiu definir ideias que possibilitou dar resposta aos problemas identificados na
boutique BCH-Lda, com base no controlo da gestão de vendas.

A escolha da metodologia de desenvolvimento do software, e a utilização das

ferramentas de modelagem, nos permitiu modelar o negócio e serviu de base para
comprrendermos devidamente o negócio e definirmos as a principais funções a serem
implementadas.

Mediante as provas de softwares aplicados no sistema, foi possível detectar erros e

corrigi-los, bem como tornou possível verificar que o sistema cumpre com os requisitos
estabelecidos.

Com o uso do aplicativo se faz o controlo da gestão de vendas da Boutique BCH-Lda,

pois o que antes era feito de forma manual, agora passará a ser feito de forma
automática através deste sistema, o que irá diminuir os riscos de perdas de
informações e dificuldades na tomada de decisões.

50
RECOMENDAÇÕES
Ao término da realização do trabalho, se constatou que os objectivos definidos foram
alcançados, pelo que se recomenda o seguinte:

A implantação do sistema na boutique BCH-Lda

A geração de gráficos para acompanhamento das vendas e também geração de

gráficos para estatísticas de vendedores.

A adaptação para a leitura de códigos de barras, para facilitar na identificação do

produto e agilizar o processo de cadastramento dos produtos e melhorar o
atendimento.

51
REFERÊNCIAS BIBLIOGRÁFICAS
1. BENDINHA, Jose Pascoal Batalha. Sistema de Gestão de dados do pessoal
para o Distrito de Recrutamento e Mobilização do Estado Maior General.
Luanda: Instituto Superior Para as Tecnologias de Informação e
Comunicação(ISUTIC). 2017.

2. BUTA, Amaro Francisco Benjamim. Sistema Informático para Controlo Das

Finanças Pessoais. Luanda : Instituto Superior Para as Tecnologias de
Informação e Comunicação(ISUTIC). 2018.

3. CAMPOS, Edmilsom. Modelagem Conceitual. Rio Grande do Norte : Instituto

Federal de Educação Ciência e Tecnologia, 2010.

4. GESTÃO CLICK. Sistema-pdv. gestãoclick. [Online] Sistema PDV Online.

2019. Disponível em <https://gestaoclick.com.br/sistema-pdv>.

5. CASA DA CONSULTORIA. casadaconsultoria. [Online] 2011. [Visto em: 26 de

Junho de 2019.] Disponível em <https://casadaconsultoria.com.br/gestao-de-
vendas/>.

6. NCR CORPORATE. NCR Corporate. NCR Corporate. [Online] NCR-Angola

Informática Lda, 2018. Disponível em <https://www.ncrcorporate.co.ao/pt/sac-
software-de-gestao/formacao/#conteudo>.

7. DANIEL, Conceitos básicos sobre Metodologias Ágeis para Desenvolvimento

de Software (Metodologias Clássicas x Extreme Programming). Devmedia.
2008.

8. DEBASTIANI., 2016. Engenharia de Software. 2ª ed. Brasil: São Paulo.

9. PORTO EDITORA., 2014. Manutenção de computadores - Prático de

informática. Porto - Portugal : Porto Editora, 2014. 978-972-0-06677-0.

10. EDUCALINGO., Loja [on-line]. educalingo. [Online] educalingo. Disponível em

<https://educalingo.com/pt/dic-pt/loja>.

11. Fitsmallbusiness. 2019. FitSmallBusiness. [Online] 2019. [Citado em: 10 de

Abril de 2019.] Disponível em <https://fitsmallbusiness.com/sales-
management-software/>.

52
12. FRESHWORKS. 2018. Freshsales. Freshsales. [Online] Freshsworks Inc.,
2018. Disponível em <https://www.freshworks.com/>.

13. GLUON. 2018. Gluon. Gluon. [Online] Scene Builder, 17 de Maio de 2018.
[Citado em: 20 de Junho de 2019.] Disponível em
<http://gluonhq.com/products/mobile/gluonmobiledocumentation.html>.

14. GODART, Frederic. 2010. Sociologia da Moda. São Paulo : Senac, 2010.

15. GITHUB, Inc. 2019. Git Hub. Git Hub. [Online] GitHub Inc, 2019. [Citado em:
13 de Junho de 2019.] Disponível em <https://github.com/Software-Design-
2017/EmbelezaMais/wiki/Padr%C3%B5es-GRASP>.

16. INFOPÉDIA, Dicionario. 2003. infopédia. Infopédia. [Online] 2003. [Citado em:
05 de 04 de 2019.] Disponível em <https://www.infopedia.pt/dicionarios/lingua-
portuguesa/loja>.

17. ISABEL, ALBERTO, Sampaio, Sampaio. 2013. Visual C++/CLI Curso

completo. Lisboa(Sede): Rua D. Estefânia, 183, r/c-Dto : FCA, 2007. 978-972-
722-364-0.

18. JÚNIOR, Walteno Martins Parreira. 2016. Apostila de Engenharia de

Software. [Apostila] Minas Gerais : Universidade do Estado de Minas Gerais,
2016.

19. LOUREIRO, Henrrique. 2014. Visual Basic 2010 Curso Completo. Porto - Rua
Damião De Gois : FCA, 2010. 978-972-722-657-3.

20. MARTINS, Marcelo. 2016. Relatórios em Java – JasperReports e iReport. k19.

[Online] 20 de 11 de 2010. [Citado em: 15 de 12 de 2016.]
<http://www.k19.com.br/artigos/relatorios-em-java-jasperreports-e-irepor/>.

21. DOUGLAS. 2016. Orientações básicas na elaboração de um diagrama de

classes. Barra da Tijuca - Rio de Janeiro : Dev media, 2016.

22. PAULO, Alberto José. 2018. sistema de venda para padaria e pastelaria bom
doces. Luanda: Instituto Superior Para as Tecnologias de Infromação e
Comunicação(ISUTIC), 2018.

23. PIPELINERSALES. 2009. Pipelinersales. Pipelinersales. [Online]

Pipelinersales, 2009. <https://www.pipelinersales.com/>.
53
24. OXFORD UNIVERSITY PRESS. 2015. Oxford Portuguese Mini Dictionary.
London : Oxford, 2007. 978-0-19-861456-2.

25. PRESSMAN, Roger S. Ph.D. 2010. Ingeniería del software, Un Enfoque

Práctico, Séptima Edicíon. C.P. 01376, México, D. F. : McGRAW-HILL
INTERAMERICANA EDITORES, S.A. DE C.V., 2010. ISBN: 978-607-15-0314-
5.

26. PRODABEL. 2019. Prodabel. Processo de Software da PBH. [Online]

PRODABEL - Empresa de Informática e Informação do Município de Belo
Horizonte S/A, 2019. [Citado em: 13 de Junho de 2019.] Disponível em
<https://psp.pbh.gov.br/sites/psp.pbh.gov.br/files/psp_v2.1_nivel_F/index.htm
>.

27. RIBEIRO, NEVES, Débora, Flávia. 2014. Dicionário Online de Português. 7

Graus. [Online] 7 Graus, 2014. [Citado em: 03 de Junho de 2019.] Disponível
em <https://www.dicio.com.br/butiques/>.

28. SANTOS, Luís Renato Dos. 2014. Técnicas de Testes de software. s.l. :
FAES-UFPR, 2011.

29. SILVA, Pedro Oziel Escobar da. 2017. Micreiros. Micreiros. [Online] Micreiros,
2017. [Citado em: 6 de Junho de 2019.] <http://micreiros.com/diagrama-de-
implantacao/>.

30. SOMMERVILLE, Ian. 2011. INGENIERÍA DE SOFTWARE 9. Mexico : Pearson

Education, 2011. 978-607-32-0603-7.

31. DeviTecnologia. 2017. blog. Devi tecnologia. [Online] Devi tecnologia, 2017.
[Citado em: 15 de 05 de 2019.] Disponível em
<http://blog.devitecnologia.com.br/a-importancia-do-sistema-de-vendas-para-
a-eficiencia-do-seu-negocio/>.

54
 ANEXOS
Entrevista com os trabalhadores da boutique BCH-Lda

Nome:

Função:

1. Como é tratada a informação da boutique?

R: toda a informação é tratada de forma manual.

2. Como é feito o processo de vendas?

R: O processo de vendas é feito atravéz de bloco de facturas.

3. Quais são as principais dificuldades que têm enfretado?

R: Dificuldade no controlo dos produtos, controlo dos clientes, relatórios, demora no

atendimento, e perca de clientes.

4. O que têm feito para soluciona-las

R: pegando todos os papéis e controlar todas as entradas e saídas, o que tem gerado
muita perca dos dados.

5. Sabe o que é um sistema de gestão de vendas?

R: Já ouvi Falar. É um sistema que faz a gestão das vendas.

6. Já utilizou um sistema de gestão de venda?

R: Nunca Utilizei

7. Sabe quais as vantagens de se utilizar um sistema de gestão

R: Não Sei

8. Quais são as principais dificuldades que gostaria que fossem

ultrapassadas?

R: controlo das actividades diaria tais como, controlo de produtos, controlo das
vendas, controlo de clientes, relatórios e consultas de produtos.

55