UNIVERSIDADE METODISTA UNIDA DEMOCAMBIQUE

CAMPUS UNIVERSITÁRIO DE CAMBINE

Tonésia Da Gloria Cumbi

Licenciatura em Engenharia Informática e Tecnologias

Desenvolvimento de Software

Cambine, Maio de 2022

UNIVERSIDADE METODISTA UNIDA DE MOCAMBIQUE

CAMPUS UNIVERSITÁRIO DE CAMBINE

Tonésia Da Gloria Cumbi

Licenciatura em Engenharia Informática e Tecnologias

Desenvolvimento de Software
SISTEMA DE GESTÃO DE ENCOMENDAS DA PIZZA HOME

Trabalho a ser apresentado na faculdade

de engenharia com fins de avaliação na
unidade curricular de Desenvolvimento de
Sistema

O docente: Engº. Alé Júnior

Cambine, Maio de 2022

Conteúdos
Lista de figuras ................................................................................ 4
Introdução ..................................................................................... 5
Objectivos ..................................................................................... 5
Metodologias .................................................................................. 6
Descrição da empresa ........................................................................ 6
Identificação da necessidade ............................................................... 6
Motivação ...................................................................................... 7
Levantamento e análise de requisitos ..................................................... 8
Requisitos Funcionais ........................................................................ 9
Requisitos não funcionais .................................................................... 9
Diagrama de Caso de uso ................................................................... 10
Descrição de Casos de uso .................................................................. 11
Diagrama de classe .......................................................................... 16
Diagrama de Sequência ..................................................................... 17
Diagrama de Actividades ................................................................... 19
Base de dados ................................................................................ 21
Conclusão ..................................................................................... 22
Referencias Bibliográficas .................................................................. 23
 Lista de figuras

Figura 1 diagrama de caso de uso do sistema ...................................................... 10

Figura 2 Diagrama de classes do sistema em projecção .......................................... 16
Figura 3 Diagrama de sequência para o registo .................................................... 17
Figura 4 Diagrama de Sequência para pedido de encomenda ................................... 18
Figura 5 Actividade fazer login ....................................................................... 19
Figura 6 Actividade Realizar registo. Fonte: autora (2022) ...................................... 20
Figura 7 Estrutura da Base de Dados ................................................................ 21
 5

Introdução
Actualmente é indispensável o uso de um Sistema de Informação para apoio nas
diferentes áreas de trabalho. Tem-se verificado visivelmente o crescimento do
mercado de consumo e consequentemente o aumento de empresas de vendas
actuantes em diferentes ramos.

Levando em consideração esse crescimento, a necessidade de organização e

automatização e pela experiência de longos anos de empresas de vendas torna-se
necessário o desenvolvimento de um sistema que venha em auxílio das empresas
nos diferentes sectores, ajudando-as na sua organização, facilitando o processo de
vendas e oferecendo um serviço de qualidade que fidelize o cliente e a faça uma
empresa destaque.

O presente trabalho apresenta a proposta para o desenvolvimento de um sistema

de vendas para uma empresa de vendas, realizando estudos dos aspectos
necessários para o seu desenvolvimento. O sistema será utilizado por uma
entidade que vende produtos alimentícios preparados e lanches.

Objectivos
Geral

Desenhar um sistema de gestão de estoque para a empresa Pizza Home

visando auxiliá-la no processo de encomendas.

Específicos

Fazer o estudo dos conceitos de modelagem de sistema e de engenharia de

software;

Estudar os conceitos de levantamento e análise de requisitos;

Estudar a actual realidade da empresa;

Fazer a análise de requisitos do sistema;
Fazer a modelagem do sistema.
 6

Metodologias
Para a realização deste projecto, o estudo de campo auxiliado por entrevistas e
questionários foi usado como técnica de recolha de dados. Foi realizado o
levantamento de requisitos junto à proprietários da pizzaria através da técnica
deentrevista, tendo presente os aspectos descritos e os objectivos que a mesma
tem em relação ao sistema. O sistema irá auxiliar no processo de execução de
encomendas pelos clientes e no registo de vendas.

Descrição da empresa
A Pizza Home é uma empresa que foi criada a 3 anos para fornecimento de
lanches, salgados e doces. Esta empresa acentua-se mais na venda de pizza e
hambúrgueres.

Esta empresa mantém uma margem competitiva por meio de entrega imediata
de produtos, de excelentes relações com os clientes e de sua capacidade de se
adequar às necessidades deste. Está instalada na vila de Massinga no bairro 21 de
Abril na avenida acordos de Lusaka. Conta com dez (10) funcionários dos quais
três entregadores de encomendas dois técnicos de vendas que trabalham de
forma intercalada por conta da situação actual da pandemia da covid-19. Duas
cozinheiras que preparam os lanches, e dois empregados de mesa e tem um
gestor que lida com a administração do estabelecimento.

Identificação da necessidade
A Pizza Home, está interessada em satisfazer a demanda crescente por seus
produtos com implementação de soluções informáticas, os quais possibilitarão
melhor e maior produtividade, diminuição de custos e redução do tempo de
processo. Assim, esta precisa de uma solução que ajude na gestão de
encomendas e registo de vendas.
 7

Motivação
Actualmente o mercado de consumo vem tendo um crescimento elevado e faz-se
necessário, para todos, a utilização do comércio para a aquisição de alguma
mercadoria, independente do género. Para tal, são escolhidas empresas de
confiabilidade, com bom atendimento e que transmitam segurança e
competência em seus serviços. Levando em consideração estas dificuldades
enfrentadas pelas empresas que utilizam sistemas de informação, torna-se
importante o estudo de estratégias de desenvolvimento e de tecnologias de
engenharia de software. Este estudo tem como objectivo contribuir para o
desenvolvimento de sistemas que auxiliem na solução e redução dos problemas
enfrentados pelas empresas que actuam no ramo da restauração no atendimento
ao cliente durante os processos de venda e encomenda de produtos por parte de
clientes.
 8

Levantamento e análise de requisitos

O levantamento de requisitos (também chamado elicitação de requisitos) combina
elementos de resolução de problemas, elaboração, negociação e especificação.
Para encorajar uma abordagem colaborativa e orientada às equipes em relação ao
levantamento de requisitos, os interessados trabalham juntos para identificar o
problema, propor elementos da solução, negociar diferentes abordagens e
especificar um conjunto preliminar de requisitos da solução. Por outro lado os
requisitos de um sistema são as descrições do que o sistema deve fazer, os
serviços que oferece e as restrições a seu funcionamento.

Os requisitos precisam ser escritos de modo que vários contratantes possam

concorrer pelo contrato e oferecer diferentes maneiras de atender às
necessidades da organização do cliente. Uma vez que o contrato tenha sido
adjudicado, o contratante deve escrever para o cliente uma definição mais
detalhada do sistema, para que este entenda e possa validar o que o software fará.
Ambos os documentos podem ser chamados documentos de requisitos de sistema.
Alguns dos problemas que surgem durante o processo de engenharia de requisitos
são as falhas em não fazer uma clara separação entre esses diferentes níveis de
descrição. Faço uma distinção entre eles usando o termo 'requisitos de usuário',
para expressar os requisitos abstractos de alto nível, e 'requisitos de sistema',
para expressar a descrição detalhada do que o sistema deve fazer. Requisitos de
usuário e requisitos de sistema podem ser definidos como segue (Sommerville,
2011, p.58):
1. Requisitos de usuário são declarações, em uma linguagem natural com
diagramas, de quais serviços o sistema deverá fornecer a seus usuários e as
restrições com as quais este deve
operar.
2. Requisitos de sistema são descrições mais detalhadas das funções, serviços e
restrições operacionais do sistema de software. O documento de requisitos do
sistema (às vezes, chamado especificação funcional) deve definir exactamente o
que deve ser implementado. Pode ser parte do contrato entre o comprador do
sistema e os desenvolvedores de software.
 9

Requisitos Funcionais
Os requisitos funcionais de um sistema descrevem o que ele deve fazer. Eles
dependem do tipo de software a ser desenvolvido, de quem são seus possíveis
usuários e da abordagem geral adoptada pela organização ao escrever os
requisitos. Esta actividade de colecta de informações e das necessidades e
funcionalidades que o sistema deverá possuir foram realizadas através de
entrevista com o cliente interessado no projecto e foram identificados os
seguintes requisitos funcionais:

i. Permitir fazer registo de clientes;

ii. Permitir registar vendas;
iii. Possibilitar listar encomendas;
iv. Permitir registar usuários.

Conforme diz Sommerville (2011, p.59), os requisitos não funcionais, como o

nome sugere, são requisitos que não estão directamente relacionados com os
serviços específicos oferecidos pelo sistema a seus usuários. Eles podem estar
relacionados às propriedades emergentes do sistema, como confiabilidade, tempo
de resposta e ocupação de área. Uma alternativa a esse cenário seria os requisitos
definirem restrições sobre a implementação do sistema, como as capacidades dos
dispositivos de E/S ou as representações de dados usadas nas interfaces com
outros sistemas.

Requisitos não funcionais

No que tange aos requisitos não funcionais para o sistema em alusão, foram
identificados os seguintes requisitos:

i. Portabilidade: O sistema deve permitir sua execução de maneira

transparente para o usuário em plataformas web.
ii. Mobilidade: Permitir a utilização em browsers.
iii. Usabilidade: Possuir uma interface limpa e de fácil compreensão.
iv. Desempenho: A aplicação deve ser extremamente leve, permitindo
sua execução em situações limitantes como: internet lenta e browsers
de versões antigas e novas versões.
 10

Diagrama de Caso de uso

Para Booch et all (2005), os casos de uso são uma técnica para captar os requisitos
funcionais de um sistema. Eles servem para descrever as interacções típicas entre
os usuários de um sistema e o próprio sistema, fornecendo uma narrativa sobre
como o sistema é utilizado.

Um diagrama de casos de utilização descreve a relação entre atores e casos de

utilização de um dado sistema. Este é um diagrama que permite dar uma visão
global e de alto nível do sistema, sendo fundamental a definição correcta da sua
fronteira (Silva & Videira, 2001 p.124). De forma geral, a construção desse
diagrama envolve os seguintes componentes: casos de uso, atores e
relacionamento entre eles.O diagrama abaixo foi concebido para o sistema que vai
beneficiar a Pizza Home, o qual descre a interacção entre o cliente com o sistema
assim como o gestor e o caixa com o sistema.

Figura 1 diagrama de caso de uso do sistema

Fonte: Autora (2022).

 11

Descrição de Casos de uso

Caso de Uso Fazer Login
Nome do caso de uso Fazer login

Actor principal Cliente, caixa e Gestor

Actores Secundários

Resumo Este caso de uso descreve o processo de

login de um usuário no sistema.

Pré-condições Conexão à Internet

Pós-condições Login efetuado/Login não efectuado

Fluxo principal

Acções do actor Acções do sistema

1. Informar seu correio electrónico e

senha

2. Consultar a base de dados remoto a

existência deste correio electrónico e a
senha

3. Se o usuário existir ou seja se estiver

cadastrado na base de dados, é
autorizado o acesso ao aplicativo. Caso
o usuário ou senha estiverem errados é
emitida uma mensagem de erro.

Restrições/Validações/Regras de 1. O usuário precisa ter um cadastro na

Negócio base de dados.

Fluxo Alternativo

Acções do ator Acções do sistema

1. Executar o caso de uso fazer

cadastrar cliente.

Estrutura de Dados

1 - E-mail;
2 - Senha
Fonte: Autora (2022).
 12

Caso de uso Cadastrar usuário

Nome do caso de uso Fazer Cadastro do cliente

Actor principal Cliente

Actores Secundários

Resumo Este caso de uso descreve o processo de

registo de um usuário no sistema.

Pré-condições Conexão à Internet

Pós-condições Registado ou não

Fluxo principal

Acções do actor Acções do Sistema

1. Solicitar a criação de um
novo usuário.

2. Apresentar uma tela de

preenchimento de dados de cadastro.

3. Preencher o formulário da tela com

os dados solicitados

4. Registar usuário na base de dados

Restrições/Validações/Regras de 1. Não haver outro usuário com mesmo

Negócio e-mail.
2. A senha ter pelo menos oito
caracteres;
3. O e-mail tem de ter o formato certo.

Estrutura de Dados

1 - Nome;
2 - Senha;
3 – Correio
electrónico;
4 – Telefone;
5 – Endereço.

Fonte: Autora (2022).

 13

Caso de uso Consultar cliente;

Nome do caso de uso Pesquisar Propriedade

Actor principal Gestor

Actores Secundários

Resumo Este caso de uso descreve o processo de

pesquisa de um cliente no sistema.

Pré-condições Conexão à Internet

Pós-condições

Fluxo principal

Acções do actor Ações do sistema

1. Clicar na caixa de pesquisa a partir

da página inicial.

2. Deixar o cursor na janela de pesquisa

3.Escrever o nome do cliente que

pretende pesquisar

4. Retornar os a lista de clientes caso

existam e no caso contrário emitir
mensagem “Nenhum resultado para a
pesquisa”.

Restrições/Validações/Regras de
Negócio

Estrutura de Dados

Fonte: Autora (2022).

 14

Caso de uso Registar venda

Nome do caso de uso Pesquisar Propriedade

Actor principal Caixa

Actores Secundários

Resumo Este caso de uso descreve o processo de

registo de uma venda no sistema.

Pré-condições Login efectuado

Pós-condições Venda Registada com sucesso

Fluxo principal

Acções do actor Ações do sistema

1. Solicitar o registo de venda a partir

do menu.

2. Apresentar uma tela de

preenchimento de dados de registo de
vendas.

3. Preencher o formulário da tela com

os dados solicitados

6. Registar a venda na base de dados e

apresentar a tela com vendas
previamente registadas.

Restrições/Validações/Regras de
Negócio

Estrutura de Dados

1 - Ordem
2 - Cliente;
3 - Produto;
4 - Quantidade;
5 - Preço

Fonte: Autora (2022).

 15

Caso de uso Fazer Encomenda

Nome do caso de uso Fazer encomenda

Actor principal Cliente

Actores Secundários

Resumo Este caso de uso descreve o processo de

pedidos de encomendas no sistema.

Pré-condições Login efectuado

Pós-condições Pedido realizado

Fluxo principal

Acções do actor Acções do sistema

1. Solicitar a envio de reserva a

partir do menu de navegação na
página.

2. Apresentar uma tela de preenchimento

de dados de pedido de encomenda.

3. Preencher o formulário da tela

com os dados solicitados

4. Gravar o pedido na base de dados.

Restrições/Validações/Regras de
Negócio

Estrutura de Dados

1 - Cliente;
2 - Produto;
3 - Preço
4 – Taxa de entrega;
5 – Subtotal.

Fonte: Autora (2022).

 16

Diagrama de classe
O diagrama de classes é utilizado na construção do modelo de classes desde o
nível de análise até o nível de
especificação. Na óptica de Nunes e O’Neill (2003) diagrama de classes
tem como objetivo suportar os requisitos funcionais do sistema, que foram
levantados previamente. Assim, o diagrama de classes é um resultado da análise
de requisitos, fornecendo um modelo que mais tarde será utilizado na fase de
desenho para a definição dos componentes da aplicação. Um diagrama de classes
é composto pelos elementos mencionado a seguir: Classes. Relações de
associação e multiplicidade. Para o caso deste sistema, foi desenvolvido um
diagrama de classes como ilustra a figura que se seque.

Figura 2 Diagrama de classes do sistema em projecção

Fonte: Autora (2022).

 17

Diagrama de Sequência
Um diagrama de sequência descreve a maneira como os grupos de objectos
colaboram em algum comportamento ao longo do tempo. Ele registra o
comportamento de um único caso de uso e exibe os objectos e as mensagens
passadas entre esses objectos no caso de uso.

Diagrama de Sequência é uma das ferramentas UML usadas para representar

interacções entre objectos de um cenário, realizadas através de operações ou
métodos (procedimentos ou funções). Este diagrama é construído a partir do
diagrama de caso de uso. Primeiro, define-se qual o papel do sistema (Use Cases),
depois, é definido como o software realizará seu papel (Sequência de
operações).

Este tipo de diagrama dá ênfase a ordenação temporal em que as mensagens são

trocadas entre os objectos de um sistema. Entende-se por mensagens os serviços
solicitados de um objecto a outro, e as respostas desenvolvidas para as
solicitações.

Para o sistema em desenho, o usuário irá seguir a sequência representada na

ilustração a seguir para fazer o registo:

Figura 3 Diagrama de sequência para o registo

Fonte: Autora (Adaptado com software glify em www.go.glify.com)

 18

Para que um cliente consiga fazer um pedido/reserva para uma encomenda é

preciso que este esteja registado no sistema e com sessão iniciada. Ele precisa
informar ao sistema o produto que precisa a quantidade e o sistema irá processar
estas informações e ele poderá fazer os devidos pagamentos de modo a empresa
consiga fazer a entrega ao cliente. O diagrama a seguir ilustra a practicidade
deste trecho escrito.

Figura 4 Diagrama de Sequência para pedido de encomenda

Fonte: Autora (Adaptado com software glify em www.go.glify.com).

 19

Diagrama de Actividades
Um diagrama de actividades conforme Silva & Videira (2001, p.222) é um caso
particular de um diagrama de estados, no qual todos ou a maioria dos estados
são “estados de actividades” e todas ou a maioria das transições são
desencadeadas pela conclusão das actividades dos estados anteriores. Afirmam
ainda que ambos os tipos de diagramas são utilizados para modelar o tempo de
vida de um objecto ou sistema. Contudo, um diagrama de actividades ilustra o
fluxo de controlo entre actividades, enquanto um diagrama de estados ilustra o
fluxo de controlo entre estados. Por outro lado, os diagramas de interacção
ilustram fluxos de controlo entre objectos. Enquanto nos diagramas de
interacção o foco é na visualização das mensagens trocadas entre objectos, nos
diagramas de actividades a atenção incide na visualização das operações
realizadas pelos objectos intervenientes.

Figura 5 Actividade fazer login

Fonte: Autora (2022).

 20

Para o processo de registo de usuário, temo o diagrama s seguir que mostra

de forma sucinta as actividades que o usuário irá fazer para efectivar o seu
registo.

Figura 6 Actividade Realizar registo. Fonte: autora (2022)

 21

Base de dados
Bases de dados são conjuntos de arquivos relacionados entre si com registos sobre
pessoas, lugares ou coisas. São colecções organizadas de dados que se relacionam
de forma a criar algum sentido (informação) e dar mais eficiência durante uma
pesquisa ou estudo científico. São de vital importância para empresas e, há mais
de duas décadas, se tornaram a principal peça dos sistemas de informação e
segurança. Normalmente existem por vários anos sem alterações em sua estrutura
sistemática.

Os bancos de dados são operados pelos Sistemas Gerenciadores de Bancos de

Dados (SGBD), que surgiram na década de 70. Antes destes, as aplicações usavam
sistemas de arquivos do sistema operacional para armazenar suas informações. Na
década de 80, a tecnologia de SGBD relacional passou a dominar o mercado, e
actualmente é utilizada em praticamente todos os bancos de dados. Outro tipo
notável é o SGBD Orientado a Objectos, implementado em bancos de dados com
estruturas complexas ou aplicações que mudam constantemente.

A principal aplicação de Banco de Dados é controlo de operações empresariais.

Outra aplicação também importante é gerenciamento de informações de estudos,
como fazem os Bancos de Dados Geográficos, que unem informações
convencionais a espaciais.

O diagrama a seguir ilustra a estrutura da base de dados do sistema proposto para

a Pizza Home.

Figura 7 Estrutura da Base de Dados

 22

Conclusão
Para chegar a conclusão do sistema proposto neste trabalho foi necessário passar
por vários estágios e cada um era uma peça do quebra-cabeça que se encaixava e
dava forma ao trabalho em questão. Cada fase era uma etapa importante desse
desenvolvimento e contribuiu para o amadurecimento do objectivo inicial. O
trabalho exigiu disciplina e estudo aprofundado em cada etapa que se iniciava e
concluía, pois a mal formação da estrutura poderia comprometer toda projecção
e desenho. Além do estudo da engenharia de software, foi necessário aprofundar
e não medir esforços para o colhimento de requisitos junto à empresa solicitante
do sistema, para que o mesmo pudesse atender sua necessidade e lhe
proporcionar o objectivo esperado. Como resultado desenhou-se e projectou-se
ferramenta de apoio à gestão de encomendas e de ajuda no controle dos vários
segmentos da pizzaria Pizza Home como: caixa, estoque, produtos, entre outros.

Espera-se que numa outra oportunidade, conclua-se com a implementação e a

posterior implantação do sistema na empresa solicitante.
 23

Referencias Bibliográficas
Bezerra, E. (2015). Princípios de Análise de projectos de sistemas com UML.
São Paulo: Elsevier
Booch, G., Rumbaugh, J., & Jocobson, I. (2012). UML - Guia do Usuário. Rio
de Janeiro: Campus.
Nunes, M., & O'Neill, H. (2011). Fundamental de UML. Lisboa: FCA –
Editora Informática.

Silva, A. M. R. & Videira, C.A. E. (2001). UML, Metodologias e Ferramentas

CASE: Linguagem de Modelação UML, Metodologias e Ferramentas CASE na
Concepção e Desenvolvimento de Software. Portugal: Centro Antlantico Lda.