Implementação de Clínica Odontológica Online Afrodente

Universidade Metodista de Angola
Faculdade de Engenharia
Curso de Engenharia Informática
Implementação de Clínica Odontológica Online Afrodente
Autor:
Vanderson de Abreu Teixeira de Carvalho
Orientador:
Professor MSc. Henriques Fernando
Luanda, Junho/2019.
Vanderson de Abreu Teixeira de Carvalho
Implementação de Clínica Odontológica Online Afrodente
Monografia de Conclusão de Curso de

graduação, apresentado à disciplina de Projecto
II, do Curso de Engenharia Informática da
Universidade Metodista de Angola como pré-
requisito para a obtenção do título de licenciado.
Orientado pelo Professor MSc. Henriques

Fernando
Luanda, Junho/ 2019.
Banca Examinadora:
Presidente:
____________________
1º Vogal
_______________________
2º Vogal
_______________________
Dedico este trabalho:
A minha querida Mãe, Berta Maria.
A minha querida irmã Vanusa.
E a todos aqueles que de forma directa

ou indirecta me ajudaram ao longo
desses anos todos
ii
Agradecimentos
Primeiramente agradeço a Deus por ter me dado tanta força, nos momentos difíceis em
que tive muitas dificuldades e não sabia o que fazer. Só tu, Senhor, me deste forças para
continuar. Agradeço a minha mãe e irmã, família, amigos e namorada por sempre estarem do
meu lado, por terem-me apoiado incondicionalmente. O meu orientador e professor MSc.
Henriques Fernando, pelos seus inúmeros conselhos, palavras de estímulos, correcções e
incentivo, e que sempre disponibilizou o seu tempo para me ajudar. Muito obrigado!
Aos meus colegas por me terem dado muita garra, e incentivo, nas aulas e para manter
a calma, porque 53 cadeiras não foram nada fácies, ao Engenheiro Emoyene que me deu uma
grande ajuda no desenvolvimento deste projecto, aos meus companheiros, Milton de Carvalho
e Emerson Cabral e os demais, que me deram sempre aquele apoio incondicional, nunca vou
esquecer do carinho que tinham por mim.
iii
Resumo
Os sistemas de gestão tornaram-se um dos principais componentes dos sistemas de

informação das empresas. Levando em consideração a importância de as empresas terem um
sistema de gestão da informação, este projecto apresenta um protótipo de um sistema para
uma clínica odontológica. O projecto foi realizado seguindo a metodologia de engenharia de
software. Para o desenvolvimento do protótipo no padrão de sistemas Web, foram utilizadas
as linguagens de programação Html, PHP e Java, banco de dados MySQL, UML para a
modelação do sistema.
Na análise do sistema foram identificados os requisitos funcionais e os requisitos não
funcionais, foram desenvolvidos os casos de usos necessários, os diagramas de casos de uso,
diagramas de sequência e de classes.
Este sistema deve ser capaz de garantir a segurança dos dados, atendimento de
qualidade aos pacientes, reduzir custos operacionais e melhorar a qualidade de
funcionamento, proporcionando assim ao profissional da área maior controlo sobre suas
actividades.
Palavras-chave: Sistema de gestão, Clínica Odontológica.
iv
Abstract
The management systems have become one of the major components of the
companies’ information systems. Taking into consideration the importance of companies
having a system of information management, this project presents a prototype system for a
dental clinic. The project was carried out following the methodology of software engineering.
To develop the prototype in standard web systems were used programming languages HTML,
PHP and Java, MySQL database, UML for modeling system.
In the analysis of the system were identified functional requirements and
nonfunctional requirements, were developed the cases required use, the diagrams of use case,
sequence and class diagrams.
This system must be able to ensure data security, quality care to patients, reduce
operating costs and improve the quality of operation, thus providing the professional area
greater control over their activities.
Keywords: Management System; Dental Clinic
v
Lista De Abreviaturas E Siglas
UML - Unified Modeling Language ou linguagem de modelagem unificada

PHP - Personal Home Page ou Preprocesso de hipertexto
SQL - Structured Query Language ou Linguagem de Consulta Estruturada
MER - Modelo Entidade Relacionamento
HTML - Hyper Text Markup Language ou Linguagem de marcação de Hipertexto
vi
Índice
Dedicatória ................................................................................................................................ ii
Agradecimentos ....................................................................................................................... iii
Resumo ..................................................................................................................................... iv
Abstract ..................................................................................................................................... v
Lista de abrevaturas e siglas .................................................................................................. vi
Lista de Figuras ....................................................................................................................... ix
Lista de Tabelas ........................................................................................................................ x
Capítulo I - Introdução ............................................................................................................ 1
1.1 Introdução .................................................................................................................... 1
1.2 Definição do problema ................................................................................................ 1
1.3 Justificativa .................................................................................................................. 2
1.4 Delimitação do problema............................................................................................. 2
1.5 Objectivos .................................................................................................................... 3
1.5.1 Objectivo geral ......................................................................................................... 3
1.5.2 Objectivo específicos ............................................................................................... 3
1.6 metodologia ................................................................................................................. 4
Capítulo II - Estado da Arte .................................................................................................... 5
2.1 Considerações iniciais ................................................................................................. 5
2.2 Desenvolvimento de sistema integrado para gestão de clínica módulo gestão de
marcação de serviços e serviços ............................................................................................. 5
2.3 Sistema de gestão de dados clínicos ............................................................................ 8
2.4 Sistema para clínica odontológica (sco): gerenciamento de agendamento ............... 12
2.5 Sistema web gerenciador de clínica médica: automatizando a clínica cardiomed .... 15
2.6 Conclusões do capítulo .............................................................................................. 18
Capitulo III - Clínica Odontológica Online (Afrodente) .................................................... 19
3.1 Considerações iniciais ............................................................................................... 19
3.2 Descrição do sistema ................................................................................................. 19
3.3 Análise do sistema ..................................................................................................... 20
3.3.1 Regras de Negócios................................................................................................ 20
vii
3.3.2 Requisitos Funcionais ............................................................................................ 22
3.3.3 Requisitos Não Funcionais .................................................................................... 23
3.3.4 Diagrama de caso de uso........................................................................................ 24
3.3.5 Descrição de casos de uso ...................................................................................... 28
3.4 Diagrama de sequência .............................................................................................. 33
3.5 Diagrama de colaboração .......................................................................................... 36
3.6 Desenho do sistema ................................................................................................... 37
3.6.1 Modelo de Entidade Relacionamento ........................................................................ 37
3.6.2 Modelo conceitual ..................................................................................................... 38
3.6.3 Modelo lógico ............................................................................................................ 38
3.6.4 Diagrama de classes................................................................................................... 39
3.6.5 Arquitectura do sistema ............................................................................................. 41
3.6.6 Arquitectura de hardware .......................................................................................... 42
3.6.7 Conclusões do capítulo .............................................................................................. 42
Capítulo VI - ConsideraçõesFinais ....................................................................................... 43
4.1 Conclusões ................................................................................................................. 43
4.2 Trabalhos futuros ....................................................................................................... 44
4.3 Sugestões ................................................................................................................... 44
Referências Bibliográficas ..................................................................................................... 45
Apêndice .................................................................................................................................. 46
viii
Lista de Figuras
Figura 2.1 – Arquitectura do sistema (módulo gestão de marcações) .............................................. 7

Figura 2.2 – Estrutura modular (Sistema de Gestão de Dados Clínicos) ....................................... 10
Figura 2.3 -Estrutura do Sistema (Gerenciamento de agendamento) ............................................. 13
Figura 2.4 -Estrutura do Sistema (Automatizando a Clínica CARDIOMED) ............................... 17
Figura 3.1 - Modelo Arquitectural do Sistema ............................................................................... 19
Figura 3.2 – Diagrama de Caso de Uso do Sistema ....................................................................... 24
Figura 3.3 – Caso de uso Secretária ............................................................................................... 25
Figura 3.4 – Caso de uso Dentista .................................................................................................. 26
Figura 3.5 – Caso de uso Paciente .................................................................................................. 26
Figura 3.6 – Caso de uso Administrador ........................................................................................ 27
Figura 3.7 – Diagrama de sequência Registar Dentista.................................................................. 34
Figura 3.8 – Diagrama de sequência Registar Secretária ............................................................... 34
Figura 3.9 – Diagrama de sequência Registar Paciente ................................................................. 35
Figura 3.10 – Diagrama de sequência Registar Agenda................................................................. 35
Figura 3.11 – Diagrama de sequência Registar Agendamento....................................................... 36
Figura 3.12 – Diagrama de colaboração Registar Paciente ............................................................ 36
Figura 3.13 – Diagrama de colaboração Registar Agendamento ................................................... 37
Figura 3.14 – Modelo Conceitual ................................................................................................... 38
Figura 3.15 – Modelo Lógico ......................................................................................................... 39
Figura 3.16 – Diagrama de classe .................................................................................................. 40
Figura 3.17 – Arquitectura de Software ......................................................................................... 41
Figura 3.18 – Arquitectura de HW ................................................................................................. 42
Figura B.1 Tela Página Inicial ........................................................................................................ 47
Figura B.2 Tela de Login ............................................................................................................... 47
Figura B.3 Tela de boas vindas secretária ...................................................................................... 48
Figura B.4 Tela de Registo de dentistas ......................................................................................... 48
Figura B.5 Tela de Registo de pacientes ........................................................................................ 49
Figura B.6 Tela de Agendamento de consultas .............................................................................. 49
Figura B.7 Tela de Plano de tratamentos ....................................................................................... 50
Figura B.8 Tela de Procedimentos executados .............................................................................. 50
Figura B.9 Tela de Orçamento ....................................................................................................... 51
Figura B.10 Tela de Pagamento ..................................................................................................... 51
Figura B.11 Tela de Movimento de caixa ...................................................................................... 52
Figura B.12 Tela de Registo de materiais ...................................................................................... 52
ix
Lista de Tabelas
Tabela 3.1 – Regras de Negócios ................................................................................................... 20

Tabela 3.2 – Requisitos Funcionais ................................................................................................ 22
Tabela 3.3 – Requisitos Não Funcionais ........................................................................................ 23
Tabela 3.4 – Descrição de Caso de uso “Registar Dentista” .......................................................... 28
Tabela 3.5 – Descrição de Caso de uso “Registar Secretária” ....................................................... 29
Tabela 3.6 – Descrição de Caso de uso “Registar Paciente” .......................................................... 30
Tabela 3.7 – Descrição de Caso de uso “Registar Agenda” ........................................................... 31
Tabela 3.8 – Descrição de Caso de uso “Registar Agendamento” ................................................. 32
x
Capítulo I - Introdução
Este capítulo trata de abordar a importância do tema, os objectivos que se pretendem

atingir, bem como o problema encontrado, a metodologia do processo de desenvolvimento e a
justificação do trabalho a ser realizado.
1.1 Introdução
A actualização de tecnologias hoje é constante, tendo que cada dia se adaptar a novos
métodos e padrões. Para acompanhar essas tecnologias são necessárias actualizações
periódicas de sistemas existentes, para que em um futuro próximo não se tornem obsoletos.
Este relatório relata o desenvolvimento de um sistema Online para Clínica
Odontológica (Afrodente), o sistema está dividido em três módulos, mencionados na secção
3.3 do capítulo 3.
O Sistema é para uma Clínica especializada na área de Odontologia. Com este sistema
pretende colmatar as necessidades de uma clínica Odontológica que busca melhorar o registo
dos dados no sistema, o atendimento dos seus pacientes, e fazer de melhor forma a gestão das
suas informações interna.
Uma clínica odontológica tem a função de atender pessoas que possuem algum tipo de
problema bucal, principalmente nos dentes ou ainda simplesmente examinar com frequência a
situação bucal destas. Portanto, existem informações sobre os pacientes muito pertinentes ao
contexto odontológico que devem ser organizadas e armazenadas para futuras consultas.
Os módulos propostos foram desenvolvidos usando as ferramentas, StarUML para
toda a modelagem do sistema, o PHP para o desenvolvimento da aplicação Web, e o Mysql
para o armazenamento de dados usando a ferramenta PhpMyAdmin.
1.2 Definição do problema
A clínica odontológica Afrodente Angola, desde o início de suas actividades, realiza o

registo de seus clientes e agendamento de consultas, pagamento de consultas e recebimento de
clientes manualmente. Ao realizar estas actividades desta maneira ocorre lentidão no trabalho,
perda de dados, confusões na busca de dados para consultas e erro de cálculos em
recebimento de clientes e pagamento de consultas.
1
Uma das dificuldades da clínica é a realização de agendamento de consultas, onde
podem ocorrer enganos e perda de informações. Em caso de uma consulta de histórico de
cliente há muita dificuldade, pois as actividades de agendamento de consultas são efetuadas
manualmente e os registos podem acabar ficando desorganizado e até mesmo serem
armazenadas com informações de outro cliente.
A inexistência de um odontograma (prontuário odontológico com imagem) online,

para registar a situação em que se encontra cada elemento dentário, a fim de se criar o plano
de tratamento adequado, é outro problema encontrado. Uma vez que a clínica ainda usa
formulários em formato papel, o que dificulta muito na pesquisa das informações na hora do
tratamento, devido as quantidades de registos gerados.
1.3 Justificativa
O que motivou o desenvolvimento deste projecto foi o uso de novas tecnologias e

técnicas de desenvolvimento que estão sendo utilizadas no mercado. Além de tudo, como
principal motivação, a necessidade de informatização da clínica, que até a presente data de
conclusão deste projecto, trabalha de forma manual, desde o registo de clientes até o
agendamento de consultas entre outras actividades. Os registos são feitos em fichas e
arquivadas em pastas, já as consultas são agendadas utilizando agendas, podendo ocasionar
uma perda de informações e o histórico do cliente.
Sendo assim, torna-se de suma importância a informatização da mesma. Com o
sistema de gestão, não haverá perda de informações, as actividades desenvolvidas serão
efetuadas de forma rápida, eficiente e de fácil manuseio, trazendo satisfação ao cliente.
Espera-se que com o desenvolvimento deste projecto, possa atender as necessidades da
clínica e que não tenham mais dificuldades com a manipulação de seus dados.
1.4 Delimitação do Problema
Este projecto limita-se na criação de sistema de gestão eficiente que visa melhorar os
métodos de atendimento a consulta dos pacientes, agendamento de consulta, armazenamento
do histórico médico do paciente, geração de uma agenda com datas das disponibilidades de
cada dentista.
2
Numa primeira fase o sistema só irá abranger as áreas, recursos humanos (relacionado
com a geração de agendas com datas das disponibilidades de cada dentista), facturação,
contabilidade, tesouraria (na marcação de consulta) e na área clínica (no que concerne o
registo integral dos funcionários, pacientes, agendamentos, odontogramas, exames e
procedimentos realizados).
A área de finanças, não possuí ainda um subsistema de informação não serão
abrangidas pelo sistema a ser desenvolvido.
1.5 Objectivos
Objectivos bem definidos proporcionam um caminho para o alcance dos resultados e

propósitos desejados.
1.5.1. Objectivo Geral
Desenvolver um protótipo de software que será utilizado para gerir um consultório

odontológico, capaz garantir a segurança dos dados, atendimento de qualidade aos pacientes,
reduzir custos operacionais e melhorar a qualidade de funcionamento, proporcionando assim
ao profissional da área maior controlo sobre suas actividades.
1.5.2. Objectivos Específicos
Os objectivos específicos que se pretende alcançar nesta proposta são:
 Criar subsistema de controlo de consulta dos Pacientes: Subsistema que permite manter
o histórico dos procedimentos realizados das consultas de cada paciente;
 Criar subsistema de Agendamento de Consultas: Subsistema que permite o fazer o
controlo dos agendamentos das consultas marcadas;
 Criar subsistema de controlo de Pagamentos: Subsistema que permite o fazer o controlo
dos pagamentos dos orçamentos gerados por cada consulta realizada.
3
1.6 Metodologia
Para desenvolvimento deste trabalho foram realizadas algumas visitas a Clínica

Afrodente, e entrevistas com alguns trabalhadores, principalmente da área administrativa, com
intuito de obter mais informações sobre a clínica e suas respectivas actividades, de modo a
obter informações necessárias que me permitiram avaliar as necessidade para desenvolver
então uma aplicação que pudesse padronizar e facilitar cada tarefa realizada na clínica.
Para um melhor desenvolvimento do projecto, levando em conta a pouca experiência
que tenho e a falta de equipas para desenvolvimento deste projecto decidi adoptar o modelo
clássico ou sequencial como Metodologia de Desenvolvimento de Software. Para o modelo
escolhido realizei as seguintes actividades:
a) Planeamento: Tendo em conta a disponibilidade da área administrativa da Clínica em
fornecer informações necessárias, baseei-me nas informações dada nas visitas e em
relatórios para reter as informações necessárias;
b) Análise de Requisitos: analisou-se o que deve fazer e não fazer, o que será
implementado, fez-se ainda a aquisição, refinamento e verificação das necessidades do
sistema;
c) Projecto: Após a conclusão da fase de análise de requisitos foi feita a criação dos
artefactos e diagramas de forma a ilustrar melhor a interligação dos diferentes módulos
do sistema e o fluxo de informação existente entre eles, partes e componentes do
sistema;
d) Codificação: A aplicação foi codificada usando as linguagens de programação HTML5
e Php, para a Base de Dados usei o MySql, servidor Web o Apache e a ferramenta
EasyPHP tendo em conta que é um aplicativo que alberga as ferramentas (Apache, Msql
e Php) e por último para a construção dos diagramas a ferramenta StarUML;
e) Teste: Realizarei somente os testes ao sistema.
4
Capítulo II - Estado da Arte
2.1 Considerações Iniciais
O estado da arte ou estado do conhecimento traz o desafio de mapear e discutir temas

de produções académicas em diferentes campos, os mesmos são considerados uma das partes
mais importantes de um trabalho científico, onde nos aprofundamos em conhecimentos que já
foram estudados. O estado da arte tem o papel de colectar o maior número possível de
informações relevantes sobre o assunto que se pretende estudar.
Neste capítulo são apresentados (4) trabalhos realizados na área e que representam as
maiores contribuições ao estado da arte actual.
2.2. Desenvolvimento de Sistema Integrado para gestão de Clínica

Módulo Gestão de Marcação de Serviços e Serviços
O sistema de gestão de clínica abrangendo todos os serviços prestados na clínica e

todas as áreas de actuação (Recursos humanos, contabilidade, Administração etc.). Gere a
agenda Médica, as Consultas, as marcações das consultas, os pagamentos, o stock, entre
outros. É um projecto que vai revolucionar os serviços e a administração das clínicas médicas
em Cabo verde, contribuindo para um serviço mais rápido e eficiente [1].
Durante o desenvolvimento fez-se o uso de várias técnicas e ferramentas. As fases
realizadas são apresentadas a seguir:
 Levantamento de requisitos: Nesta fase definiu-se uma visão geral de como do

sistema, fez-se a compreensão do contexto do sistema, conhecendo as reais
necessidades, os objectivos e a viabilidade do sistema. Numa primeira fase foram
identificadas e conhecidas todas as necessidades do sistema. Necessidades essas
que permitiram conhecer a actual situação do problema a ser resolvido;
 Análise e especificação de requisitos: Posteriormente foi realizada a análise e
especificação de requisitos do mesmo, se fez principalmente através a
especificação de todos os requisitos que o sistema deverá conter através do
desenho lógico do respectivo sistema, fazendo a identificação de todas as
entidades e atributos que corresponde o sistema, com a construção do Modelo
Entidade - Relacionamento utilizando a ferramenta Ms Visio;
5
 Modelagem: Na fase de modelagem deste sistema, foram construídos vários
diagramas, que representam desde a modelagem de dados, até a do sistema em sí.
Foi feito o Modelo físico, o Diagrama de Caso de Utilização, O Diagrama de
transacção de Estado e o Diagrama de Classe. Para a construção do modelo físico
(Diagrama E-R), no Visual Paradigm;
 Implementação: Por fim, realizou-se uma secção prolongada de pesquisa
bibliográfica para o desenvolvimento do relatório e a implementação do sistema
por meio da plataforma Oracle Aplication Express 10g.
No decorrer do estágio foram utilizadas várias ferramentas e tecnologias para proceder

ao desenvolvimento do referido sistema.
 UML - A UML tem 9 tipos de diagramas que podem ser construídos ao longo de
desenvolvimento de um sistema:
 Visual Paradigm - Paradigm visual para UML é um poderoso e fácil e que torna
fácil a utilização de modelagem UML e ferramenta CASE.
 MS Visio - A Microsoft Office Visio 2007 torna fácil para a TI e para os
profissionais de negócios visualizar, analisar e comunicar informações complexas,
sistemas e processos porque utiliza diagramas.
 MS Project - O MS Project 2007 é um excelente aplicativo de gestão de projectos
que pode ser utilizado para planear, programar e representar graficamente as
informações sobre projectos.
 Oracle Aplication Express 10G - O base de dados Oracle 10g oferece liberdade
para desenvolver e implementar aplicações em diversas plataformas e traz suporte
para uma grande variedade de ambientes de desenvolvimento.
 PL/SQL - PL/SQL é a linguagem de programação utilizada para programar o Base
de dados Oracle. Com o PL/SQL pode-se utilizar comandos SQL
A arquitectura do sistema está estruturado em dois módulos fundamentais

apresentados a seguir:
6
Figura 2.1 – Arquitectura do sistema (Módulo Gestão de Marcações)
Fonte: Adaptado Barbosa, (2010).
Módulo de Marcações: Onde são efectuados os pedidos de marcação de consultas,

exames e tratamentos. Também faz a gestão da chegada dos pacientes. Quando o paciente
chega e faz a solicitação de marcação, essa é automaticamente agendada numa data e hora e
colocada no relatório de marcação de serviços.
Módulo de Serviços: Módulo destinado aos médicos, onde efectuam a gestão dos
pacientes, e detalham as intervenções das consultas e respectivas actividades desencadeadas
(exames, Tratamentos, etc.). Permite também controlar todo o historial clínico do paciente.
Este módulo suporta as seguintes actividades:
 Marcação de serviços A recepcionista da clínica marca uma consulta na agenda,

com a identificação do tipo de consulta, identificação do paciente a que se destina
a consulta, motivo da consulta, data e hora da consulta e data da marcação (estes
dois últimos dados podem ser preenchidos automaticamente pelo sistema); Por
iniciativa do paciente, as consultas podem ser canceladas ou adiadas; deve ficar
registada a data do cancelamento ou adiamento, o motivo e a nova data e hora da
consulta;
 Realização de serviços No dia e hora marcados, o paciente deve apresentar-se na
recepção da clínica; se comparecer com mais do que 30 minutos de atraso, não há
nenhuma garantia de que seja atendido (se não poder ser atendido, considera-se
que faltou); O médico que realiza a consulta regista os seguintes dados médicos:
sintoma do paciente, resumo do exame clínico, resume do diagnóstico e
7
tratamentos prescritos; o médico pode consultar todos os dados do paciente,
incluindo consultas anteriormente realizadas e consultas marcadas, o Médico
também pode indicar uma nova consulta.
Como requisitos adiados foram destacados as seguintes funcionalidades

 Desenvolver os módulos de RH: Desenvolver um subsistema para melhorar
todos os processos que envolvem a gestão de pessoas da clínica, através dele
oferecer soluções que maximizem os resultados das principais tarefas do sector
de Recursos Humanos;
 Fazer a melhoria de rotina mediante o fluxo de dados existentes: Aumentar a o
desempenho do sistema através da economia de tempo, redução de custos de
memória e qualidade nos resultados.
2.3. Sistema de Gestão de Dados Clínicos
De todo o avanço tecnológico, o desenvolvimento da informática é, talvez, aquele que

mais directamente nos afecta. Cada vez mais a informática, e a tecnologia que a suporta,
fazem parte integrante do nosso dia-a-dia. Desde o mais simples gadget até ao nosso
computador portátil, passando por calculadoras, máquinas fotográficas e até por sistemas de
pagamento automático de portagens, a tecnologia está presente em todas as nossas actividades
[10].
Deste modo, para minimizar estas divergências, Desenvolveu-se o projecto para uma
aplicação para Centros Médicos Desportivos ou Gabinetes Médicos. Idealmente este software
permitiria o controlo de todos os processos. Poderia inclusivamente existir módulos adicionais
acerca das consultas/especialidades, controlo de fornecedores e controlo de stocks,
sms/mailing list, validação e visualização de relatórios on-line e até prescrição electrónica.
Esta aplicação deve estar preparada para processar e gerir rápida e eficazmente todo o volume
de informação. A agenda e controlo das marcações deverá ter um aspecto simples e intuitivo
de forma a permitir uma leitura fácil e rápida da ocupação da clínica. Deve ter grande
flexibilidade e personalização na definição dos horários, garantindo 35 uma maior
rentabilização dos recursos [10].
A aplicação deve utilizar uma arquitectura cliente/servidor, que irá questionar o

servidor de base de dados para aceder à informação desejada. Para permitir futuras evoluções,
8
esta deve estar estruturada de uma forma modular, que permita facilmente adicionar novos
módulos à aplicação.
O projecto foi desenvolvido seguindo o ciclo de desenvolvimento que contou com as

seguintes fases:
 Formulação do problema: consistiu em identificar os fenómenos, os objectos de

análise e à formulação de concepção do problema;
 Análise de requisitos: Consistiu em analisar as informações existentes obtidas na
fase anterior;
 Escolha do modelo de implementação: Consistiu na estruturação dos dados e na
escolha da parte gráfica;
 Implementação: Consistiu em implementar as relações lógicas já definidas, todo o
processo de implementação, recorrendo aos recursos e soluções disponíveis;
 Teste: Consistiu em testar a operacionalidade do sistema, funções e rotinas de
processamento a fim de corrigir eventuais falhas e potencializar o sistema.
Para a elaboração desta aplicação foi utilizado:
 Microsoft Visual Studio 2012 Ultimate (Ambiente Integrado de Desenvolvimento

que permite o desenvolvimento de aplicações para web, Windows e Windows
Phone) e a ASP.NET para a construção de 33 páginas dinâmicas e que permite
ligações a bases de dados.
 Linguagem C# que é uma linguagem orientada a objectos, criada pela Microsoft.
 A base de dados foi projectada com a ferramenta PowerDesigner 16.1 a partir da
qual se desenvolveu e criou a base de dados.
 O PowerDesigner é uma ferramenta de desenho de base de dados, que permite
criar os modelos conceptuais, lógicos e físicos.
 A aplicação foi desenvolvida na tecnologia Microsoft Visual Studio LightSwitch.
9
Figura 2.2 – Estrutura modular (Sistema de Gestão de Dados Clínicos)
Fonte: Adaptado Roque (2012).
Interligação entre os módulos: Os módulos do sistema trocam informação entre si

obedecendo uma estrutura lógica de módulos hierarquicamente superiores e inferiores, as
setas representam esta hierarquia existente entre os módulos do sistema, representam a
proveniência de informação de cada módulo.
Com base na análise do problema foram considerados os seguintes módulos a

implementar:
Módulo Gestão de Atletas: O módulo de gestão atletas deve permitir no mesmo

interface todas as operações possíveis de executar relativamente à informação dos atletas.
Neste interface deve permitir: Inserir a informação de um novo atleta; Alterar a informação de
um atleta já existente; Remover a informação de um atleta já existente; Pesquisar a
informação de atletas que existem na base de dados; Aceder à informação das consultas desse
paciente na Clínica.
Módulo Gestão de Consultas: O módulo de gestão de consultas deve permitir: Inserir

a informação de uma nova consulta; Alterar a informação de uma consulta já existente;
Remover a informação de uma consulta já existente.
Módulo Gestão de Médicos: O módulo de gestão de Médicos deve permitir: Inserir a

informação de um novo médico; Alterar a informação de um médico já existente; Remover a
informação de um médico já existente; Pesquisar a informação de médico que existe na base
de dados.
10
Módulo Gestão de Exames: O módulo de gestão de Exames deve permitir inserir a
informação de um novo exame: Aquando da inserção devem ser executadas as seguintes
operações: Geração automática do código interno que será associado a esse exame. Este
código deve ser gerado duma forma sequencial; Verificar se a informação introduzida satisfaz
as restrições definidas na base de dados: A designação não é nula e está escrita;
Módulo Gestão de Modalidades: O módulo de gestão de Modalidades deve permitir

inserir a informação de uma nova modalidade. Aquando da inserção devem ser executadas as
seguintes operações: Geração automática do código interno que será associado a essa
modalidade. Este código deve ser gerado duma forma sequencial e não deve ser visualizado
na aplicação; Verificar se a informação introduzida satisfaz as restrições definidas na base de
dados.
Módulo Gestão de Clubes: O módulo de gestão de Clubes deve permitir inserir a

informação de um novo clube. Aquando da inserção devem ser executadas as seguintes
operações: Geração automática do código interno que será associado a esse clube. Este código
deve ser gerado duma forma sequencial e não deve ser visualizado na aplicação; Verificar se a
informação introduzida satisfaz as restrições definidas na base de dados: A designação do
clube não é nula e está escrita;
Existem algumas funcionalidades que poderão ser implementadas para melhorar a

aplicação. Nem todos os requisitos foram cumpridos mas foi definido como meta
implementar as funcionalidades essenciais para a aplicação ser utilizada.
 Implementar lembretes enviados via SMS aos pacientes, com a data da consulta e
com o médico que realizará o atendimento, pode reduzir o número de atrasos e/ou
faltas dos pacientes às consultas;
 Outro melhoramento que pode ser implantado refere-se à possibilidade de realizar
a importação de planilhas em formato CSV no que diz respeito ao CID-10,
procedimentos médicos e índice de remédios pelo próprio sistema sem a
necessidade de intervenção do administrador.
11
2.4. Sistema Para Clínica Odontológica (SCO): Gerenciamento de Agendamento.
De todo o desenvolvimento da ciência da informação e a introdução dos computadores

no âmbito profissional trouxeram profundas transformações na odontologia beneficiando a
sociedade, promovendo soluções para simplificar e optimizar a vida, no intuito de agilizar,
tornar mais dinâmico o trabalho e automatizar processos repetitivos.
A obtenção da informação por meio electrónico reflecte positivamente no resultado do

atendimento com qualidade, pois a dificuldade e a perda de informação com prontuários
obsoletos e pouco precisos podem causar danos irreversíveis para o profissional e para o
paciente [2].
Assim surgiu a necessidade de desenvolver um sistema para gerenciar uma agenda

odontológica, mais abrangente, com registo completo do paciente, ficha de anamnese,
convénio e agenda do dentista, incluindo um 16 campo para anotações onde o profissional
descreve a consulta. O sistema controla o acesso pelo login e senha do utilizador registado. O
dentista entra com o login e senha e regista o utilizador do tipo funcionário que também tem
acesso para regista o paciente, pois na primeira consulta, o paciente visita a clínica para que
seja feito o seu registo e logo terá seu login e senha para acessar a agenda pela internet,
escolhe a data e horário da consulta e anota o motivo pela qual está consultando. O
profissional da área sentiu-se obrigado a adequar-se à nova realidade, agregando valor à
clínica [2].
O projecto foi desenvolvido seguindo as seguintes fases:
 Análise de requisitos: Para a fase de análise de requisitos foi capturada as

intenções e as necessidades dos utilizadores do sistema a ser desenvolvido através
do uso do diagrama de “caso de uso” (use-cases) que faz a interacção com o
utilizador (atores) e suas necessidades disponíveis mostrando o que o utilizador
espera do sistema conhecendo toda sua funcionalidade;
 Projecto: A fase de Design (Projecto) Foi a solução técnica, determinou como o
sistema funcionará para atender os requisitos assim novas classes foram
adicionadas para prover uma infra-estrutura técnica: a interface do Utilizador e de
periféricos, gerenciamento de base de dados, comunicação com outros sistemas,
dentre outros;
 Programação: A fase de programação foi uma fase separada e distinta, onde os
modelos criados foram convertidos em código da linguagem orientada a objectos;
12
 Testes: Na fase de testes O sistema foi testado pelo Utilizador final e verificou se
os resultados mostrados estavam realmente de acordo com as intenções do
Utilizador final.
Para a criação, foram utilizadas várias tecnologias como:
 Java Enterprise Edition (J2EE) linguagem de programação;

 Para a interface de desenvolvimento foi utilizada a ferramenta eclipse;
 A UML para modelagem de dados no auxílio ao desenvolvimento;
 MySQL como gerenciador de base de dados para armazenamento de dados;
 A tecnologia AJAX foi utilizada na aplicação com o intuito de tornar as interfaces
mais dinâmicas e interactivas para o Utilizador.
 Para edição de imagens utilizou-se GIMP, Inkscape e Flash.
Figura 2.3 -Estrutura do Sistema (Gerenciamento de agendamento)
Fonte adaptado Costa, (2010).
Interligação entre os módulos: A estrutura modular do sistema demonstra como os

módulos estão ligados e a ordem de envio de dados que suportam cada um deles, o módulo de
agendamento e o módulo de relatórios são módulos que maior fluxo de informação recebem
por serem módulos que estão directamente relacionados com os demais e necessitam de maior
informação para atender a demanda de processamento de dados e operações.
Módulo de autenticação: Para utilizadores web, é necessário fazer a primeira

consulta no consultório e a secretária faz o registo, assim o paciente adquire um login e senha
para acessar e então logar pelo site para agendar seu dia e horário, lembrando que é um pré-
13
agendamento; a secretária entra em contacto para confirmar o dia e horário. O sistema verifica
se login está registado, na base de dado, se não estiver, o sistema emite mensagem “Login
informado 67 não existe!”, se existir, então faz uma comparação com a senha digitada, se a
senha for incorrecta, o sistema emite mensagem “Senha Incorrecta!”. Se o login e senha
forem válidos, o sistema habilita, no menu ao lado esquerdo da página, e os botões de acesso
para cada tipo de utilizadores.
Módulo de registo: permite realizar operações relacionadas a Registar dentista,

convénios e amanenses.
 Registo de Dentista: O Utilizador do tipo administrador solicita registo e digita o

login do dentista escolhido, ao perder o foco do campo login, uma função
JavaScript verifica na base de dados se login existe, se não existe, o sistema emite
mensagem: “Não existe dados do DENTISTA no sistema!”, assim possibilitando a
inserção de um novo dentista. Após o preenchimento correcto de todos os campos,
o Utilizador deve clicar no botão Registar, assim os dados são enviados para o
servidor e ele envia para a base de dados para que possa salvá-los. Ao clicar no
botão limpar, os dados digitados nos campos são apagados da tela para que novos
dados sejam inseridos;
 Registo de convénio: O sistema verifica no base de dados se existe razão social, se
existir ele emite mensagem “Convénio informado: -razão social já existe”, assim o
sistema possibilita a entrada de novos dados e, ao clicar no botão Registar, os
dados são enviados para o servidor e ele envia para a base de dados para que possa
salvá-los. Se o dentista clicar em limpar, o conteúdo do campo razão social é
apagado para que um novo convénio seja inserido;
 Registo de anamnese: uma ficha de diagnóstico do paciente, onde o Utilizador do
tipo interno solicita o registo e escolhe o nome do paciente, e preenche o restante
dos dados. Além de Registar os dados, ao clicar em limpar, os dados digitados nos
campos são apagados da tela para que novos dados sejam inseridos. Nos campos
doença, medicamentos e alergia, foi utilizada uma função JavaScript para mostrar
o limite de caracteres de cada campo.
Módulo de Agenda: Tem por objectivo gerar a agenda do dentista, onde o Utilizador
interno escolhe o dentista, digita a data inicial, data final, hora inicial, hora final e escolhe o
intervalo de tempo que o dentista atende seus pacientes. Ao clicar no botão “GERAR
AGENDA”, os dados são salvos na base de dados, assim ele disponibiliza as datas e horários
14
ao sistema e, a partir deste ponto, os horários podem ser agendados localmente ou pela web; o
botão limpar remove todos os dados dos campos para que possa adicionar novos dados.
Módulo de agendamento: O utilizador deve fazer a primeira consulta na clínica,

assim o utilizador interno faz o registo e o paciente adquire um login e senha para que possa
agendar pela web. Ao logar, o Utilizador é gravado na sessão, assim aparece o nome completo
do utilizador logado no campo paciente, o cliente escolhe o dentista, para escolher a data o
paciente deve anotar o dia da consulta no campo “Digite uma data para o agendamento”. É
usada uma função JavaScript que recupera o valor do campo data e faz a busca na base de
dados, assim exibindo todos os horários disponíveis para a data escolhida.
Módulo de relatórios: O utilizador do tipo interno clica no botão “Horários

Registados” e exibe na tela todos os horários registados gravados no base de dados, por ordem
de data e horário possibilitando a exclusão ao lado direito do relatório um link “Excluir”.
Assim o utilizador interno remove a data e horário dos pacientes Registados. No campo
telefone web é uma forma de diferenciar o utilizador web do interno, sendo um campo de
preenchimento obrigatório ao agendar; o Utilizador interno visualiza na tela o telefone e
precisa confirmar a consulta ao clicar no link “Confirmar”; o campo telefone é alterado.
Como sugestão de trabalhos futuros fica:
 A necessidade de completar a implementação do sistema devido à complexidade

deste projecto foram desenvolvidas apenas as funções de maior importância para o
funcionamento do agendamento, no entanto dependendo a especialidade de cada
profissional;
 A necessidade de melhorar a performance do sistema completando a
implementação do módulo financeiro, odontograma (prontuário odontológico com
imagem);
 O desenvolvimento de uma função que possibilite dar ao paciente prioridade na
marcação de um horário para atendimento com urgência (encaixar horários).
2.5. Sistema Web Gerenciador de Clínica Médica: Automatizando a Clínica

CARDIOMED.
A evolução e a globalização do comércio propiciaram uma série de benefícios aos

homens, mas também diversos problemas. Entre os mais diversos problemas estão às doenças
15
causadas pelas mais diversas origens. Este recrudescimento tornou a assistência médica do
estado inviável. Neste cenário, surgiram as clínicas médicas, cujo objectivo é o atendimento
de pacientes enfermos. Elas surgiram e logo se tornaram congestionadas pela burocracia e
controles médicos. Todos conhecem os enormes problemas causados pelo ineficiente e
arcaico sistema de arquivamento médico em papel, que vão desde a tradicional ilegibilidade
das anotações médicas, até a perda de informações ou a dificuldade de achar qualquer coisa
[11].
Para controlar e gerir as clínicas, então, surge o Sistema de Informação (SI), cujo
objectivo é auxiliar os profissionais médicos na obtenção de informações do histórico dos
pacientes. A maior vantagem da utilização de um SI é poder proporcionar melhor atendimento
e tratamento de problemas de saúde dos pacientes, obtendo maior controle e rapidez nas
informações necessárias. O SI permite o acesso rápido e sigiloso ao seu histórico, gerando um
prontuário electrónico disponível de qualquer parte, ao médico e ao paciente [11].
O objectivo principal do trabalho é desenvolver um sistema de informação para

gerenciamento das informações das consultas da clínica médica CardioMed, utilizando
ambiente Web. Os objectivos específicos do trabalho são:
 Possibilitar melhor controlo dos agendamentos das consultas na CardioMed através de

sistema informatizado;
 Disponibilizar e agilizar a emissão de receitas e laudos médicos através do sistema
informatizado;
 Permitir criação de histórico das receitas e laudos médicos repassados aos pacientes da
clínica através do armazenamento em base de dados.
Baseada nas técnicas de análise orientada a objectos o desenvolvimento do projecto

obedeceu as seguintes fases:
 Levantamento de Requisitos: Nesta fase descreveu-se a finalidade do projecto,

resumiu-se o processo padrão adoptado no cliente, as expectativas, quais as
funcionalidades que o projecto do sistema deverá contemplar, e identificou-se o
sistema possuirá interface;
 Desenho: Após a conclusão da fase de levantamento de requisitos foi feita a criação
dos artefacto se diagramas de forma a ilustrar melhor a interligação dos diferentes
16
módulos do sistema e o fluxo de informação existente entre eles, partes e componentes
do sistema;
 Construção Implementação: Consistiu em definir a estrutura do código em termos
de implementação em linguagem de programação. Consistiu na construção do
código fonte e a documentação técnica gerada;
 Testes: Foi feito um acompanhamento do que foi feito, verificando as
funcionalidades solicitadas pelo cliente, a desempenho do sistema, dentre outras.
As ferramentas utilizadas para desenvolvimento do trabalho foram as seguintes:
 Apache Como servidor de internet;

 MySql como base de dados;
 Linguagem de programação Hypertext Preprocessor – PHP, HyperText Markup
Language – HTML
 Software para edição do código PHP Designer 2005.
Figura 2.4 -Estrutura do Sistema (Automatizando a Clínica CARDIOMED)
Fonte: adaptado STOLF (2007).
Interligação entre os módulos: O Módulo Administrador é o módulo principal do

sistema, ele administra as informações existentes nos demais módulos, tem uma visão geral
do sistema. A ordem de ligação e fluxo de informações entre eles é representada pelas setas.
Módulo Funcionário: Compreende funções relativas ao dia-a-dia da secretária da
clínica. Possui recursos de agendamento de consultas, registo de pacientes, de medicamentos,
de exames complementares e de locais de encaminhamentos. Todos estes recursos possuem
suas devidas consultas para obtenção de informações pelo funcionário.
Módulo Administrador: Compreende funções de administração do sistema, como
registo de funcionários, médicos, e o acesso a relatórios, registo de convénios, cargos e
17
clínicas (no caso de utilização para plataforma multiclínicas). Estas funcionalidades são
liberadas no registo do funcionário ou no registo do médico, para utilizadores do sistema com
este perfil.
Módulo Médico: Compreende os recursos necessários para o trabalho do médico da

clínica, como a visualização das consultas marcadas, emissão de receitas, laudos e consulta ao
prontuário dos pacientes.
Módulo Paciente incorpora as funções de verificação de consultas marcadas para o

paciente e geração do prontuário, mostrando os remédios e exames receitados e seus
respectivos resultados.
Existem várias implementações importantes que podem ser realizadas neste trabalho,
podendo-se melhorar as tabelas da base de dados, acessos ao base de dados (selects) e
diversos recursos importantes para gerenciamento de uma clínica. Algumas sugestões são:
 Melhorias na base de dados: optimização das consultas e opção de utilização de

outros bancos de dados. Melhora no modelo físico da base de dados;
 Opções de modelos de receitas médicas: criação de um registo de padrões de
receitas e campo no registo da clínica para selecção da receita desejada;
 Upload de fotos de pacientes: permitir a inserção no base de dados de fotos dos no
menu de registos de paciente, facilitando a identificação dos mesmos;
 Geração de lembretes automáticos: criação de espaço na tela principal onde são
informadas as consultas do dia para o médico e lembretes repassados por outros
utilizadores do sistema;
 Retorno programado: agendamento automático da consulta de retorno do paciente
e geração na tela da confirmação da data.
2.6. Conclusões do Capítulo
O estado da arte é o nível mais alto de desenvolvimento, seja de uma sistema, uma
técnica ou de uma área científica. Esse ponto indica o ponto em que produto em questão deixa
de ser um projecto técnico para se tornar uma obra-prima. Nesta etapa foram efectuados
estudos em trabalhos e soluções similares, servindo como base para avaliar o nível do
projecto que se está a desenvolver, avaliando aspectos técnicos e não só.
18
Capítulo III - Clínica Odontológica Online (Afrodente)
3.1. Considerações Iniciais
Nesta sessão será abordado sobre a concepção do protótipo, descrevendo os requisitos

funcionais, não funcionais, casos de usos do sistema, modelo entidade relacionamento,
modelo lógico e modelo de classes, consoante os objectivos específicos descrito acima.
O Protótipo é uma palavra que deriva do grego, onde (protós), significa primeiro e
(typos), significa tipo; mas uma tradução correcta, seria: primeiro modelo, que está em fase de
teste, estudo ou planeamento ou seja versão de um sistema que antecede á principal,
normalmente reduzida, para ser aperfeiçoada.
3.2. Descrição do Sistema
O sistema Odontológico online Afrodente, permite a gestão da informação interna em

duas vertentes: por um lado a informação confidencial sobre cada Paciente e o seu historial,
por outro, a gestão financeira e facturação das marcações aos Pacientes e Entidades.
Está é a solução para obter toda a gestão operacional da Clínica ou Consultório, dos
pacientes, dentistas/especialistas, das marcações e agendas, bem como a respectiva facturação
entidades e pacientes.
O sistema é desmembrado em três módulos que são: módulo da gestão de registo de
dados, módulo de marcação de serviços e o módulo de pagamento.
A figura 3.1 mostra os módulos do sistema e a sua interligação que mostra como a
comunicação funcional entre os subprogramas ou seja o fluxo de informação entre estes.
Figura 3.1 - Modelo Arquitectural do Sistema
19
 Módulo de Registo dos dados: onde são efectuados o registo dos dados (registar,
alterar e eliminar) de paciente, funcionário (dentista, secretária), fornecedor, materiais,
e entidades seguradoras.
 Módulo de Marcação de Serviços: Onde são efectuados os pedidos de marcação de
consultas, exames e tratamentos.
 Módulo de Pagamentos: são efectuadas a gestão das despesas da clínica e contas do
paciente.
3.3. Análise Do Sistema
Análise de sistemas é a actividade que tem como finalidade a realização de estudos de

processos a fim de encontrar o melhor caminho racional para que a informação possa ser
processada. Os analistas de sistemas estudam os diversos sistemas existentes entre hardwares
(equipamentos), softwares (programas) e o Utilizador final [12].
3.3.1. Regras de Negócios
Tabela 3.1 – Regras de Negócios

ID Regra Descrição das Regras
RN01 Registar Todo o utilizador do sistema deverá ser funcionário da
Utilizador organização.
RN02 Preenchimento Todos os campos de registo são de preenchimento obrigatório.
obrigatório
RN03 Perfil de acesso Somente Administrador terá acesso a gestão de utilizadores.
ao Módulo
Status de Todo o utilizador registado receberá o Status activo. Caso não
RN04 Utilizador seja mais permitido o acesso deste funcionário ao Sistema,
passará para inactivo.
Além do administrador aceder aos módulos do sistema, deverá
atribuir também o grau de acesso a cada utilizador registado:
o Nível 1- Administrador (Acesso total)
Perfil de Acesso
RN05 o Nível 2 - Utilizador com limitações (Módulo registo de
dados, Agenda, marcação de serviços, Pagamentos e
Relatórios)
o Nível 3 - Utilizador com limitações (marcação de
serviços e Relatórios)
20
O utilizador deverá registar uma senha de no mínimo 6 e no
RN06 máximo 8 caracteres. A senha não poderá conter dados que
Registo de Senha
estejam presentes no registo do utilizador
A senha deverá guiar-se pelos requisitos de complexidade:

o A senha deverá ser criptografada pelo sistema
o A senha não deverá ser armazenada no sistema operativo;
o O Campo senha não deverá aceitar os comandos cópia e
Directivas de
RN07 Senhas cola
o O campo senha não deverá ficar em branco
o A senha poderá ser composta por números e letras ou
somente uma ou outra.
Para que sejam aceitos o campo nome completo deverá conter no
Regras de
RN08 mínimo 8 caracteres e o campo email deverá conter um domínio.
preenchimento
O registo poderá ser actualizado quando houver solicitação de
Alteração de
RN09 alteração de dados. Todos os campos serão habilitados para
Registo
actualização.
O utilizador não poderá ser excluído pelo facto de afectar em
todos os registos que estão relacionados com este. Se houver
Exclusão de
RN10 necessidade de desactivação por motivos de mudanças de cidade,
Registo
falecimento, ou qualquer outro motivo, receberá o status de
inactivo.
RN11 Acesso no Para utilizar qualquer módulo do sistema o utilizador deverá
Sistema efectuar o login.
RN12 Preenchimento Deverá preencher obrigatoriamente os campos Utilizador e
obrigatório senha.
RN13 Validação de Os dados informados nos campos, Utilizador e senha deverão ser
dados validados junto ao registo de utilizadores na base de dados.
21
3.3.2. Requisitos Funcionais
Segundo Eduardo Figueiredo, eles descrevem explicitamente as funcionalidades e

serviços do sistema. Documenta como o sistema deve reagir a entradas específicas como deve
se comportar em determinadas situações [6].
Para o Desenvolvimento deste sistema devem ser compridos os seguintes Requisitos,
apresentados na Tabela 3.2.
Tabela 3.2 – Requisitos Funcionais

ID Descrição dos Requisitos Prioridade
RF01 O sistema deverá permitir o administrador Registar dois tipos de
Importante
Utilizadores, interno (dentista e secretária) e web (paciente).
RF02 O sistema deverá permitir que Utilizador do tipo secretária seja capaz
Importante
de Registar pacientes.
RF03 O sistema deverá permitir que Utilizador do tipo secretária seja capaz
Importante
de Registar dentistas.
RF04 O sistema deverá permitir que Utilizador do tipo dentista seja capaz
Essencial
de manter convénios.
RF05 O sistema deverá permitir que Utilizador do tipo Secretária ou
Importante
Administrador, realiza o registo da agenda do dentista.
RF06 O sistema deverá permitir que Utilizador do tipo dentista seja capaz
Essencial
de manter o registo da ficha de anamnese.
RF07 O sistema deverá permitir que Utilizador do tipo Secretária ou
Importante
Administrador, Registar Agendamento de consultas.
RF08 O sistema deverá permitir o Utilizador do tipo Web (Paciente)
Importante
realizar agendamento de consultas.
RF09 O sistema deverá permitir o Utilizador do tipo Dentista, realizar o
Importante
registo de tratamentos a serem efectuados por cada paciente.
RF10 O sistema deverá permitir o Utilizador do tipo Dentista Registar os
Importante
procedimentos que já foram executados em cada paciente.
RF11 O sistema deve permitir o Utilizador do tipo Secretária ou
Importante
Administrador registar os orçamentos dos tratamentos realizados.
RF12 O sistema deve permitir o Utilizador do tipo Secretária ou
Importante
Administrador, efectuar o pagamento dos tratamentos.
22
RF13 O sistema deve permitir o registo da caixa, este caixa deve possuir
registos de movimentações do dia com a forma de pagamento, o tipo
Importante
de lançamento e o valor deste movimento.
RF14 O sistema deve permitir Registar dos fornecedores dos materiais.
Essencial
RF15 O sistema deve permitir Registar os materiais utilizados na clínica.
Essencial
RF16 O sistema deve permitir registar os movimentos do Stock ou seja as
Essencial
entradas e saídas dos materiais.
3.3.3. Requisitos Não Funcionais
Segundo Eduardo Figueiredo, eles definem propriedades e restrições do sistema.

Exemplos: segurança, desempenho, espaço em disco. Podem ser do sistema todo ou de partes
do sistema, Requisitos não funcionais podem ser mais críticos que requisitos funcionais, Se
não satisfaz, o sistema é inútil [7].
Tabela 3.3 – Requisitos Não Funcionais

ID Tipo Descrição dos Requisitos
O sistema precisará apresentar uma interface amigável, sólida,
RNF01 imediata e de simples acessibilidade, isto é, suas informações e
Usabilidade
funcionalidades deverão estar bem visíveis e disponíveis.
RNF02 Deve ter um alto nível de acessibilidade. Devendo ser acessível
Acessibilidade
a partir de qualquer SO e qualquer navegador.
RNF03 O sistema não terá limitações quanto ao tempo de resposta,
Desempenho
dependendo somente da internet do Utilizador.
RNF04 A aplicação devera executar em diferentes plataformas
Portabilidade
Hardware e Software.
RNF05 A aplicação deve estar em serviço a tempo inteiro.
Confiabilidade
O acesso a aplicação deve ser restringido a utilização de um
Segurança
RNF06 nome de utilizador e palavra passe previamente criadas pelo
administrador da mesma.
23
3.3.4. Diagrama de caso de uso
Nesta sessão são ilustrados os casos de uso do sistema referentes aos quatros actores
do sistema, a Secretária, o Administrador, Dentista e o Paciente. Ver figuras 3.2, 3.3, 3.4, 3.5
e 3.6.
Figura 3.2 – Digrama de Caso de Uso do Sistema
24
A figura abaixo ilustra a interacção da secretária no sistema.
Figura 3.3 – Caso de uso Secretária
25
A figura abaixo ilustra a interacção do dentista no sistema.
Figura 3.4 – Caso de uso Dentista
A figura abaixo ilustra a interacção do paciente no sistema.
Figura 3.5 – Caso de uso Paciente
26
A figura abaixo ilustra a interacção do administrador no sistema.
Figura 3.6 – Caso de uso Administrador
27
3.3.5. Descrição de Casos de Uso
A descrição de Casos de uso é uma abordagem detalhada da descrição ou narrativa dos

casos de uso, descrevendo as actividades que são realizadas por um determinado actor e a sua
interacção com o sistema. A seguir é feita a descrição dos casos de uso “Registar Dentista”,
“Registar Secretária”, “Registar Paciente”, “Registar Agenda” e “Registar Agendamento” do
Sistema AFRODENTE.
Tabela 3.4 – Descrição de Caso de uso “Registar Dentista”
Caso de uso – Registar Dentista

Actor: Administrador/Secretária
Objectivo: Permitir a secretária ou Administrador Registar dentistas.
Pré-condições: Utilizador logado no sistema com perfil secretária ou Administrador
Registado.
Pós-condições: Dentista Registado no sistema.
Fluxo Principal:
1. O administrador/secretária informa o login.
2. O sistema verifica se existe login registado.
3. O administrador/secretária informa e confirma senha.
3.1 O sistema verifica senha.
4. O administrador/secretária solicita registo do dentista.
5.O administrador/secretária informa os dados.
6. Confirma os dados do dentista.
7. O sistema grava os dados do dentista.
8. O sistema exibe tela de confirmação do registo.
9. Finalizar caso de uso.
Fluxo Alternativo 2:
2.1. O sistema exibe mensagem de erro
2.2. Sistema permite novo registo de dentista.
2.3. Retornar para o passo 2.
3.1. O sistema emite mensagem “Senhas Diferentes”.
5.1. Os dados do dentista não foram informados.
5.2. O sistema informa “Preencher o(s) campo(s) em destaque”.
28
Tabela 3.5 – Descrição de Caso de uso “Registar Secretária”
Caso de uso – Registar Secretária

Actor: Administrador
Objectivo: Permitir Administrador Registar secretárias.
Pré-condições: Utilizador logado no sistema com perfil Administrador Registado.
Pós-condições: Secretária Registada no sistema.
Fluxo Principal:
1. O administrador informa o login.
3. O administrador informa e confirma senha.
4. O administrador solicita registo de secretária.
5.O administrador informa os dados.
6. Confirma os dados da secretária.
7. O sistema grava os dados da secretária.
2.1.O sistema exibe mensagem de erro
2.2. Sistema permite novo registo de secretária.
5.1. Os dados do dentista não foram informados.
29
Tabela 3.6 – Descrição de Caso de uso “Registar Paciente”
Caso de uso – Registar Paciente

Actor: Administrador/Secretária
Objectivo: Permitir a secretária ou Administrador Registar Pacientes.
Pré-condições: Utilizador logado no sistema com perfil secretária ou Administrador
Registado.
Pós-condições: Paciente Registado no sistema.
Fluxo Principal:
1. O administrador/secretária informa o login.
3. O administrador/secretária informa e confirma senha.
4. O administrador/secretária solicita registo do paciente.
5.O administrador/secretária informa os dados.
6. Confirma os dados do paciente.
7. O sistema grava os dados do paciente.
2.1. O sistema exibe mensagem de erro
2.2. Sistema permite novo registo de paciente.
5.1. Os dados do paciente não foram informados.
30
Tabela 3.7 – Descrição de Caso de uso “Registar Agenda”
Caso de uso – Registar Agenda

Actor: Secretária
Objectivo: Este caso de uso é responsável pelo registo, alteração e remoção da agenda.
Pré-condições: Utilizador logado no sistema com perfil secretária e dentista registado.
Pós-condições: Agenda Registada com sucesso.
Fluxo Principal:
1. Escolhe o nome do dentista.
2. Escolhe a data inicial.
3. Escolhe a data final.
4. Escolhe hora inicial.
5. Escolhe hora final.
6. Escolhe o intervalo de tempo.
7. E cria instância agenda.
8. O sistema informa mostra tela de confirmação.
1.1. O nome do dentista não foi informado
1.2. Retornar ao passo 1
2.1. A data inicial não foi informada.
2.2. O sistema mostra mensagem “Informar data inicial maior ou igual á data actual”. 2.3
Retornar ao passo 2.
3.1. A data final não foi informada.
3.2. O sistema mostra mensagem “Informar data final maior ou igual á data inicial e data
actual”.
3.3. Retornar ao passo 3.
4.1. A hora inicial não foi informada.
4.2. O sistema mostra mensagem “Informar hora inicial maior ou igual á hora actual”. 4.3.
Retornar ao passo 4.
31
5.1. A hora final não foi informada.
5.2. O sistema mostra mensagem “Informar hora final maior ou igual á data inicial e hora
actual”.
6.1. O intervalo de tempo não foi informado.
6.2. Retornar ao passo 6
Tabela 3.8 – Descrição de Caso de uso “Registar Agendamento”
Caso de uso – Registar Agendamento

Actor: Secretária/Paciente
Objectivo: Este caso de uso é responsável pelo registo, alteração e remoção do
agendamento e pré-agendamento.
Pré-condições: Utilizador logado no sistema com perfil secretária e paciente.
Pós-condições: Agendamento Realizado com sucesso.
Fluxo Principal:
1. É informado o login e senha do Secretária/Paciente.
2. É informado a senha do Secretária/Paciente.
3. O Utilizador Secretária/Paciente é logado.
4. Escolhe o nome do paciente.
5. Escolhe o nome do dentista.
6. É informada a data do agendamento.
7. É informado o horário da consulta.
8. É informado o motivo do Agendamento.
9. O sistema recupera os dados do formulário.
10. E cria instância agenda.
1.1. O login do Utilizador interno não existe.
1.2. O sistema informa “Login inválido!”.
2.1. A senha do Utilizador interno não existe.
32
2.2. O sistema informa “Senha Incorrecta!”.
Fluxo Alternativo4:
4.1. O nome do paciente não foi informado.
Fluxo Alternativo5:
5.1. O nome do dentista não foi informado.
Fluxo Alternativo6:
6.1. A data do agendamento é informada.
6.2. O sistema mostra os horários disponíveis.
7.1. O horário do agendamento não é informado.
5.1. O motivo do agendamento não foi informado.
5.2. O sistema informa “Preencher os campos em destaque!”.
3.4. Diagrama de sequência
O diagrama de sequência é uma ferramenta que deve ser utilizada sempre em função
dos casos de uso. Um diagrama de sequência captura o comportamento de um único caso de
uso, ou seja, mostra a interacção entre os objectos ao longo do tempo, apresentando os
objectos que participam da interacção e a sequência das mensagens trocadas [8].
As figuras abaixo ilustram as interacções dos objectos no decorrer do processo de

registar dentista, secretária, paciente, agenda e agendamento:
33
Figura 3.7 – Diagrama de sequência Registar Dentista
Figura 3.8 – Diagrama de sequência Registar Secretária
34
Figura 3.9 – Diagrama de sequência Registar Paciente
Figura 3.10 – Diagrama de sequência Registar Agenda
35
Figura 3.11 – Diagrama de sequência Registar Agendamento
3.5. Diagrama de colaboração
Ele define a estrutura de como os objectos estão vinculados, indica quais mensagens
são trocadas entre objectos, não se preocupa com a temporalidade. Se preocupa com a
organização estrutural dos objectos.
Figura 3.12 – Diagrama de colaboração Registar Paciente
36
Figura 3.13 – Diagrama de colaboração Registar Agendamento
3.6. Desenho do Sistema
Nesta secção contém os principais diagramas e modelos para criação do sistema desde
o modelo de entidade e relacionamento a até o desenho de hardware da aplicação.
3.6.1. Modelo de Entidade Relacionamento
Modelo de base de dados é uma descrição dos tipos de informações que estão
armazenadas em uma base de dados. Uma entidade é um objecto ou evento do mundo real
sobre o qual desejamos manter um registo. Um relacionamento é uma relação entre uma, duas
ou várias entidades geralmente associamos através da acção (verbo) entre as entidades.
O Modelo Entidade Relacionamento, é um modelo conceitual utilizado na Engenharia
de Software para descrever os objectos (entidades) envolvidos em um domínio de negócios,
com suas características (atributos) e como elas se relacionam entre si (relacionamentos) [3].
37
3.6.2. Modelo Conceitual
Modelo que representa fielmente o negócio em questão, demonstrando características

fiéis ao ambiente observado ou imaginado independente de qualquer limitação imposta por
tecnologia, técnica de implementação ou dispositivo físico [4].
Figura 3.14 – Modelo Conceitual
3.6.3. Modelo Lógico
É uma descrição de uma base de dados no nível de abstracção vista pelo Utilizador do
SGBD. Assim, esse modelo depende do SGBD que está sendo usado. Aqui são detalhados os
componentes da estrutura física da base de dados, como tabelas, campos, tipos de valores,
índices, etc. [5].
38
Figura 3.15 – Modelo Lógico
3.6.4. Diagrama de classes
O diagrama de classes representa as interacções estáticas e as classes envolvidas no

sistema, permitindo também identificar as hierarquias das classes, representadas por heranças
e agregações. Este diagrama permite visualizar os dados que serão armazenados e
manipulados pelo sistema. A Classe é uma descrição de um conjunto de objectos que
compartilham os mesmos atributos, operações, relacionamentos [9].
39
Figura 3.16 – Diagrama de classe
40
3.6.5. Arquitectura do sistema
A Arquitectura de Software demonstra como o sistema está subdividido logicamente,

para tal foi utilizado modelo em 3 camadas web based, este modelo “retira” as regras de
negócio do cliente e as centraliza num determinado ponto, o que é chamado de Servidor de
Aplicações.
O acesso ao Banco de Dados é feito através das regras contidas no Servidor de

Aplicações. Ao centralizar as Regras de Negócio em um único ponto, fica muito mais fácil a
actualização destas regras. A figura 3.10 ilustra a ideia geral do modelo em 3 camadas web
based.
Figura 3.17 – Arquitectura de Software
Fonte: Elaborado pelo autor, 2019
Camada de apresentação
É a chamada GUI (Graphical User Interface), ou simplesmente interface. Esta camada

interage directamente com o Utilizador, é através dela que são feitas as requisições como
consultas, por exemplo.
Camada de negócio
Também chamada de lógica empresarial, regras de negócio ou funcionalidade. É nela

que ficam as funções e regras de todo o negócio. Não existe uma interface para o Utilizador e
seus dados são voláteis, ou seja, para que algum dado seja mantido deve ser utilizada a
camada de dados.
41
Camada de Dados
É composta pelo repositório das informações e as classes que as manipulam. Esta

camada recebe as requisições da camada de negócios e seus métodos executam essas
requisições em um banco de dados
3.6.6. Arquitectura de Hardware
Este modelo apresenta qual é a infra-estrutura necessária para a implementação no

sistema nas unidades administrativas, sendo eles: computadores clientes e servidores,
switches, roteadores, tudo compartilhado a partir de rede cabeada.
Figura 3.18 – Arquitectura de HW
Fonte: Elaborado pelo autor, 2019
3.6.7. Conclusões do capítulo
Nesta etapa apresentou-se o protótipo, descrito em formas de diagramas, modelos e os

requisitos obrigatórios para a implementação. A principal ferramenta utilizada foi o StarUML,
na sua versão 5.0.2, que permitiu demonstrar algumas interacções entre os utilizadores do
sistema, que serviu para clarear a codificação do mesmo. Apresentou-se também a
arquitectura da aplicação que demonstra ao Utilizador final como os equipamentos de rede
podem estar interligados.
42
Capítulo VI - Considerações Finais
4.1. Conclusões
Este trabalho apresenta o desenvolvimento de um software de auxílio a clínica dentária

Afrodente. O sistema oferece novas alternativas e maior agilidade aos profissionais, assim
organizando a rotina do seu consultório com um sistema desenvolvido para proporcionar
produtividade, facilitando a organização da agenda e as actividades na clínica; uma aplicação
com variados recursos para a resolução de problemas antes existentes como atrasos no
atendimento, falta de informação, prontuários obsoletos e os cadernos de anotações. O
sistema pode também ser usado por clínicas em geral que usam agenda com registos.
Deste modo, foi desenvolvido um sistema para clínica odontológica com

gerenciamento de agendamento local e para internet podendo, os profissionais acessarem os
dados de seus pacientes e ficha de anamnese. A disponibilização online de informações
clínicas pode ser acessada de qualquer lugar; estas novas possibilidades intensificam as
interacções entre cirurgiões-dentistas facilitando a troca de informações clínicas e a prestação
de serviços via internet, assim apresentando a clínica e agregando valor.
Para o desenvolvimento deste trabalho, foram utilizadas algumas tecnologias como:

HTML, Php, Javascript, UML, MySQL. A pesquisa foi de extrema importância para o
aprendizado e conhecimento das tecnologias utilizadas. Neste estudo constatou-se que é
importante observar que as tecnologias oferecem vários recursos e vantagens, dependendo da
criatividade do programador, em desenvolver um projecto funcional e eficiente.
Com base em todos os estudos e análises realizadas e de um detalhado levantamento

de requisitos, foi concluída toda a análise, projecto e o protótipo do sistema proposto.
Contudo, pode se dizer que os objectivos propostos nesta monografia foram alcançados. O
sistema realiza as principais funções para o gerenciamento de um agendamento de consulta
para uma clínica odontológica. Espera-se que com este projecto possa colaborar com as
futuras pesquisas agregando mais um “tijolinho” no alicerce do conhecimento.
43
4.2. Trabalhos Futuros
Como sugestão de trabalhos futuros fica a necessidade de completar a implementação

do sistema devido à complexidade deste projecto foram desenvolvidas apenas as funções de
maior importância como funcionamento do agendamento e controle de consultas, no entanto
dependendo a especialidade de cada profissional, surge a necessidade de melhorar a
performance do sistema completando a implementação de um módulo financeiro mais robusto
permitindo geração de gráficos estatísticos das principais actividades realizadas pela
organização, para facilitar na tomada de decisão. E o desenvolvimento de uma função que
possibilite dar ao paciente prioridade na marcação de um horário para atendimento com
urgência (encaixar horários).
4.3. Sugestões
Com base nos estudos feitos e representados neste trabalho, recomenda-se como estímulo
aos Hospitais/ Clínicas em Angola:
1. É obrigatório que todo e qualquer paciente sejam registados, antes de marcar uma
consulta na recepção;
2. Ter noções básicas de como acessar a internet via computador, Tablet ou Smartphone;
3. Possuir um correio electrónico para os pacientes que não têm convénio com a clínica;
4. Estudar o mecanismo devido, para uma boa gestão da Clínica;
5. O uso do manual de apoio em caso de dúvidas ou dificuldades em utilizar o sistema;
6. Preencher os formulários do sistema com informações verdadeiras.
44
Referências Bibliográficas
1. (Barbosa, Neusa Sofia Lopes, 2010), Desenvolvimento de Sistema Integrado para

gestão de Clínica, Módulo Gestão de Marcação de Serviços e Serviços.
2. (Costa, Haislan Nascimento, 2010), SCO – Sistema Para Clínica Odontológica. 88p.
il. 31cm. Monografia apresentada ao Centro Universitário Católico Salesiano
Auxilium – UNISALESIANO, Lins – SP, para graduação em Tecnologia em Sistemas
para Internet.
3. DEVMEDIA, O que é Modelo Entidade Relacionamento (MER). Disponível em:
https://www.devmedia.com.br/modelo-entidade-relacionamento-mer/19821. Acesso
em 22 Nov. 2018.
4. DEVMEDIA, Modelo Conceitual. Disponível em:
https://www.devmedia.com.br/modelo-entidade-relacionamento-mer/19821. Acesso
em: 22 Nov. 2018.
5. DEVMEDIA, Modelo Lógico. Disponível em: https://www.devmedia.com.br/modelo-
entidade-relacionamento-mer/19821. Acesso em 22 Nov. 2018.
6. HOMEPAGES, Requisitos Funcionais. Disponível em:
https://homepages.dcc.ufmg.br/~figueiredo/disciplinas/aulas/req-funcional-
rnf_v01.pdf. Acesso em 22 out. 2018.
7. HOMEPAGES, Requisitos Não-Funcionais (RFN). Disponível em:
https://homepages.dcc.ufmg.br/~figueiredo/disciplinas/aulas/req-funcional-
rnf_v01.pdf. Acesso em 22 Out. 2018.
8. LUCIDCHART, O que é um diagrama de sequência em UML. Disponível em:
https://www.lucidchart.com/pages/pt/o-que-e-diagrama-de-sequencia-uml. Acesso em:
07 Nov. 2018.
9. LUCIDCHART, O que é um diagrama de classe UML. Disponível em:
https://www.lucidchart.com/pages/pt/o-que-e-diagrama-de-classe-uml. Acesso em 07
Dez. 2018.
10. (Roque, Diana Isabel Fernandes, 2012), Sistema de Gestão de Dados Clínicos.
11. STOLF, Giuliano M. Sistema Gerenciador de clínica médica: automatizando a clínica
cardiomed. 2007. 71 f. Trabalho de Conclusão de Curso (Bacharelado em Sistema de
Informação) – Ciências Exactas e Naturais, Universidade Regional de Blumenau,
Blumenau.
12. WIKIPÉDIA, a enciclopédia livre, análise de sistemas. Disponível em:
https://pt.wikipedia.org/wiki/Análise_de_sistemas. Acesso em 20 Out. 2018.
45
APÊNDICE
APÊNDICE A - Questionário para levantamento de requisitos.
Este apêndice apresenta as questões elaboradas para a realização do levantamento de

requisito para as para se obter as funcionalidades principais do sistema.
1. Qual é a sua opinião em relação a implementação de um sistema de gestão?

2. Que problemas pretenderias que este sistema resolve-se?
3. Que funcionalidades acham que devem ser implementados neste sistema?
4. Que tratamentos são realizados na clínica?
5. Quais os dados necessários para o registo dos pacientes?
6. Como é elaborado a ficha dos pacientes?
7. Como são efectuados os orçamentos?
8. Como é feito o pagamento dos orçamentos?
9. Como é feito os registos das consultas?
10. Quais os horários para a marcação de consulta?
11. Quais os dados necessários para o registo dos funcionários?
12. Quais as funções desempenhadas por cada funcionário?
13. Que matérias são utilizados na clínica?
14. Quais os dados necessários para o registo dos materiais?
15. Quais os dados necessários para o registo dos fornecedores?
16. Como é feito o controlo do stock?
APÊNDICE B - Interfaces do Sistema
Este anexo apresenta as interfaces principais do sistema e oferece uma breve descrição
operacional.
A interface principal é constituída por um ambiente padrão, contendo uma barra de

menus onde se encontram os links de início, quem somos, a clínica, especialidades e a área
reservada (Entrar) onde utilizadores terão a opção de fazer o seu login.
46
Essa é interface responsável por ilustrar a página inicial, onde contem informações
simples como endereços, contactos, horários disponíveis, corpo clínico.
Figura B.1 Tela Página Inicial
Esta interface contém um formulário na qual este é responsável pelo login dos
utilizadores do sistema.
Figura B.2 Tela de Login
47
Essa tela é responsável por apresentar a página principal após o login, antes de
qualquer actividade a ser realizada pelo Utilizador do tipo secretária.
Figura B.3 Tela de boas vindas secretária
Esse formulário é responsável em Registar os dados dos dentistas.
Figura B.4 Tela de Registo de dentistas
48
Esse formulário é responsável em Registar os dados dos pacientes.
Figura B.5 Tela de Registo de pacientes
Esse formulário é responsável pelo agendamento de consulta dos pacientes registados

no sistema.
Figura B.6 Tela de Agendamento de consultas
49
Esse formulário é responsável pelo registo do plano de tratamento dos pacientes
registrados no sistema.
Figura B.7 Tela de Plano de tratamentos
Esse formulário é responsável pelo registo dos procedimentos executados pelos

dentistas para o tratamento desejado pelos pacientes.
Figura B.8 procedimentos executados
50
Esse formulário é responsável pelo registo dos orçamentos dos procedimentos
executados por cada dentista.
Figura B.9 Tela de Orçamento
Esse formulário é responsável pelo registo dos pagamentos de cada orçamento

realizado dos tratamentos dos pacientes.
Figura B.10 Tela de Pagamento
51
Esse formulário é responsável pelo registo dos movimentos de caixa realizados na
clínica.
Figura B.11 Tela de Movimento de caixa
Esse formulário é responsável pelo registo dos materiais utilizados na clínica.
Figura B.12 Tela de Registo de materiais
52

Implementação de Clínica Odontológica Online Afrodente

Enviado por

Direitos autorais:

Formatos disponíveis

Implementação de Clínica Odontológica Online Afrodente

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Implementação de Clínica Odontológica Online Afrodente

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade Metodista de Angola

Implementação de Clínica Odontológica Online Afrodente

Vanderson de Abreu Teixeira de Carvalho

Professor MSc. Henriques Fernando

Implementação de Clínica Odontológica Online Afrodente

Monografia de Conclusão de Curso de

Orientado pelo Professor MSc. Henriques

A minha querida Mãe, Berta Maria.

A minha querida irmã Vanusa.

E a todos aqueles que de forma directa

Os sistemas de gestão tornaram-se um dos principais componentes dos sistemas de

Palavras-chave: Sistema de gestão, Clínica Odontológica.

Keywords: Management System; Dental Clinic

UML - Unified Modeling Language ou linguagem de modelagem unificada

Figura 2.1 – Arquitectura do sistema (módulo gestão de marcações) .............................................. 7

Tabela 3.1 – Regras de Negócios ................................................................................................... 20

Este capítulo trata de abordar a importância do tema, os objectivos que se pretendem

1.2 Definição do problema

A clínica odontológica Afrodente Angola, desde o início de suas actividades, realiza o

A inexistência de um odontograma (prontuário odontológico com imagem) online,

O que motivou o desenvolvimento deste projecto foi o uso de novas tecnologias e

1.4 Delimitação do Problema

Objectivos bem definidos proporcionam um caminho para o alcance dos resultados e

1.5.1. Objectivo Geral

Desenvolver um protótipo de software que será utilizado para gerir um consultório

1.5.2. Objectivos Específicos

Os objectivos específicos que se pretende alcançar nesta proposta são:

Para desenvolvimento deste trabalho foram realizadas algumas visitas a Clínica

2.1 Considerações Iniciais

O estado da arte ou estado do conhecimento traz o desafio de mapear e discutir temas

2.2. Desenvolvimento de Sistema Integrado para gestão de Clínica

O sistema de gestão de clínica abrangendo todos os serviços prestados na clínica e

 Levantamento de requisitos: Nesta fase definiu-se uma visão geral de como do

No decorrer do estágio foram utilizadas várias ferramentas e tecnologias para proceder

A arquitectura do sistema está estruturado em dois módulos fundamentais

Fonte: Adaptado Barbosa, (2010).

Módulo de Marcações: Onde são efectuados os pedidos de marcação de consultas,

Este módulo suporta as seguintes actividades:

 Marcação de serviços A recepcionista da clínica marca uma consulta na agenda,

Como requisitos adiados foram destacados as seguintes funcionalidades

2.3. Sistema de Gestão de Dados Clínicos

De todo o avanço tecnológico, o desenvolvimento da informática é, talvez, aquele que

A aplicação deve utilizar uma arquitectura cliente/servidor, que irá questionar o

O projecto foi desenvolvido seguindo o ciclo de desenvolvimento que contou com as

 Formulação do problema: consistiu em identificar os fenómenos, os objectos de

 Microsoft Visual Studio 2012 Ultimate (Ambiente Integrado de Desenvolvimento

Fonte: Adaptado Roque (2012).

Interligação entre os módulos: Os módulos do sistema trocam informação entre si

Com base na análise do problema foram considerados os seguintes módulos a

Módulo Gestão de Atletas: O módulo de gestão atletas deve permitir no mesmo

Módulo Gestão de Consultas: O módulo de gestão de consultas deve permitir: Inserir

Módulo Gestão de Médicos: O módulo de gestão de Médicos deve permitir: Inserir a

Módulo Gestão de Modalidades: O módulo de gestão de Modalidades deve permitir

Módulo Gestão de Clubes: O módulo de gestão de Clubes deve permitir inserir a

Existem algumas funcionalidades que poderão ser implementadas para melhorar a

De todo o desenvolvimento da ciência da informação e a introdução dos computadores

A obtenção da informação por meio electrónico reflecte positivamente no resultado do

Assim surgiu a necessidade de desenvolver um sistema para gerenciar uma agenda

O projecto foi desenvolvido seguindo as seguintes fases:

 Análise de requisitos: Para a fase de análise de requisitos foi capturada as