UNIVERSIDADE TÉCNICA DE ANGOLA

FACULDADE DE ENGENHARIAS

DEPARTAMENTO DE ENSINO E INVESTIGAÇÃO DAS TECNOLOGIAS DE

INFORMAÇÃO E COMUNICAÇÃO - DEITIC

DESENVOLVIMENTO DE UMA PLATAFORMA DE LOCALIZAÇÃO E MARCAÇÃO

DE CONSULTAS EM CLÍNICA DE ESPECIALIDADE PARA PROVÍNCIA DE
LUANDA

DANIEL DE CARVALHO CONSTANTINO

LUANDA-ANGOLA

AGOSTO/2019
 UNIVERSIDADE TÉCNICA DE ANGOLA

FACULDADE DE ENGENHARIAS

DEPARTAMENTO DE ENSINO E INVESTIGAÇÃO DAS TECNOLOGIAS DE

INFORMAÇÃO E COMUNICAÇÃO-DEITIC

CURSO DE ENGENHARIA INFORMÁTICA

DESENVOLVIMENTO DE UMA PLATAFORMA DE LOCALIZAÇÃO E MARCAÇÃO

DE CONSULTAS EM CLÍNICA DE ESPECIALIDADE PARA PROVÍNCIA DE
LUANDA

DANIEL DE CARVALHO CONSTANTINO

Trabalho de Fim de curso apresentado a

Universidade Técnica de Angola, como
requisito para obtenção do título de
licenciado em Engenharia Informática.

Orientador: Msc Amiraldes Xavier

LUANDA-ANGOLA

AGOSTO/2019
 DEDICATÓRIA

A minha mãe “Catarina de Carvalho” e a todos que

ajudaram para a realização deste trabalho.

i
 AGRADECIMENTO

À Deus pelo dom da vida e por me ter dado saúde e força

para concluir esse trabalho.

Ao meu orientador por ter aceite trabalhar comigo.

Aos meus pais pelo apoio e por terem acreditado em

mim.

A minha irmã por ter-me motivado para a elaboração do

trabalho.

Enfim agradeço a todas as pessoas que fizeram parte

desta etapa da minha vida.
 EPÍGRAFE

“A persistência é o caminho do êxito”

Charles Chaplin.

iii
 RESUMO

O presente trabalho tem como objectivo o desenvolvimento de uma plataforma de localização

de clinicas de especialidades e marcação de consultas para a província de Luanda.

Uma das dificuldades encontradas por grande parte dos utentes é localizar clínicas que
atendem a especialidade e saber os respectivos preços dos exames. Para dar suporte a essas
dificuldades, foi desenvolvido uma plataforma de localização de clínicas de especialidade e
marcação de consultas. O desenvolvimento da plataforma aqui descrito visa melhorar e
facilitar os utentes na localização de clinicas de especialidades e marcações de consultas.

Conforme os requisitos levantados, a plataforma foi desenvolvida com suas principais

funcionalidades, registo de utentes, de clínicas, de médicos, especialidades, de exames, de
marcação de consulta e etc.

Por fim, todos os objetivos estabelecidos inicialmente foram cumpridos, visto que o sistema
foi desenvolvido e possui todas as funcionalidades essenciais.

Palavras-Chaves: Plataforma, Localização de Clínicas, Utentes.

 ABSTRACT

The present work aims to develop a platform for locating specialty clinics and making
appointments for Luanda province.

One of the difficulties encountered by most patients is locating clinics that cater to the
specialty and knowing their exam prices. To support these difficulties, a platform for locating
specialty clinics and scheduling appointments was developed. The development of the
platform described here aims to improve and facilitate users in locating specialty clinics and
appointment bookings.

According to the requirements raised, the platform was developed with its main features,
registration of users, clinics, doctors, specialties, exams, appointment and so on.

Finally, all initially set objectives were met as the system it was developed and has all the
essential functionality.

Keywords: Platform , Clinic Location, Users.

 ÍNDICE

DEDICATÓRIA..........................................................................................................................i
EPÍGRAFE................................................................................................................................iii
RESUMO...................................................................................................................................iv
ABSTRACT................................................................................................................................v
ÍNDICE DE FIGURAS.............................................................................................................ix
ÍNDICE DE TABELAS..............................................................................................................x
INTRODUÇÃO..........................................................................................................................1
Descrição do problema...................................................................................................................1

Justificativa.....................................................................................................................................2

Objectivos........................................................................................................................................2

Objectivo Geral...........................................................................................................................2
Objectivos específicos:................................................................................................................2
Estrutura do Trabalho...................................................................................................................3

CAPÍTULO 1 - FUNDAMENTAÇÃO TEÓRICA....................................................................4

1.1. Plataformas Digitais............................................................................................................4

1.1.1. Para Que Serve as Plataformas Digitais.....................................................................4

1.2. Sistemas Semelhantes..........................................................................................................4

1.3. Engenharia de Software......................................................................................................5

1.3.1. Processo de Desenvolvimento de Software.................................................................5

1.3.2. Requisitos do Sistema...................................................................................................7
1.3.3. Modelação de Sistemas................................................................................................8
1.4. Base de Dados.......................................................................................................................9

1.4.1. Modelo Conceitual........................................................................................................9

1.4.2. Modelo Lógico.............................................................................................................10
1.4.3. Modelo Físico..............................................................................................................10
1.4.4. Normalização de Dados..............................................................................................10

vi
 1.4.5. SQL Server..................................................................................................................11
1.5. Programação......................................................................................................................11

1.5.1. POO.............................................................................................................................11
1.5.2. Asp.Net MVC..............................................................................................................13
1.6. Teste de Software...............................................................................................................13

 Testes Funcionais........................................................................................................13
 Testes de Integração...................................................................................................14
 Testes de Segurança...................................................................................................14
 Teste Unitários............................................................................................................14
1.7. Arquitectura de Software..................................................................................................14

1.7.1. Cliente/Servidor..........................................................................................................14
CAPÍTULO 2 – METODOLOGIA..........................................................................................16
2.1 Metodologia de Investigação.............................................................................................16

2.2. Tipo de estudo e técnicas de recolha de dados....................................................................16

2.3. Campo de estudo....................................................................................................................16

2.4. Ferramentas utilizadas..........................................................................................................17

2.5. Processo de Desenvolvimento...............................................................................................17

2.6. Análise de Requisitos.............................................................................................................18

2.6.1. Requisitos Funcionais.................................................................................................18

2.6.2. Requisitos Não Funcionais.........................................................................................19
2.7. Modelação do Sistema.......................................................................................................20

2.7.1. Diagrama de Caso de Uso..........................................................................................20

2.7.2. Diagrama de Actividades...........................................................................................21
2.7.3. Diagrama de Sequência..............................................................................................22
2.7.4. Diagrama de Classe....................................................................................................23
2.7.5. Modelo Conceitual......................................................................................................24
2.7.6. Dicionário de Dados...................................................................................................25
2.7.7. Modelo Lógico.............................................................................................................31
CAPÍTULO 3 - RESULTADOS..............................................................................................32
vii
 3.1. Introdução a plataforma Consulting Clinic....................................................................32

3.2. Interface do Sistema..........................................................................................................32

3.2.1 Página de Login..........................................................................................................32

3.2.2. Registo de Utente........................................................................................................33
3.2.3. Registo de Clínicas......................................................................................................34
3.2.4. Página de Consulta de Clínicas.................................................................................34
3.2.5. Página de endereço das clínicas................................................................................35
CONCLUSÃO..........................................................................................................................36
RECOMENDAÇÃO.................................................................................................................36

viii
 ÍNDICE DE FIGURAS

Figura 1: Diagrama de caso de uso...........................................................................................20

Figura 2: Diagrama de Actividades..........................................................................................21

Figura 3: Diagrama de Sequência.............................................................................................22

Figura 4: Diagrama de Classe...................................................................................................23

Figura 5: Modelo Lógico..........................................................................................................29

Figura 6 : Página de Login........................................................................................................30

Figura 7: Página de Registo de Utente......................................................................................31

Figura 8 : Página de Registo de Clínica....................................................................................32

Figura 9: Página de Consulta de Clínicas.................................................................................32

Figura 10: Página de Endereços de Clínicas.............................................................................33

ix
 ÍNDICE DE TABELAS

Tabela 1: Requisitos Funcionais...............................................................................................19

Tabela 2: Requisitos Não Funcionais.......................................................................................20

Tabela 3: Tabela Município......................................................................................................26

Tabela 4: Tabela Distrito..........................................................................................................26

Tabela 5: Tabela Bairro............................................................................................................26

Tabela 6: Tabela Rua................................................................................................................27

Tabela 7: Tabela Perfil..............................................................................................................27

Tabela 8: Tabela Usuário..........................................................................................................27

Tabela 9: Tabela Especialidade................................................................................................27

Tabela 10: Tabela Utente..........................................................................................................28

Tabela 11: Tabela Administrador.............................................................................................28

Tabela 12: Tabela Clinica.........................................................................................................28

Tabela 13: Tabela Exame..........................................................................................................28

Tabela 14: Tabela Consulta......................................................................................................29

Tabela 15 : Tabela Exame Clinica............................................................................................29

Tabela 16 : Tabela Gestor Clinica............................................................................................29

Tabela 17 : Tabela Medico.......................................................................................................30

Tabela 18 : Tabela Especialidade Clínica.................................................................................30

Tabela 19 : Tabela Especialidade Médico................................................................................30

Tabela 20 : Tabela Médico Clínica...........................................................................................30

Tabela 21 : Tabela Calendário Clínica......................................................................................31

 INTRODUÇÃO

A internet actualmente é um recurso que está cada dia mais presente no dia-a-dia da nossa
sociedade, devido aos seus benefícios e facilidade de acesso, muitas empresas a utilizam tanto
para oferecer serviços como para passar informações, e as pessoas comuns por sua vez a
utilizam para se comunicarem, outras para aceder a informações e outras como ferramenta de
trabalho.

Devido a facilidade de acesso, muitas organizações optam por implementarem aplicações

webs para automatizar os seus processos, tanto para a digitalização de serviços ou para a
divulgação de informações de modos a se tornarem mais próximos de seus clientes.

A utilização de aplicações webs está presente em quase todas as áreas desde educação,
desporto, comércio, marketing, saúde entre outras.

O número de pessoas a aderirem a internet no nosso país vem aumentado o que traz a
oportunidade para organizações começarem a olhar para o mercado das aplicações web para
terem um diferencial a nível da concorrência e poder eventualmente atingir novos clientes.
Um dos principais motivos das pessoas utilizarem as plataformas webs é a procura de
determinados serviços e no nosso país ainda são poucas as plataformas que oferecem este tipo
de serviço.

É neste sentido que o nosso trabalho vem propor o desenvolvimento de uma plataforma web
para a divulgação de serviços de saúde.

Descrição do problema
Há cada vez mais no nosso país clínicas especializadas no tratamento de determinadas
patologias, mas que em muitos casos os pacientes desconhecem a existência das mesmas e
acabam indo fazer o tratamento no exterior do país.

Encontrar uma clínica de especialidade pode não ser uma tarefa fácil, principalmente na
cidade de Luanda. Muitas vezes nessas ocasiões a pessoa procurando esse estabelecimento já
está aflita ou estressada por um problema de saúde.

Que solução deve ser implementada para tornar acessível e fácil a localização das clinicas de
especialidade na província de Luanda, bem como a marcação de consultas nas respectivas
clinicas?
Justificativa
Devido a dificuldade que as pessoas têm em localizar clínicas de especialidades e ter que
telefonar ou deslocar-se para fazer a marcação de consultas, foi pensado na criação de uma
plataforma web que possibilitará aos utentes conhecer a localização exata das clínicas e os
serviços médicos disponíveis nas mesmas, sendo possível efectuar as marcações de consultas
de especialidade através da plataforma proposta neste trabalho.

Objectivos
Objectivo Geral

Desenvolver uma plataforma de localização de clínicas de especialidade e marcação de

consultas para província de Luanda.

Objectivos específicos:

 Analisar as tecnologias necessárias para desenvolver a plataforma;

 Estudar a biblioteca do Google Maps;
 Identificar os requisitos funcionais e não funcionais da plataforma;
 Modelar os principais diagramas do sistema;
 Definir a arquitetura de desenvolvimento;
 Implementar as funcionalidades do sistema;

Estrutura do Trabalho
Este trabalho está estruturado da seguinte forma: uma parte introdutória onde apresentou-se a
visão do trabalho, a problemática a ser investigada bem como o que se pretendeu alcançar

2
com esta pesquisa através dos objectivos específicos. Posteriormente dividiu-se o trabalho em
3 capítulos que são descritos a seguir:

 Capítulo 1 - Neste capítulo abordou-se a fundamentação teórica sobre o projecto

desenvolvido, apresentando algumas tecnologias usadas no projecto, arquitectura e
metodologias usadas para a desenvolvimento do projecto.
 Capítulo 2 - Este capítulo apresenta a análise metodológica, onde são apresentadas as
técnicas, os procedimentos e os métodos de pesquisa usados para a elaboração deste
projecto, apresentamos os requisitos e os diagramas.
 Capítulo 3 - Neste capítulo é apresentado os resultados obtidos através das pesquisas
e metodologias mencionadas no capítulo anterior, que inclui a interface juntamente
com alguma explicação do funcionamento do mesmo.

3
 CAPÍTULO 1 - FUNDAMENTAÇÃO TEÓRICA

1.1. Plataformas Digitais

Segundo [ CITATION Mar11 \l 2070 ], as plataformas digitais estão relacionadas à tecnologia
utilizada para a criação e desenvolvimento de sistemas utilizados na web. A plataforma digital
possibilita que diferentes aplicativos possam ser usados ao mesmo tempo por internautas.

Uma das características essenciais da plataforma digital é que ela não exige um determinado
lugar físico para conexão. Para estar no mesmo ambiente, basta a todos os participantes terem
um aparelho conectado à internet.

1.1.1. Para Que Serve as Plataformas Digitais

As plataformas digitais podem ser usadas para uma infinidade de objectivos. Muitas
organizações podem usá-las para aumentar os lucros, alcançar novos clientes, redução de
custos, melhoria do diálogo com o cliente, tornar produtos ou serviços visíveis para o público-
alvo do negócio, melhorar processos.

Portanto, o objectivo da plataforma digital pode ser complexo, dependendo da proposta pela
qual ela foi criada e também a finalidade que a empresa interessada pode abstrair.

No geral, existem quatro objectivos gerais da plataforma digital:

 Venda
 Mídias
 Social
 Serviços

1.2. Sistemas Semelhantes

Foram analisados alguns aplicativos ou sistemas que possuem características parecidas com as
do sistema que está a ser desenvolvido, dos quais a maioria para dispositivos móveis.

O Appy Saúde é um aplicativo que possibilita para o usuário realizar marcações de consultas
online nas melhores clínicas, fazer reservas de milhares de produtos farmacêuticos em várias
farmácias em Angola, com informação de preço e stock em tempo real, fazer a listagem de
médicos em vários estabelecimentos, com horários, contactos (telefone e e-mail) etc.
O Centro médico Cidadela possui um sistema para marcação de consultas online que
possibilita ao usuário escolher a data da consulta.

O ministério da saúde possui um portal de pedidos de cartão de saúde e agendamentos de

consulta.

1.3. Engenharia de Software

A Engenharia de Software é a área da computação que estabelece uma abordagem sistemática
de desenvolvimento de software com qualidade envolvendo processos, técnicas e ferramentas
apropriadas para uma ampla gama de aplicações, considerando prazos, restrições e recursos
disponíveis. [ CITATION Rog11 \l 2070 ].

A criação da Engenharia de Software surgiu no intuito de contornar a crise do software, dando

um tratamento de engenharia ao desenvolvimento de sistemas complexos caracterizados por
um conjunto de componentes abstratos (estrutura de dados e algoritmos) encapsulados na
forma de procedimentos, funções, módulos, objetos ou agentes e interconectados entre si,
compondo a arquitetura do software, devendo ser executados em sistemas computacionais.
[ CITATION Rog11 \l 2070 ].

1.3.1. Processo de Desenvolvimento de Software

Um processo de desenvolvimento de software pode ser visto como um conjunto de

actividades organizadas, usadas para definir, desenvolver, testar e manter um software. A
seguir, alguns objectivos do processo de desenvolvimento:

● Definição das actividades a serem executadas;

● Quando determinada actividade deve ser executada;

● Pessoa ou grupo a executar tais actividades;

● Padronização no processo de desenvolvimento.

Existem diversas fases de desenvolvimento de software, no entanto há algumas actividades

básicas comuns à grande parte dos processos existentes, nesse artigo será descrito algumas
dessas actividades, como: Levantamento de requisitos, Análise de Requisitos, Projecto,
Implementação, Testes, Implantação. [ CITATION dev19 \l 2070 ].

5
1.3.1.1. Fases de Desenvolvimento de Software

1. Levantamento de Requisitos - Esta actividade tem como objectivo, compreender o

problema, dando aos desenvolvedores e usuários, a mesma visão do que deve ser
construído para resolução do problema. Desenvolvedores e clientes, em conjunto,
buscam levantar e priorizar as necessidades dos futuros usuários do software
(necessidades essas denominadas como requisitos).
O levantamento de requisitos é a etapa mais importante, no que diz respeito ao retorno
de investimentos no projecto. Vários projectos são abandonados pelo baixo
levantamento de requisitos, ou seja, membros da equipe não disponibilizaram tempo
suficiente para essa fase do projecto, em compreender as necessidades dos clientes em
relação ao sistema a ser desenvolvido. [CITATION Hud17 \l 2070 ].

2. Análise de Requisitos - Esta etapa, também chamada de especificação de requisitos, é

onde os desenvolvedores fazem um estudo detalhado dos dados levantados na
actividade anterior. O interesse nessa actividade é criar uma estratégia de solução, sem
se preocupar como essa estratégia será realizada, ou seja, utilizar as necessidades dos
clientes, depois de compreendido o problema, para resolução do problema solicitado.
 Validação: tem por objectivo, assegurar que o sistema de software está atendendo às
reais necessidades do cliente;
 Verificação: verifica se os modelos construídos na análise estão em conformidade
com os requisitos do cliente.

3. Projecto - Nesta fase é que deve ser considerado, como o sistema funcionará
internamente, para que os requisitos do cliente possam ser atendidos. Alguns aspectos
devem ser considerados nessa fase de projecto do sistema, como: arquitectura do
sistema, linguagem de programação utilizada, Sistema Gerenciador de Base de Dados
(SGBD) utilizado, padrão de interface gráfica, entre outros. (devmedia.com.br).
O projecto possui duas actividades básicas: projecto da arquitectura (ou projecto de
alto nível), e projecto detalhado (ou projecto de baixo nível). O projecto da
arquitectura visa distribuir as classes de objectos relacionados do sistema em
subsistemas e seus componentes, distribuindo também esses componentes pelos
recursos de hardware disponíveis. [CITATION Hud17 \l 2070 ].

6
 Já no projecto detalhado, são modeladas as relações de cada módulo com o objectivo
de realizar as funcionalidades do módulo. Além de desenvolver o projecto de interface
com o usuário e o projecto de banco de dados. [CITATION Hud17 \l 2070 ].

4. Implementação - Nessa etapa, o sistema é codificado a partir da descrição

computacional da fase de projecto em uma outra linguagem, onde se torna possível a
compilação e geração do código-executável para o desenvolvimento software.
[CITATION Hud17 \l 2070 ].

5. Testes - Diversas actividades de testes são executadas a fim de se validar o produto de

software, testando cada funcionalidade de cada módulo, buscando, levando em
consideração a especificação feita na fase de projecto. Onde o principal resultado é o
relatório de testes, que contém as informações relevantes sobre erros encontrados no
sistema, e seu comportamento em vários aspectos. Ao final dessa actividade, os
diversos módulos do sistema são integrados, resultando no produto de software.
[CITATION Hud17 \l 2070 ].

6. Implantação - Por fim a implantação compreende a instalação do software no

ambiente do usuário. O que inclui os manuais do sistema, importação dos dados para o
novo sistema e treinamento dos usuários para o uso correto e adequado do sistema. Em
alguns casos quando da existência de um software anterior, também é realizada a
migração de dados anteriores desse software. [ CITATION dev19 \l 2070 ]

1.3.2. Requisitos do Sistema

[ CITATION Som11 \l 2070 ], afirma que os requisitos de sistema de software são,

frequentemente, classificados como funcionais ou não funcionais ou como requisitos de
domínio:

 Requisitos funcionais: são declarações de funções que o sistema deve fornecer, como
o sistema deve reagir a entradas específicas e como deve se comportar em
determinadas situações. Em alguns casos os requisitos funcionais podem também
explicitamente declarar o que o sistema não deve fazer.

7
  Requisitos não funcionais: são restrições oferecidas pelo sistema. Entre eles
destacam-se restrições de tempo, restrições sobre o processo de desenvolvimento,
padrões, entre outros.

Os requisitos não funcionais estão classificados em:

 Requisitos de produto: são os requisitos que especificam o comportamento do

produto.
Entre os exemplos estão os requisitos de desempenho sobre com que rapidez o sistema
deve operar e quanta memória ele requer, os requisitos de confiabilidade, que
estabelecem a taxa aceitável de falhas, os requisitos de portabilidade e os requisitos de
facilidade de uso.
 Requisitos organizacionais: são precedentes de políticas e procedimentos nas
organizações do cliente e do desenvolvedor. Entre os exemplos estão os padrões de
processos que devem ser utilizados, os requisitos de implementação, com a linguagem
de programação ou o método de projeto utilizado, os requisitos de fornecimento, que
especificam quando o produto e seus documentos devem ser entregues.
 Requisitos externos: esse amplo tópico abrange todos os requisitos precedentes de
fatores externos ao sistema e a seu processo de desenvolvimento. Dentre eles
destacamse os requisitos de interoperabilidade, que definem como o sistema interage
com sistemas e outras organizações, os requisitos legais, que devem ser seguidos para
assegurar que o sistema opera de acordo a lei, e os requisitos éticos, são definidos em
um sistema para garantir que este será aceitável para seus usuários.
 Requisitos de domínio: são requisitos que se originam do domínio da aplicação do
sistema e que refletem características deste domínio. Podem ser requisitos funcionais
ou não funcionais.

1.3.3. Modelação de Sistemas

1.3.3.1. Linguagem UML

A UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) é uma

linguagem visual utilizada para modelar sistemas computacionais por meio do paradigma de
Orientação a Objetos.

8
UML não é uma linguagem de programação, mas uma linguagem de modelagem, cujo
objectivo é auxiliar os engenheiros de software a definir as características do software, tais
como seus requisitos, seu comportamento, sua estrutura lógica, a dinâmica de seus processos
e até mesmo suas necessidades físicas em relação ao equipamento sobre o qual o sistema
deverá ser implementado.[ CITATION Gue05 \l 2070 ].

 Diagrama de Casos de Uso: Este é o diagrama mais geral e informal da UML, sendo
utilizado principalmente para auxiliar no levantamento e análise dos requisitos, em
que são determinadas as necessidades do usuário, e na compreensão do sistema como
um todo, embora venha a ser consultado durante todo o processo de modelagem e
sirva de base para todos os outros diagramas. [ CITATION Gue05 \l 2070 ].
 Diagrama de Classes: Este é o diagrama mais utilizado e o mais importante da UML,
servindo de apoio para a maioria dos outros diagramas. Como o próprio nome diz,
esse diagrama define a estrutura das classes utilizadas pelo sistema, determinando os
atributos e métodos possuídos por cada classe, além de estabelecer como as classes se
relacionam e trocam informações entre si. [ CITATION Gue05 \l 2070 ]
 Diagrama de Atividades: O Diagrama de Atividade se preocupa em descrever os
passos a serem percorridos para a conclusão de uma atividade específica, muitas vezes
representada por um método com um certo grau de complexidade, podendo, no
entanto, modelar um processo completo. Concentra-se na representação do fluxo de
controle e no fluxo de objeto de uma atividade. [ CITATION Gue05 \l 2070 ]
 Diagrama de Sequencia: “preocupa-se com a ordem temporal em que as mensagens
são trocadas entre os objetos envolvidos em um determinado processo. Em geral,
baseia-se em um Caso de Uso definido pelo diagrama de mesmo nome e apóia-se no
Diagrama de Classes para determinar os objetos das classes envolvidas em um
processo, bem como os métodos disparados entre os mesmos”. [ CITATION Gue05 \l
2070 ]

1.4. Base de Dados

Base de dados é uma colecção de factos registrados que refletem o estado de certos aspectos
de interesse do mundo real. A todo momento o conteúdo a base de dados representa uma
visão instantânea do estado do mundo real. Cada mudança em algum item da base de dados
reflete uma mudança ocorrida no mundo real.

9
1.4.1. Modelo Conceitual

Segundo [ CITATION Fel04 \l 2070 ], o modelo conceitual “representa e/ou descreve a

realidade do ambiente do problema, constituindo-se em uma visão global dos principais dados
e relacionamentos independentemente das restrições de implementação.

Quando se fala de modelo conceitual, estamos nos referindo a primeira etapa do projecto de
um sistema de aplicação de base de dados.

O objectivo do modelo conceitual é descrever as informações em uma realidade, as quais irão

estar armazenadas em uma base de dados. É uma descrição em alto nível, mas que tem a
preocupação de captar e retratar toda a realidade de uma organização, sector, repartição,
departamento, etc.

1.4.2. Modelo Lógico

O modelo logico tem seu início a partir do Modelo Conceitual, levando em consideração uma
das três abordagens actualmente possíveis: Relacional, Hierárquica e Rede.

O modelo logico descreve a estrutura que estarão contidas na base de dados, de acordo com as
possibilidades permitidas pela abordagem, mas sem considerar ainda nenhuma característica
especifica de um sistema Gerenciador de Base de Dados (SGBD), resultando em um esquema
logico de dados sob a óptica de uma das abordagens citadas. [ CITATION Fel04 \l 2070 ].

Esta é a etapa final do projecto de Base de Dados, na qual será utilizada a Linguagem de
Definição de Dados do SGBD (DDL), para a realização da montagem do mesmo no nível do
Dicionário de Dados. [ CITATION Fel04 \l 2070 ].

1.4.3. Modelo Físico

O modelo físico parte do modelo logico e descreve as estruturas físicas de armazenamento de

dados, tais como: tamanho de campos, tipo de dados, etc. Este modelo detalha o estudo dos
métodos de acesso do SGBD. [ CITATION Fel04 \l 2070 ].

1.4.4. Normalização de Dados

O conceito normalização foi introduzindo por E. F. Cood em 1970 (primeira formal normal).

 Primeira Forma Normal (1FN): a 1FN diz que na tabela não pode houver um grupo
de dados repetidos, isto é, se todos os valores forem únicos. Em outras palavras

10
 podemos definir que a primeira forma normal não admite repetições ou campos que
tenha mais que um valor.

 Segunda Forma Normal (2FN): a 2FN diz que a tabela deve estar na 1FN e todos os
atributos não chave forem totalmente dependentes da chave primária (dependente de
toda a chave e não apenas de parte dela).

 Terceira Forma Normal (3FN): a 3FN diz que a tabela deve estar na 2FN e que
nenhum atributo não chave pode depender funcionalmente de algum outro atributo que
não seja a chave primária.

1.4.5. SQL Server

O SQL Server, segundo (Pacievitch, s.d.), é um dos SGBD da Microsoft, criado em

parceria com a Sybase, em 1988, inicialmente como um complementar do Windows NT,
sendo
que depois passou a ser aperfeiçoado e vendido separadamente. A parceria com a Sybase
terminou em 1994, e a Microsoft continuou a melhorar o programa após isto. Este SGBD é
um
dos mais usados no mundo atualmente, tendo como competidores sistemas como o MySQL e
Oracle.

1.5. Programação
1.5.1. POO

Um dos grandes diferenciais da programação orientada a objectos em relação a outros

paradigmas de programação que também permitem a definição de estruturas e operações
sobre
essas estruturas está no conceito de herança, mecanismo através do qual definições existentes
podem ser facilmente estendidas. Juntamente com a herança deve ser enfatizada a importância
do polimorfismo, que permite selecionar funcionalidades que um programa irá utilizar de
forma
dinâmica, durante sua execução”.

11
Classes: “a definição de classes e seus inter-relacionamentos é o principal resultado da etapa
de projeto de software. Em geral, esse resultado é expresso em termos de alguma linguagem
de modelagem, tal como UML.

Uma classe é um gabarito para a definição de objetos. Através da definição de uma classe,
descreve-se que propriedades ou atributos o objeto terá.

Além da especificação de atributos, a definição de uma classe descreve também qual o

comportamento de objetos da classe, ou seja, que funcionalidades podem ser aplicadas a
objetos
da classe. Essas funcionalidades são descritas através de métodos. Um método nada mais é
que
o equivalente a um procedimento ou função, com a restrição que ele manipula apenas suas
variáveis locais e os atributos que foram definidos para a classe.

O conjunto de atributos descreve as propriedades da classe. Cada atributo é identificado por

um
nome e tem um tipo associado. Em uma linguagem de programação orientada a objetos pura,
o
tipo é o nome de uma classe. Na prática, a maior parte das linguagens de programação
orientada a objetos oferecem um grupo de tipos primitivos, como inteiro, real e caráter, que
podem ser
usados na descrição de atributos.

Os métodos definem as funcionalidades da classe, ou seja, o que será possível fazer com
objetos
dessa classe. Cada método é especificado por uma assinatura, composta por um identificador
para o método (o nome do método), o tipo para o valor de retorno e sua lista de argumentos,
sendo cada argumento identificado por seu tipo e nome.”

Objetos: Objetos são instâncias de classes. É através deles que (praticamente) todo o
processamento ocorre em sistemas implementados com linguagens de programação orientadas
a objetos. O uso racional de objetos, obedecendo aos princípios associados à sua definição
conforme estabelecido no paradigma de desenvolvimento orientado a objetos, é chave para o
desenvolvimento de sistemas complexos e eficientes.

12
Um objeto é um elemento que representa, no domínio da solução, alguma entidade (abstrata
ou concreta) do domínio de interesse do problema sob análise. Objetos similares são
agrupados em classes.

Da mesma forma, quando se cria um objeto, esse objeto adquire um espaço em memória para
armazenar seu estado (os valores de seu conjunto de atributos, definidos pela classe) e um
conjunto de operações que podem ser aplicadas ao objeto (o conjunto de métodos definidos
pela classe). Um programa orientado a objetos é composto por um conjunto de objetos que
interagem através de “trocas de mensagens”. Na prática, essa troca de mensagem traduz-se na
aplicação de métodos a objetos.”

Herança:” O conceito de encapsular estrutura e comportamento em um tipo não é exclusivo

da orientação a objetos; particularmente, a programação por tipos abstratos de dados segue
esse mesmo conceito. O que torna a orientação a objetos única é o conceito de herança.

Herança é um mecanismo que permite que características comuns a diversas classes sejam
factoradas em uma classe base, ou superclasse. A partir de uma classe base, outras classes
podem ser espenicadas.”

Polimorfismo: “Polimorfismo é o princípio pelo qual duas ou mais classes derivadas de uma
mesma superclasse podem invocar métodos que têm a mesma identificação
(assinatura) mas comportamentos distintos, especializados para cada classe derivada, usando
para tanto uma referência a um objeto do tipo da superclasse. Esse mecanismo é fundamental
na programação orientada a objetos, permitindo definir funcionalidades que operem
genericamente com objetos, abstraindo-se de seus detalhes particulares quando esses não
forem
necessários.”

1.5.2. Asp.Net MVC

O padrão MVC é um padrão responsável pela apresentação da aplicação. Basicamente, ele

visa criar um código que não possui uma conexão forte entre as partes. Essa é uma das bases
do desenvolvimento de código atual, e facilita muito a manutenção e adição de
funcionalidades ao código posteriormente. Dentro do padrão MVC, há três elementos
principais: o model, responsável por representar as entidades da lógica de negócios da
aplicação; a view, responsável por apresentar uma interface para o usuário; e o controller, que
realiza o controle dos outros elementos, fornecendo uma ligação entre eles. Essa técnica

13
envolve alguns detalhes para a implementação, e apresentaremos como eles funcionam dentro
do ASP.NET MVC. [ CITATION Hen14 \l 2070 ].

Uma das grandes vantagens do MVC Framework é a flexibilidade que ele permite ao
desenvolvedor. A ideia é que o programador tenha liberdade para preparar a plataforma da
forma que é melhor para seu estilo de desenvolvimento. Por isso, para a maioria dos projetos
é interessantes começarmos com um projeto vazio, como veremos, e construir a nossa
aplicação baseada nisso. [ CITATION Hen14 \l 2070 ].

1.6. Teste de Software

Os testes representam uma etapa de extrema importância no processo de desenvolvimento de
software, pois visam validar se a aplicação está funcionando corretamente e se atende aos
requisitos especificados.[CITATION dev19 \l 2070 ]

Nesse contexto existem diversas técnicas que podem ser aplicadas em diferentes momentos e
de diferentes formas para validar os aspectos principais do software. A seguir será
apresentado conceitos fundamentais do teste de software e como aplicá-los.[CITATION
dev19 \l 2070 ]

 Testes Funcionais

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

 Testes de Integração

Os testes de integração, como o nome sugere, têm por objetivo unir os diversos módulos do
sistema e testá-los em conjunto.

 Testes de Segurança

Os testes de segurança visam garantir a correta aplicação das premissas de segurança

definidas para o software, alcançando assim um ambiente operacional mais seguro.

 Teste Unitários

Os testes unitários têm por objetivo validar pequenas partes do software com base em suas
entradas possíveis e saídas esperadas. As unidades usadas nesse tipo de teste são as menores

14
partes testáveis de um sistema, normalmente funções, que recebem argumentos e retornam um
determinado valor ou efetuam alguma ação cujo resultado pode ser analisado.

1.7. Arquitectura de Software

1.7.1. Cliente/Servidor

O modelo cliente-servidor, é uma estrutura de aplicação distribuída que distribui as tarefas e

cargas de trabalho entre os fornecedores de um recurso ou serviço, designados como
servidores, e os requerentes dos serviços, designados como clientes.

Geralmente os clientes e servidores comunicam através de uma rede de computadores em

computadores distintos, mas tanto o cliente quanto o servidor podem residir no mesmo
computador.

Um servidor é um host que está executando um ou mais serviços ou programas que

compartilham recursos com os clientes. Um cliente não compartilha qualquer de seus
recursos, mas solicita um conteúdo ou função do servidor. Os clientes iniciam sessões de
comunicação com os servidores que aguardam requisições de entrada. [CITATION Ama93 \l
2070 ]

O modelo cliente-servidor foi desenvolvido na Xerox PARC durante os anos 70. Este modelo
é actualmente o predominante nas redes informáticas. Email, a World Wide Web e redes de
impressão são exemplos comuns deste modelo.

A característica do modelo cliente-servidor, descreve a relação de programas numa aplicação.

O componente de servidor fornece uma função ou serviço a um ou mais clientes, que iniciam
os pedidos de serviço.

15
 CAPÍTULO 2 – METODOLOGIA

Neste capítulo iremos informar quais os métodos ou tipo de pesquisa que foram utilizados
para realizar a nossa pesquisa, qual instrumento usado para a colecta de dados, o cenário e os
indivíduos participantes da investigação.

2.1 Metodologia de Investigação

Segundo [ CITATION Sou11 \l 2070 ] a metodologia de investigação é um processo de
selecção da estratégia de investigação que abrange a definição do tipo de pesquisa e as
técnicas de recolha de dados.

Neste âmbito, definimos a metodologia de investigação Qualitativa por centrar-se na

compreensão dos problemas, tendo em conta os comportamentos as atitudes ou valores do
campo de estudo (organização ou comunidade). [ CITATION Sou11 \l 2070 ].

16
2.2. Tipo de estudo e técnicas de recolha de dados
Utilizamos o estudo de caso como tipo de pesquisa, nos possibilitou efectuar um estudo
cuidado e detalhado do nosso campo de estudo e a observação não participante e analise
documental como técnicas de recolha de dados.

Através das técnicas mencionadas, foi possível observar a necessidade dos utentes em obter a
informação exata das clínicas e conhecer as suas especialidades. Também foi possível
efectuar a análise documental (documento eletrónico) através do Google para perceber e
conhecer o número de clínicas que possuem soluções web.

2.3. Campo de estudo

A cidade de Luanda constituí o nosso campo de estudo, onde centramos o estudo as médias e
grandes clínicas existentes. Luanda é uma das 18 províncias de Angola, localizada na região
centro-norte do país. Segundo as projeções populacionais de 2018, elaborada pelo Instituto
Nacional de Estatística, conta com uma população de 7 976 907 habitantes e área territorial de
18 826km², sendo a província mais populosa e densamente povoada de Angola.

2.4. Ferramentas utilizadas

 Visual Studio 2017: é um ambiente de desenvolvimento integrado da Microsoft,
capaz de oferecer ao desenvolvidor suporte completo para criação de software para
Windows, Mac, Linux, alem de estrutura para desenvolvimento web e de aplicativos
para android e iOS.
 Microsoft SQL Server 2017: é um sistema gerenciador de Banco de dados relacional
desenvolvido pela Microsoft.
 Astah Community versão 6.3: é um software para modelagem UML.
 BrModelo: é uma ferramenta de modelagem de banco de dados relacional.

2.5. Processo de Desenvolvimento

O processo de desenvolvimento escolhido é o Processo Iterativo Incremental por ser um
modelo simples, direito e objectivo, pois é baseado no modelo espiral, mas tem em conta a
iteração, ou seja, faz melhorias ou refinamento em cada incremento ou partes do projecto em
cada nova entrega. Esta metodologia obedece as seguintes etapas:
17
  Levantamento de Requisitos: na primeira etapa será feita o levantamento de
requisitos da plataforma proposta bem como a organização geral do projeto.
Primeiramente será identificado o problema que a plataforma deseja solucionar para
que então possam ser apresentadas as funcionalidades do sistema.

 Análise de Requisitos: baseando-se na etapa anterior, nesta etapa fizemos a análise

dos requisitos para resolução dos problemas
 Projecto: nesta etapa baseando-se nos requisitos levantados, definimos a arquitectura
(baixo e alto nível) do sistema e o padrão de desenvolvimento, as ferramentas, a
linguagem de programação, modelamos o sistema e definimos o sistema gerenciador
da base de dados e os seus respectivos modelos.
 Implementação: nesta etapa fizemos a codificação do sistema, usando as ferramentas
escolhidas na etapa anterior.
 Testes: esta etapa foi feita na etapa anterior, visto que o nosso processo de
desenvolvimento é o iterativo e incremental, na medida que fomos implementando
uma funcionalidade também foram feitos os testes das mesmas.
 Implantação: Esta etapa ainda não foi feita por falta de alguns requisitos.

2.6. Análise de Requisitos

Para o levantamento dos requisitos do sistema fizemos uma colecta de dados no interagindo
com os stakeholders do sistema que são os utentes e as clinicas.

2.6.1. Requisitos Funcionais

Apresentaremos a seguir na tabela 1 os requisitos funcionais da plataforma proposta.

Código Requisitos Funcionais Descrição

RF1 Cadastrar Clínicas A plataforma deverá permitir fazer o cadastro de

clínicas

RF2 Pesquisar Clínicas A plataforma deverá permitir aos utentes fazer a

pesquisa de clínicas.
RF3 Marcar Consultas A plataforma deverá permitir aos utentes fazer a
marcação de consultas.

RF4 Registar Exame A plataforma deverá permitir aos gestores de clínica

fazer o registo de exames.

18
 RF5 Remarcar Consultas A plataforma deverá permitir aos utentes fazer a
remarcação de consultas.
RF6 Cancelar Consulta A plataforma deverá permitir aos utentes fazer a
cancelamento de consultas.
RF7 Gerir Clinicas A plataforma deverá permitir fazer a gestão de
clinicas.

RF8 Ver Marcações A plataforma deverá permitir aos utentes ver as

marcações feitas.
Tabela 1: Requisitos Funcionais

2.6.2. Requisitos Não Funcionais

Apresentaremos a seguir na tabela 2 os requisitos não funcionais da plataforma proposta.

Código Requisitos Não Funcionais Descrição

RNF1 Usabilidade A plataforma terá uma interface agradável que

facilite a comunicação entre a plataforma e o
usuário com mensagens simples, explicativas.

RNF2 Segurança Autenticação de usuários para fazer uso das

funcionalidades da plataforma.

RNF3 Manutenibilidade A plataforma será desenvolvida com as boas

práticas de desenvolvimento, a fim de facilitar a
manutenção da plataforma.

RNF4 Disponibilidade A plataforma deverá funcionar 24 x 7 (vinte e

quatro horas por dia, sete dias por semana). Por
isso é necessário que o sistema seja hospedado
em uma provedora de hospedagem de sites, a
fim de ter réplicas de servidores para dar suporte
sempre que houver problemas com o servidor
principal.

19
 Tabela 2: Requisitos Não Funcionais

2.7. Modelação do Sistema

2.7.1. Diagrama de Caso de Uso

Considerando os requisitos descritos anteriormente, é possível modelar as funcionalidades do

sistema proposto. Para isso, inicialmente, é apresentado na figura 1 o diagrama de casos de
uso do sistema. Dos três atores do sistema (utente, gestor de clinica e administrador), apenas o
administrador tem acesso à todas as funcionalidades do sistema.

20
 Figura 1: Diagrama de caso de uso

2.7.2. Diagrama de Actividades

A figura 2 é referente a um diagrama aonde representamos o fluxo de actividades necessários

para a realização do caso de uso localizar clínicas.

21
 Figura 2: Diagrama de Actividades

2.7.3. Diagrama de Sequência

Na figura 3 apresentamos o diagrama de sequência que ilustram as interacções entre objectos

num determinado período de tempo realizada pelo sistema. Esta figura faz menção ao caso de
uso marcar consulta.

22
 Figura 3: Diagrama de Sequência

2.7.4. Diagrama de Classe

Na figura 4 apresentamos o diagrama de classe do sistema, onde nos mostra como o sistema
está constituído internamente e as relações entre si.

23
 Figura 4: Diagrama de Classe

2.7.5. Modelo Conceitual

Na figura 5 apresentamos o modelo conceitual, este modelo descreve as informações em uma

realidade, as quais irão estar armazenadas em uma base de dados, relacionamento e as
cardinalidades.
24
 Figura 5: Modelo Conceitual

2.7.6. Dicionário de Dados

Um dicionário de dados é uma coleção de dados que contem características logicas dos dados
que serão utilizados na modelagem do modelo lógico.

Apresentamos o dicionário de dados da plataforma de localização de clínicas de

especialidades e marcação de consultas.

25
 Tabela Município

Atributos Tipo de Dados Permissão Chave

MunicipioId Int Não Nulo Primária

Municipio Varchar(50) Não Nulo

Tabela 3: Tabela Município

 Tabela Distrito

Atributos Tipo de Dados Permissão Chave

DistritoId Int Não Nulo Primária

Distrito Varchar(50) Não Nulo
MunicipioId Int Não Nulo Estrangeira
Tabela 4: Tabela Distrito

 Tabela Bairro

Atributos Tipo de Dados Permissão Chave

BairroId Int Não Nulo Primária

Bairro Varchar(50) Não Nulo

DistritoId Int Não Nulo Estrangeira
Tabela 5: Tabela Bairro

 Tabela Rua

Atributos Tipo de Dados Permissão Chave

RuaId Int Não Nulo Primária
Rua Varchar(50) Não Nulo
BairroId Int Não Nulo Estrangeira
Tabela 6: Tabela Rua

 Tabela Tipo de Usuario

26
 Atributos Tipo de Dados Permissão Chave
TipoUsuarioId Int Não Nulo Primária
TipoUsuario Varchar(50) Não Nulo
Tabela 7: Tabela Perfil

 Tabela Usuario

Atributos Tipo de Dados Permissão Chave

UsuarioId Int Não Nulo Primária
Nome Varchar(50) Não Nulo
Email Varchar(50) Não Nulo
Passworduser Varchar(20) Não Nulo
DataRegisto Datetime Não Nulo
TipoUsuarioId Int Não Nulo Estrangeira
Foto Varchar(100) Não Nulo
Ativo Char(1) Não Nulo
Tabela 8: Tabela Usuário

 Tabela Especialidade

Atributos Tipo de Dados Permissão Chave

EspecialidadeId Int Não Nulo Primária
NomeEspecialidade Varchar(50) Não Nulo
Tabela 9: Tabela Especialidade

 Tabela Utente

Atributos Tipo de Dados Permissão Chave

UtenteId Int Não Nulo Primária
UsuarioId Int Não Nulo Estrangeira
Telemovel Int Não Nula
Tabela 10: Tabela Utente

 Tabela Admin

27
 Atributos Tipo de Dados Permissão Chave
AdminId Int Não Nulo Primária
UsuarioId Int Não Nulo Estrangeira
DataRegisto DateTime Não Nulo
Tabela 11: Tabela Administrador

 Tabela Clinica

Atributos Tipo de Dados Permissão Chave

ClinicaId Int Não Nulo Primária
HoraTrabalho Varchar(6) Não Nulo
AdminId Int Não Nulo Estrangeira
UsuarioId Int Não Nulo Estrangeira
LongitudeClinica Varchar(100) Não Nulo
LatitudeClinica Varchar(100) Não Nulo
HoraTrabalho Varchar(
RuaId Int Não Nulo Estrangeira
Tabela 12: Tabela Clinica

 Tabela Exame

Atributos Tipo de Dados Permissão Chave

ExameId Int Não Nulo Primária
Exame Varchar(50) Não Nulo
EspecialidadeId Int Não Nulo Estrangeira
Tabela 13: Tabela Exame

 Tabela Marcação de Consulta

Atributos Tipo de Dados Permissão Chave

MarcacaoId Int Não Nulo Primária
DataMarcacao DateTime Não Nulo
HoraConsulta Time Não Nulo
EspecialidadeId Int Não Nulo Estrangeira
ClinicaId Int Não Nulo Estrangeira
UtenteId Int Não Nulo Estrangeira
DataRegisto DateTime Não Nulo

28
 Tabela 14: Tabela Consulta

 Tabela Exame Clinica

Atributos Tipo de Dados Permissão Chave

ExameId Int Não Nulo Primária, Estrangeira
ClinicaId Int Não Nulo Primária, Estrangeira
PrecoExame Numeric(6,2) Não Nulo
Tabela 15 : Tabela Exame Clinica

 Tabela Gestor Clinica

Atributos Tipo de Dados Permissão Chave

GestorId Int Não Nulo Primária
ClinicaId Int Não Nulo Estrangeira
DataRegisto DateTime Não Nulo
Tabela 16 : Tabela Gestor Clinica

 Tabela Médico

Atributos Tipo de Dados Permissão Chave

MedicoId Int Não Nulo Primária
Nome Varchar(100) Não Nulo
NOM Varchar(10) Não Nulo
Tabela 17 : Tabela Medico

 Tabela Especialidade Clínica

Atributos Tipo de Dados Permissão Chave

EspecialidadeId Int Não Nulo Primária, Estrangeira
ClinicaId Int Não Nulo Primária, Estrangeira
Tabela 18 : Tabela Especialidade Clínica

 Tabela Especialidade Medico

29
 Atributos Tipo de Dados Permissão Chave
EspecialidadeId Int Não Nulo Primária, Estrangeira
MedicoId Int Não Nulo Primária, Estrangeira
Tabela 19 : Tabela Especialidade Médico

 Tabela Medico Clínica

Atributos Tipo de Dados Permissão Chave

MedicoId Int Não Nulo Primária, Estrangeira
ClinicaId Int Não Nulo Primária, Estrangeira
Estado bit Não Nulo
GestorId int Não Nulo Estrangeira
Tabela 20 : Tabela Médico Clínica

 Tabela CalendarioClinica

Atributos Tipo de Dados Permissão Chave

DataCalendario Date Não Nulo Primaria
HoraAtendimento Time Não Nulo Primaria
MedicoId Int Não Nulo Primária, Estrangeira
ClinicaId Int Não Nulo Primária, Estrangeira
EstadoCalendario bit Não Nulo
DataRegisto DateTime Não Nulo
GestorId int Não Nulo Estrangeira
Tabela 21 : Tabela Calendário Clínica

30
2.7.7. Modelo Lógico

A partir do modelo conceitual, criamos o modelo lógico como mostra a figura 6, este modelo
mostra as chaves primárias, estrangeiras e as relações entre as entidades.

31
 TbExameClinica
TbExame
ExameId
TbClinica ExameId
ClinicaId ClinicaId
Exame
Clinica PrecoExame
Especialid adeId
Email

Telefone

HoraTrabalho

Imagem
TbEspecialidadeClinica
LatiitudeClinica ClinicaId TbEspecialidade
EspecialidadeId
LongitudeClinica Especialid adeId
Especialidade
RuaId
TbUsuario
UsuarioId

Nome TbTipoUsuario
TbAdmin Email Tip oUsuarioId

TbRua AdminId PassWordUser Tip oUsuario

RuaId DataRegis to Foto

Rua
TipoUsuario Id
BairroId Ativo
TbMarcacao
MarcacaoId

DataMarcacao

HoraConsulta TbUtente
UtenteId
TbBairro ClinicaId TbEspecialidadeMedico
BairroId Telemovel MedicoId
EspecialidadeId
Bairro DataRegisto Especialid adeId

Dis tritoId

TbCalendarioMedico
TbDistrito CalendarioId
Dis tritoId TbMedico
DataCalendario MedicoId
Dis trito
HoraAtendimento NomeMedico
Municipio Id
ClinicaId NOM
TbGestorClinica
GestorId GestorId

ClinicaId

DataRegisto
TbMunicipio
Municipio Id
TbMedicoClinica
Municipio
Medic oId

ClinicaId

Estado

GestorId

Figura 5: Modelo Lógico

CAPÍTULO 3 - RESULTADOS

3.1. Introdução a plataforma Consulting Clinic

A plataforma Consulting Clinic foi desenvolvido para facilitar os utentes na localização de
clinicas de especialidades e na marcação de consultas.

32
A plataforma Consulting Clinic tem 3 tipos de usuários registados na base de dados que são:
Utente, Clinica, Admin, os utilizadores utentes vão poder fazer uso das seguintes
funcionalidades: Marcar consultas, Ver a localização das clinicas e fazer a impressão das
marcações feitas pelos utentes ou guardar como formato pdf, os utilizadores Gestor de
clinicas vão poder ver as marcações de consultas feitas pelos utentes, atualizar as suas
informações, registar especialidades e ver as especialidades registadas. O utilizador Admin
vai fazer a gestão dos outros utilizadores.

3.2. Interface do Sistema

3.2.1 Página de Login

A figura 6 apresenta a página de Login do sistema, onde os utilizadores terão que inserir as
suas credencias para poder fazer uso das funcionalidades do sistema.

Figura 6 : Página de Login

33
3.2.2. Registo de Utente
Esta figura 7 nos apresenta a página de registo de utente, o registo de utente é feito por um
utilizador anonimo, esta funcionalidade atende ao requisito funcional registar utente.

Figura 7: Página de Registo de Utente

3.2.3. Registo de Clínicas
Esta figura 8 é a página de registo de clinicas, onde o administrador preenche os dados da
clinica, esta funcionalidade atende ao requisito funcional Registar clinicas.

Figura 8 : Página de Registo de Clínica

3.2.4. Página de Consulta de Clínicas

Esta figura 9 é a página onde o administrador do sistema visualiza todas as clinicas registadas,
com a opção de editar os dados das clinicas e ver as informações de cada clinica.

Figura 9: Página de Consulta de Clínicas

35
3.2.5. Página de endereço das clínicas
Esta é página onde o utente visualiza todas as clinicas registadas na plataforma Consulting
Clinic, e a partir desta página o utente veja o endereço das clinicas e tem a opção de fazer a
marcação de consulta.

Figura 10: Página de Endereços de Clínicas

36
 CONCLUSÃO

Neste trabalho de conclusão de curso é o desenvolvimento de um sistema de localização de

clinicas de especialidade e marcação de consultas para a província de Luanda, para o
desenvolvimento deste sistema definimos alguns objectivos específicos que ajudou-nos a
atingir o objectivo geral. A escolha da metodologia ajudou no levantamento dos requisitos.

Chegou-se a conclusão que o presente trabalho veio ajudar os utentes devido os problemas na
localização de clinicas de especialidades. Os problemas encontrados relacionados com: a
localização de clinicas e marcação de consultas e muitos outros, serão resolvidas com a
implementação da plataforma Consulting Clinic.

Com a plataforma Consulting Clinic em funcionamento, será possível marcar consultas sem
sair de casa e ver os preços das consultas nas respectivas clinicas.

RECOMENDAÇÃO

Recomendamos que em próximas versões sejam adicionadas mais funcionalidades ao sistema

como: escolher o médico para a consulta, um chat para interação entre os utentes com as
respectivas clinicas.

37
 BIBLIOGRAFIA

Livros:

Chamusca, Marcello e Carvalhal, Márcia. 2011. Comunicação e Marketing Digitais:

conceitos, práticas, métricas e inovações. Salvador, BA : Edições VNI, 2011.

Guedes, Gilleanes T.A. 2005. Guia de Consulta Rápida UML 2. s.l. : Novatec Editora, 2005.

Machado, Felipe Nery Rodrigues e Abreu, Maurício Pereira de. 2004. Projecto de Banco
de Dados: Uma Visão Prática. s.l. : Editora Érica Ltd, 2004.

Mendes, Antonio. 2002. Arquitetura de Software: desenvolvimento orientado para

arquitetura. s.l. : Campus, 2002.

Pressman, Roger S. 2011. Engenharia de Software 7° Edição - Uma Abordagem

Profissional. s.l. : AMGH, 2011.

Sommerville, Ian. 2011. Engenharia de Software. São Paulo : Peason Education, 2011.

Sousa, Maria e Baptista, Cristina. 2011. Como fazer Investigação,Disertações, Testes e

Relatórios. Lisboa : Pactor, 2011.

Sites:

1. DEVMEDIA. devmedia.com.br. devmedia.com.br. Disponivel em:

https://www.devmedia.com.br/introducao-ao-padrao-mvc/29308. Acesso em: 23 Abril
de 2019

2. Henrique. 2014. Introdução ao ASP.NET MVC. Devmedia. Disponivel em:

https://www.devmedia.com.br/introducao-ao-asp-net-mvc/31878. Acesso em: 24 de
Julho de 2019

3. Hudson. 2017. DEVMEDIA. www.devmedia.com.br. Disponivel em:

https://www.devmedia.com.br/atividades-basicas-ao-processo-de-desenvolvimento-
de-software/5413. Acesso em: 29 Julho de 2019

4. Pacievitch, Yuri. InfoEscola : Navegando e Aprendendo. InfoEscola. [Online]

https://www.infoescola.com/informatica/sql-server/. Acesso em: 25 de Abril de 2019