Documentação do Sistema de gestão e agendamento de oficina

auto SOMAIS
Versão 0.1

Autora: Sheila Ferrão Chaúque

Índice
1. Prefácio ........................................................................................................... 1
2. Introdução ao documento ............................................................................ 2
2.1. Tema ..................................................................................................................... 2
2.2. Objectivo do Projecto ............................................................................................ 2
2.3. Delimitação do Problema ...................................................................................... 2
2.4. Método de Trabalho ............................................................................................. 3
3. Descrição Geral do Sistema......................................................................... 4
3.1. Descrição do Problema .......................................................................................... 5
3.2. Principais envolvidos e suas Características ........................................................... 5
3.2.1. Usuários do Sistema ........................................................................................................ 5
3.2.2. Desenvolvedores do Sistema .......................................................................................... 5
3.3. Regras de Negócio ................................................................................................. 5
3.3.1. Restrições de negócio ..................................................................................................... 5
3.3.2. Restrições de desempenho ............................................................................................. 5
3.4. Requisitos do Sistema ........................................................................................... 6
3.4.1. Requisitos Funcionais ...................................................................................................... 6
3.4.2. Requisitos Não-Funcionais .............................................................................................. 7
4. Arquitetura do Sistema ................................................................................. 8
5. Modelo do Domínio ....................................................................................... 8
6. Diagramas de Interação ................................................................................ 9
6.1. Diagrama de Sequência ......................................................................................... 9
7. Modelo de Dados ......................................................................................... 11
7.1. Modelo Lógico da Base de Dados ........................................................................ 11
7.2. Criação Física do Modelo de Dados ..................................................................... 11
7.3. Dicionário de Dados ............................................................................................ 18
8. Ambiente de Desenvolvimento.................................................................. 21
9. Sistemas e componentes externos utilizados ........................................ 22
10. Implementação ......................................................................................... 22
2.7.1. Interface da aplicação sistema Web ............................................................................. 25
2.7.2. Implantação .................................................................................................................. 27

11. Conclusões e considerações finais ...................................................... 28

 1

1. Prefácio
O objectivo deste documento é fornecer uma descrição do desenvolvimento do
software da SOMAIS utilizando os princípios da engenharia de software
orientada à objectos com notação UML (Unified Modeling Language).
Sugestões e Comentários podem ser enviados para
sheilachauque07@gmail.com.
 2

2. Introdução ao documento
2.1. Tema
Documentação do Sistema de gestão e agendamento da oficina auto SOMAIS
2.2. Objectivo do Projecto
• Identificar os requisitos essências da plataforma a ser concebida;
• Indicar a melhor plataforma eficaz na gestão de informação na oficina
Somais;
• Compor mecanismos que podem melhorar a gestão dos dados da oficina
Somais;
• Implementar mecanismos de agendamento de serviços.
2.3. Delimitação do Problema
A Somais.lda é uma organização que tem como missão oferecer serviços de
manutenção e limpeza de veículos automóveis, e tem como objectivos oferecer
serviços inovadores, contribuir para eficácia das actividades dos seus clientes
com preços competitivos e com um atendimento virado a satisfação dos clientes.
Tem como visão ser referência no país na prestação de serviços de manutenção
e limpeza de veículos automóveis, de qualidade e excelência, funcionando com
uma equipa técnica com altos conhecimentos em todas áreas de sua
intervenção.
Quando o cliente chega na Somais é atendido pelos técnicos, onde ele expõe
que tipo de serviço precisa entre limpeza do seu automóvel e ou reparação do
mesmo.
Em caso de reparação, o técnico atendente, faz o diagnostico e estabelece o
preço do serviço, e após o pagamento que o cliente efectua ao técnico, este por
sua vez reporta o trabalho por ele feito e entrega o valor pago ao gestor, em caso
de lavagem, o atendente informa o preço ao cliente, e efectua o trabalho após o
pagamento e depois entrega o valor ao gestor.
Por sua vez o gestor faz o registo das actividades em planilhas “Microsoft Excel”
separadas, nomeadamente uma planilha para o fluxo de caixa, uma para os
dados dos clientes particulares e empresas com contrato, uma planilha para
despesas diárias com materiais consumíveis, uma planilha que contem os
serviços prestados e os respectivos preços e mais uma planilha para registar as
transações bancárias tais como depositos e levantamentos.
 3

O cliente é sempre informado os preços de cada serviço efectuado pelo

funcionário que lhe atende, havendo possibilidade de este alterar os preços à
seu favor individual, dificultando a integridade da gestão das actividades,
ferramentas e materiais consumíveis envolvidos no trabalho diário da
organização
Por outro lado, os dados que o gestor recebe dos funcionários operacionais, não
têm nenhuma garantia da sua veracidade, e são de difícil validação.
Em períodos semanais a Somais elabora estatísticas com base nos registos nas
planilhas “Microsoft Excel”, balançando a semana com base nas receitas,
dividas, despesas e recebimentos, no entanto esse modelo tem dificultado a sua
elaboração em tempo util.

2.4. Método de Trabalho

O método utilizado para a realização do trabalho foi Metodologia Agil de
Desenvolvimento.
O desenvolvimento tradicional muitas vezes não atende às peculiaridades de
desenvolvimento web. Desta forma, são buscadas novas abordagens de
desenvolvimento, buscando uma maior agilidade na entrega do produto e,
também, a inclusão destes novos papéis e actividades no processo.
Conforme descrito por Murugesan et al. (2001), falta rigor, abordagem sistêmica,
controle de qualidade e garantia aos métodos utilizados para desenvolvimento
de aplicações web. Deste problema, surge a necessidade de uma nova
abordagem para disciplinar e introduzir novos métodos e ferramentas para o
desenvolvimento, validação e implantação de sistemas web.
Esta nova área pode ser chamada de Engenharia Web, definida por Pressman
e Lowe (2009), como uma proposta de um ágil, porém disciplinado framework
para produção de aplicações web. Este framework seria composto pelas
seguintes actividades:
1) Comunicação: Envolve a interação e colaboração do cliente e interessados e
engloba a coleta de requisitos e outras atividades relacionadas;
2) Planeamento: Estabelece um plano incremental para o trabalho. Ele descreve
como as ações irão ocorrer, como serão conduzidas as tarefas técnicas, os
riscos associados, os recursos que serão necessários, os produtos que serão
produzidos e o cronograma de trabalho;
 4

3) Modelagem: Engloba a criação dos modelos que ajudarão o desenvolvedor e

o cliente a entender melhor os requisitos e o projecto da aplicação;
4) Construção: Combina a geração do código-fonte, junto com os testes para
verificar erros na aplicação;
5) Implantação: Realiza a entrega do incremento da aplicação para os clientes
que validarão e providenciarão um feedback deste processo.
Para Kumar e Sangwan (2011), são os atributos da aplicação que definem o
processo a ser utilizado. Se imediatismo e contínua evolução são atributos
primários, deve ser utilizado um processo ágil. Caso o produto seja
desenvolvido durante um longo período, um processo incremental deve ser
utilizado. Para pequenos projetos, uma cascata tradicional pode ser utilizada,
porém para projetos grandes e complexos, o processo em espiral pode ser mais
apropriado.
Pressman e Lowe (2009) listam as melhores práticas para o desenvolvimento de
aplicações web:
1) O tempo deve ser utilizado para entender o objectivo do produto e sua
necessidade de negócio;
2) A interação dos usuários com a aplicação deve ser descrita por meio de
cenários;
3) Um plano de projecto deve ser desenvolvido, mesmo que breve;
4) Deve ser realizada modelagem de pontos mais obscuros do projecto;
5) Os modelos devem ser revistos quanto à consistência e qualidade;
6) A tecnologia deve permitir que os componentes utilizados para a construção
devem ser reutilizados quantas vezes forem possíveis;
7) Utilizar design patterns desenvolvidos para reutilização de componentes;
8) Os testes devem ser criteriosos antes da liberação para implantação.

3. Descrição Geral do Sistema

Este documento tem por finalidade colectar, analisar e definir necessidade e
características gerais da aplicação. Concentra-se nas necessidades apontadas
pelos usuários, nas razões que levam a essas necessidades e como elas serão
atendidas pelo sistema. O escopo deste documento se limita a fornecer a todas
partes interessadas no projecto uma descrição compreensível das
 5

funcionalidades que serão atendidas no projecto. Quando necessário este

documento pode ser actualizado durante o ciclo de desenvolvimento da solução.
3.1. Descrição do Problema
Neste item deve ser descrito o problema que será resolvido com o
desenvolvimento do sistema. As
questões a seguir devem ser respondidas.
! Quem é afetado pelo sistema?
! Qual é o impacto do sistema?
! Qual seria uma boa solução para o problema?
3.2. Principais envolvidos e suas Características
3.2.1. Usuários do Sistema
Funcionários da SOMAIS
• Usuário normal: responsável por registar atendimentos, gastos,
recebimentos, agendamentos, recebimentos,
• Usuário administrador
Clientes da SOMAIS
Terão acesso a aplicação mobile, onde poderão visualizar os serviços, e agendar
atendimento.
3.2.2. Desenvolvedores do Sistema
Sheila Ferrão Chaúque
- Analista de sistema;
- Desenvolvedora;
- Testadora.
3.3. Regras de Negócio
3.3.1. Restrições de negócio
• O registro de atendimentos só deve ser efectuado por funcionários da
SOMAIS;
3.3.2. Restrições de desempenho
• A aplicação deve funcionar online e em tempo real
• tolerância à falhas
• volume de informação a ser armazenada
• estimativa de crescimento de volume ferramentas de apoio
 6

3.4. Requisitos do Sistema

3.4.1. Requisitos Funcionais
São declarações de serviços que o sistema deve fornecer, de como o sistema
deve reagir a entradas específicas e de como o sistema deve se comportar em
determinadas situações. Em alguns casos, os requisitos funcionais também
podem explicitar o que o sistema não deve fazer.
A tabela a seguir contém os requisitos funcionais do sistema.
Identificador Descrição Prioridade Depende
de
Clientes
RF001 Criar conta na aplicação Alta -
RF002 Iniciar sessão Alta RF001
RF003 Terminar sessão Alta RF002
Perfil dos clientes
RF004 Introduzir seus dados básicos Alta RF002
como nome completo,
fotografia.
RF005 Visualizar e editar sua conta Alta RF002
Serviços
RF006 Visualizar a lista de serviços Alta RF002
RF007 Visualizar os detalhes de um Alta RF006
determinado serviço tais como
preço, disponibilidade,
duração.
RF008 Partilhar serviços nas redes Alta RF007
socias tais como: Facebook,
WhatsApp e Twitter.
Funcionário da SOMAIS
RF009 Iniciar sessão Alta
RF0010 Terminar sessão Alta RF009
RF0011 Registrar e listar atendimentos Alta RF009
RF0012 Registrar e listar gastos Alta RF009
RF0012 Registrar e listar serviços Alta RF009
 7

RF0013 Registrar empresas Alta RF009

RF0013 Registrar e listar dividas de Alta RF009
empresas
RF0014 Responder mensagens de Alta RF009
clientes
RF0015 Listar clientes Alta RF009
RF0016 Imprimir relatorio Alta RF009

3.4.2. Requisitos Não-Funcionais

São restrições aos serviços ou funções oferecidas pelo sistema. Incluem
restrições de timing, restrições no processo de desenvolvimento e restrições
impostas pelas normas. Ao contrário das características individuais ou serviços
do sistema, os requisitos não funcionais, muitas vezes, aplicam-se ao sistema
como um todo.
A tabela a seguir contém os requisitos não funcionais dos sistema:
Identificador Descrição Prioridade
Disponibilidade
RN0001 ­ Funcionar por tempo ininterrupto Média
RN0002 ­ Poder agendar atendimentos offline e Média
submeter logo que estiver online
Usabilidade
RN0003 ­ O processo de listagem de serviços é o Alta
primeiro contacto que o cliente tem com
a aplicação, portanto deve ser muito
simples e rápido.
Segurança
RN0004 ­ Garantir que a conexão com o servidor Alta
é segura o suficiente para evitar roubo
de informação por parte de hackers
RN0005 ­ Garantir autenticidade dos dados do Alta
utilizador a nível da aplicação.
RN0006 ­ Responder somente a requisições com Alta
Token de autenticação
 8

4. Arquitetura do Sistema
O modelo proposto será baseado numa plataforma que terá um sistema Web
para os funcionários e uma aplicação móvel para os clientes. No sistema Web
será possível fazer registo das actividades diárias, levantamento de dados
estatísticos, gerir os agendamentos provenientes dos clientes, submeter
informação sobre os serviços prestados que será consumida pela aplicação
móvel. Através aplicação movel os clientes poderam ter informação sobre os
serviços prestados assim como preços, a agenda da empresa e poderam
agendar um atendimento. A aplicação movel também possibilitará aos clientes
partilhar os serviços através das redes socias o que vai contribuir na expansão
de informação e da plataforma. A figura 5 ilustra o princípio de comunicação da
plataforma via API Rest.

5. Modelo do Domínio
 9

6. Diagramas de Interação
6.1. Diagrama de Sequência
Diagrama de sequência é um diagrama comportamental que procura determinar
a sequência de eventos que ocorrem em um determinado processo,
identificando quais mensagens devem ser disparadas entre os elementos
envolvidos e em que ordem
A figura abaixo apresenta o diagrama de sequência de abertura da conta do
cliente.

Figura 1: Diagrama de sequencia criar conta

Fonte: Autor

A figura abaixo apresenta o diagrama de sequência de início de sessão do

cliente.

Figura 2: Diagrama de sequencia de inicio de sessão

Fonte: Autor
 10

A figura a seguir ilustra o diagrama de sequência visualizar serviços.

Figura 3: Diagrama de sequência de visualizar serviços

Fonte: Autor

A figura abaixo ilustra o diagrama de sequência agendar atendimento.

Figura 4: Diagrama de sequência agendar atendimento

Fonte: Autor
 11

7. Modelo de Dados
7.1. Modelo Lógico da Base de Dados

7.2. Criação Física do Modelo de Dados

12
13
14
15
16
17
 18

7.3. Dicionário de Dados

Tabela: users
Campo Descrição Tipo Tamanho Dec
PK Id Codigo do usuário inteiro 20
name Nome do usuário caracteres 255
apelido Apelido do usuário caracteres 255
is_admin Tipo de usuário booleano
email Email do usuário caracteres 255
email_verified_at Data de verificação data
do email
password Senha do usuário caracteres 255
remember_token Símbolo de caracteres 100
memorização da
sessão do usuário
created_at Data de criação da data
conta do usuário
updated_at Data da ultima data
actualização da
conta do usuário
 19

Tabela: tipo_de_servicos
Campo Descrição Tipo Tamanho Dec
PK Id Código do tipo de inteiro 35
serviço
Designação Designação do tipo caracteres 128
de serviço
created_at Data de criação do data
registro
updated_at Data da ultima data
actualização do
registro

Tabela: agendamentos
Campo Descrição Tipo Tamanho
PK Id Código do inteiro 35
agendamento
data Data do agendamento data

hora Hora do agendamento tempo

FK servico_id Chave estrangeira que inteiro 35

referencia chave
primaria do serviço
agendado
FK cliente_id Chave estrangeira que FK
referencia chave
primaria do cliente que
agendou
status Estado do enum
agendamento, por
defeito está pendente
created_at Data de criação do data
registro
updated_at Data da ultima data
actualização do registro

Tabela: servicos
Campo Descrição Tipo Tamanho
PK Id Código do serviço inteiro 35

designacao Designação do serviço caracteres 255

image Imagem do servico caracteres 255

FK item_id Chave estrangeira que inteiro 35

referencia chave
primaria do item
 20

FK tipo_de_servico_id Chave estrangeira que inteiro 35

referencia chave
primaria da tabela tipos
_de_servicos
preco Preço do serviço real

created_at Data de criação do data

registro
updated_at Data da ultima data
actualização do registro

Tabela: services_orders
Campo Descrição Tipo Tamanho Dec
PK Id Código da transacao inteiro 35
FK order_id Nome do assunto inteiro 35
FK service_id Código do serviço da inteiro 35
transação
created_at Data de criação do data
registro
updated_at Data da ultima data
actualização do
registro

Tabela: messages
Campo Descrição Tipo Tamanho Dec
PK Id Código da inteiro 35
mensagem
content Nome do assunto caracteres 255
Read_at Data de leitura da caracteres 255
mensagem
created_at Data de criação do data
registro
updated_at Data da ultima data
actualização do
registro

Tabela: subjects
Campo Descrição Tipo Tamanho Dec
PK Id Código do assunto inteiro 35
name Nome do assunto caracteres 255
created_at Data de criação do data
registro
updated_at Data da ultima data
actualização do
registro
 21

8. Ambiente de Desenvolvimento
Back-end Front-end
Linguagens de PHP 8.1.2 Javascript
programação
Linguagens de JSON HTML 5, CSS3,
marcação JSON
IDE
Visual Studio Code

Bibliotecas • alymosul/laravel-exponent-push-
notifications
• arielmejiadev/larapex-charts
• barryvdh/laravel-dompdf
• beyondcode/laravel-websockets
• dompdf/dompdf
• lcobucci/jwt
• livewire/livewire
• maatwebsite/excel
• mediconesystems/livewire-datatables
• nesbot/carbon
• realrashid/sweet-alert
• tymon/jwt-auth
Frameworks Laravel 8.1.0
Gestão de Composer Yarn
pacotes/bibliotecas
Sistema de
Git
controle de versão
Plataforma
Hospedeira em Heroku
nuvém
Sistema de Gestão MySQL / PHPMyAdmin
de Base de dados
Servidor Web Apache 2
Ferramentas extras Webpack,
PostCSS
 22

9. Sistemas e componentes externos utilizados

Bibliotecas PHP:
• alymosul/laravel-exponent-push-notifications;
• arielmejiadev/larapex-charts;
• barryvdh/laravel-dompdf;
• beyondcode/laravel-websockets;
• dompdf/dompdf;
• lcobucci/jwt;
• livewire/livewire;
• maatwebsite/excel;
• mediconesystems/livewire-datatables;
• nesbot/carbon;
• realrashid/sweet-alert;
• tymon/jwt-auth;
10. Implementação
As figuras 5,6 e 7 ilustram as primeiras telas possíveis que o usuário vê ao abrir
a aplicação. A tela inicial, tela de início de sessão e tela de abertura de conta.

Figura 6: Tela de início de

Figura 5: Tela Inicial da sessão Figura 7: Tela de abertura de
aplicação móvel conta
Fonte: Autor
Fonte: Autor Fonte: Autor
 23

A parte do código que gera a página inicial em Javascript e XML.

 24

Figura 8: Página inicial de listagem de serviços

Figura 9: Tela de agendamento
Fonte: Autor
Fonte: Autor

A parte do código que gera a página de listagem de serviços em Javascript e

XML.
 25

2.7.1. Interface da aplicação sistema Web

A figura 12 ilustra a página de início de sessão na parte do back-office.

Figura 10: Página de início de sessão

Fonte: Autor
A parte do código que gera a página de início de sessão em PHP blade
template engine.
 26

A figura 13 ilustra a página inicial após o início de sessão.

Figura 11: Página inicial do funcionário

Fonte: Autor

A parte do código que gera a página de painel apos início de sessão em PHP
blade template engine.
 27

2.7.2. Implantação
A parte web do sistema esta hospedada na Plataforma de hospedagem em
nuvem Heroku, com o dominio https://somais.herokuapp.com/.
A parte mobile esta na Google Play Store com o nome SOMAIS.
 28

11. Conclusões e considerações finais

A plataforma implementada apresenta uma boa aplicabilidade no negócio da
empresa SOMAIS, mesmo com os poucos dados ainda disponíveis. As
limitações que o projecto de desenvolvimento enfrentou são
O agendamento remoto representa uma inovação tendo em conta o “modus
operandi” das empresas do ramo automóvel, presentes no mercado a nível da
província de Tete assim como no Pais em geral.
Há previsão de possível integração de sistemas de pagamentos, via carteiras
moveis mais usadas no Pais.
E o sistema continuará em manutenção sendo esta apenas a primeira versão.