Concepção de Um Sistema para Gestão Dos Registos de Ocupação de Bancas No Mercado Xipamanine

INSTITUTO SUPERIOR DE TRANSPORTES E COMUNICAÇÕES
CONCEPÇÃO DE UM SISTEMA PARA GESTÃO DOS REGISTOS DE

OCUPAÇÃO DE BANCAS NO MERCADO XIPAMANINE
Ângelo Mussa Massache Júnior
Projecto Final do Curso
Licenciatura em Engenharia Informática e Telecomunicações
Supervisor
Eng.º. Helton Luís General
Departamento de Tecnologias de Informação
Abril de 2022
INSTITUTO SUPERIOR DE TRANSPORTES E COMUNICAÇÕES
CONCEPÇÃO DE UM SISTEMA PARA GESTÃO DOS REGISTOS DE

OCUPAÇÃO DE BANCAS NO MERCADO XIPAMANINE
Projecto Final do Curso

Licenciatura em Engenharia Informática e Telecomunicações
Supervisor
Eng.º. Helton Luís General
Departamento de Tecnologias de Informação
Abril de 2022
CONCEPÇÃO DE UM SISTEMA PARA GESTÃO DOS REGISTOS DE BANCAS NO
MERCADO XIPAMANINE
ÍNDICE
Índice de figuras..............................................................................................................................V
Índice de Tabelas...........................................................................................................................VI
lista das abreviaturas utilizadas....................................................................................................VII
Capítulo 1 – INTRODUÇÃO..........................................................................................................1
1.1. Introdução.........................................................................................................................1
1.2. Problemática......................................................................................................................1
1.3. Problema de estudo...........................................................................................................2
1.4. Objecto de estudo..............................................................................................................2
1.5. Objectivos.........................................................................................................................2
1.5.1. Objectivo geral...........................................................................................................2
1.5.2. Objectivos específicos...............................................................................................2
1.6. Perguntas de investigação.................................................................................................3
1.7. A importância ou razões que motivam o trabalho............................................................3
1.8. Estrutura do trabalho.........................................................................................................4
Capítulo 2 – Revisão da Literatura..................................................................................................6
2.1. Antecedentes do objecto e do problema de investigação..................................................6

2.1.1. Aplicações semelhantes implementadas em outros países........................................6
2.1.2. Comparação dos sistemas apresentados....................................................................8
2.2. Conceitos básicos da investigação....................................................................................9
2.2.1. Banca.........................................................................................................................9
2.2.2. Registo.......................................................................................................................9
2.2.3. Comércio....................................................................................................................9
2.2.4. Mercado...................................................................................................................10
2.2.5. Vendedor..................................................................................................................10
2.3. Teorias principais da investigação..................................................................................10
2.3.1. Sistemas...................................................................................................................10
2.3.2. Sistemas de informação...........................................................................................11
2.3.3. Tipos de sistemas de informação.............................................................................12
Concepção de um sistema de gestão para os registos de bancas do mercado Xipamanine
2.3.4. Dados.......................................................................................................................13
2.3.5. Informação...............................................................................................................13
2.3.6. Software...................................................................................................................13
2.3.7. Modelos de processo de software............................................................................14
2.3.8. Linguagem de modelagem unificada (UML)..........................................................18
2.3.9. Notação BPM...........................................................................................................23
2.3.10. Padrões de Arquitectura para sistemas distribuídos.............................................23
2.3.11. Base de dados.......................................................................................................27
2.3.12. Vantagens da utilização de bases de dados..........................................................27
2.3.13. Base de dados relacional (SQL)...........................................................................27
2.3.14. Base de dados não relacional (NoSQL)...............................................................28
2.3.15. Diferença entre base de dados relacionais e não relacionais................................29
2.3.16. Sistemas de gestão de base de dados...................................................................30
2.3.17. Protocolos de rede................................................................................................30
2.3.18. Métodos HTTP.....................................................................................................31
2.3.19. Arquitectura orientada a serviços.........................................................................32
2.3.20. Serviços................................................................................................................33
2.3.21. Arquitectura SOAP..............................................................................................33
2.3.22. Arquitectura REST...............................................................................................34
2.3.23. Interface de programação e aplicação (API)........................................................35
2.3.24. Internet e World Wide Web..................................................................................36
2.3.25. Web browser........................................................................................................36
2.3.26. Linguagem HTML...............................................................................................37
2.3.27. CSS.......................................................................................................................37
2.3.28. Linguagens de programação................................................................................37
2.3.29. Frameworks usados em desenvolvimento web....................................................39
2.3.30. Template Engines.................................................................................................40
2.3.31. Vantagens da utilização de template engine........................................................41
Capítulo 3 – Contextualização da investigação.............................................................................43
3.1. Caracterização sócio – histórica, geográfica, política do objecto de investigação.............43

3.1.1. Cidade de Maputo....................................................................................................43
3.1.2. Conselho Municipal da Cidade de Maputo.............................................................44
II
3.1.3. Mercado Xipamanine...............................................................................................44

3.2. Estado actual do objecto da investigação........................................................................46
3.2.1. Processo actual de registo de bancas no mercado Xipamanine...............................46
3.2.2. Transferência de autorização de venda numa banca................................................47
3.2.3. Regras do mercado..................................................................................................48
3.2.4. Pagamento de taxas..................................................................................................48
3.3. Limitações do processo actual de registo de bancas.......................................................49
Capítulo 4 – Metodologia de resolução do problema....................................................................50
4.1. Tipo de pesquisa..............................................................................................................50

4.1.1. Pesquisa quanto à natureza......................................................................................50
4.1.2. Pesquisa quanto à abordagem..................................................................................51
4.1.3. Pesquisa quanto aos objectivos................................................................................51
4.1.4. Pesquisa quanto aos procedimentos.........................................................................52
4.2. Instrumentos e procedimentos de recolha de dados........................................................55
4.3. Variáveis de investigação................................................................................................55
4.4. Metodologias de desenvolvimento de software..............................................................56
Capítulo 5 – Apresentação e análise de resultados........................................................................57
5.1. Requisitos do sistema......................................................................................................57

5.1.1. Requisitos funcionais...............................................................................................57
5.1.2. Requisitos não funcionais........................................................................................58
5.2. Principais diagramas.......................................................................................................59
5.2.1. Diagrama de casos de uso............................................................................................59
5.2.2. Diagrama de estados das bancas..................................................................................60
5.2.3. Diagrama de classes.....................................................................................................61
5.3. Ferramentas utilizadas.....................................................................................................61
5.4. Arquitectura e funcionamento do sistema.......................................................................62
5.5. Apresentação das telas....................................................................................................63
5.1. Apresentação de orçamento............................................................................................63
5.1.1. Custo de desenvolvimento do protótipo..................................................................63
Capítulo 6 – Conclusões e Recomendações..................................................................................65
6.1. Conclusões......................................................................................................................65
III
6.2. Limitações de pesquisa...................................................................................................65

6.3. Recomendações...............................................................................................................66
Referências bibliográficas.............................................................................................................67
IV
AGRADECIMENTOS
Lorem ipsum……
V
DEDICATÓRIA
Lorem ipsum…..
VI
DECLARAÇÃO DE HONRA
Eu, Ângelo Mussa Massache Júnior declaro por minha honra que o presente Projecto Final do
Curso é exclusivamente de minha autoria, não constituindo cópia de nenhum trabalho realizado
anteriormente e as fontes usadas para a realização do trabalho encontram-se devidamente citadas
ao longo do trabalho e referidas na bibliografia final.
_________________________________________
VII
ÍNDICE DE FIGURAS
Figura 2.1 Logotipo do Manage My Market...................................................................................7
Figura 2.2 Logotipo do Tô Legal.....................................................................................................7
Figura 2.3 Elementos básicos de um sistema................................................................................11
Figura 2.4 Papéis fundamentais de um negócio............................................................................13
Figura 2.5 Modelo cascata.............................................................................................................14
Figura 2.6 Modelo Incremental.....................................................................................................15
Figura 2.7 Fases da prototipação...................................................................................................16
Figura 2.8 Modelo em espiral........................................................................................................16
Figura 2.9 O Processo da XP.........................................................................................................18
Figura 2.10 Processo Scrum..........................................................................................................19
Figura 2.11 Casos de uso...............................................................................................................30
Figura 2.12 Representação de classes............................................................................................32
Figura 2.13 Diagrama de actividades............................................................................................33
Figura 2.14 Diagrama de estados...................................................................................................34
Figura 2.15 Exemplo de diagrama de sequência...........................................................................36
Figura 3.1 Cidade de Maputo........................................................................................................57
Figura 3.2 Conselho Municipal da Cidade de Maputo..................................................................58
Figura 3.4 Vista aérea do mercado Xipamanine............................................................................60
Figura 3.5 Processo actual de atribuição de bancas no mercado Xipamanine..............................61
Figura 3.6 Recibo de pagamento de taxa diária.............................................................................63
Figura 5.1 Diagrama de caso de uso do sistema proposto.............................................................73
Figura 5.2 Diagrama de estados das bancas..................................................................................74
Figura 5.3 Diagrama de classes.....................................................................................................75
Figura 5.4 Arquitectura do projecto...............................................................................................77
VIII
ÍNDICE DE TABELAS
Tabela 2.1 Comparação entre Manage My Market e Tô Legal.......................................................8
Tabela 2.2 Comparação entre as metodologias clássicas e metodologias ágeis............................19
Tabela 2.3 Valores de estimativa de esforço (Básico e intermediário).........................................21
Tabela 2.4 Valores de estimativa de tempo...................................................................................22
Tabela 2.5 Tabela de direcionadores de custo...............................................................................22
Tabela 2.6 Multiplicadores de esforço de desenvolvimento de software (COCOMO
Intermediário)................................................................................................................................23
Tabela 2.7 Classificação das funções............................................................................................26
Tabela 2.8 Distribuição de Pesos...................................................................................................27
Tabela 2.9. Descrição da utilização do diagrama de sequência durante as fases de um projecto. 35
Tabela 2.10 Comparação SQL e NoSQL......................................................................................42
Tabela 2.11 Métodos HTTP..........................................................................................................45
Tabela 2.12 Comparação entre JS e Java.......................................................................................51
Tabela 2.13 Template engines utilizados em determinadas linguagens de programação.............55
Tabela 4.1. Classificação da pesquisa sob o ponto de vista dos procedimentos...........................67
Tabela 5.1 Requisitos funcionais...................................................................................................71
Tabela 5.2 Requisitos não funcionais............................................................................................72
Tabela 5.3 Ferramentas utilizadas.................................................................................................76
Tabela 5.5. Custo de equipamento do projecto..............................................................................78
IX
LISTA DAS ABREVIATURAS UTILIZADAS
Abreviatura Significado
ACAP Analist Capability
ACID Atomicidade Consistência Isolamento Durabilidade
AEXP Application Experience
AIE Arquivos de Interface Externa
ALI Arquivo Lógico Interno
API Aplication Programming Interface
BI Bilhete de Identidade
BD Base de Dados
BPM Business Process Model
CE Consulta Externa
CMCM Conselho Municipal da Cidade de Maputo
CGI Common Gateway Interface
COCOMO Constructive Cost Model
COVID-19 Coronavirus Disease of 2019
CPLX Product Complexity
CSS Cascading Style Sheets
DATA Data Base Size
DNS Domain Name System
EAF Effort Adjustment Factor
EE Entradas Externas
EUA Estados Unidos da América
FTP File Transfer Protocol
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
IoC Inversion of Control
JS Javascript
X
JSON Javascript Object Notation

JVM Java Virtual Machine
LEXP Programming Language Experience
LOC Lines Of Code
MODP Modern Programming Practices
MVC Model View Controller
NoSQL Not only Structured Query Language
OMG Object Management Group
ORM Object-Relational Mapping
PIB Produto Interno Bruto
PHP Php Hypertext Preprocessor
POS Post Of Sale
RIA Rich Internet Application
RELY Required software Reliability
REST Representational State Transfer
SAD Sistema de Apoio a Decisão
SCED Required Development Schedule
SE Saída Externa
SGBD Sistema de Gestão de Base de Dados
SI Sistema de Informação
SIE Sistema de Informação Executivo
SIG Sistema de Informação De Gestão
SLOC Source Lines of Code
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
SPT Sistemas de Processamento de Transacções
SQL Structured Query Language
SSH Secure Socket Shell
SSL Secure Sockets Layer
TCP Transmission Control Protocol
TIME Execution Time Constraint
XI
TOOL Use of Software Tools

TURN Computer Turnaround Time
UDDI Universal Description, Discovery and Integration
UDP User Datagram Protocol
UML Unified Modeling Language
URI Uniform Resource Identifier
VEXP Virtual Machine Experience
VIRT Virtual Machine Volatility
XML External Markup Language
XP Extreme Programming
W3C World Wide Web Consortium
WAIS Wechsler Adult Intelligence Scale
WSDL Web Services Description Language
WWW World Wide Web
XII
Concepção de um sistema de gestão para as bancas do mercado Xipamanine
CAPÍTULO 1 – INTRODUÇÃO
1.1. Introdução
Moçambique, considerado um país em vias de desenvolvimento, possui uma elevada taxa de
desemprego, factor que faz com que a população procure meios alternativos de subsistência,
dentre os quais a venda informal de bens de consumo diversos. Este tipo de actividade é
caracterizado por constantes conflitos entre as autoridades municipais e os vendedores, pois estes
alegam não encontrar bancas disponíveis nos mercados ou preferem não vender dentro deles
argumentando haver um fraco movimento de clientes.
No cenário em que o país se encontrava nos períodos de Abril a Julho do ano de 2020,
caracterizado por uma acção de grande envergadura das autoridades municipais da cidade de
Maputo com vista a retirar os vendedores informais das ruas e alocá-los aos diversos mercados
da cidade por questões estéticas e como forma de se evitar aglomerações, o que se tentava evitar
dado o contexto da pandemia da COVID-19 em que o país se deparava, foram adoptadas
medidas de reestruturação e requalificação de alguns mercados na cidade de Maputo, e neste
processo foram reveladas fragilidades na gestão e organização dos mesmos.
Fragilidades essas que causam um impacto negativo nas famílias cuja fonte de renda provém do
mercado pois, por causa das mudanças que são tomadas a cabo naquele local, estas correm o
risco de subitamente perder o seu sustento.
1.2. Problemática
Num mercado que possui cerca de 5 mil vendedores, o método de armazenamento de dados
utilizado pela sua administração é baseado na manutenção dos registos de vendedores em pastas
de arquivos que por sua vez são colocadas em um cacifo na sala da administração onde, para que
se tenha uma dada informação relativa a estes registos é necessário que se faça uma busca
manual nas várias pastas existentes até que se encontre a informação desejada.
Nota-se que o método utilizado para registar os vendedores e as suas bancas é precário e
trabalhoso, deixando assim estes dados susceptíveis a perda, extravio ou dano por diversos
motivos. A falta de um meio fiável de gestão e armazenamento das informações da ocupação das
1
bancas deixa incertezas na apuração dos reais ocupantes das mesmas, propicia um ambiente de
insegurança para os vendedores quanto ao direito de exercer as suas actividades no mercado,
para além de dificultar o controle da cobrança de taxas aos vendedores, situação esta que se faz
reflectir negativamente nas contas da administração daquele local, podendo haver uma
discrepância entre o número de vendedores a ocupar as bancas e o valor a ser cobrado num
determinado período de cobrança.
Assim sendo, com a utilização de um sistema de gestão de registos de ocupação das bancas no
mercado Xipamanine, tornar-se-á fiável e íntegro o processo de atribuição das bancas aos
vendedores, para além das cobranças das taxas de ocupação das mesmas, melhorando assim o
controle sobre a ocupação das bancas e a organização do próprio mercado.
1.3. Problema de estudo

De que maneira se pode melhorar a gestão dos registos de ocupação das bancas do mercado
Xipamanine?
1.4. Objecto de estudo

O objecto de estudo deste projecto é a gestão dos registos de ocupação de bancas do mercado
Xipamanine.
1.5. Objectivos
1.5.1. Objectivo geral
Desenvolver um protótipo de sistema para a gestão para os registos de ocupação das bancas do
mercado Xipamanine.
1.5.2. Objectivos específicos

 Descrever a situação actual da gestão de atribuição e monitoria dos registos de ocupação
das bancas do mercado;
2
 Construir o modelo conceptual do sistema em causa;

 Conceber um protótipo do sistema;
 Testar o protótipo do sistema;
1.6. Perguntas de investigação

 Como é feita a gestão de atribuição e monitoria dos registos de ocupação das bancas no
mercado Xipamanine?
 Como modelar o protótipo do sistema?
 Como conceber um protótipo do sistema?
 Como testar o protótipo do sistema?
1.7. A importância ou razões que motivam o trabalho

Independentemente do sector ou área, quando é firmado um acordo, as partes envolvidas passam
a ter direitos, deveres e responsabilidades uma com a outra, e sob as mesmas directrizes funciona
o acordo entre os vendedores e as autoridades municipais, representadas neste caso pela
administração do mercado, que deve garantir a manutenção segura dos registos dos vendedores
de modo a evitar constrangimentos e conflitos relacionados aos assuntos à que estes registos se
destinam. Muitos dos vendedores do mercado têm como fonte de subsistência as actividades que
exercem naquele local, o que faz com que estes registos se tornem uma garantia do seu sustento,
assim sendo, a perda ou extravio destes registos por parte da administração do mercado implica
que o vendedor deixa de ser reconhecido pela mesma, fazendo com que perca o direito de
exercer a sua actividade comercial naquele local e deste modo possa vir a perder a sua fonte de
rendimento.
De facto, a confirmação de que uma banca pertence a um determinado vendedor pode ser feita
através do reconhecimento do mesmo por testemunhas (vendedores que se localizam próximo à
referida banca), mas não há garantia de uma boa gestão em um local que alberga cerca de cinco
mil pessoas tendo como base esta modalidade de identificação. O que permite a criação de
esquemas e corrupção entre oportunistas e fiscais.
3
O desenvolvimento de um sistema de gestão para o registo de bancas visa armazenar os dados

dos vendedores deste mercado de forma fiável e íntegra, controlar melhor o processo de
atribuição das bancas de modo a mitigar os conflitos existentes entre os vendedores. Este sistema
irá prover maior controle das receitas por parte da administração do mercado e fornecer dados
exactos às autoridades municipais para efeitos estatísticos e organizacionais, por outro lado, visa
garantir a fonte de rendimento das várias famílias que tiram o seu sustento das vendas no
mercado, permitindo que estas se desenvolvam e contribuam activamente na sociedade através
do pagamento de impostos, para além de evitar que estes percam os seus lugares e passem a
vender os seus produtos em locais impróprios ou mesmo comecem a delinquir-se. No âmbito
académico, este projecto visa demonstrar aos estudantes que é possível implementar os
conhecimentos adquiridos ao longo processo curricular em situações do mundo real com impacto
significativo na vida das pessoas afectadas pelo projecto.
1.8. Estrutura do trabalho

O presente trabalho é composto por seis capítulos, organizados na seguinte sequência:
 Capítulo 1 – Introdução
Este capítulo visa descrever o projecto de um modo geral, expondo a problemática que se
pretende resolver, os objectivos a alcançar, as perguntas de investigação e as directrizes gerais
em que se baseia o projecto.
 Capítulo 2 – Revisão da literatura
É neste capítulo que são apresentados os fundamentos teóricos relevantes para o conhecimento
dos assuntos a serem abordados. Nele estarão contidas as principais teorias e conceitos
envolvidos na investigação para maior compreensão do projecto.
 Capítulo 3 – Contextualização da Investigação
Neste capítulo está contido o estado actual do objecto da investigação. É onde será feita a
contextualização do objecto de estudo no espaço e serão evidenciadas as limitações que se
pretendem ultrapassar.
4
 Capítulo 4 – Metodologia de Resolução do Problema
Este capítulo tem como finalidade mostrar as metodologias e técnicas utilizadas na investigação
e os métodos aplicados para a resolução do problema.
 Capítulo 5 – Apresentação e Análise dos Resultados
É neste capítulo onde são apresentados os resultados obtidos na investigação, a apresentação da

solução proposta e análise dos resultados de modo a compará-los com a revisão bibliográfica.
 Capítulo 6 – Conclusões e Recomendações
Este capítulo é reservado para as conclusões obtidas na investigação e recomendações para

melhorias da solução proposta consoante os resultados obtidos durante a pesquisa.
5
CAPÍTULO 2 – REVISÃO DA LITERATURA
Neste capítulo são apresentados os principais fundamentos teóricos como forma de facilitar a
percepção dos conteúdos a serem abordados neste trabalho. Para isso, foi feita a revisão da
literatura que irá ajudar a sustentar os princípios que culminaram com o desenvolvimento deste
projecto.
2.1. Antecedentes do objecto e do problema de investigação

2.1.1. Aplicações semelhantes implementadas em outros países
a) Manage My Market
É um sistema de gestão americano que oferece uma solução online de modo a eliminar a
dependência aos registos físicos relacionados aos mercados.
Foi concebido no ano 2003 em Portland, Oregon (EUA) e visa facilitar o acesso às informações
relacionadas à venda nos mercados daquela cidade, proporcionando um utilitário para registar
dados de fornecedores, atribuir barracas e correio electrónico em massa.
Esta aplicação possui as seguintes funcionalidades:
 Registo de fornecedores online;
 Exibição de mapas interactivos do mercado;
 Serviço de e-mail (para fornecedores ou um grupo específico);
 Administração de licenças aos vendedores; e
 Contabilidade.
6
Figura 2.1 Logotipo do Manage My Market
Fonte: (Manage My Market 2020)
b) Tô Legal
O Tô Legal é um sistema de gestão online para a o cadastro e autorização temporária de até 90

dias para vendedores ambulantes na cidade de São Paulo, tem como objectivo principal
incentivar a legalização e transparência nas actividades comerciais em locais de grande
movimento.
Esta plataforma, concebida pela Prefeitura (equivalente ao Conselho Municipal) de São Paulo,
permite o licenciamento por parte dos vendedores para exercer as suas actividades comerciais no
espaço público e autoriza a venda de produtos num determinado local previamente conhecido até
que se expire a sua licença.
Figura 2.2 Logotipo do Tô Legal
Fonte: (Prefeitura de São Paulo 2020)
7
2.1.2. Comparação dos sistemas apresentados
Tabela 2.1 Comparação entre Manage My Market e Tô Legal
Manage My Market Tô Legal

Propriedade de uma entidade privada Propriedade de uma entidade pública
Licença paga Grátis (para utilização pública)
Utilização permitida nos EUA, Canadá e Utilização permitida apenas para o Brasil
Austrália
Olhando sob uma perspectiva de utilização, o Manage My Market é o sistema mais próximo
daquele que se pretende projectar pois possui muitas funcionalidades similares, porém a sua
utilização não é permitida em Moçambique e mesmo que fosse, não seria muito viável do ponto
de vista económico pois a sua licença custa 15 dólares por vendedor, por ano. Sendo que o
cenário em estudo é constituído por 5000 bancas, teríamos cerca de 75 mil dólares anuais de
custo apenas para licenças de utilização do software.
Por outro lado, o Tô Legal mostra-se mais barato que o sistema referido no parágrafo anterior e
apresenta algumas funcionalidades que seriam úteis por implementar, porém há certos aspectos
que concorrem para fazer com que este sistema não seja o mais adequado ao contexto em que o
presente projecto se enquadra como:
 Este sistema é concebido para atribuir licenças à vendedores nos passeios e praças da
cidade, sendo que o CMCM não autoriza a venda de bens de consumo nos passeios das
ruas e estradas;
 As licenças atribuídas por este sistema são temporárias, de até 90 dias, enquanto que
para o caso de estudo pretende-se obter licenças permanentes;
 A utilização deste sistema só é possível no território brasileiro, mais especificamente na

cidade de São Paulo.
Por estes motivos vê-se pertinente a criação de um novo projecto que atenda as necessidades
concernentes à manutenção dos registos de bancas do mercado Xipamanine.
8
2.2. Conceitos básicos da investigação

2.2.1. Banca
Segundo a Cambridge University Press (2021) uma banca consiste em uma mesa ou uma
pequena loja com uma frente aberta da qual as mercadorias são vendidas em local público.
2.2.2. Registo
A Cambridge University Press (2021) define registo como uma informação que constitui
evidência sobre o passado, consistindo geralmente num relato feito por escrito ou alguma outra
forma permanente.
2.2.3. Comércio
Segundo (Sousa 2019) o comércio pode ser definido como uma actividade do campo económico
que consiste na troca de bens ou serviços entre duas ou mais pessoas, realizado com o objectivo
final de obter lucro. O comércio pode ser categorizado em dois tipos:
 Comércio formal: é aquele legalmente estabelecido, realizado sob licenciamento e

autorização das autoridades estatais, caracterizado pelo pagamento de impostos ou taxas.
É neste tipo de comércio em que podemos encontrar diferentes tipos de estabelecimentos
comerciais como lojas, bombas de combustível, restaurantes, farmácias, barracas, entre
outros (Portal São Francisco 2016).
 Comércio informal: para (Meneguim e Bugarin 2007) é o comércio praticado sem o

atendimento às regras comerciais regulares, ou seja, não há nenhum registo de
actividades realizadas, não são pagas taxas e impostos, não são segurados pela
previdência social e os seus praticantes não são reconhecidos por não contar com uma
legislação que garanta o cumprimento de seus direitos mais fundamentais. Este tipo de
comércio é geralmente protagonizado por vendedores ambulantes e muitas vezes
realizado em locais impróprios para tal actividade.
9
2.2.4. Mercado
O mercado é o ambiente social físico ou virtual propício às condições para a troca de bens e
serviços. Também se pode entender como sendo a instituição ou organização mediante a qual os
vendedores e os compradores estabelecem uma relação comercial com o fim de realizar
transacções, acordos ou trocas comercias. O mercado aparece a partir do momento em que se
unem grupos de vendedores e de compradores, o que permite que se articule um mecanismo de
oferta e procura (Sousa 2011).
Sousa (2011) afirma que em qualquer mercado o preço é o mecanismo regulador. Ele também
funciona como uma espécie de indicador para a economia, ou seja, se os consumidores tendem a
procurar por um determinado produto ou serviço, então o preço desse bem tende a aumentar,
sinalizando que ele possui demanda e assim, a sua produção deve ser aumentada. Mas também
pode acontecer o contrário e o determinado bem ou serviço passar a ser produzido em menos
escala.
2.2.5. Vendedor
Para (Sousa 2016) “vendedor” é utilizado para qualificar àquele que vende. Um vendedor possui
a função de comercializar produtos e serviços. Para que haja sucesso nas suas funções, este deve
conhecer os detalhes do produto que vende, como também o poder de persuasão para convencer
potenciais compradores. Os vendedores podem ser associados à uma firma – estes são
funcionários da firma e têm a função de vender os produtos ou serviços prestados pela mesma,
possuem salários fixos e podem ganhar comissões sob as suas vendas, mas também existem
outro tipo de vendedores, estes que são independentes e podem vender uma variedade de
produtos à sua escolha e sob seus termos em bancas – mesa / local geralmente coberto destinado
a venda de produtos. Estes não são associados à nenhuma firma e não possuem salários fixos.
Geralmente encontram-se em mercados, bazares ou mesmo na rua.
2.3. Teorias principais da investigação

2.3.1. Sistemas
Para que se compreenda o conceito de sistemas de informação, é importante entender primeiro o
conceito de sistemas, uma vez que este tem a sua essência contida na definição do SI.
10
Wakulicz (2016) define sistemas como sendo um grupo de componentes relacionados e que
visam uma meta comum a partir do recebimento de informações produzindo resultados em um
processo organizado de transformação. Este é composto basicamente por três funções básicas, a
saber:
 Inputs: Envolve a captação de elementos, dados e informações que serão processados

pelo sistema;
 Processamento: Envolve os processos de transformação dos elementos colectados em

um produto;
 Outputs: Envolve a transferência, dos elementos produzidos durante o processamento,

para uma informação útil e formatada de acordo com as necessidades dos utilizadores do
sistema (relatórios, gráficos).
Figura 2.3 Elementos básicos de um sistema
Fonte: (Wakulicz 2016)
2.3.2. Sistemas de informação

Segundo Laudon e Laudon (2011) um SI pode ser definido como um conjunto de componentes
inter-relacionados que colectam (ou recuperam), processam, armazenam e distribuem
informações destinadas a apoiar a tomada de decisões, a coordenação e o controle de uma
organização, para além de auxiliar os gestores e trabalhadores na análise de problemas,
visualização de assuntos complexos e criação de novos produtos.
“Um sistema de informação é um sistema especializado no processamento e na comunicação de

dados (máquinas) ou de informações (organismos vivos). É constituído por um conjunto de
módulos (objectos) de comunicação, de controle, de memórias e de processadores, interligados
entre si por meio de uma rede com protocolo comum. As relações logicas entre esses módulos
são definidas pelos programas executados pelo sistema de informação.” (Mattos 2005).
11
O conceito de sistemas de informação não possue uma definição única, porém ao se analisar as
diversas fontes pode-se constatar que diversas definições versam sobre pontos comuns como:
processamento de informação, interligação e colaboração de componentes com vista ao alcance
de um objectivo comum.
Mattos (2005) ainda afirma que as pessoas também são parte integrante desse sistema, embora
por vezes se costume esquecer esse importante detalhe. De nada adianta investir grandes
montantes em equipamento, se as pessoas não estiverem preparadas para aceitá-las e usá-los
adequadamente. Por mais high-tech que sejam as máquinas, o sistema, como um todo, não
funcionará a contento, como os consequentes prejuízos para a empresa, que terá um sistema de
informação deficiente.
2.3.3. Tipos de sistemas de informação

Os diferentes níveis hierárquicos de uma organização requerem diferentes tipos de informação e,
a forma como esta informação deve ser manipulada influencia na maneira como os SI trabalham
e são utilizados. Por isso existe a necessidade de haver sistemas de informação específicos que
irão atender as necessidades de cada nível de uma determinada organização.
O’Brien e Marakas (2010) dividem os SI em quatro tipos principais:
 Sistemas de processamento de transacções (SPT): Contemplam o processamento das

operações rotineiras das da organização, processam dados resultantes das transacções de
comerciais, actualização de base de dados operacionais e produzem documentos de
negócios;
 Sistemas de informação de gestão (SIG): Fornecem informações sob a forma de
relatórios e apresentam-nas de forma pré-definida para suporte na tomada de decisão de
negócios;
 Sistemas de apoio a decisão (SAD): Fornecem apoio interactivo ad hoc para os
processos de tomada de decisão dos gestores e outros profissionais de negócio;
 Sistemas de informação executivo (SIE): Fornecem informações críticas dos SIG, SAD
e outras fontes adaptadas às necessidades de informação dos executivos.
12
Figura 2.4 Papéis fundamentais de um negócio
Fonte: (O’Brien e Marakas 2010)
2.3.4. Dados
“Dado é qualquer elemento identificado em sua forma bruta que, por si só, não conduz a uma
compreensão de determinado facto ou situação” (Date 2005).
2.3.5. Informação
Segundo Date (2005), a informação é o dado trabalhado que quando agrupado de maneira lógica
permite aos utilizadores desta informação tomar decisões.
2.3.6. Software
Pressman (2011) traz três abordagens ao definir o software: (1) software consiste em instruções
que, quando executadas, fornecem características, funções e desempenho desejados; (2)
estruturas de dados que possibilitam aos programas manipular informações adequadamente; (3) e
informação descritiva, tanto na forma impressa como na virtual, descrevendo a operação e o uso
dos programas.
2.3.7. Modelos de processo de software

a) Modelos clássicos
Quando se utiliza a abordagem clássica busca-se ao máximo a estrutura e a ordem, segundo

Pressman (2011) este modelo chama-se prescritivo porque prescrevem um conjunto de
13
elementos de processo – actividades metodológicas, acções de engenharia de software, tarefas,

produtos de trabalho, garantia de qualidade e mecanismos de controle de mudanças para cada
projecto.
O modelo cascata
Utiliza-se em casos em que os requisitos de um problema são bem compreendidos e quando os

requisitos estão bem definidos e minimamente estáveis. Pressman (2011) afirma que este modelo
sugere uma abordagem sequencial e sistemática para o desenvolvimento de software, começando
pelo levantamento de necessidades, avançando pelas fases de planeamento, modelagem,
construção, emprego e culminando no suporte contínuo do software concluído.
Figura 2.5 Modelo cascata
Fonte: (Pressman 2011)
Modelo Incremental
Esta abordagem intercala as actividades de especificação, desenvolvimento e validação. O

sistema é desenvolvido como uma série de versões, de maneira que cada versão adiciona
funcionalidade à anterior. Segundo Sommerville (2011) cada incremento incorpora uma
funcionalidade do sistema, sendo que nos incrementos iniciais são incluídas as funcionalidades
mais importantes ou mais urgentes. Esta metodologia permite que se acompanhe o
desenvolvimento do sistema desde a fase inicial e que seja avaliada se o mesmo entrega o que foi
requisitado, tornando fácil acomodar mudanças nos seus requisitos.
14
Figura 2.6 Modelo Incremental
Fonte: (Sommerville 2011)
Prototipação
Sommerville (2011) define um protótipo como a versão inicial de um software, usado para
demonstrar conceitos, experimentar opções de projecto e descobrir mais sobre o problema e suas
possíveis soluções. O desenvolvimento rápido do protótipo é essencial para que os custos sejam
controlados e os envolvidos possam experimentá-lo no início do processo de software e fornecer
um retorno que servirá para aprimorar os requisitos. Pressman (2011) afirma também que na sua
forma ideal, o protótipo actua como um mecanismo de identificação de requisitos do software e
quando houver necessidade de se desenvolver um protótipo operacional, pode-se utilizar partes
de programas já existentes ou aplicar ferramentas que possibilitem gerar rapidamente tais
programas.
15
Figura 2.7 Fases da prototipação
Modelo espiral
O processo de software é representado como uma espiral e não como uma sequência de
actividades com retornos de uma para outra. Sommerville (2011) explica que nesta metodologia,
cada volta da espiral representa uma fase do processo de software, sendo que a volta mais interna
se preocupa com a viabilidade do sistema, o ciclo seguinte, com a definição de requisitos, o
seguinte, com o projecto do sistema, e assim por diante.
Figura 2.8 Modelo em espiral
16
b) Modelos ágeis
Sommerville (2011) explica que a metodologia de desenvolvimento de software ágil permite que
a equipe de desenvolvimento foque-se no software em si ao invés do seu desenho e
documentação. De uma forma geral, este tipo de metodologia baseia-se numa abordagem
incremental para a especificação, desenvolvimento e entrega. Elas adequam-se bem no
desenvolvimento de aplicações em que os requisitos do sistema podem mudar constantemente
durante o processo de desenvolvimento, para além de adoptar a filosofia do manifesto ágil que
valoriza mais:
 Os indivíduos e interacções do que processos e ferramentas;

 Software em funcionamento do que documentação abrangente;
 Colaboração do cliente do que negociação de contracto;
 Respostas a mudanças do que seguir um plano.
Extreme programming
Esta é a abordagem mais utilizada quando se fala de desenvolvimento de software ágil. Ela é
estabelecida por um grupo de 5 valores que são a comunicação, simplicidade, feedback, coragem
e respeito. Sendo que cada um destes valores é usado para direccionar as actividades, acções e
tarefas específicas da XP (Pressman 2011).
Sommerville (2011) explica que o XP envolve certas práticas que reflectem os princípios dos
métodos ágeis tais como:
 Sustentar o desenvolvimento incremental por meio de pequenos releases do sistema cujos

requisitos são baseados em cenários simples;
 Envolver o cliente através do seu engajamento contínuo, permitindo que o seu

representante participe do desenvolvimento do sistema e atribuindo-lhe a
responsabilidade de definir os testes de aceitação do mesmo;
 Focar nas pessoas e não nos processos aplicando a programação aos pares, propriedade
colectiva do código do sistema e um processo de desenvolvimento que não envolva um
número muito elevado de horas de trabalho;
17
 Aceitar as mudanças por meios de releases contínuos para os clientes;
 Manter a simplicidade através da refactoração constante de modo a melhorar a qualidade

do código.
Figura 2.9 O Processo da XP
Scrum
Pressman (2011) explica que os princípios do Scrum seguem também a filosofia do manifesto
ágil e são utilizados para orientar as actividades de desenvolvimento dentro de um processo que
incorpora as seguintes actividades estruturais: requisitos, análise, projecto, evolução e entrega.
O Scrum é um método ágil geral, mas seu foco está na gestão do desenvolvimento interactivo, ao
invés das abordagens técnicas específicas da engenharia de software ágil. Sommerville (2011)
mostra que a característica inovadora do Scrum está na sua fase central, chamada de ciclos de
sprint – unidade de planeamento onde o trabalho a ser realizado é avaliado, os recursos
seleccionados e o software é implementado. Em que no ciclo de uma sprint, a funcionalidade
completa é entrega aos stakeholders.
18
Figura 2.10 Processo Scrum
A ideia por detrás deste método é que toda a equipe deve ter poderes para tomar decisões, e para
isso, é necessário que todos os seus integrantes estejam a par do que acontece no projecto. Isto é
possível graças às reuniões diárias da equipe onde os seus membros compartilham informações e
descrevem o seu progresso desde a última reunião, os problemas que têm surgido e o planeado
para o dia seguinte. Esta prática abre espaço para que se surgirem problemas, a equipe possa
replanear o trabalho de curto prazo para lidar com eles.
Tabela 2.2 Comparação entre as metodologias clássicas e metodologias ágeis
Metodologias Clássicas Metodologias Ágeis

Possui etapas bem definidas onde a entrega é São feitas entregas regularmente ao longo do
feita apenas no final do projecto. desenvolvimento do projecto.
Cada etapa do projecto é planeada com muita O planeamento é feito de forma iterativa e
antecedência. incremental.
Segue um modelo sequencial em que uma Segue um modelo que é constituído por ciclos
etapa apenas é executada assim que a anterior de desenvolvimento conhecidos como Sprints.
for concluída.
Não é muito tolerante a mudanças. É muito tolerante a mudanças
As mudanças podem acarretar custos elevados, As mudanças são feitas quando necessário, o
dependendo do estágio em que estiver o que reduz o custo oriundo das mesmas.
projecto.
19
2.3.8. Modelos empíricos de estimativa de custo de software

Ponto 3.7.1 de Pressman 1995
Segundo Pressman (2011) a estimativa de custo é fundamental no processo de desenvolvimento

de software pois, permite mensurar o esforço, prazo e custo associados ao desenvolvimento. O
modelo de estimativas de software utiliza formulários empiricamente derivados para
prognosticar informações relativas ao planeamento do projecto. Os dados empíricos que
suportam muitos modelos de estimativa são obtidos de uma amostragem limitada de projectos,
por isso, nenhum modelo de estimativa é apropriado para todas as classes de software e todos os
ambientes de desenvolvimento.
a) Modelo COCOMO
Pressman (1995) descreve o Constructive Cost Model como um modelo que apresenta uma
hierarquia de modelos de estimativa de software que pode assumir as seguintes formas:
 COCOMO básico – é um modelo estático de valor simples que computa o esforço e

custo de desenvolvimento de software como uma função do tamanho de programa
expresso em linhas de código estimadas.
 COCOMO intermediário – este modelo computa o esforço de desenvolvimento de
software com uma função do tamanho do programa e de um conjunto de
“condicionadores de custo” que incluem avaliações subjectivas do produto, do
hardware, do pessoal e dos atributos do projecto.
 COCOMO avançado – este modelo incorpora todas as características da versão
intermediária, com uma avaliação do impacto dos direcionadores de custo sobre cada
passo do processo de engenharia de software.
Pressman (1995) demonstra que o COCOMO pode ser aplicado a três classes de projectos de
software, a saber:
 Modo orgânico – Aplicado à projectos de software simples e pequenos nos quais

trabalham pequenas equipes com boa experiência em desenvolvimento de software;
 Modo semidestacado – aplicado em projectos de software no qual equipes com níveis de
experiências mistos devem atingir uma combinação de requisitos rígidos e não tão
rígidos.
20
 Modo embutido – utilizado em projectos de software que devem ser desenvolvidos dentro
de um conjunto rígido de restrições operacionais, tanto de hardware como de software.
As equações COCOMO para a estimativa do esforço, tempo e número de pessoas para projecto
de software são respectivamente:
bi
E=ai ( KLOC) EAF (1)
di
D=c i E (2)
E
N= (3)
D
Onde:
 E é o esforço aplicado, em pessoas-mês;

 KLOC é o tamanho do software expresso em milhares de linhas de código;
 EAF é um multiplicador de esforço denominado Effort adjustment Factor (factor de
ajuste do esforço) que depende de quinze atributos direccionadores de curso. Sendo que
no COCOMO básico EAF = 1 e no COCOMO intermediário devem ser atribuídos
valores específicos para cada atributo.
 D é o tempo de desenvolvimento em meses cronológicos;
 N é o número de pessoas.
Tabela 2.3 Valores de estimativa de esforço (Básico e intermediário)
Modo COCOMO básico COCOMO intermediário

ai bi ai bi
Orgânico 2,4 1,05 3,2 1,05
Semi-destacado 3,0 1,12 3,0 1,12
Embutido 3,6 1,20 2,8 1,20
21
Tabela 2.4 Valores de estimativa de tempo
Modo ci di
Orgânico 2,5 0,38
Semi-destacado 2,5 0,35
Embutido 2,5 0,32
Para além de se ter de tomar em conta factores como a estimativa de esforço e tempo, os
direccionadores de custo são características de desenvolvimento de software que influenciam na
variação do esforço de desenvolvimento final do projecto. Pressman (1995) agrupa os
direccionadores de custo em quatro categorias que serão mostradas na tabela a seguir:
Tabela 2.5 Tabela de direcionadores de custo
Categoria Atributos
RELY – Required software Reliability (Confiabilidade exigida do sistema)
Produto DATA – Data Base Size (Tamanho da Base de dados do sistema)
CPLX – Product Complexity (Complexidade do sistema)

Time – Execution Time Constraint (Restrições de memória)
STOR – Main Storage Constraint (Restrições)

Hardware
VIRT – Virtual Machine Volatility (Volatilidade da máquina virtual)
TURN – Computer Turnaround Time (Tempo de rotatividade do computador)

ACAP – Analist Capability (Capacidade do analista)
Pessoal
AEXP – Application Experience (Experiência em aplicações)
22
PCAP – Programmer Capability (Capacidade do programador)
VEXP – Virtual Machine Experience (Experiência com máquina virtual)
LEXP – Programming Language Experience (Experiência com a linguagem de

programação)
MODP – Modern Programming Practices (Prática com programação moderna)
Projecto TOOL – Use of software Tools (Uso de ferramentas de software)
SCED – Required Development Scheduled (Cronograma de desenvolvimento

exigido)
De acordo com PRESSMAN (1995) cada um dos quinze atributos é classificado de acordo com
uma escala que varia de “muito baixo” à “extremamente elevado”, em importância e valor. O
produto dos quinze direccionadores de custo resulta no factor de ajustamento de esforço (EAF)
da equação de estimativa de esforço de desenvolvimento (Equação 1). A seguinte tabela
apresenta os valores de cada atributo, de acordo com a sua classificação.
Tabela 2.6 Multiplicadores de esforço de desenvolvimento de software (COCOMO Intermediário)
Valor
Atributo Muito Baixo Nominal Elevado Muito Extra
baixo elevado elevado
Produto
RELY 0,75 0,88 1 1,15 1,4 -
DATA - 0,94 1 1,08 1,16 -
CPLX 0,7 0,85 1 1,15 1,3 1,65
Hardware
23
TIME - - 1 1,11 1,3 1,66

STOR - - 1 1,06 1,21 1,56
VIRT - 0,87 1 1,15 1,3 -
TURN - 0,87 1 1,07 1,15 -
Pessoal
ACAP 1,46 1,19 1 0,86 0,71 -
AEXP 1,29 1,13 1 0,91 0,82 -
PCAP 1,42 1,17 1 0,86 0,7 -
VEXP 1,21 1,1 1 0,9 - -
LEXP 1,14 1,07 1 0,95 - -
Projecto
MODP 1,24 1,1 1 0,91 0,82 -
TOOL 1,24 1,1 1 0,91 0,83 -
SCED 1,23 1,08 1 1,04 1,1 -
Fonte: (Boehm)
2.3.9. Estimativas de linhas de código e pontos de função

As estimativas de linhas de código e os pontos por função são dados básicos a partir
dos quais as métricas de produtividade podem ser computorizadas. São utilizadas de
duas maneiras na estimativa de projectos:
 Como variáveis de estimativa;
 Como métricas de linha básica.
Ao estimar o tamanho do projecto, existe a necessidade de se considerar as seguintes métricas:
 Linhas de código (LOC);

 Análise por ponto de função;
 Pontos de características;
 Pontos de caso de uso.
24
1) Pontos de função
Buscam minimizar as dificuldades associadas às linhas de código como medida

de tamanho de software, e de ajudar na geração de um mecanismo para prever
o esforço associado ao desenvolvimento de software. Existem os seguintes
tipos de função nomeadamente:
 Dados: funcionalidade provida ao utilizador através de dados internos ou externos à

aplicação, estes podem ser do tipo ALI e AIE.
 ALI (Arquivo Lógico Interno): Grupo lógico de dados relacionados ou
informação de controlo identificado pelo usuário e mantido dentro da fronteira da
aplicação. A intenção primária de um ALI é manter os dados que sofrem
manutenção através de um ou mais processos elementares da aplicação que está
sendo contada. Podem ser considerados arquivos lógicos internos os cadastros de
clientes, cadastro de produtos, cadastro de funcionários, arquivo de dependentes,
arquivo de controlo de acesso à aplicação, entre outros.
 AIE (Arquivos de Interface Externa): Grupo lógico de dados relacionados ou
informação de controlo referenciado pela aplicação, mas mantido dentro da
fronteira de outra aplicação. A intenção primária de uma AIE é manter os dados
referenciados através de um ou mais processos elementares da aplicação que está
sendo contada. Isso significa que uma AIE contado por uma aplicação deve ser
um ALI em outra aplicação.
 Transacional: funcionalidades providas ao usuário, para o processamento de dados de

uma aplicação, estes podem ser do tipo EE, SE, e CE.
 EE (Entrada Externa): é um processo elementar que processa dados ou
informação de controlo que venha de fora da fronteira da aplicação. A intenção
primária de uma EE é manter um ou mais ALIs e/ou alterar o comportamento do
sistema. Podem ser consideradas entradas externas: inclusão, alteração e exclusão
de registos em cadastros e ainda, transacções vindas de outras aplicações.
 SE (Saída Externa): Uma saída externa é um processo elementar que envia dados
de controlo para fora da fronteira da aplicação. A intenção primária de um SE é
25
apresentar informações ao usuário através de processamento lógico, além da

recuperação de dados e informação de controlo. O processamento lógico deve
conter pelo menos uma fórmula matemática ou cálculo, ou criar dados derivados.
Uma SE também pode manter pelo menos um ALI e/ou alterar o comportamento
de um ou mais ALIs e/ou alterar o comportamento do sistema.
 CE (Consulta Externa): é um processo elementar que envia dados ou informação
de controlo para fora da fronteira da aplicação. A intenção primária de uma CE é
apresentar informações ao usuário através da recuperação de dados e informação
de controlo de um ALI ou AIE. O processamento lógico não contém nenhuma
fórmula matemática ou cálculo, ou cria dados derivados, o comportamento do
sistema não é alterado.
Estes pontos de função podem ser classificados conforme a seguinte tabela:
Tabela 2.7 Classificação das funções
ALI e AIE
Elementos de Dados
Elementos de Registo 1 a 19 20 a 50 51 ou mais
1 Baixa Baixa Média
2a5 Baixa Média Alta
6 ou mais Média Alta Alta
SE e CE
Elementos de Elementos de Dados
Registo 1a5 6 a 19 20 ou mais
0 ou 1 Baixa Baixa Média
EE
Elementos de Registo Elementos de Dados
1a4 5 a 15 16 ou mais
0 ou 1 Baixa Baixa Média
26
Tabela 2.8 Distribuição de Pesos
Tipo de Função Peso de Complexidade

Baixa Média Alta
Arquivo Lógico Interno 7 10 15
Arquivo de Interface 5 7 10
Externa
Entrada Externa 3 4 6
Saída Externa 4 5 7
Consulta Externa 3 4 6
De modo a determinar o tamanho do software deve-se converter os pontos de função não

ajustados em linhas de código consoante a linguagem de programação a ser utilizada. A tabela a
seguir demonstra a relação entre os pontos de função e as linhas de código para algumas
linguagens de programação.
Tabela 2.9 Relação Pontos de Função e Linhas de Código
Linguagem SLOC/UFP
C 320
C++ 55
Java 53
Javascript 71
PHP 67
Fonte: (Taina 2005)
27
2.3.10. Linguagem de modelagem unificada (UML)

Com o crescimento de sistemas desenvolvidos em linguagens orientadas à objectos, surgiram
diversos métodos que visavam criar técnicas de modo a definir e estruturar a implementação
desses sistemas de forma regrada. Segundo Ribeiro (2012) como os métodos de modelagem
eram feitos de acordo com os seus autores, tornou-se necessário o desenvolvimento uma
ferramenta que pudesse unificar as formas de modelagem entre os diversos métodos e é com este
objectivo que Grady Booch, James Rumbaugh e Ivar Jacobson, que são conhecidos como “os
três amigos”, criaram a Unified Modeling Language (UML) – uma linguagem de modelagem que
visa, através de diagramas, definir e mostrar as principais fases dentro dos vários métodos
baseados em objectos, tais como as fases de análise, projecto e implementação.
UML permite que desenvolvedores visualizem os produtos de seus trabalhos em diagramas

padronizados. Junto com uma notação gráfica, ilustrando também a semântica.
Os objectivos da UML são:
 A modelagem de sistemas (não apenas de software) usando os conceitos da orientação a

objectos;
 Estabelecer uma união fazendo com que métodos conceituais sejam também executáveis;
 Criar uma linguagem de modelagem usável tanto pelo homem quanto pela máquina
(Ribeiro 2012).
Segundo Alves (2018) em 2004 a OMG aprovou o lançamento da versão 2.0 da notação UML
composta por diagramas distribuídos em duas categorias: estruturais e comportamentais. Os
diagramas estruturais são utilizados na abstracção e para enfatizar a organização do sistema, são
eles:
 Diagramas de classes;
 Diagramas de objectos;
 Diagramas de componentes;
 Diagramas de implementação;
 Diagramas de pacotes;
 Diagramas de estrutura composta;
 Diagramas de perfil (adicionado na versão 2.2).
28
Enquanto os diagramas comportamentais são empregados na representação da dinâmica do

sistema, estes são:
 Diagramas de casos de uso;

 Diagramas de sequência;
 Diagramas de colaboração;
 Diagramas de estados;
 Diagramas de actividades.
a) Diagrama de caso de uso
Os diagramas de caso de uso têm por finalidade representar unidades de funcionalidades que
descrevem funções completas de um sistema, devendo ser compreensíveis por qualquer pessoa
que visualize o diagrama. Diagramas de caso de uso descrevem uma sequência de processos que
devem demostrar as funções e o comportamento de um sistema, através de interacções com
actores (pessoa ou objecto que interage com o sistema) (Ribeiro 2012).
Permite que se veja um sistema de uma maneira que seja possível observar as situações de
aplicação, mas para tal, é necessário que se siga os seguintes preceitos:
1) Descrever os requisitos funcionais do sistema de forma simples e clara que permita a

compreensão do leitor;
2) Fornecer uma descrição consistente e clara sore as responsabilidades que devem ser
cumpridas pelos diversos actores e subsistemas que compõem o sistema.
Um diagrama de casos de uso é composto pelos seguintes elementos:
1) Cenário – Sequência de eventos que acontecem quando o usuário interage com o sistema;
2) Caso de Uso – Narra a iteração entre o sistema e os actores envolvidos e deve estar
relacionado à um processo bem definido. É representado por uma elipse contendo o seu
nome, que também pode ser colocado abaixo da elipse;
3) Actor – Utilizador do sistema, podendo ser uma pessoa ou outro sistema que interagem
directa ou indirectamente com o sistema.
29
4) Relacionamento – auxiliam na descrição dos casos de uso, podendo ser: entre um actor e
um caso de uso, entre actores e entre casos de uso.
Figura 2.11 Casos de uso
Fonte: (Paschoal 2016)
b) Diagrama de classe
Uma classe é a descrição de um tipo de objecto. Todos os objectos são instâncias de classes,
onde a classe descreve as propriedades e comportamentos daquele objecto. Objectos só podem
ser instanciados de classes. Usam-se classes para classificar os objectos que identificamos no
mundo real (Ribeiro 2012).
Uma classe pode ser a descrição de um objecto em qualquer tipo de sistema – sistemas de
informação, técnicos, integrados em tempo real, distribuídos, software etc. Num sistema de
software, por exemplo, existem classes que representam entidades de software num sistema
operacional como arquivos, programas executáveis, janelas, barras de rolagem, etc. (Ribeiro
2012).
Identificar as classes de um sistema pode ser complicado, e deve ser feito por pessoas
capacitadas no domínio do problema a que o software modelado se baseia. As classes devem ser
retiradas do domínio do problema e serem nomeadas pelo que elas representam no sistema. Para
30
Tybel (2016) quando procuramos definir as classes de um sistema, existem algumas questões que
podem ajudar a identificá-las:
 Existem informações que devem ser armazenadas ou analisadas? Se existir alguma

informação que tenha de ser guardada, transformada ou analisada de alguma forma, então
é uma possível candidata para ser uma classe.
 Existem sistemas externos ao modelado? Se existir, eles deverão ser vistos como classes
pelo sistema para que possa interagir com outros externos.
 Existem classes de bibliotecas, componentes ou modelos externos a serem utilizados pelo
sistema modelado? Se sim, normalmente essas classes, componentes e modelos conterão
classes candidatas ao nosso sistema.
 Qual o papel dos actores dentro do sistema? Talvez o papel deles possa ser visto como
classes, por exemplo, usuário, operador, cliente e daí por diante.
Em UML as classes são representadas por um rectângulo dividido em três compartimentos: o

compartimento de nome, que conterá apenas o nome da classe modelada, o de atributos, que
possuirá a relação de atributos que a classe possui em sua estrutura interna, e o compartimento de
operações, que serão os métodos de manipulação de dados e de comunicação de uma classe com
outras do sistema. A sintaxe usada em cada um destes compartimentos é independente de
qualquer linguagem de programação, embora possam ser usadas outras sintaxes como a do C++,
Java, e etc.
31
Figura 2.12 Representação de classes
Fonte: (Rangel 2017)
c) Diagrama de actividades
O diagrama de actividades é um tipo de diagrama UML que especifica o comportamento de um

software. Este ilustra graficamente o funcionamento do software e a actuação do sistema na
realidade de negócio na qual ele está inserido (Ventura 2016).
Neste diagrama, uma actividade é modelada como uma sequência estruturada de acções,
controladas por nós de decisão e sincronismo. É muito confundido com fluxogramas, mas, ao
contrario dos fluxogramas, o diagramas de actividades suportam diversos outros recursos como
partições e nós do tipo fork e merge, além da definição de regiões de interrupção, que permitem
uma modelagem bem mais rica do que simplesmente um fluxograma (Ventura 2016).
É pertinente usá-lo quando se deseja:
 Documentar o aspecto funcional do software (representar o fluxo da informação a

trafegar nele);
 Mostrar aspectos específicos de rotinas de negócio que será automatizada pelo software;
32
 Mostrar como as funcionalidades irão realizar requisitos funcionais e a relação dos

requisitos funcionais com as regras de negócio;
 Mostrar como os módulos interagem entre si e as principais informações trafegadas
durante a execução.
Figura 2.13 Diagrama de actividades
Fonte: (Ang 2022)
2.3.11. Diagrama de estado

O diagrama de estados é aquele que mostra o conjunto de estados pelos quais um objecto passa
durante o seu ciclo de vida em um sistema em resposta a eventos, juntamente com as suas
respostas e acções. Também conhecido como diagrama de transição de estados UML, ilustra
quais eventos podem mudar o estado dos objectos. Segundo (Vanazzi 2017) as principais
aplicações dos diagramas de estados são:
 Descrever os objectos orientados à eventos em um sistema;

 Descrever todos os possíveis estados de um sistema;
 Descrever a forma como um objecto se move por vários estados em seu tempo de vida.
33
Figura 2.14 Diagrama de estados
Fonte: (https://dtic.tjpr.jus.br/wiki/-/wiki/Governan%C3%A7a-TIC/Modelo+de+M%C3%A1quina+de+Estados/
pop_up)
ciclo de vida de um objecto, descrevendo como este se comporta com a ocorrência de eventos
nos diferentes estágios do seu ciclo de vida. Também conhecido como diagrama de estados
UML, este representa os múltiplos estados em que um objecto pode se encontrar e como ele
muda de um estado para o outro. https://miro.com/pt/modelos/diagrama-transicao-estados-uml/
2.3.12. Diagrama de sequência

Segundo IBM() o diagrama de sequência é aquele utilizado para demonstrar a sequência das
mensagens entre objetos em uma interação. Eles ilustram como as diferentes partes de um
sistema interagem entre si para realizar uma função, e a ordem em que as interações ocorrem
quando um determinado caso de uso é executado. É possível utilizá-lo em diversas fases durante
o processo de desenvolvimento para descrever as interações entre os objectos do sistema como
será demonstrado na tabela a seguir.
https://www.ibm.com/docs/pt-br/rsm/7.5.0?topic=uml-sequence-diagrams
Tabela 2.9. Descrição da utilização do diagrama de sequência durante as fases de um projecto
Fase Descrição
34
Análise É possível utilizar diagramas de sequência

para ilustrar as interações das instâncias de
classe para realizar um caso de uso. Nesta fase,
os diagramas de sequência podem servir de
auxílio para identificar as classes necessárias
em um sistema e o que os objetos da classe
fazem nas interações.
Design Pode-se refinar diagramas de sequência para
explicar como o sistema funciona para realizar
as interações.
Construção Durante o desenvolvimento de uma arquitetura
de sistema, é possível utilizar diagramas de
sequência para mostrar o comportamento de
padrões e mecanismos de design que o sistema
utiliza.
Fonte: (essa que está aí em cima)
35
Figura 2.15 Exemplo de diagrama de sequência
Fonte: (https://creately.com/blog/pt/diagrama/tutorial-do-diagrama-de-sequencia/#Oquee)
2.3.13. Padrões de Arquitectura para sistemas distribuídos

Sommerville (2011) afirma que o objectivo de projectistas de software é sempre alcançar o
equilíbrio entre desempenho, confiança, protecção e capacidade de gestão dos sistemas.
Contudo, não existe um modelo universal de organização de um sistema distribuído que seja
apropriado para todas as circunstâncias, por isso, surgirem vários estilos de arquitectura que
serão enumerados a seguir:
 Arquitectura mestre-escravo – utilizada em sistemas de tempo real que requerem tempos

de resposta de interacção precisos.
 Arquitectura cliente-servidor de duas camadas – utilizada para sistemas cliente-servidor

simples e quando se pretende centralizar o sistema por razões de segurança pois, nestes
casos a comunicação entre o cliente e o servidor costuma ser criptografada.
36
 Arquitectura cliente-servidor multicamadas – este modelo é utilizado quando existe um

alto volume de transacções a serem processadas pelo servidor.
 Arquitectura distribuída por componentes – utiliza-se quando recursos de diferentes

sistemas e base de dados precisam ser combinados ou pode também ser usada como
modelo de implementação para sistemas cliente-servidor em várias camadas.
 Arquitectura ponto-a-ponto – utilizada quando existe a troca de informações localmente

armazenadas entre os clientes e o servidor é o responsável de apresentar os clientes uns
aos outros.
a) Arquitectura cliente servidor
Segundo dos Santos et al. (2015) A arquitectura cliente servidor é uma arquitectura de aplicação
distribuída, ou seja, na rede existem os fornecedores de recursos ou serviços a rede, que são
chamados de servidores, e existem os requerentes dos recursos ou serviços, denominados
clientes.
O cliente não compartilha nenhum de seus recursos com o servidor, mas, no entanto, ele solicita
alguma função do servidor, sendo ele, o cliente, responsável por iniciar a comunicação com o
servidor, enquanto o mesmo aguarda requisições de entrada. Conforme a tecnologia e a dinâmica
dos negócios foram evoluindo, viu-se necessário a ampliação deste modelo e suas configurações
de modo a diminuir custos com equipamentos e garantir o maior acesso e comunicação entre
eles. Desta forma esta arquitectura evoluiu para modelos de múltiplas camadas, cada uma delas
com finalidades específicas descritas a seguir:
Arquitectura cliente servidor em 2 camadas
É a mais simples configuração dentro da arquitectura e foi uma das primeiras a ser utilizadas.
Nela, temos um programa que é instalado no cliente que acede à base de dados que fica residente
no servidor de base de dados. Ocorre que nesta configuração, o cliente mantém o código de
geração de interfaces e as regras de negócio (que definem como os dados serão manipulados)
37
com o usuário. Deste modo, caso se altere a interface de acesso ao utilizador ou as regras do
negócio, esta alteração deverá ser feita em cada um dos clientes.
Figura 2.16 Arquitectura em 2 camadas
Fonte: (Silva 2016)
Arquitectura em 3 camadas
Este modelo recebe esta denominação quando a arquitectura cliente-servidor é desenvolvida

retirando-se a camada de negócio do lado do cliente, ou seja, a parte da aplicação que contém as
regras de negócio passa a ser hospedada em um servidor específico, o servidor de aplicação.
Abrindo espaço para que caso haja mudanças na regra do negócio, estas alterações sejam feitas
apenas no servidor de aplicação e não mais em todos os clientes. Um outro aspecto a se
considerar é que o acesso à base de dados não é mais feito pelo cliente, mas sim por meio das
regras contidas no servidor de aplicação, o que pode implicar no aumento da segurança uma vez
que os clientes já não podem aceder à base de dados directamente do seu equipamento, a não ser
através de requisições de serviço ao servidor de aplicação.
38
Fonte: (IBM 2021)
Arquitectura de 4 camadas
Como uma evolução do modelo de 3 camadas, surge o modelo de 4 camadas cuja ideia básica é
retirar a camada de apresentação do lado do cliente e centralizá-la num determinado ponto, que
na maioria dos casos é um servidor web. Com isso, o cliente deixa de possuir um programa que
precisa ser instalado e alterado em cada computador da rede, entretanto o acesso é feito através
de um navegador.
Há que referir que os servidores utilizados não precisam ser separados, ou seja, é possível ter
uma única máquina a desempenhar o papel destes servidores pois os conceitos de “servidor de
aplicação”, “servidor web” e “servidor de base de dados” estão relacionados à função que cada
um desempenha, mas para tal, há que se tomar em consideração o poder computacional desta
máquina. (Macêdo 2012)
39
Fonte: (Oracle 2010)
2.3.14. Base de dados

Segundo Galassi et al. (2013) uma base de dados é uma colecção de dados inter-relacionados,
que representam informações acerca de um domínio específico.
2.3.15. Vantagens da utilização de bases de dados

Fazendo uma comparação ao método tradicional de armazenamento de informações, as bases de
dados trazem certas vantagens como:
- Densidade: O grande volume de arquivos físicos deixa de existir;
- Velocidade: O computador é muito mais rápido que o ser humano quando se trata de busca e
actualização de informação;
- Actualidade: A qualquer momento os computadores poderão, em questão de segundos,

disponibilizar informações actualizadas;
- Protecção: A perda não intencional e o acesso ilegal podem ser evitados através de bloqueios e
configurações de níveis de acesso.
2.3.16. Base de dados relacional (SQL)

“Uma base de dados relacional é um tipo de base de dados que armazena e fornece acesso a
pontos de dados relacionados entre si. Base de dados relacionais são baseados no modelo
40
relacional, uma maneira intuitiva e directa de representar dados em tabelas. Em uma base de
dados relacional, cada linha na tabela é um registo com um identificador exclusivo
chamado chave. As colunas da tabela contêm atributos dos dados e cada registo geralmente tem
um valor para cada atributo, facilitando o estabelecimento das relações entre os pontos de
dados.” (Oracle 2021).
A Oracle apresenta quatro propriedades essenciais que definem as transacções das base de dados
relacionais: atomicidade, consistência, isolamento e durabilidade (ACID).
A atomicidade trata da definição de todos elementos que compõem uma transacção completa da
base de dados; a consistência define as regras para manter os pontos de dados em um estado
correcto após uma transacção; o isolamento é utilizado para manter o efeito de uma transacção
invisível para outras pessoas até que seja confirmada e a durabilidade garante que as alterações
dos dados se tornem permanentes quando a transacção for confirmada. São exemplos de bases de
dados relacionais o SQL, Oracle,
2.3.17. Base de dados não relacional (NoSQL)

Segundo a (MongoDB 2021), as base de dados NoSQL (“Not only SQL”) são não tabulares e são
caracterizadas basicamente por armazenar dados de forma diferente em relação às base de dados
relacionais, isto é, não possuem conformidade com ACID, joins, chaves estrangeiras nem vários
outros recursos fundamentais na utilização das base de dados relacionais (Hows et al, 2015).
As base de dados NoSQL podem ser apresentadas em 4 modelos distintos que podem ser
descritos como:
 Modelo de colunas: em que a base de dados faz o armazenamento em linhas

particularmente distintas da tabela, ou seja, as linhas não necessariamente precisam de
ter o mesmo número de colunas. São muito úteis quando se pretende armazenar grandes
volumes de dados e se pode prever quais serão os padrões de consulta;
 Modelo de chave-valor: neste modelo temos uma base de dados formada por pares de
chave-valor, estes últimos que podem tipicamente ser recuperados referenciando a sua
chave. A sua aplicação torna-se muito útil nos casos em que se necessita armazenar
grandes volumes de dados, mas não são requeridas consultas complexas para acedê-los;
41
 Modelo de grafos: neste modelo, os dados são dispostos no formato de arcos conectados
por arestas. Este modelo mostra ser eficiente quando se trata de pesquisas complexas
pois possuem latência baixa e destacam-se nos casos em que é necessário cruzar
relacionamentos para procurar padrões como redes sociais, detecção de fraudes e
mecanismos de recomendação;
 Modelo de documentos: como o nome já sugere, os dados são armazenados como

documentos. Documentos estes semelhantes à objectos JSON em que cada um deles
contém pares de chaves e valores. São óptimos para uma grande variedade de casos de
uso e podem ser utilizados como base de dados para propósitos gerais.
2.3.18. Diferença entre base de dados relacionais e não relacionais

Tabela 2.10 Comparação SQL e NoSQL
Característica Base de dados SQL Base de dados NoSQL
Modelo de armazenamento de Tabelas com número fixo de Documento: Documentos JSON;

dados linhas e colunas Chave-valor: Pares de chave-valor;
Colunas: Tabelas com linhas e

colunas dinâmicas;
Grafos: Nós e arestas
Exemplos Oracle, MySQL, Microsoft Documento: MongoDB, CouchDB;

SQL Server, PostgreSQL Chave-valor: Redis, DynamoDB;
Colunas: Cassandra, HBase;
Grafos: Neo4j, Amazon Neptune
Esquema Rígido Flexível
Escalabilidade Vertical Horizontal
Junções (Joins) Normalmente exigido Normalmente não requerido
Mapeamento de dados para Requer ORM (Mapeamento Muitos não requerem ORM.
42
objectos objecto-relacional) Documentos MongoDB são

mapeados directamente para
estruturas de dados nas linguagens
de programação mais populares.
Fonte: (Aalst e Hee 2009)
2.3.19. Sistemas de gestão de base de dados

Aalst e Hee (2009) definem um SGBD como um programa ou conjunto de programas
de software que permitem a criação e a manutenção de uma base de dados bem como o acesso à
mesma por parte de todos os seus utilizadores, em resumo é um software utilizado para gerir
base de dados no intuito de criar, modificar, eliminar, inserir base de dados e realizar todas estas
operações na própria base de dados. São exemplos de SGBD o IBM DB2, MySQL, OracleDB,
PostgreSQL, Microsoft SQL server, MariaDB.
Figura 2.19 Funcionamento de uma SGBD
Fonte: (Aalst e Hee 2009)
a) MySQL é um SGBD relacional de código aberto baseado em SQL utilizado para a gestão
de base de dados baseadas no modelo relacional. Este SGBD é comummente utilizado no
desenvolvimento de aplicações pela sua velocidade, facilidade de integração com
servidores e linguagens de programação web, para além de ter API’s para C, C++, Java,
Perl, PHP e Phyton (Luís 2021).
b) Oracle SQL é também um SGBD relacional, porém diferentemente do MySQL que é de
código aberto, este é utilizado sob uma licença comercial. Foi concebido para gerir um
grande volume de dados e oferece um alto nível de escalabilidade e flexibilidade, o que
43
torna prática a sua utilização em negócios, para além disso é um SGBD multiplataforma,
o que significa que pode operar em vários sistemas operativos.
https://towardsdatascience.com/mysql-vs-oracle-sql-a97a7659f992#:~:text=As%20far
%20as%20scalability%2C%20MySQL,%2C%20however%2C%20supports%20data
%20partitioning.
c) O MongoDB é um SGBD não relacional de código aberto criado em resposta da
necessidade de um bom desempenho quando se lida com um grande volume de dados.
Apresenta-se útil em situações em que se necessita altos níveis de flexibilidade e
escalabilidade como por exemplo, sites de e-commerce. Segundo () as empresas utilizam
o MongoDB como uma solução de alto desempenho para actualizar os dados mais
rapidamente na estrutura e na informação. MySQL vs. MongoDB: What’s the
Difference? | IBM
2.3.20. Protocolos de rede

Segundo Tanenbaum (2006), um protocolo é um conjunto de regras e convenções usadas na
comunicação entre máquinas. É a partir destas normas que será estabelecida a maneira como se
dará a comunicação entre as máquinas envolvidas.
a) Protocolo HTTP
O HTTP é o protocolo de transferência utilizado em toda a World Wide Web, sendo responsável
pela especificação das mensagens que os navegadores podem enviar aos servidores e que
respostas eles receberão, sendo, portanto, baseado em requisição e resposta (Tanenbaum, 2006).
b) Protocolo HTTPS
No início da web as suas páginas eram estáticas, mas com a evolução da mesma, as empresas
tiveram a ideia de usá-las para executar transacções sensíveis (ex.: compra e venda de produtos
por cartões de crédito) e por consequência disso necessitavam de mecanismos que garantissem
segurança adicional nas suas transacções.
44
Em 1995 a Netscape Communications Corp., respondeu introduzindo um pacote de segurança

chamado SSL (Secure Sockets Layer) que constrói a ligação segura entre dois sockets. Este
pacote é introduzido entre a camada de aplicação e a camada de transporte, aceitando
solicitações do navegador e enviando-as ao TCP para transmissão ao servidor. Depois que uma
conexão segura é estabelecida, a principal tarefa do SSL é manipular a compactação e a
criptografia, então, quando o protocolo HTTP é utilizado sobre o SSL, ele então denomina-se
HTTPS (Secure HTTP) (Tanenbaum, 2006).
2.3.21. Métodos HTTP

Embora o HTTP tenha sido projectado para a utilização na web, ele foi criado de um modo
genérico visando suportar também as aplicações orientadas a objectos, e por essa razão é que são
aceites operações (métodos) diferentes da simples solicitação de uma página web.
Tabela 2.11 Métodos HTTP
Método Descrição
GET Solicita a leitura de uma página da Web
HEAD Solicita a leitura de um cabeçalho de página da Web
PUT Solicita o armazenamento de uma página da Web
POST Acrescenta a um recurso (por exemplo, uma página

da web)
DELETE Remove a página da Web
TRACE Ecoa a solicitação recebida
CONNECT Reservado para uso futuro
OPTIONS Consulta certas opções
Fonte: (Tanenbaum 2006)
45
2.3.22. Arquitectura orientada a serviços

Para Ngolo (2009) SOA é um paradigma dos sistemas de informação que permite tirar mais
rendimento dos sistemas actuais sem a necessidade de se estar sempre a criar ou inventar novos
sistemas. Ele descreve o seu funcionamento da seguinte maneira: primeiro é necessário definir o
serviço e fornecer detalhes necessários para a sua utilização de forma apropriada. Após a
existência do serviço, um provedor de serviços tem de publicar detalhes do serviço que dispõe,
de modo que os potenciais interessados possam saber como proceder para acedê-lo, e por fim, os
interessados no serviço têm de ter alguma forma para determinar quais os serviços que
satisfazem as suas necessidades.
Figura 2.20 Funcionamento da arquitectura SOA
Fonte: (Ngolo 2009)
2.3.23. Serviços
Tendo em conta a velocidade em que o ambiente de negócios têm evoluído, é imposta uma
necessidade de se desenvolver sistemas mais flexíveis e ágeis de modo a atender a demanda que
os negócios apresentam em tempo útil. Segundo Marzullo (2009) as organizações vêm buscando
cada vez mais novas ferramentas para competirem em seu ambiente de negócios, entre elas estão
as soluções orientadas a serviços e é neste contexto que define serviço como “um conjunto de
actividades correlatas, com objectivo ou regras bem definidas, e que, ao ser avaliado no todo,
representa um benefício de valor específico para o qual se deseja um controle de recursos
consumidos”. Com isto em mente, a materialização da ideia de um serviço disponibilizado na
Internet que permite que um ou mais clientes enviem requisições de um tipo bem definido de
informação e recebam respostas síncronas ou assíncronas, é vista como Web Service por
Marzullo (2009).
46
2.3.24. Arquitectura SOAP

O SOAP (protocolo de arquitectura orientada a serviços) é o protocolo padrão para transmissão
de dados quando se trata de web services, pertencentes ao conjunto de especificações WS-*. Esta
arquitectura é baseada em XML e segue o modelo de request-response do HTTP, permitindo a
integração de aplicações implementadas em tecnologias diferentes através do uso do WSDL que
estabelece um formato de descrição padrão para as aplicações que lho irão utilizar (Ngolo 2009).
a) WSDL
Ngolo (2009) descreve o WSDL (Web Services Description Language) como um arquivo padrão
XML que tem como objectivo fornecer uma descrição detalhada do web service ao solicitante.
Nesta descrição são especificadas as operações que compõem o serviço, definindo claramente
como deve ser o formato de entrada e saída de cada operação. É possível armazenar este WSDL
tanto no provedor de web services (que pode ser um servidor de aplicação ou um web container)
como no UDDI.
b) UDDI
Segundo Gomes (2009) o UDDI (Universal Description, Discovery and Integration) é um

mecanismo que atende tanto ao cliente quanto ao provedor. Ele é responsável por entregar ao
provedor de web services dos recursos para que os web services sejam registados e publicados de
modo a permitir que estes sejam pesquisados e localizados pelos clientes. Ngolo (2009) infere
que a descoberta e a publicações de operações são possíveis através de uma especificação UDDI,
que é composta por vários documentos onde encontram-se descritas as especificações SOAP
API.
2.3.25. Arquitectura REST

Segundo Ngolo (2009), o REST (Representational State Transfer) é um estilo de arquitectura de
software alternativo ao SOAP para implementar web services e o uso vem aumentando devido a
sua simplicidade e a sua fácil aplicabilidade em tecnologias web nativas como o HTTP.
47
Gomes (2009) afirma que os componentes envolvidos na arquitectura REST são: o cliente de
web service, o provedor do web service, e o protocolo HTTP. Com este cenário, o cliente envia
mensagens de solicitação a um determinado web service disponível no provedor, este web
service irá realizar um determinado processamento e retornar uma mensagem de resposta ao
cliente através do protocolo HTTP, que para além de transportar as mensagens, determina o
formato das mesmas.
Figura 2.21 Arquitectura dos web services REST
Fonte: (Gomes 2009)
Segundo Sampaio (2011), quando se fala de REST há que ter em conta três aspectos básicos que
são:
 Recurso – Um recurso disponível, pode ser um produto, cliente, etc.
 Localização – Uma URI que define a localização do recurso. Por isso esta deve ser única
e deve estar armazenada em um único local;
 Verbo – Um método HTTP como GET, PUT, DELETE ou POST
2.3.26. Interface de programação e aplicação (API)

Segundo Grinberg (2018) tem havido uma tendência das aplicações web transferir cada vez mais
a lógica de negócios para o lado do cliente, resultando numa arquitectura conhecida como RIAs
(Rich Internet Applications). Nas RIAs, a principal função do servidor é oferecer serviços de
48
obtenção e armazenamento de dados para a aplicação cliente. Neste modelo, o servidor passa a
ser um web service ou uma API.
API é um conjunto de definições e protocolos usado no desenvolvimento e na integração de

software de aplicações. Geralmente costumam ser vistas como contractos, com documentações
que representam um acordo entre as partes interessadas. Se uma dessas partes enviar uma
solicitação remota estruturada de uma forma específica, isso determinará como o software da
outra parte responderá (RedHat 2018).
Figura 2.22 Funcionamento da API
Fonte: (RedHat 2018)
2.3.27. Internet e World Wide Web

“A Internet é uma rede constituída por várias redes que se encontram interligadas, criando uma
comunidade virtual de utilizadores de grande dimensão. Uma das características da Internet é o
facto de não possuir qualquer autoridade a controlar.” (Costa 2007).
Actualmente a internet encontra-se em quase todos dispositivos e é utilizada para diversas

aplicações. Segundo Costa (2007), os principais serviços da internet são o correio electrónico (e-
mail), sessões remotas (Telnet), transferência de ficheiros (usando o protocolo FTP), grupos de
discussão (news), Archie e WAIS, Gopher e WWW. Mas devido às potencialidades gráficas a
WWW é claramente a mais popular.
A WWW é um SI cliente-servidor em hipertexto distribuído na internet. Na Web todos os

ficheiros que podemos encontrar (documentos, menus, entre outros) são objectos em hipertexto
no formato HTML, manipulados pelo programa cliente (browser) (Costa 2007).
49
2.3.28. Web browser

Costa (2007) define o Web browser como um software que é executado num computador
(cliente) permitindo mostrar o conteúdo de uma página que se encontra em um outro computador
(Servidor). De forma que possa aceder a essa informação é necessário que se utilize um
protocolo de transferência de hipertexto ou HTTP.
2.3.29. Linguagem HTML

HTML é a linguagem de marcação que consiste na formatação de texto, utilizada para o acesso e
exibição de páginas Web. O código HTML é interpretado pelo navegador que mostra o resultado
ao utilizador. Genericamente a linguagem HTML é constituída por textos e códigos especiais
denominadas tags. (Lalli, Bueno, and Zacharias 2008; Costa 2007).
2.3.30. CSS
CSS é a sigla em inglês que significa Cascading Style Sheets e é a linguagem utilizada para
modificar visualmente elementos HTML em páginas web. Gomes (2022) explica que foi criado
em 1996 pela W3C para resolver a limitação que o HTML tem de formatar as páginas. O CSS é
facilmente acoplado às páginas HTML e facilita a criação de páginas amigáveis e intuitivas
porque enquanto o HTML é focado na marcação, o CSS é focado na estilização de componentes.
2.3.31. Linguagens de programação

a) JavaScript
É uma linguagem de script desenvolvida pela Netscape que permite a criação de páginas
interactivas. O JS possibilita realizar muitas tarefas para enriquecer uma página Web. Como
exemplo disso podemos ter a exibição de mensagens e efeitos dinâmicos (Costa 2007).
b) Java
Luckow e de Melo (2010) afirmam que a linguagem Java começou a surgir em 1991 pela Sun
Microsystems com o nome Oak, e tinha como objectivo possibilitar a convergência entre o
50
computador, equipamentos electrónicos e electrodomésticos. Após James Gosling ter sido

encarregue de adaptar a linguagem Oak, surgiu assim em 1995 a plataforma Java que trazia
como principal diferença com as demais linguagens existentes na época, a execução numa JVM,
o que permite que qualquer equipamento que pode executar uma máquina virtual consegue
executar Java e daí se justifica o seu slogan “write once, run anywhere”.
Apesar da semelhança do nome, o JS é diferente da linguagem Java, como será exibido na

seguinte tabela.
Tabela 2.12 Comparação entre JS e Java
JavaScript Java
Interpretada pelo cliente. Os bytecodes compilados são carregados do
servidor e executados no cliente.
Orientado a objectos; Baseado em classes;
Não há distinção entre os tipos de objectos; Os objectos são divididos em classes e
Herança é feita através do mecanismo de instâncias com a herança a resultar da
protótipo. hierarquia de classes.
O código está integrado e embebido no Applets são distintos do HTML.
HTML.
Os tipos de dados das variáveis não são Os tipos de dados das variáveis têm
declarados. obrigatoriamente de ser declarados.
Fonte: (Costa 2007)
c) PHP
PHP significa PHP: Hypertext Preprocessor. Foi originalmente chamado de Personal Home
Page e hoje é conhecida pela sua sintaxe intuitiva e não verbosa, para além de reduzir a
complexidade do processo de produção de páginas dinâmicas, deixando de ser necessário o uso
da interface CGI (Converse and Joyce 2003).
É uma linguagem para a criação de scripts para a web no server-side embutidos em HTML,
possui código open source que é compatível com os mais importantes servidores web
(especialmente o Apache). Permite incorporar fragmentos de código em páginas HTML normais
51
e facilita a conexão das suas páginas web com a base de dados do lado do servidor (Converse and
Joyce 2003)
2.3.32. Frameworks usados em desenvolvimento web

Para que se criem produtos com uma qualidade mínima e em menos tempo, é necessário que os
desenvolvedores se sirvam de ferramentas que facilitem o desenvolvimento do produto em
causa, para isso, são usados os frameworks.
House (2021) define o framework como um modelo pronto que conta com diversas
funcionalidades que podem ser utilizadas no desenvolvimento de um projecto. O principal
objectivo do framework é resolver problemas recorrentes com uma abordagem genérica, pois ele
é composto com diversas ferramentas, sistemas e componentes que facilitam o processo de
desenvolvimento de um projecto o que traz uma significativa poupança no tempo gasto. Desta
forma, existem frameworks projectados para o auxílio do desenvolvimento da parte lógica
(backend) e outros para o auxílio na parte visual do sistema (frontend), como serão apresentados
alguns destes.
1) Frameworks backend
a) NodeJS
Foi apresentado em 2009 por Ryan Dahl na JSConf Europa. O NodeJS (ou vulgarmente
chamado Node) é uma plataforma poderosa para aplicações, para construir aplicações de
rede fácil e rapidamente e que utiliza a engine Js open source (código aberto)de alta
performance do Google Chrome (Moraes 2018).
Ela difere da arquitectura do PHP, em que temos o PHP como linguagem server-side
(lado do servidor) e o Apache como servidor web, com NodeJS é possível escrever o seu
próprio servidor web e a aplicação JS server-side, tudo em JS.
O NodeJS utiliza uma arquitectura orientada a eventos e um modelo I/O não bloqueante
que faz com que seja leve e eficiente. Estas características são favoráveis quando se
depara com problemas de intenso tráfego de rede e aplicações em tempo real. Segundo
52
(Moraes 2018), o NodeJs suporta qualquer dos seguintes protocolos: DNS, FTP, HTTP,
HTTPS, SSH, TCP, UDP ou WebSockets (Moraes 2018).
b) Spring
Rod et al. (2007) descreve o Spring como um framework Java de código aberto que visa
facilitar o desenvolvimento de aplicações baseando-se nos conceitos de inversão de
controle e injecção de dependências. Cavalcante (2020) afirma que a inversão de controle
(IoC) permite delegar a um elemento o controle sobre a execução de alguns
comportamentos do sistema, e a esse elemento dá-se o nome de container. Enquanto que
a injecção de dependência Segundo Cavalcante (2020) é uma das maneiras de se fazer a
inversão de controle e trata-se a fonte de instâncias de classes que um determinado
objecto necessita sem que este instancie por si mesmo.
c) Laravel
Bean (2015) descreve o Laravel como um framework PHP de código aberto que foi
criado em 2011 por Tyler B. Otwell, como uma alternativa ao CodeIgniter (um
framework muito popular na época). Ele é baseado na arquitectura MVC e faz a
reutilização de componentes existentes para fornecer uma camada coesa sobre a qual se
pode construir aplicações de maneira mais bem estruturada e prática. O Laravel oferece
um conjunto robusto de ferramentas e uma arquitectura de aplicação que incorpora
muitas das melhores características de frameworks como CodeIgniter, Yii, ASP.NET
MVC, Ruby on Rails, Sinatra e outras.
2) Frameworks frontend
a) Bootstrap
Segundo (Bootstrap 3 Tutorial (w3schools.com)), o Bootstrap é o framework mais

popular de HTML, CSS, e JS para desenvolver páginas web responsivas. Criado em 2011
por Mark Otto e Jacob Thornton no Twitter, é um framework de código aberto que possui
características responsivas, o que o permite ajustar os componentes da tela para os vários
tamanhos dos vários dispositivos disponíveis, para além de ser compatível com a maior
parte dos navegadores modernos (Chrome, Firefox, Edge, Internet Explorer, Safari e
Opera).
53
b) AngularJS
Segundo (What is AngularJS? | Learn the Versions of AngularJS with Examples

(educba.com)), em 2009 os desenvolvedores Misko Hevery e Adam Abron criaram um
framework Javascript que liga elementos HTML com elementos Javascript e o
denominaram Angular JS. O Angular JS tem como principais recursos a vinculação de
dados e a injeção de dependências, que economizam tempo na escrita de códigos longos,
de modo a facilitar o trabalho dos desenvolvedores e navegadores.
c) Vue.JS
Vue.js é um framework progressivo de Javascript que é utilizado para desenvolver

interfaces de utilizador e aplicações de página única. A facilidade de aprender esta
tecnologia é um dos aspectos que a torna amplamente conhecida pois, com
conhecimentos básicos de HTML, CSS e JS é possível começar a criar aplicações web
com o Vue.js. É um framework de código aberto que cuja abordagem é similar à do É um
framework de código aberto cuja abordagem é virada para o uso de componentes, o que
facilita o reuso dos mesmos onde quer que seja necessário.
2.3.33. Template Engines

Quando se desenvolve uma página web, é comum que queiramos exibir determinados dados
obtidos de alguma fonte (que pode ser a base de dados, API, listas, etc). Para a exibição dessa
informação no navegador normalmente são utilizadas páginas HTML, porém, segundo de
Andrade (2020) a utilização de grandes volumes de dados e recursos das linguagens de
programação nas páginas pode tornar-se ineficiente quando se trata apenas de HTML, neste
âmbito os template engines facilitam a criação de páginas HTML e tornam o envio e exibição de
informações para estas páginas um processo mais simples e organizado.
Segundo Ramos (2020), os template engine podem ser interpretados como ferramentas de
tradução que organizam os dados criados pelo desenvolvedor e traduzem-nos para HTML puro,
que é a única linguagem que os navegadores são capazes de ler e demonstrar para o utilizador, e
os envia.
54
Na tabela abaixo são apresentados alguns template engines mais utilizados em algumas
linguagens:
Tabela 2.13 Template engines utilizados em determinadas linguagens de programação
Linguagem Template Engine

PHP Plates, Blade, Twig
Python Django Template, Genshi, Jinja, Mako
Java Java Server Pages (JSP), Thymeleaf,
FreeMarker
Javascript Mustache, Handlebars, EJS, Jade Language,
PUG
Fonte: (Ramos 2020)
2.3.34. Vantagens da utilização de template engine

Um dos grandes desafios ao trabalhar em grandes grupos de desenvolvedores é a comunicação.
A utilização de um template engine irá reduzir este problema porque permitirá que os designers e
os desenvolvedores back-end possam trabalhar em conjunto sem que sejam criados obstáculos
entre eles pois utilizam tecnologias diferentes, mas que podem ser associadas com muita
facilidade. Para Ramos (2020) as template engines trazem como vantagem:
 Mais velocidade na criação

 Fácil leitura
 Facilidade de personalização
 Possibilidade de restringir o acesso
 Facilidade na colaboração
 Utilização de recursos das linguagens de programação em páginas HTML (estruturas de
selecção, estruturas de condição, etc).
55
Figura 2.23 Funcionamento do template engine
Fonte: (de Andrade 2020)
56
CAPÍTULO 3 – CONTEXTUALIZAÇÃO DA INVESTIGAÇÃO

O objectivo deste capítulo é apresentar e descrever de forma clara o objecto de investigação e a
sua situação actual, isto é, pretende-se abordar as circunstâncias existentes actualmente, as
dificuldades, quem e como são os afectados pelo problema. Estes aspectos serão tomados em
consideração para a contextualizar o objecto de estudo de modo a justificar a viabilidade da sua
implementação no cenário apresentado.
1.9. 3.1. Caracterização sócio – histórica, geográfica, política do objecto de

investigação
3.1.1. Cidade de Maputo
A cidade de Maputo (Lourenço Marques até 1976) é a capital de Moçambique, situa-se na
margem ocidental da baía com o mesmo nome, no extremo sul do país e ocupa uma superfície de
346.77 Km2 incluindo os Distritos Municipais da Katembe e Ilha de Inhaca. Esta cidade está
dividida em sete distritos municipais a saber: Distrito Urbano de KaMpfumo, Distrito Urbano de
KaNlhamankulo, Distrito Urbano de KaMaxaquene, Distrito Urbano de KaMavota, Distrito
Urbano de KaMubukwana, Distrito Urbano de KaTembe e Distrito Urbano de KaNyaka. Este
por sua vez contém os vários bairros que albergam os 1 120 867 habitantes que esta ela possui.
Figura 3.16 Cidade de Maputo
Fonte:(Governo da Cidade de Maputo 2021)
Maputo é um município com governo eleito e desde 1980 também passou a ser uma província.
Esta cidade, para além de ser a capital social é o principal centro financeiro, corporativo e
mercantil do país. Nela está contida a maior parte dos serviços e sedes de grandes grupos
57
económicos e empresas públicas e privadas. O porto de Maputo, as linhas ferroviárias, a rede

rodoviária, que liga Moçambique a África do Sul e ao Reino de Enswatini e o maior aeroporto do
país tornam a cidade num ponto estratégico no desenvolvimento de Moçambique. Pois, segundo
a (UCCLA 2015), apesar de concentrar apenas 5,4% da população do país, esta cidade é
responsável por 20,2% do PIB moçambicano.
3.1.2. Conselho Municipal da Cidade de Maputo

O Conselho Municipal da Cidade de Maputo é a entidade do estado responsável pela gestão do
município, exercendo os seus poderes e autoridade em conformidade com a lei moçambicana e
com o seu regulamento. O CMCM tem como missão “Liderar o processo de elevação da
qualidade de vida dos munícipes, criação de um ambiente atractivo aos investimentos e a geração
de emprego, através da melhor prestação de serviços, da mobilização dos munícipes e da acção
coordenada entre os diversos intervenientes”.
Figura 3.17 Conselho Municipal da Cidade de Maputo
Fonte: (Wikipedia 2021)
3.1.3. Mercado Xipamanine

O mercado Xipamanine, localizado no Distrito Urbano de KaNlhamankulo em Maputo é o maior
mercado informal da cidade. Localizado na rua com o mesmo nome, foi construído na década de
1940 e foi ampliado diversas vezes ao longo dos anos. Conta com cerca de 5 mil vendedores
formalizados e outros 6 mil que vendem nos arredores do mercado (Henrique, Stacciarini, and
58
Cristina 2016). A gestão deste mercado é tutorada pelo Conselho Municipal da Cidade de
Maputo representado por uma administração interna conhecida entre os vendedores como
“escritório”, que é responsável por organizar o mercado em sectores, registar e atribuir bancas
aos vendedores, realizar cobranças das taxas, garantir a organização das bancas e a limpeza em
espaços comuns como casas de banho.
Com o passar do tempo, o mercado cresceu em dimensão e número de vendedores até que em
certo ponto, as bancas e espaços disponíveis esgotaram-se. As pessoas passaram a ocupar os
espaços ao redor deste, criando bancas improvisadas ou demarcando espaços e estendendo seus
sacos no chão para vender roupas e utensílios de modo a garantir o seu sustento. Até que, como
forma de organizar melhor a actividade de venda destes cidadãos e garantir espaços dignos para
àqueles que procuravam exercer a actividade de venda de produtos, o município de Maputo, em
Março de 2021 requalificou o mercado anexo de Xipamanine, construindo bancas, barracas,
alpendres e sanitários no espaço do antigo edifício de Salubridade do Conselho Municipal de
Maputo.
Figura 3.3 Bancas do mercado anexo do Xipamanine
59
Estas obras visavam acolher os vendedores que exerciam as suas actividades tanto nas ruas e
passeios das redondezas quanto como em outros locais mais distantes, garantindo assim que estas
pessoas tivessem espaços definitivos e com melhores condições para o exercício das suas
actividades.
Figura 3.18 Vista aérea do mercado Xipamanine
Fonte: (Minube 2016)
3.2. Estado actual do objecto da investigação

3.2.1. Processo actual de registo de bancas no mercado Xipamanine
Movida pela necessidade de garantir uma melhor gestão das bancas e espaços disponíveis no
mercado a administração deste regista os vendedores, que para o efeito, têm de:
 Apresentar o seu documento de identificação ao escritório e solicitar uma banca,

referindo que tipo de produtos pretende vender;
60
 Após essa solicitação, os funcionários da administração deslocam-se ao sector onde são

vendidos produtos da mesma categoria que o solicitante pretende vender de modo a
verificar se existe um espaço/banca disponível;
 Se houver espaço disponível, o funcionário regista o solicitante em um livro de registo

que é mantido no escritório;
 E por fim emite um cartão (Cartão de comerciante) ao solicitante que serve como
comprovativo da autorização da ocupação de uma determinada banca ou espaço.
Figura 3.19 Processo actual de atribuição de bancas no mercado Xipamanine
61
3.2.2. Propriedade de banca no mercado

Uma vez que um indivíduo possui a propriedade de uma banca, este pode alugá-la ou até vendê-
la. Se for o caso de aluguer, o proprietário e o locatário devem dirigir-se ao escritório e
comunicar verbalmente que o locatário em questão passa a exercer as suas actividades no espaço
referido, porém nenhum registo é feito.
No caso da venda de uma banca à administração é comunicada, faz-se um novo registo no livro
com o nome do novo proprietário e é atribuído um novo cartão de comerciante.
3.2.3. Regras do mercado

Quando um solicitante adquire o direito de ocupar uma banca, este passa por uma instrução dada
pelo funcionário do mercado onde são apresentadas àquelas que são chamadas as regras do
mercado. Esta instrução consiste em mostrar as regras relacionadas à apresentação do vendedor
perante a sua banca, regras de asseio e higiene que este deve cumprir enquanto estiver no
mercado a exercer as suas actividades, tais como:
 Não fazer necessidades biológicas em espaços inapropriados;
 Não deitar lixo e manter a sua banca/espaço e arredores limpo;
Para o caso das mulheres, estas não devem se apresentar às suas bancas com blusas de alças, não
podem pintar as unhas ou trançar o cabelo enquanto estiverem a vender.
Caso o vendedor seja encontrado a descumprir algumas destas regras, este pode ser suspenso de
vender na sua banca por 14 dias.
3.2.4. Pagamento de taxas

Uma vez que o vendedor possui a autorização para vender os seus produtos no mercado do
Xipamanine, este deverá se submeter a pagar uma taxa diária que varia do tipo de banca / espaço
que ele ocupa, sendo esta taxa de:
 10 meticais para espaços cobertos com um 1 metro de comprimento;

 15 meticais para espaços cobertos com mais de 1,5 metro de comprimento;
 15 meticais para bancas de alvenaria / madeira
62
 25 meticais para barracas metálicas, estas que podem até ter energia eléctrica.
Os pagamentos são efectuados à um fiscal que passa de banca em banca e emite um bilhete
através de uma máquina, similar à um POS que comprova que a taxa diária foi paga. Estes
pagamentos podem ser diários ou mensais.
Quando o vendedor não paga a taxa diária, ele deve, no dia seguinte pagá-la do dia corrente e o
dobro da taxa do dia anterior. Se a banca estiver encerrada num determinado dia, nenhuma taxa
será cobrada.
Figura 3.20 Recibo de pagamento de taxa diária
3.3. Limitações do processo actual de registo de bancas

 Sistema de armazenamento de registos manual e susceptível a perda ou destruição;
 Toda vez que se solicita uma banca, existe a necessidade de o funcionário deixar os seus
afazeres e se deslocar até ao sector para verificar se existem bancas disponíveis;
 Dificuldade de apurar os donos e locatários das bancas ou quem está a ocupar as bancas;
 Dificuldade em controlar o tempo de suspensão dos vendedores;
 Dificuldade em realocar bancas aos vendedores em períodos em que são feitas obras de
requalificação no mercado.
63
64
CAPÍTULO 4 – METODOLOGIA DE RESOLUÇÃO DO PROBLEMA
Segundo Prodanov e Freitas (2013) a investigação científica é resultado de uma série de

procedimentos intelectuais e técnicos para que os seus objectivos sejam atingidos, e é neste
âmbito que neste capítulo será descrita a metodologia utilizada na investigação, incluindo o tipo
de investigação, os métodos e técnicas de pesquisas utilizados de modo a alcançar o resultado
esperado.
4.1. Tipo de pesquisa

Gil (2002) define a pesquisa como o “procedimento racional e sistemático que tem como
objectivo proporcionar respostas aos problemas que são propostos.” A pesquisa científica visa
conhecer cientificamente um ou mais aspectos de determinado assunto. Para tanto, deve ser
sistemática, metódica e crítica.
4.1.1. Pesquisa quanto à natureza

De acordo com Prodanov e Freitas (2013) sob o ponto de vista da sua natureza a pesquisa pode
ser:
a) Pesquisa básica: aquela com o objectivo de gerar conhecimentos novos úteis para o
avanço da ciência sem aplicação prática prevista. Envolve verdades e interesses
universais;
b) Pesquisa aplicada: objectiva gerar conhecimentos para aplicação prática dirigidos à
solução de problemas específicos. Envolve verdades e interesses locais.
Uma vez que o projecto a ser desenvolvido visa trazer como resultado um objecto prático que
tenciona resolver um problema específico, o tipo de pesquisa quanto a natureza a ser utilizado foi
a pesquisa aplicada.
4.1.2. Pesquisa quanto à abordagem

Quanto à abordagem a pesquisa pode ser qualitativa, quantitativa ou mista. Sendo que a pesquisa
qualitativa não se preocupa com a representatividade numérica mas sim, com o aprofundamento
65
da compreensão de um grupo social ou organização Gerhardt e Silveira (2009). Os pesquisadores

que utilizam os métodos qualitativos buscam explicar as razões das coisas, exprimindo o que é
conveniente ser feito, porém não quantificam os valores e nem se submetem a provas de facto
por estes serem não métricos. A pesquisa qualitativa preocupa-se com aspectos da realidade que
não podem ser quantificados e centra-se na compreensão e explicação da dinâmica das relações
sociais.
Diferentemente, a pesquisa quantitativa tem a característica de trazer resultados que possam ser
quantificados. Segundo Prodanov e Freitas (2013) o desenvolvimento deste tipo de pesquisa
deve-se formular hipóteses e classificar a relação entre as variáveis para garantir a precisão dos
resultados, de modo a evitar contradições no processo de análise e interpretação. Esta abordagem
mune-se de recursos e técnicas estatísticas como percentagens, média, moda, mediana, desvio-
padrão, etc., (Gerhardt and Silveira 2009).
A pesquisa mista é uma abordagem que combina os métodos quantitativo e qualitativo, pois
assim como ela preconiza a obtenção de dados precisos, ela também prega a compreensão
aprofundada desses dados. Não os tomando como resposta absoluta, mas compreendendo que os
dados são parte de um todo que necessita ser compreendido como tal (Creswell 2002).
Optou-se pelo uso da abordagem qualitativa dada a necessidade de compreender os factores

relevantes para o registo de bancas no mercado Xipamanine e como este processo é realizado, a
fim de encontrar uma solução que irá alcançar os objectivos pretendidos.
4.1.3. Pesquisa quanto aos objectivos

Do ponto de vista dos objectivos, uma pesquisa pode ser de três tipos, a saber:
 Pesquisa exploratória - segundo Da Silva e Menezes (2001) este tipo de pesquisa visa
proporcionar maior familiaridade com o problema com vista a torna-lo explícito ou a
construir hipóteses. Envolve levantamento bibliográfico; entrevistas à pessoas com
experiências práticas com o problema pesquisado; análise de exemplos que estimulem a
compreensão. Assume, em geral, as formas de pesquisas bibliográficas e estudos de caso.
 Pesquisa descritiva - para Gil (2008), este tipo de pesquisa objectiva descrever as
características de determinada população ou fenómeno ou o estabelecimento de relações
66
entre variáveis. As pesquisas descritivas salientam-se por estudar, por exemplo: a

distribuição de um grupo por idade, sexo, procedência, nível de escolaridade, etc. Outras
pesquisas deste tipo visam estudar, por exemplo o nível de atendimento de órgãos
públicos de uma comunidade, condições de habitação de seus habitantes e pesquisas que
têm por objectivo levantar as opiniões, atitudes e crenças de uma população.
 Pesquisa explicativas – São as que consistem em investigações de pesquisa cujo
objectivo principal é o teste de hipóteses que dizem respeito a relações de tipo causa-
efeito. Da Silva e Menezes (2001) explica também que este tipo de pesquisa aprofunda o
conhecimento da realidade porque explica o “porquê” das coisas.
Quanto aos objectivos, os tipos de pesquisa utilizados para este projecto foram a pesquisa
descritiva e a exploratória, dada a necessidade de descrever o processo de atribuição e
manutenção dos registos de bancas do mercado Xipamanine e a utilização dos métodos para a
colecta de informações e levantamento bibliográfico sobre o tema que foram: as entrevistas às
pessoas que lidam diariamente com o objecto de estudo.
4.1.4. Pesquisa quanto aos procedimentos

Para Prodanov e Freitas (2013), diferentemente da abordagem, os procedimentos são menos
abstractos, pois são as etapas da investigação. Estão relacionados com os procedimentos técnicos
a serem seguidos pelo pesquisador dentro de uma área de conhecimento. Os métodos escolhidos
determinarão os procedimentos a serem utilizados tanto na colecta de dados quanto na sua
análise. A tabela seguinte descreve os tipos de pesquisa quanto aos procedimentos com base na
explanação de Gil (2002):
67
Tabela 4.14. Classificação da pesquisa sob o ponto de vista dos procedimentos
Tipo de pesquisa Descrição

Experimental Consiste em submeter os objectos de estudo à
influência de certas variáveis em condições
controladas e conhecidas pelo investigador
para observar os resultados que a variável
produz no objecto.
Bibliográfica É um tipo de pesquisa elaborada a partir de
material já publicado (livros, revistas, jornais
entre outros), com vista a colocar o
pesquisador em contacto com todo material já
escrito sobre o assunto da pesquisa.
Documental É um tipo de pesquisa que se assemelha muito
à pesquisa bibliográfica, tendo como principal
diferença a natureza das fontes. Enquanto a
pesquisa bibliográfica baseia-se em
contribuições de vários autores sobre um
determinado assunto, a pesquisa documental
vale-se de material que ainda não foi analisado
ou que ainda pode ser reelaborado de acordo
com os objectos da pesquisa.
Ex-Post Facto Neste tipo de pesquisa o estudo realizado é
feito após a ocorrência de variações na
variável dependente no curso natural dos
acontecimentos. O propósito básico desta
pesquisa é verificar a existência de relações
entre as variáveis.
Levantamento Este tipo de pesquisa caracteriza-se pela
interrogação directa das pessoas cujo
comportamento se deseja conhecer.
Basicamente, faz-se a solicitação de
68
informações a um grupo significativo de

pessoas acerca do problema estudado para que
em seguida sejam obtidas as conclusões
correspondentes aos dados colectados.
Estudo de campo O estudo de campo apresenta muitas
semelhanças com o levantamento. Distingue-
se pelo facto de que o levantamento procura
ser representativo de universo definido e
oferecer resultados caracterizados pela
precisão estatística enquanto o estudo de
campo procura muito mais o aprofundamento
das questões propostas do que a distribuição
das características da população segundo
determinadas variáveis, o que permite uma
maior flexibilidade, abrindo espaço até para a
reformulação dos seus objectivos ao longo da
pesquisa.
Estudo de caso É uma modalidade de pesquisa muito utilizada
nas ciências biomédicas e sociais. Ela consiste
no estudo profundo e exaustivo de um ou
poucos objectos, de maneira que permita o seu
amplo e detalhado conhecimento.
Pesquisa-Acção “É um tipo de pesquisa concebida e realizada
em estreita a associação com uma acção ou
com a resolução de um problema colectivo e
no qual os pesquisadores e participantes
representativos da situação ou do problema
estão envolvidos de modo cooperativo ou
participativo”
69
Quanto aos procedimentos optou-se por adoptar o estudo de campo, dada a necessidade de se
recolherem dados mediante observações e entrevistas e também as pesquisas documental e
bibliográfica de modo a obter informações sobre o histórico do mercado e descrever os métodos
utilizados para efectuar o registo de bancas no passado.
4.2. Instrumentos e procedimentos de recolha de dados

Segundo de Oliveira e Ferreira (2014), ao conhecimento científico constrói-se com base na
realidade e nos factos, ou seja, qualquer problema é identificado e formulado tendo como
referencia a realidade. Do mesmo modo que a solução desse problema deve ser testada e
verificada pelos factos, daí que se torna imprescindível a utilização da recolha de dados no
processo de pesquisa.
Para este projecto, foi utilizada a pesquisa de campo que segundo Marconi e Lakatos (2003),
consiste na observação de factos e fenómenos tal como estes ocorrem espontaneamente, na
colecta de dados a eles referentes e no registo de variáveis que se presumam relevantes para a
pesquisa, de modo a analisá-los.
Para complementar a compreensão do problema a ser estudado e que se pretende resolver,

também foram feitas entrevistas estruturadas aos funcionários da administração do mercado
Xipamanine. Para Marconi e Lakatos (2003), este tipo de entrevista é aquela em que existe um
roteiro previamente estabelecido pelo entrevistador que é seguido sem que haja espaço para
adaptar as perguntas a determinada situação, de alterar a ordem dos tópicos ou de fazer outras
perguntas para além daquelas já estabelecidas.
4.3. Variáveis de investigação

 Tempo;
 Fidelidade;
70
4.4. Metodologias de desenvolvimento de software

A metodologia utilizada no desenvolvimento do projecto foi a prototipação, pois, como
referenciado no capítulo 2, este modelo visa conceber um protótipo funcional do sistema de
modo a ter custos controlados, riscos reduzidos e a possibilidade de realizar validações antes da
implementação. que seja testado logo de início para que os requisitos sejam aprimorados caso
necessário. Este projecto irá passar por todas as fases do desenvolvimento de um protótipo, a
saber: o estabelecimento dos objectivos do protótipo, definição das funcionalidades do protótipo,
desenvolvimento do protótipo e a avaliação do protótipo.
71
CAPÍTULO 5 – APRESENTAÇÃO E ANÁLISE DE RESULTADOS
Após feito o levantamento bibliográfico e a identificação dos problemas encontrados no actual

sistema de registo de bancas do mercado Xipamanine como descritos nos capítulos 2 e 3
respectivamente, e a apresentação das metodologias de resolução dos problemas no capítulo 4,
neste capítulo será mostrada a solução proposta para os problemas referidos, através do
levantamento dos requisitos, apresentação das ferramentas utilizadas na concepção da proposta,
apresentação da arquitectura geral do projecto, das interfaces e do orçamento para a execução do
mesmo. Bem como será feita a análise dos resultados encontrados com a solução proposta.
5.1. Requisitos do sistema

5.1.1. Requisitos funcionais
Tabela 5.15 Requisitos funcionais
Id Função Descrição Actor

RF01 Verificar banca disponível O sistema deve permitir ao Funcionário do
utilizador verificar quais são os mercado
bancas disponíveis no mercado.
RF02 Fazer gestão de O sistema deve permitir ao Funcionário do
vendedores utilizador registar, visualizar, mercado
alterar, remover ou suspender
vendedores.
RF03 Fazer gestão de bancas O sistema deve permitir ao Funcionário do
utilizador registar, visualizar, mercado
alterar e remover bancas ou suas
informações.
RF04 Registar pagamentos O sistema deve permitir ao Funcionário do
diários de taxas utilizador registar os pagamentos mercado
diários das taxas de cada tipo de
72
banca.
RF05 Consulta de pagamentos O sistema deve permitir que se Funcionário do
de taxa faça a consulta dos pagamentos mercado
efectuados pelos ocupantes das
bancas.
RF06 Extrair informação de O sistema deve permitir que se Funcionário do
vendedor extraia toda a informação de um mercado
determinado vendedor
5.1.2. Requisitos não funcionais

Os requisitos não funcionais são definidos na seguinte tabela:
Tabela 5.16 Requisitos não funcionais
Id Requisito Descrição
RNF01 Disponibilidade O sistema deve estar disponível 24 horas por dia, todos o os dias de
modo a garantir um trabalho interrupto ou fora das horas normais de
expediente, caso necessário.
RNF02 Conectividade O sistema deverá estar conectado a internet para que seja possível
operar.
RNF03 Segurança O sistema deve ser capaz de armazenar e proteger os dados nele
contidos.
RNF04 Restrições de O sistema deve restringir o acesso apenas a pessoas autorizadas e
software previamente cadastradas.
RNF05 Complexidade O sistema deve ser intuitivo e fácil de manusear.
73
5.2. Principais diagramas

5.2.1. Diagrama de casos de uso
Figura 5.21 Diagrama de caso de uso do sistema proposto
74
5.2.2. Diagrama de estados das bancas
Figura 5.22 Diagrama de estados das bancas
75
5.2.3. Diagrama de classes
Figura 5.23 Diagrama de classes
5.3. Ferramentas utilizadas

De modo a materializar a concepção do sistema proposto, foram utilizadas as ferramentas
descritas a seguir:
Tabela 5.17 Ferramentas utilizadas
Propósito Ferramenta Versão

Modelação UML Astah Comunity versão 7.2
Desenvolvimento do software Node JS versão 14.15.1
Linguagem de marcação HTML5 5
Template Engine Jade 1.11.1
Ambiente de desenvolvimento Visual Studio code 1.68.0
76
Servidor de base de dados MongoDB 4.2.12

Redacção de documentos Microsoft Word 365
5.4. Arquitectura e funcionamento do sistema

A arquitectura utilizada no sistema é a cliente-servidor de 4 camadas, sendo ela composta pelos
clientes, o serviço de internet, um servidor de aplicação e uma base de dados.
É na camada do cliente onde será exibida a aplicação web, esta que permitirá aos utilizadores
visualizar, criar, editar e remover registos das bancas do mercado.
Através do protocolo TCP/IP os pedidos realizados pelo cliente serão transportados para o
servidor de aplicação, este que será o responsável por efectuar as validações necessárias para que
sejam realizadas as operações desejadas pelo cliente, uma vez que é nele onde estão as regras de
negócio.
O servidor, por sua vez é suportado por uma base de dados que é onde serão persistidas as
informações de bancas, vendedores e utilizadores, de modo a servir ao cliente de acordo com a
necessidade.
Figura 5.24 Arquitectura do projecto
77
5.5. Apresentação das telas
5.6. Estimativas de custo
Para se desenvolver a aplicação web foi necessário antes saber o custo que a mesma acarreta,
para tal foi calculado o esforço e o tempo necessário para o seu desenvolvimento como abordado
no ponto 2.8.5. Foi escolhido o modelo COCOMO intermediário, por permitir calcular o esforço
do desenvolvimento do software, e o modo semidestacado pois o software que se pretende
desenvolver é simples.
5.6.1. Tipos de funções
ALI Elementos Elementos de Complexidade Peso de Pontos de

de Registo Dados Complexidade Função
Não
Ajustados
Funcionario Funcionario Id, nome, telefone, Baixa 7 35

(1) estado,
nomeUtilizador,
senha (7)
Vendedor Vendedor, Id, nome, telefone, Baixa 7

Banca (2) estado, dataRegisto,
dataInicioSuspensa
o (6)
Sector Sector (1) Id, nome, Baixa 7

limitebancas,
dataRegisto,
categoriaProduto
(5)
Banca Banca, Id, dataRegisto, Baixa 7

Sector (2) tipoBanca, estado
78
(4)
Manutenca Manutencao Id, estado, Baixa 7

o , Banca (2) dataInicio, dataFim,
descrição (5)
EE Elementos Elementos de Complexidad Peso de Pontos de

de Registo Dados e Complexidad Função
e Não
Ajustado
s
Adicionar nome, telefone, 15

nomeUtilizador,
Funcionario
senha (4)
Baixa 3
Alterar nome, telefone,
senha (3)
Apagar Id (1)
Vendedor Adicionar nome, telefone (2)
Alterar nome, telefone,

senha (3) Baixa 3
Apagar Id (1)
Sector Adicionar nome, limiteBancas

(2)
Alterar nome, limiteBancas Baixa 3

(2)
Apagar Id (1)
Banca Adicionar tipoBanca (1)
Alterar tipoBanca (1) Baixa 3
Apagar Id (1)
79
Estado, dataInicio,
dataFim, descrição
Manutenca Adicionar
(4)
o Baixa 3
Estado, dataInicio,
dataFim, descrição
Alterar
(4)
CE Elementos Elementos de Complexidad Peso de Pontos de

e Não
Ajustado
s
Funcionario Funcionario Nome, telefone, Baixa 3 15

(1) estado (3)
Utilizador Utilizador Nome, telefone, Baixa 3

(1) estado, dataRegisto
(4)
Sector Sector (1) Nome (1) Baixa 3
Banca Banca (1) tipoBanca, estado Baixa 3

(2)
Manutenca Manutencao Estado (1) Baixa 3

o (1)
SE Elementos Elementos de Complexidad Peso de Pontos de

e Não
Ajustado
s
Sector Relatório Total de bancas, Baixa 4 8
80
total de vendedores
por sector, última
atribuição de banca
(3)
Vendedor Relatório de Total de Baixa 4

vendedores vendedores, total de
vendedores por
estado (2)
Total 73
5.7. Conversão dos pontos de função não ajustados para LOC

HTML = 15, correspondendo a 70% no projecto
Javascript = 71, correspondendo a 30% no projecto
(JS + 0,3 * 71) + (15 + 0,8*15) = 94,2

SLOC
=94,2
UFP
SLOC = 94,2*UFP
SLOC = 94,2*132
SLOC = 12434,4
KLOC = 12,434
5.8. Estimativa de esforço

De modo a calcular a estimativa de esforço para o projecto foi utilizado o modelo intermediário
com o modo semi-destacado tendo como valores para a 1=3 e b 1=1,12.
RELY – Elevado = 1,15
DATA – Baixa = 0,94
PCAP – Normal = 1
LEXP – Normal = 1
MODP – Normal = 1
81
TOOL – Normal = 1,1
FA = 1,15*0,94*1*1*1*1,1=1,891
Deste modo:
b
E=a(KLOC ) F A
E=3 ¿(12,434)1,12 1,891
E=¿95,45 ≈ 95 pessoas-mês
5.9. Estimativa de tempo de desenvolvimento por mês

Os valores de c i=2,5 e d i=0,35 para a estimativa de tempo de desenvolvimento surgem
através da tabela XX
Assim sendo:
d1
D=C 1 E
0,35
D=2,5∗95,45
D=12,33 ≈ 13 meses
5.10. Estimativa do número de pessoas a trabalhar no projecto

E 95,45
N= = =7,95 pessoas ≈ 8 pessoas
D 12
5.11. Custo de desenvolvimento do protótipo

Tabela 5.18. Custo de equipamento do projecto
Item Descrição Quantidade Valor (Mt)
Computador Intel(R) Core (TM) 1 45 000

i5-7500 CPU @
3.40GHz
Servidor de aplicação Licença Node Js 1 Grátis
82
14.15.1
Servidor de base de Licença MongoDB 1 Grátis

dados 4.2.12
Total 45 500
Tabela 5.6 Orçamento de desenvolvimento do projecto
Elemento Descrição Custo unitário Custo total

Internet Provedor: TV 2 200 MZN/mês 2 200
Cabo, 4 Mbps
download / 2
Mbps upload
Analista Responsável por 400 MZN/hora 64 000
modelar o
protótipo
Desenvolvedor Responsável por 300 MZN/hora 48 000
desenvolver o
protótipo
Total
83
CAPÍTULO 6 – CONCLUSÕES E RECOMENDAÇÕES

6.1. Conclusões
O presente projecto foi criado com a finalidade de conceber um sistema de auxílio ao trabalho
diário dos funcionários do mercado Xipamanine. Na busca de uma solução viável, fez-se uma
análise dos dados encontrados no campo, como por exemplo, a forma como são executados os
processos de localização de banca, do registo de bancas e da monitoria das mesmas, tendo-se
constatado que tais tarefas se tornam onerosas para os funcionários por serem executadas de
forma manual e sem procedimentos padronizados.
Através das visitas e entrevistas feitas, como descritas no ponto 4.2, foi possível colectar
informações de modo a transformar as necessidades encontradas no campo em requisitos de
sistema, construir o modelo conceptual do mesmo em diagramas UML e com a utilização de
ferramentas de desenvolvimento de software conceber um sistema funcional para satisfazer tais
necessidades.
Uma vez construído o protótipo do sistema, foi possível testá-lo de modo a identificar possíveis
erros na interface, conexão com a base de dados, se os processos ocorrem como o esperado e a
performance do sistema. Assim sendo, conclui-se que foi possível cumprir com os objectivos
traçados para o projecto, tendo como resultado um protótipo funcional que satisfaz todos os
requisitos necessários para optimizar os processos de registo de banca do mercado Xipamanine,
podendo-se observar as seguintes melhorias:
 Existência de um mecanismo fiável de armazenamento da informação das bancas;

 Criação de uma estrutura padronizada de identificação de bancas;
 Facilidade na obtenção de dados de modo a apoiar a tomada de decisões;
6.2. Limitações de pesquisa

 Dificuldade na obtenção de informações sobre o processo de registo de bancas no
mercado Xipamanine;
 Ausência do mapeamento das bancas do mercado;
 Escassez de fontes bibliográficas relacionadas a história do mercado e dos sistemas de
informação nele utilizados ao longo do tempo;
84
6.3. Recomendações
Com a realização deste projecto tem-se as seguintes recomendações:
 A integração do sistema de registos de bancas do mercado Xipamanine com o sistema de

pagamentos de taxas já existente;
 Implementação do sistema de registo de bancas em outros mercados da cidade de Maputo
e quiçá, do país;
 Adaptar ao sistema ao modelo do sector público.
85
REFERÊNCIAS BIBLIOGRÁFICAS
Aalst, Wil van der, and Kees van Hee. 2009. Gestão de Workflows: Modelos, Métodos e
Sistemas. Coimbra: Imprensa da Universidade de Coimbra.
https://books.google.co.mz/books?id=t-
EKI6KEyrkC&dq=sistemas+de+gestão+de+base+de+dados&hl=pt-
PT&source=gbs_navlinks_s.
Alves, William Pereira. 2018. Análise e Projeto de Sistemas. Edited by Bruno Paoleschi. São
Paulo: Saraiva Educação S.A.
Ang, Joan. 2022. “Cómo Crear Un Diagrama de Actividades [+Ejemplos].” 2022.

https://es.venngage.com/blog/diagrama-de-actividades/.
Bean, Martin. 2015. Laravel 5 Essentials. Birmingham: Packt Publishing.
Cambridge University Press. 2021a. “Record.” 2021.

https://dictionary.cambridge.org/pt/dicionario/ingles/record.
———. 2021b. “Stall.” 2021. https://dictionary.cambridge.org/pt/dicionario/ingles/stall.
Cavalcante, Pablo Henrique Aguiar. 2020. “Spring Framework: O Que é, Seus Módulos e
Exemplos!” 2020.
https://blog.geekhunter.com.br/spring-framework/#O_que_e_o_Spring_Framework.
Converse, Tim, and Park Joyce. 2003. PHP a Bíblia. Edited by Lorenzo Ridolfi. 2a ed. Rio de
Janeiro: Editora Campus. https://books.google.co.mz/books?
id=_xv1frKVlp8C&printsec=frontcover&hl=pt-
PT&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false.
Costa, Carlos J. 2007. Desenvolvimento Para Web. Lisboa: Lusocredito, Lda.

https://books.google.co.mz/books?id=Jn6dTDF-wcsC&printsec=frontcover&hl=pt-
PT#v=onepage&q&f=false.
Creswell, John W. 2002. Projeto de Pesquisa: Métodos Qualitativo, Quantitativo e Misto. Edited
by Artmed Editora S.A. Porto Alegre: Artmed Editora S.A.
Date, C.J. 2005. Introdução a Sistemas de Banco de Dados. Edited by Katherine Harutunian. 8a.
Pearson Education.
86
Gerhardt, Tatiana Engel, and Denise Tolfo Silveira. 2009. Métodos de Pesquisa. Edited by Sara
Viola Rodrigues. Porto Alegre: PLAGEDER. https://books.google.co.mz/books?
id=dRuzRyEIzmkC&printsec=frontcover&dq=metodologia+de+investigação+cientifica+pd
f&hl=pt-PT&sa=X&redir_esc=y#v=onepage&q&f=false.
Gil, Antonio Carlos. 2002. Como Elaborar Projetos de Pesquisa. Edited by Leonardo Hermano.
4a. São Paulo: Editora Atlas S.A.
———. 2008. Métodos e Técnicas de Pesquisa Social. 6th ed. São Paulo: Editora Atlas S.A.
Gomes, Ariane. 2022. “O Que é CSS? Guia Básico Para Iniciantes.” 2022.
https://www.hostinger.com.br/tutoriais/o-que-e-css-guia-basico-de-css.
Henrique, João, Santana Stacciarini, and Laira Cristina. 2016. “O Mercado Informal de Maputo (
Moçambique ) e a Feira de Xipamanine : Entre Curiosidades e Vivências No Continente
Africano.”
House, Digital. 2021. “15 Frameworks Mais Usados Em Programação Que Você Precisa
Conhecer.” 2021. https://www.digitalhouse.com/br/blog/frameworks-mais-usados-em-
programacao.
Lalli, Felipe Micaroni, Franco Felippe Bueno, and Guilherme Kees Zacharias. 2008. “Evolucao
Da Programação Web.” Faculdade Comunitária de Campinas Unidade III.
https://books.google.co.mz/books?id=zJ_a4omO6NkC&printsec=frontcover&hl=pt-
PT&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false.
Laudon, Kenneth, and Jane Laudon. 2011. Sistemas de Informação Gerenciais. Edited by
Brunno Barreto. 9a edição. São Paulo: Pearson Education Brasil.
Luckow, Décio Heinzelmann, and Alexandre Altair de Melo. 2010. Programação Java Para a
Web. Edited by Rubens Prates. São Paulo: Novatec Editora Ltda.
https://books.google.co.mz/books?
id=eROWAwAAQBAJ&printsec=frontcover&dq=linguagem+java&hl=pt-
PT&sa=X&redir_esc=y#v=onepage&q=linguagem java&f=false.
Luís, Andrei. 2021. “O Que É MySQL? Guia Para Iniciantes.” 2021.
Macêdo, Diego. 2012. “Arquitetura de Aplicações Em 2, 3, 4 Ou N Camadas.” 2012.
87
https://www.diegomacedo.com.br/arquitetura-de-aplicacoes-em-2-3-4-ou-n-camadas/.
Marconi, Maria, and Eva Lakatos. 2003. Fundamentos de Metodologia Científica. Editora Atlas
S. A. https://doi.org/10.1590/S1517-97022003000100005.
Mattos, António Carlor M. 2005. Sistemas de Informação. Edited by Rita de Cássia da Silva and
Juliana Rodrigues de Queiroz. 2a Edição. São Paulo: Editora Saraiva.
Meneguim, Fernando B., and Maurício S. Bugarin. 2007. “A Informalidade No Mercado de

Tabalho e o Impacto Das Instituições: Uma Análise Sob a Ótica Da Teoria Dos Jogos.”
MongoDB, Inc. 2021. “What Is NoSQL?” 2021. https://www.mongodb.com/pt-br/nosql-

explained.
Moraes, William Bruno. 2018. Construindo Aplicações Com NodeJS. Edited by Rubens Prates.
2a ed. São Paulo: Novatec Editora Ltda. https://books.google.co.mz/books?
id=H4ViDwAAQBAJ&pg=PA16&dq=node+Js&hl=pt-
PT&sa=X&ved=2ahUKEwiYvPG96rTsAhWMSBUIHb1aAm0Q6AEwAHoECAMQAg#v
=onepage&q=node Js&f=false.
Oliveira, Elizabeth Real de, and Pedro Ferreira. 2014. Métodos de Investigação : Da
Interrogação à Descoberta Científica. Edited by SA Vida Económica - Editorial. Porto:
Vida Económica - Editorial SA. https://books.google.co.mz/books?
id=Xku7BAAAQBAJ&printsec=frontcover&dq=metodos+de+investigacao&hl=pt-
PT&sa=X&redir_esc=y#v=onepage&q=metodos de investigacao&f=false.
Oracle. 2010. “Multitiered Architecture Design.” 2010.
———. 2021. “O Que é Um Banco de Dados Relacional?” 2021.

https://www.oracle.com/br/database/what-is-a-relational-database/.
Paschoal, Leo Nathan. 2016. “Agente Inteligente Sensível Ao Contexto Do Usuário Integrado
Em Um Ambiente Virtual Para Aprendizagem Ubíqua.” 2016.
https://www.researchgate.net/figure/Figura-19-Diagrama-UML-de-casos-de-uso-usuarios-
no-Moodle_fig14_321319242.
Portal São Francisco. 2016. “Dia Do Comércio.” 2016.

https://www.portalsaofrancisco.com.br/calendario-comemorativo/dia-do-comercio.
88
Pressman, Roger S. 2011. Software Engineering: A Practitioner’s Approach, 7th Edition. The
McGraw-Hill Companies, Inc., New York, NY, EUA. 7a ed. Nova York: Companies, The
McGraw-Hill.
Prodanov, Cleber Cristiano, and Ernani Cesar De Freitas. 2013. Metodologia Do Trabalho
Científico: Métodos e Técnicas Da Pesquisa e Do Trabalho Acadêmico. Novo Hamburgo:
Feevale. https://doi.org/10.1017/CBO9781107415324.004.
Ramos, Leonardo. 2020. “O Que é Template Engine?” 2020. https://auditeste.com.br/o-que-e-

template-engine/.
Rangel, Tarcisio Bruni. 2017. “Diagrama de Classes.” 2017.

https://oblogdotarcisio.wordpress.com/2017/10/21/diagrama-de-classes/.
RedHat. 2018. “O Que é API.” 2018.
Ribeiro, Leandro. 2012. “O Que é UML e Diagramas de Caso de Uso: Introdução Prática à
UML.” 2012.
Rod, Johnson, Jürgen Höller, Alef Arendsen, Thomas Risberg, and Colin Sampaleanu. 2007.
Professional Java Development with the Spring Framework. Indianopolis: Wiley
Publishing.
Silva, Edna Lúcia Da, and Estera Muszkat Menezes. 2001. “Metodologia Da Pesquisa e
Elaboração de Dissertação.” Portal 29 (1): 121. https://doi.org/10.1590/S1517-
97022003000100005.
Sommerville, Ian. 2011. Engenharia de Software. Edited by Aline Marques. 9th ed. São Paulo:
Pearson Education.
Sousa, Priscila. 2011. “Conceito de Comércio.” 2011. https://conceito.de/mercado.
Taina, Juha. 2005. “A Brief Introduction to Function Points.”

https://www.cs.helsinki.fi/u/taina/ohtu/fp.html.
Tanenbaum, Andrew S. 2006. Redes de Computadores. IEEE Latin America Transactions. 4th
ed. Vol. 4. Rio de Janeiro: Editora Campus. https://doi.org/10.1109/TLA.2006.1642455.
UCCLA. 2015. “No Title.” 2015. https://www.uccla.pt/membro/maputo.
89
Vanazzi, Fabrício. 2017. “Diagramas Comportamentais Da UML: Diagrama de Estados.” 2017.

https://micreiros.com/diagramas-comportamentais-da-uml-diagrama-de-estados/.
Ventura, Plínio. 2016. “Entendendo o Diagrama de Atividades Da UML.” 2016.
90

Concepção de Um Sistema para Gestão Dos Registos de Ocupação de Bancas No Mercado Xipamanine

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Concepção de Um Sistema para Gestão Dos Registos de Ocupação de Bancas No Mercado Xipamanine

Enviado por

Direitos autorais:

Formatos disponíveis

INSTITUTO SUPERIOR DE TRANSPORTES E COMUNICAÇÕES

CONCEPÇÃO DE UM SISTEMA PARA GESTÃO DOS REGISTOS DE

Ângelo Mussa Massache Júnior

Projecto Final do Curso

Licenciatura em Engenharia Informática e Telecomunicações

Eng.º. Helton Luís General

Departamento de Tecnologias de Informação

CONCEPÇÃO DE UM SISTEMA PARA GESTÃO DOS REGISTOS DE

Ângelo Mussa Massache Júnior

Projecto Final do Curso

Eng.º. Helton Luís General

Departamento de Tecnologias de Informação

lista das abreviaturas utilizadas....................................................................................................VII

2.1. Antecedentes do objecto e do problema de investigação..................................................6

3.1. Caracterização sócio – histórica, geográfica, política do objecto de investigação.............43

3.1.3. Mercado Xipamanine...............................................................................................44

4.1. Tipo de pesquisa..............................................................................................................50

5.1. Requisitos do sistema......................................................................................................57

6.2. Limitações de pesquisa...................................................................................................65

Ângelo Mussa Massache Júnior

LISTA DAS ABREVIATURAS UTILIZADAS

JSON Javascript Object Notation

TOOL Use of Software Tools

1.3. Problema de estudo

1.4. Objecto de estudo

1.5.2. Objectivos específicos

 Construir o modelo conceptual do sistema em causa;

1.6. Perguntas de investigação

1.7. A importância ou razões que motivam o trabalho

O desenvolvimento de um sistema de gestão para o registo de bancas visa armazenar os dados

1.8. Estrutura do trabalho

 Capítulo 2 – Revisão da literatura

 Capítulo 3 – Contextualização da Investigação

 Capítulo 4 – Metodologia de Resolução do Problema

 Capítulo 5 – Apresentação e Análise dos Resultados

É neste capítulo onde são apresentados os resultados obtidos na investigação, a apresentação da

 Capítulo 6 – Conclusões e Recomendações

Este capítulo é reservado para as conclusões obtidas na investigação e recomendações para

CAPÍTULO 2 – REVISÃO DA LITERATURA

2.1. Antecedentes do objecto e do problema de investigação

Esta aplicação possui as seguintes funcionalidades:

 Registo de fornecedores online;

 Exibição de mapas interactivos do mercado;

 Serviço de e-mail (para fornecedores ou um grupo específico);

 Administração de licenças aos vendedores; e

Figura 2.1 Logotipo do Manage My Market

Fonte: (Manage My Market 2020)

O Tô Legal é um sistema de gestão online para a o cadastro e autorização temporária de até 90

Figura 2.2 Logotipo do Tô Legal

Fonte: (Prefeitura de São Paulo 2020)

2.1.2. Comparação dos sistemas apresentados

Tabela 2.1 Comparação entre Manage My Market e Tô Legal

Manage My Market Tô Legal

 A utilização deste sistema só é possível no território brasileiro, mais especificamente na

2.2. Conceitos básicos da investigação

 Comércio formal: é aquele legalmente estabelecido, realizado sob licenciamento e

 Comércio informal: para (Meneguim e Bugarin 2007) é o comércio praticado sem o

2.3. Teorias principais da investigação

 Inputs: Envolve a captação de elementos, dados e informações que serão processados

 Processamento: Envolve os processos de transformação dos elementos colectados em

 Outputs: Envolve a transferência, dos elementos produzidos durante o processamento,

Figura 2.3 Elementos básicos de um sistema

Fonte: (Wakulicz 2016)