Post on 20-Jan-2019
Sistema de Gerenciamento de Consultório Odontológico
Trabalho de Conclusão de Curso apresentado ao
Instituto Municipal de Ensino Superior de Assis, como
requisito de conclusão do Curso Superior de Análise
e Desenvolvimento de Sistemas.
Orientador: Prof. Dr. Luiz Carlos Begosso Área de Concentração: Informática
Assis
2014
FICHA CATALOGRÁFICA
Campos, Danilo Emerson de Melo.
Software de Gerenciamento de Consultório Odontológico / Danilo Emerson de Melo Campos.
Fundação Educacional do Município de Assis - FEMA - Assis, 2014.
41 Páginas.
Orientador: Prof. Dr. Luiz Carlos Begosso
Trabalho de Conclusão de Curso - Instituto Municipal de Ensino Superior de Assis - IMESA.
1. Programas 2. Controle de Atividades para Clínicas Odontológicas
CDD: 001.61 Biblioteca FEMA
Sistema de Gerenciamento de Consultório Odontológico
Danilo Emerson de Melo Campos
Trabalho de Conclusão de Curso apresentado ao Instituto Municipal
de Ensino Superior de Assis, como requisito do Curso Superior de
Análise e Desenvolvimento de Sistemas, analisado pela seguinte
comissão examinadora:
Orientador: Prof. Dr. Luiz Carlos Begosso Analisador: Prof. Felipe Alexandre Cardoso Pazinatto
Assis
2014
AGRADECIMENTOS Ao professor, Luiz Carlos Begosso, pela orientação e pela constante motivação,
estímulo e direção transmitidos durante o trabalho.
Aos amigos, de classe e trabalho pelo apoio e troca de experiências.
E a todos que colaboraram direta ou indiretamente na execução deste trabalho.
E aos familiares, Iraci Pereira de Melo Campos, Edson Campos da Silva, Natalia
Alves Bernardo e Gabriele Priscila de Melo Campos que me incentivaram e
compreenderam meus esforços durante todo o período de confecção deste trabalho
de conclusão de curso.
RESUMO Atualmente é quase que inimaginável um estabelecimento comercial ou industrial
sem um software para ajudar nas tomadas de decisões. A partir da constatação da
ausência de um recurso de automatização nas clínicas odontológicas na cidade de
Maracaí surgiu à oportunidade da criação de um sistema que visa auxiliar as tarefas
do dia a dia como agendamento de horário, gerenciamento de mensalidades,
recebimentos de serviços prestados a clientes e gerenciamentos de dentistas e
pacientes, sempre com foco nas tomadas de decisões visando trazer agilidade e
facilidades para usuários diretos ou indiretos.
O sistema apresenta uma interface amigável e funcional não se esquecendo da
segurança e confiabilidade, requisitos que são indispensáveis no desenvolvimento
de qualquer software, independente de área de atuação.
Palavras chaves: Software, Clínicas Odontológicas.
ABSTRACT
Currently it is almost unimaginable that a commercial or industrial establishment
without a software to help in decision making, since the lack of a resource
automation in odontology clinics in the city of Maraca, came the opportunity of
creating a system that aims to assist the tasks of the day by day, as time scheduling,
management fees and receipts for services provided to clients, managements of
dentists and patients, always focusing on decision making aiming to bring agility and
facilities for direct or indirect users.
Software will bring a friendly and functional interface, not forgetting the safety and
reliability requirements that are indispensable in the development of any independent
software field.
Key words: Software, clinics Odontology.
7
LISTA DE ILUSTRAÇÕES
Figura 1 Representa o diagrama EAP do projeto. ............................................................. 18 Figura 2 Sequenciamento de Atividades ............................................................................. 19
Figura 3 Diagrama de Caso de Uso ..................................................................................... 25 Figura 4 Diagrama Entidade Relacionamento .................................................................... 34
Figura 5 Diagrama de Classe ................................................................................................ 35 Figura 6 Diagrama de Atividades Agendar Consulta ......................................................... 36 Figura 7 Diagrama de Atividades Receber Mensalidade .................................................. 37
Figura 8 Tela Menu Principal ................................................................................................. 38
Figura 9 Tela De Cadastro de Paciente ............................................................................... 38
Figura 10 Agenda .................................................................................................................... 39
8
LISTA DE TABELAS
Tabela 1 – Acompanhamento do Cronograma...................................................21
9
Sumário 1. INTRODUÇÃO ............................................................................................................................ 11
1.1. OBJETIVOS ................................................................................................................................ 11
1.1.1 Objetivos Gerais .................................................................................................................. 11
1.1.2 Objetivos Específicos .......................................................................................................... 12
1.2 JUSTIFICATIVAS ....................................................................................................................... 12
1.3. FOCO DO TRABALHO ......................................................................................................... 13
1.4. MOTIVAÇÃO .............................................................................................................................. 13
1.5. PERSPECTIVA DE CONTRIBUIÇÃO .................................................................................... 13
2. METODOLOGIA DE DESENVOLVIMENTO ............................................................................ 14
2.1. UML.............................................................................................................................................. 14
2.1.1 Astah ...................................................................................................................................... 14
2.2. LINGUAGENS DE PROGRAMAÇÃO .................................................................................... 15
2.2.1. .NET ...................................................................................................................................... 15
2.2.2. C# .......................................................................................................................................... 15
2.3. BANCO DE DADOS .................................................................................................................. 16
2.3.1. SQL Server 2012 Express ................................................................................................ 16
3. PLANEJAMENTO DO PROJETO .............................................................................................. 17
3.1. ESTRUTURA ANALÍTICA DO PROJETO (EAP) ................................................................. 17
3.2. SEQUENCIAMENTO DAS ATIVIDADES .............................................................................. 18
3.3. ESPECIFICAÇÕES DE CUSTO ............................................................................................. 19
3.3.1. Gerenciamento de Custos ................................................................................................ 19
3.4. ORÇAMENTO ............................................................................................................................ 20
3.5. Custo Total do Projeto .............................................................................................................. 21
4. ANÁLISE DO PROJETO .............................................................................................................. 22
4.1 ESPECIFICAÇÕES DE REQUISITOS .............................................................................. 22
4.1.1 Requisitos Funcionais ......................................................................................................... 22
4.1.2 Requisitos Não Funcionais ................................................................................................ 23
5. MODELAGEM DO SISTEMA ...................................................................................................... 24
5.1 CASOS DE USO ......................................................................................................................... 24
5.1.2 Narrativas de Caso de Uso ................................................................................................ 25
10
5.2. DIAGRAMA ENTIDADE RELACIONAMENTO ................................................................... 33
5.3. DIAGRAMA DE CLASSE ......................................................................................................... 34
5.4. DIAGRAMA DE ATIVIDADES ................................................................................................. 35
6. RESULTADOS ........................................................................................................................... 38
7. CONCLUSÃO ............................................................................................................................. 40
8. REFERÊNCIAS .............................................................................................................................. 41
11
1. INTRODUÇÃO
Este trabalho tem como finalidade a elaboração de documentação e implementação
de sistema de gerenciamento para consultório odontológico. Constatada falta de
ferramentas que oferecem suporte no dia a dia de consultórios odontológicos na
cidade de Maracaí – SP, o sistema de gerenciamento de consultórios odontológico
trará maior interatividade, agilidade, controle e auxílio nas tomadas de decisões para
o administrador do consultório e usuários do sistema como odontologistas e
secretárias.
Espera-se que o sistema possa auxiliar em tarefas como agendamento de consultas,
histórico de pacientes e controle de mensalidades de clientes.
Em geral, a falta de ferramentas automatizadas faz com que algumas tarefas
demorem mais do que o necessário para serem realizadas, como consultar
informações sobre os pacientes, controle do recebimento de mensalidades e
alterações de horários marcados.
1.1. OBJETIVOS
1.1.1 Objetivos Gerais
O presente trabalho tem por objetivo o desenvolvimento de um projeto e
implementação de um sistema de gerenciamento para consultório dentário. O
sistema, denominado de Sistema de Gerenciamento de Consultório odontológico
(SGCO), apresenta uma dinâmica para as tarefas diárias de um consultório dentário,
auxílio em tomadas de decisões, consultas e retiradas de relatórios visando manter a
documentação sobre tarefas efetuadas ou decisões futuras.
12
1.1.2 Objetivos Específicos
No controle Financeiro foram implementadas as seguintes funcionalidades:
Entrada e saída de caixa.
Na área de atendimento ao Cliente foram implementados:
Cadastro de Pacientes.
Gerenciamento de consultas.
As funcionalidades que auxiliam o gestor do sistema nas tomas de decisão, são:
Pacientes faltosos;
Consultas canceladas;
Pacientes aniversariantes;
Pacientes inadimplentes;
Pacientes que declaram imposto de renda;
Receitas por determinado período;
Cadastro de usuários do sistema;
Cadastro de procedimentos;
Cadastro de Dentista;
1.2 JUSTIFICATIVAS
Com o surgimento de novas tecnologias e a possibilidade de ter acesso a
informações de qualquer lugar com acesso a internet, surgiu à oportunidade da
criação de um Sistema de Gerenciamento de Consultório odontológico para uma
clínica situada na cidade de Maracaí, já que todas as atividades com relação à
administração da clínica eram realizadas de forma manual. Podendo desta forma
ocorrer inconsistências e transtornos em relação a históricos de pacientes
recebimentos de mensalidades e agendamento de consultas.
13
A implementação do sistema visa trazer melhorias e agilidade em tarefas do dia a dia.
Como o sistema foi desenvolvido em uma plataforma web, ele possui, como uma de
suas principais características, o acesso a informações de qualquer lugar ou horário.
1.3. FOCO DO TRABALHO
O foco está em atender as necessidades levantadas da clínica dentária, levando em
consideração os seguintes requisitos:
Proporcionar otimização de agendamento ou cancelamento de consultas;
Manter registro rigoroso de recebimento ou retirada de dinheiro do caixa;
Acelerar determinadas funções como busca de registro de algum paciente,
relatórios diários, semanais ou mensais de pacientes inadimplentes por
exemplo.
1.4. MOTIVAÇÃO
Observada a falta de um software para gerenciamento de clínicas odontológicas em
toda cidade de Maracaí, e juntamente com a administradora de uma clínica dentária
da cidade surgiu à motivação para o desenvolvimento do presente trabalho visando
trazer comodidade e agilidade nas tarefas do dia a dia.
A possibilidade de implantação do respectivo sistema em outras empresas do mesmo
segmento o torna muito interessante, levando-se em consideração que o problema
apresentado na cidade de Maracaí também deve existir em outras cidades da região.
1.5. PERSPECTIVA DE CONTRIBUIÇÃO
O sistema foi desenvolvido de modo que, se futuramente houver necessidade de
novas funcionalidades, estas podem ser implementadas garantindo sempre o
atendimento às necessidades de novos clientes, e a modernização do sistema em si.
14
2. METODOLOGIA DE DESENVOLVIMENTO
Para fins de documentação e validação de requisitos, proporcionando ao usuário e
equipe de desenvolvimento um maior entendimento sobre o projeto, foi necessária a
utilização de algumas ferramentas para a elaboração da análise e projeto do sistema.
A seguir são apresentadas as definições técnicas sobre ferramentas usadas neste
projeto.
2.1. UML
A UML surgiu da união de três métodos de modelagem: o método de Booch, o
método OMT (Object Modeling Technique) de Jacobson, e o método OOSE (Object-
Oriented Software Engineering) de Rumbaugh. Estes eram, até meados da década de
90, os métodos de modelagem orientada a objetos mais populares entre os
profissionais da área de desenvolvimento de software. A união desses métodos
contou com o amplo apoio da Rational Software, que a incentivou e financiou. Tão
logo a primeira versão foi lançada, muitas empresas atuantes na área de modelagem
e desenvolvimento de software passaram a contribuir para o projeto, fornecendo
sugestões para melhorar e ampliar a linguagem. Finalmente, a UML foi
adotada, em 1997, pela OMG (Object Management Group ou Grupo de
Gerenciamento de Objetos), como uma linguagem-padrão de modelagem.
A versão 2.0 da linguagem foi oficialmente lançada em julho de 2005, encontrando-
se esta atualmente na versão 2.2, sendo que já existe a versão 2.3 beta. Sabe-se que
para garantir a qualidade de um software é essencial que seus requisitos sejam
compreendidos. Para a confecção de diagramas UML será utilizado o Astah.(Guedes,
2010).
2.1.1 Astah
O Astah Professional é uma ferramenta de design de sistemas que suporta UML,
diagrama de classe, fluxograma, caso de uso, diagrama de sequência, Tabela de
Requisições e Mapas Mentais. Astah é uma ferramenta gratuita voltada para a
modelagem de diagramas UML (Unified Modeling Language). Além do Astah
Professional, existem outras três versões: Astah UML, Astah Community e Astah
15
Share que disponibilizam outras funcionalidades além da modelagem UML, porém,
sua licença é comercial. (BRONDANI, 2013)
2.2. LINGUAGENS DE PROGRAMAÇÃO
2.2.1. .NET
Cabe esclarecer que o .NET não é uma linguagem, e sim uma plataforma da
Microsoft que permite a utilização de diversas linguagens, como C#, Visual Basic, J#
e ASP.
O .NET é um componente integrado ao Windows que suporta a execução e
desenvolvimento de uma nova geração de aplicações e XML web services. Segundo
sua documentação, o, .NET foi projetado com os seguintes objetivos:
Prover um ambiente consistente de programação orientada a objeto de modo
que o código é armazenado e executado localmente, mas pode também ser
armazenado na internet e executado remotamente.
Prover um ambiente de execução de código que minimiza o desenvolvimento
de software e conflitos de versão.
Prover um ambiente de execução de código que elimine os problemas de
desempenho gerados por linguagens de script ou ambientes interpretados.
Aproveitar o conhecimento do programador em diferentes tipos de aplicações
como aplicações desktop ou web.
Construir toda comunicação em padrões reconhecidos pela indústria para que
o .NET possa se integrar em qualquer tipo de código.(Lotar, 2010)
2.2.2. C#
É uma linguagem de programação orientada a objetos, simples e poderosa, e ao
mesmo, tempo ideal para desenvolvimentos web com a plataforma .NET. A sua
sintaxe orientada a objetos foi baseada no C++, mas inclui muitas influências de
outras linguagens de programação, como Object Pascal e Java. Possui um
mecanismo chamado Garbage Colector (Coletor de lixo) que gerencia de forma
16
automática, a memoria utilizada pelas aplicações e facilita o desenvolvimento de
aplicações web e desktop.(Lotar, 2010)
2.3. BANCO DE DADOS
2.3.1. SQL Server 2012 Express
O Microsoft SQL Server 2012 Express é um sistema gratuito de gerenciamento de
dados avançado e confiável que fornece um repositório de dados confiável e
avançado para sites leves e aplicativos de área de trabalho, aplicativos Web e de
servidores pequenos. A versão do SQL Server 2012 Express inclui a versão
completa do SQL Server 2012 Management. Essa versão não contém o banco de
dados, mas apenas as ferramentas para gerenciar as instâncias do SQL Server,
incluindo LocalDB, SQL Express, SQL Azure, versão completa do SQL Server 2012
Management Studio.( Microsoft, 2014).
17
3. PLANEJAMENTO DO PROJETO
3.1. ESTRUTURA ANALÍTICA DO PROJETO (EAP)
A EAP (Estrutura Analítica do Projeto) ou WBS (Work Breakdown Structure) é
fundamental para o projeto, pois através dela consegue-se organizar e definir o
escopo do projeto. Todo o trabalho do projeto deve ser visualizado na EAP, caso
contrário, não faz parte do escopo. Alguns pontos interessantes da EAP:
Separa as entregas em partes menores para assegurar que o plano de
gerenciamento do projeto cumprirá o escopo aprovado;
Auxilia na decomposição do projeto em elementos simples;
Auxilia no planejamento e na designação de responsabilidades;
Fundamental para a comunicação referente ao escopo do projeto entre os
clientes e futuros usuários do sistema.
Uma etapa muito importante para o escopo e a coleta de requisitos que consiste em
definir e gerenciar as expectativas do cliente. Os requisitos documentados serão a
estrutura para a criação da EAP, essas informações do cliente serão as futuras
funcionalidades e características do sistema (PMI, 2008).
Com todas as informações em mãos pode-se construir a WBS, que é criada com base
nas informações do inicio do projeto e segue por toda área de planejamento,
execução, monitoramento e controle do projeto. A estrutura da EAP segue uma
hierarquia orientada ao cronograma de entrega do trabalho que serão executados
pela equipe responsável pelos objetivos. Todo trabalho planejado é contido em
componentes menores que são os níveis mais baixos da EAP, denominados de
pacotes (PMI, 2008). A figura 1 representa o WBS do Sistema de Gerenciamento de
Consultório Odontológico.
18
Figura 1 Representa o diagrama EAP do projeto.
3.2. SEQUENCIAMENTO DAS ATIVIDADES
O sequenciamento da atividade envolve identificar e documentar os relacionamentos
lógicos entre as atividades. As atividades devem ser sequenciadas corretamente para
suportar o desenvolvimento de um cronograma realístico e alcançável. O
sequenciamento pode ser feito com o auxílio de ferramentas como o Astah ou com
técnicas manuais. As técnicas manuais são, geralmente, mais efetivas em projetos
menores e em fases iniciais de projetos maiores quando poucos detalhes estão
disponíveis. As técnicas manuais e automatizadas podem, também, ser utilizadas em
conjunto. A figura 2 ilustra o processo de Sequenciamento de Atividades do Sistema
de Gerenciamento de Consultório Odontológico.
19
Figura 2 Sequenciamento de Atividades
3.3. ESPECIFICAÇÕES DE CUSTO
3.3.1. Gerenciamento de Custos
É interessante notar que, o gerenciamento de custos trata principalmente dos custos
dos recursos necessários para terminar as atividades, ou seja, dos custos referentes
aos recursos alocados nas mesmas. De forma a garantir que o projeto seja executado
20
dentro do orçamento aprovado para o projeto sua estimativa deve ser baseada na
WBS, e devem estar envolvidos pontos como:
Custos de mão de obra;
Custos de materiais e suprimentos;
Custos de serviços contratados;
Custos de gerenciamento;
Custos de sistemas utilizados.
3.4. ORÇAMENTO
Custo com recursos humanos
Analista Quantidade de
horas Custo / hora (R$) Total (R$)
Analista 1 312 25,00 7.800
Custo Analista 7.800
Programador Quantidade de horas
Custo / hora (R$) Total (R$)
Programador 1 780 15,00 11.700
Custo Programadores 11.700
Custo Total Humano R$19,500
Equipamento 01 computador
Valor unitário = R$2.748,00
Dias (de uso) = 200 dias
Depreciação = R$2.748,00 / 24 meses (02 anos. Tempo de depreciação) =
R$114,5/mês
Custo nos 200 dias = R$763,00;
01 Impressora
Valor = R$300,00
Dias (de uso) = 200 dias
Depreciação = R$300,00 / 24 = R$12,5
Custo nos 200 dias = R$83,33
21
Custo Total com Equipamentos = R$846,33 Software
Visual Studio Professional 2012 = R$795,00
Microsoft SQL Server Express = R$0,00
Astah Professional = R$208,26
Axure 7.0 = R$600,00Db Designer = R$0,00
Microsoft Office Professional 2013 = R$1.179,00
Custo Total com software = R$2.782,23
3.5. Custo Total do Projeto
Tipo Valor R$
Custo Humano 19.500,00
Equipamentos 846,33
Software 2.782,23
Total 23.128,56
3.5. ACOMPANHAMENTO DO CRONOGRAMA
Atividades Data Início Data Fim Previsão Dias Status
Levantamento de Necessidades 02/dez 08/dez 5 Ok
Levantamento de Requisitos 09/dez 11/dez 2 Ok
Especificação dos Requisitos 11/dez 17/dez 5 Ok
Caso de Uso 18/dez 24/out 5 Ok
Especificação Caso de Uso 26/dez 09/jan 10 Ok
Diagrama de Atividades 10/jan 16/jan 5 Ok
Diagrama de Classe 17/jan 23/jan 5 Ok
Estrutura Analítica 24/jan 29/jan 5 Ok
Sequenciamento de Atividades 30/jan 05/fev 5 Ok
Cronograma 06/fev 11/fev 5 Ok
Orçamento 12/fev 17/fev 5 Ok
Implementação 03/mar 17/jul 120 OK
Testes 18/jul 24/jul 5 OK
Total 182
Tabela 1 Acompanhamento do Cronograma
22
4. ANÁLISE DO PROJETO
4.1 ESPECIFICAÇÕES DE REQUISITOS
A tarefa de desenvolvimento de software engloba uma série de fases e atividades,
que independentemente da metodologia escolhida, ocorrem para a realização do seu
objetivo maior: entregar software funcionando corretamente dentro do orçamento e
prazos previstos para o seu desenvolvimento.
Segundo Andrade (2014), especificação de requisitos - São todas as atividades
realizadas para identificar, analisar, especificar e definir as necessidades de negócio
que um aplicativo deve prover para solução do problema levantado.
Gestão de requisitos preocupa-se com a documentação, versionamento, controle de
mudanças e qualidade dos requisitos levantados na fase de especificação de
requisitos. Todo requisito apresenta um ciclo de vida único que acompanha a
dinâmica dos negócios associados. Assim sendo, não se pode esperar que um
requisito seja imutável ao longo do tempo, uma vez que o negócio do qual o requisito
se desprende é dinâmico.
4.1.1 Requisitos Funcionais
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. Seguem
os requisitos funcionais do Sistema de Gerenciamento de Consultório Odontológico.
Manter Usuário (Administrador);
Manter Dentista (Administrador);
Manter Procedimentos (Administrador);
Manter Mensalidades (Administrador, secretária);
Gerar Comprovante de Pagamentos (Administrador, secretária);
23
Gerar Inadimplentes (Administrador, secretária);
Gerar Receitas (Administrador, secretária);
Manter Pacientes (Administrador, secretária);
Gerar Declarantes de imposto de renda (Administrador, secretária);
Gerar Aniversariantes (Administrador, secretária);
Manter Consulta (Administrador, secretária);
Gerar Lembrete de Consulta (Administrador, secretária);
Gerar Relatórios de pacientes faltosos (Administrador, secretária);
Gerar Relatórios de Consultas Canceladas (Administrador, secretária);
Permitir que um usuário autorizado exclua consultas que por ventura venha ser
canceladas por algum contratempo.
Permitir a visualização de dados estatísticos como pacientes inadimplentes,
pacientes faltosos, pacientes que declaram imposto de renda e aniversariantes do
mês.
Permitir que um usuário autorizado forneça, opcionalmente, um porcentual
mínimo de desconto com autorização mediante digitação de senha do administrador.
4.1.2 Requisitos Não Funcionais
Expressam qualidade e restrições sobre os serviços ou as funções oferecidas pelo
sistema. Seguem os requisitos não funcionais do Sistema de Gerenciamento de
Consultório Odontológico:
Os usuários deverão estar logados no sistema antes de acessarem os recursos
e ferramentas do software.
O sistema deve permitir que usuários autorizados sejam capazes de agendar
consultas, cadastrar pacientes, e gerenciar mensalidades.
Permitir que usuários autorizados possam editar posteriormente um cadastro
de clientes ou adequar agenda de consultas.
Possuir uma plataforma de desenvolvimento que traz toda confiabilidade na
parte de segurança e no seu comportamento funcional.
24
5. MODELAGEM DO SISTEMA
5.1 CASOS DE USO
Larman (2004) considera os casos de uso como um mecanismo amplamente utilizado
para descobrir e registrar requisitos. Um caso de uso vem a representar uma forma
descrita de como usar o sistema para resolver os requisitos descritos pelo cliente. Os
casos de usos seriam em termos simples, casos em que o sistema seria usado pelo
usuário, um cenário onde o usuário estaria se utilizando de todas as funcionalidades
que o programa tem e todos os tipos de resultados esperados que o programa deva
apresentar como resposta.
Os casos de usos são feitos em duas formas, uma escrita, de acordo com os vários
padrões existentes, como colunas de ação do usuário e reação do sistema, ou listas
de ações e estados possíveis com várias ações do sistema. Posteriormente a
diagramação, onde a UML possui um padrão para ilustrar os nomes dos casos de
usos, atores e seus relacionamentos. A Figura 3 representa o diagrama de caso de
25
uso do Sistema de Gerenciamento de Consultório Odontológico.
Figura 3 Diagrama de Caso de Uso
5.1.2 Narrativas de Caso de Uso
Caso de Uso: Manter Usuário Ator: Administrador Fluxo Principal Fluxo Principal 1- O ator Seleciona a aba de cadastros de usuários;
2- O sistema Lista as opções;
3- O ator seleciona que deseja incluir um novo usuário (A1, A2, A3);
4- O sistema solicita os dados cadastrais;
5- O ator Insere os dados e confirma a operação;
6- O sistema retorna mensagem de operação executada com sucesso (E2);
7- O caso de uso é encerrado;
26
Fluxo alternativo A1- Atualizar Cadastro
1- O ator seleciona o cadastro que deseja alterar (E1);
2- O sistema oferece o cadastro para alteração; Segue com o passo 5 do fluxo
principal.
A2- Excluir Cadastro
1- O ator Seleciona o usuário que deseja excluir (E1);
2- O sistema solicita confirmação;
3- O ator confirma a exclusão;
4- O sistema efetua a exclusão e retorna ao passo 2 do fluxo principal.
A3- Cancelar Operação
1- O ator cancela a operação de cadastro podendo ou não informar algum dado;
2- O Sistema Retorna ao Passo 2 do fluxo principal;
Fluxo de exceção
E1- Usuário não cadastrado
1- O sistema realiza uma consulta e verifica que o usuário não esta cadastrado;
2- O sistema retorna ao passo 2 do fluxo principal.
E2- Falta ou Dados incorretos
1- O sistema verifica os campos obrigatórios em branco ou dados incorretos;
2- O sistema retorna uma mensagem listando campos inconsistentes para serem
revidas;
3- O sistema retorna ao passo 5 do fluxo principal.
27
Caso de Uso: Manter Dentista
Ator: Administrador
Fluxo Principal
1- O ator Seleciona a aba de cadastros de dentistas;
2- O sistema Lista as opções;
3- O ator seleciona que deseja incluir um novo dentista (A1, A2, A3);
4- O sistema solicita os dados cadastrais;
5- O ator Insere os dados e confirma a operação;
6- O sistema retorna mensagem de operação executada com sucesso (E2);
7- O caso de uso é encerrado;
Fluxo alternativo
A1- Atualizar Cadastro
1- O ator seleciona o cadastro que deseja alterar (E1);
2- O sistema oferece o cadastro para alteração; Segue com o passo 5 do fluxo
principal.
A2- Excluir Cadastro
1- O ator Seleciona o dentista que deseja excluir (E1);
2- O sistema solicita confirmação;
3- O ator confirma a exclusão;
4- O sistema efetua a exclusão e retorna ao passo 2 do fluxo principal.
A3- Cancelar Operação
28
1- O ator cancela a operação de cadastro podendo ou não informar algum dado;
2- O Sistema Retorna ao Passo 2 do fluxo principal;
Fluxo de exceção
E1- Dentista não cadastrado
1- O sistema realiza uma consulta e verifica que o dentista não esta cadastrado;
2- O sistema retorna ao passo 2 do fluxo principal.
E2- Falta ou Dados incorretos
1- O sistema verifica os campos obrigatórios em branco ou dados incorretos;
2- O sistema retorna uma mensagem listando campos inconsistentes para serem
revidas;
3- O sistema retorna ao passo 5 do fluxo principal.
Caso de uso: Manter mensalidade
Ator: Administrador, Secretária.
Fluxo Principal
1- O ator Seleciona a aba de mensalidades;
2- O sistema Lista as opções;
3- O ator seleciona que deseja efetuar baixa de mensalidade (A1);
4- O sistema solicita os dados do paciente;
5- O ator Insere os dados e confirma a operação (E1);
6- O sistema retorna o histórico de mensalidades pagas e em aberto (E2);
7- O ator seleciona qual mensalidade será paga;
8- O sistema baixa a mensalidade e emite comprovante de pagamento;
9- O caso de uso é encerrado;
29
Fluxo alternativo
A1- Atualizar Mensalidade
1- O ator seleciona que deseja alterar mensalidade (E1);
1- O sistema solicita os dados do paciente;
2- O ator Insere os dados e confirma a operação;
3- O sistema lista mensalidades em aberto para alteração;
4- O ator seleciona mensalidade que deseja alterar (A2);
5- O sistema atualiza os dados e retorna ao passo 2 do fluxo principal.
A2- Ator não tem Privilégios de administrador
1- O sistema solicita senha de administrador (A1);
2- O ator informa seu usuário e senha;
3- O sistema verifica os privilégios do ator (A2);
4- O Sistema retorna ao passo 2 do fluxo principal.
A3- Cancelar Operação
1- O ator cancela a operação de cadastro podendo ou não informar algum dado;
2- O Sistema Retorna ao Passo 2 do fluxo principal;
Fluxo de exceção
E1- Usuário não cadastrado
1- O sistema realiza uma consulta e verifica que o usuário não esta cadastrado;
2- O sistema retorna ao passo 2 do fluxo principal.
E2- Falta ou Dados incorretos
30
1- O sistema verifica os campos obrigatórios em branco ou dados incorretos;
2- O sistema retorna uma mensagem listando campos inconsistentes para serem
revidas;
3- O sistema retorna ao passo 4 do fluxo principal.
Caso de Uso: Manter Paciente
Ator: Administrador, secretária.
Fluxo Principal
1- O ator Seleciona a aba de cadastros de Pacientes;
2- O sistema Lista as opções;
3- O ator seleciona que deseja incluir um novo paciente (A1, A2, A3);
4- O sistema solicita os dados cadastrais;
5- O ator Insere os dados e confirma a operação;
6- O sistema retorna mensagem de operação executada com sucesso (E2);
7- O caso de uso é encerrado;
Fluxo alternativo
A1- Atualizar Cadastro
1- O ator seleciona o cadastro que deseja alterar (E1);
2- O sistema oferece o cadastro para alteração; Segue com o passo 5 do fluxo
principal.
A2- Excluir Cadastro
1- O ator Seleciona o cadastro que deseja excluir (E1);
2- O sistema solicita confirmação;
3- O ator confirma a exclusão;
4- O sistema efetua a exclusão e retorna ao passo 2 do fluxo principal.
31
A3- Cancelar Operação
1- O ator cancela a operação de cadastro podendo ou não informar algum dado;
2- O Sistema Retorna ao Passo 2 do fluxo principal;
Fluxo de exceção
E1- Usuário não cadastrado
1- O sistema realiza uma consulta e verifica que o usuário não esta cadastrado;
2- O sistema retorna ao passo dois do fluxo principal.
E2- Falta ou Dados incorretos
1- O sistema verifica os campos obrigatórios em branco ou dados incorretos;
2- O sistema retorna uma mensagem listando campos inconsistentes para serem
revidas;
3- O sistema retorna ao passo 5 do fluxo principal.
Caso de Uso: Manter Agenda
Ator: Administrador, secretária.
Fluxo Principal
1- O ator Seleciona a aba da agenda;
2- O sistema Lista as opções;
3- O ator seleciona que deseja incluir uma nova consulta (A1, A2, A3);
4- O sistema solicita os dados;
5- O ator Insere os dados e confirma a operação;
32
6- O sistema retorna mensagem de operação executada com sucesso gerando
comprovante do agendamento de nova consulta (E2);
7- O caso de uso é encerrado;
Fluxo alternativo
A1- Atualizar consulta
1- O ator seleciona a consulta que deseja alterar (E1);
2- O sistema oferece o cadastro para alteração; Segue com o passo 5 do fluxo
principal.
A2- Excluir consulta
1- O ator Seleciona a consulta que deseja excluir (E1);
2- O sistema solicita confirmação;
3- O ator confirma a exclusão;
4- O sistema efetua a exclusão e retorna ao passo 2 do fluxo principal.
A3- Cancelar Operação
1- O ator cancela a operação de cadastro podendo ou não informar algum dado;
2- O Sistema Retorna ao Passo 2 do fluxo principal;
Fluxo de exceção
E1- consulta não cadastrado
1- O sistema realiza uma busca e verifica que a consulta não está cadastrada;
2- O sistema retorna ao passo 2 do fluxo principal.
E2- Falta ou Dados incorretos
33
1- O sistema verifica os campos obrigatórios em branco ou dados incorretos;
2- O sistema retorna uma mensagem listando campos inconsistentes para serem
revidas;
3- O sistema retorna ao passo 5 do fluxo principal
5.2. DIAGRAMA ENTIDADE RELACIONAMENTO
Modelo baseado na percepção do mundo real, que consiste em um conjunto de
objetos básicos chamados entidades e nos relacionamentos entre esses objetos tem
como principal objetivo facilitar o projeto de banco de dados, possibilitando a
especificação da estrutura lógica geral do banco de dados. A estrutura lógica geral de
um banco de dados pode ser expressa graficamente por um Diagrama Entidade-
Relacionamento (DER). O DER serve para modelar os dados do sistema se torna
interessante quando se deseja especificar os dados que são necessários, mostrar a
quem pertence os dados e identificar seus relacionamentos. (YOURDON, 1997) A
figura 4 ilustra o DER do Sistema de Gerenciamento de Consultório Odontológico.
34
Figura 4 Diagrama Entidade Relacionamento
5.3. DIAGRAMA DE CLASSE
O diagrama de classes é provavelmente o diagrama mais utilizado e é um dos mais
importantes da UML. Serve de apoio para a maioria dos demais diagramas. Como o
próprio nome diz, define a estrutura das classes utilizadas pelo sistema, determinando
os atributos e métodos que cada classe tem, além de estabelecer como as classes se
relacionam e trocam informações entre si. (Guedes, 2010). A Figura 5 ilustra o
Diagrama de Classe do Sistema de Gerenciamento de Consultório Odontológico.
35
Figura 5 Diagrama de Classe
5.4. DIAGRAMA DE ATIVIDADES
O diagrama de atividades era considerado um caso especial do antigo diagrama de
gráfico de estado hoje conhecido como diagrama de máquina de estado. A partir da
UML 2.0 foi considerado independente do diagrama de máquinas de estado. O
diagrama de atividades preocupa-se em descrever os passos a serem percorridos
para a conclusão de uma atividade específica muitas vezes representada por um
método com certo grau de complexidade e não de um processo completo como é
considerado o diagrama de sequência ou colaboração embora também possa ser
36
utilizado para tal fim.(Guedes, 2010). O diagrama de atividades do Sistema de
Gerenciamento de Consultório Odontológico encontra-se na representação abaixo
figuras 6 e 7.
Figura 6 Diagrama de Atividades Agendar Consulta
40
7. CONCLUSÃO
O desenvolvimento do presente trabalho proporcionou um ganho de experiência em
desenvolvimento web, C#, diagramas UML e gerenciamento de banco de dados,
assim concluindo que os objetivos foram todos atingidos. Espera-se que após
implantação do SGCO, o mesmo possa trazer todos os benefícios que um sistema
web proporciona a seus usuários, como a comodidade de acesso as informações de
qualquer lugar com acesso a internet e a agilidade da automatização de processos
diários reduzindo o tempo de realização de tarefas.
Como trabalhos futuros, pretende-se desenvolver o módulo de folha de pagamento,
painel do usuário para uma aproximação dos dentistas e funcionários da clinica com
pacientes e o modulo de SMS como lembretes de consultas ou avisos de
cancelamentos.
41
8. REFERÊNCIAS
ANDRADE, Márcio S. Importância do levantamento de Requisitos Disponível em: http://www.linhadecodigo.com.br/artigo/1685/a-importancia-do-levantamento-de-requisitos-no-sucesso-dos-projetos-de-software.aspx. Acesso em: 04 de março de 2014.
BRONDANI, Camila; AREND, Cesar; ZILIO, Darciele; PUIATI, José Carlos. Guia Prático de utilização da ferramenta Astah Community 6.1. Disponível em: <http://www-pet-si.inf.ufsm.br/images/consultoriodesoftware/Astah.pdf> Acesso em 06 de Março de 2014.
Guedes, Gilleanes T. A. – UML Uma Abordagem Pratica, 3°Edição. São Paulo, Editora Novatec, 2010. LARMAN, Craig - Utilizando UML e Padrões. Editora Bookman, 2007. 695 p. LOTAR, Alfredo – Como Programar com ASP.NET e C#, 2°Edição. São Paulo, Editora Novatec, 2010. Microsoft SQL Server disponível em: http://www.microsoft.com/pt-br/download/details.aspx?id=35579. Acesso em 07 de março de 2014. Requisitos Funcionais e não funcionais disponível em: http://www.deinf.ufma.br/~maria/arqan/cap3-requis.pdf. Acesso em: 04 de março de 2014. PMI. Um guia do conhecimento em gerenciamento de projetos: guia PMBOK. 4. ed. Newton Square: PE, 2008. 459 p. YOURDON, Edward - Análise Estruturada Moderna; 3ª Edição; Editora Campus; Rio de Janeiro, 1990.