Faculdade de Tecnologia da Zona Sul

Rafael Almeida da Silva

DOCUMENTAO DO SISTEMA DE GERENCIAMENTO

DE CONSULTAS: ODONTUS

So Paulo
2013

Rafael Almeida da Silva

DOCUMENTAO DO SISTEMA DE GERENCIAMENTO

DE CONSULTAS: ODONTUS

Trabalho apresentado disciplina Engenharia de

Software III, ministrada pela Prof. Esp. Denise
Lemes Fernandes Neves para o curso Superior
de Tecnologia em Anlise e Desenvolvimento de
Sistemas.

FACULDADE DE TECNOLOGIA DA ZONA SUL

So Paulo
2013

Dedico este trabalho aos meus avs Iraci e

Hermnio, pelo eterno carinho e incentivo.

AGRADECIMENTOS

Agradeo a todos que me incentivaram a desenvolver este trabalho e me

ajudaram com experincias, ideias e dicas para a execuo dele.
minha famlia pela dedicao e compreenso no decorrer desse trabalho.
A todos os professores e colegas que me ensinaram e ajudaram, direta ou
indiretamente, contribuindo com o meu crescimento.

O insucesso apenas uma

oportunidade para recomear de
novo com mais inteligncia.
Henry Ford

RESUMO

O presente trabalho tem como objetivo o emprego de tcnicas de

levantamento e anlise de requisitos, modelagem de sistema utilizando a linguagem
UML e demais tcnicas e metodologias aprendidas durante as aulas de Engenharia
de Software, para que seja elaborada a documentao de um sistema de informao
seguindo as tcnicas e padres relacionados UML e ao paradigma orientado a
objetos. Com a utilizao desses conceitos de forma adequada pretende-se garantir
que a documentao do sistema seja o mais simples e completa possvel, facilitando
a futura implementao do software projetado.

Palavras-chave: anlise de requisitos, UML, sistemas, modelagem, projetos.

ABSTRACT

The present work aims employing survey techniques ans analysis of

requirements, system modeling using UML and other techniques and methodologies
learned during class Software Engineering, to be prepared documenting na
information system following techniques ans standards related to UML and also the
object-oriented paradigm. With the use of these concepts appropriately intended to
ensure that the system documentation is as simple and complete as possible,
facilitating future implementation of the designed software.

Keywords: analysis of requirements, UML, systems, modeling, projects.

LISTA DE FIGURAS

Figura 1 - Diagrama de casos de uso do sistema Odontu's - Acesso Desktop

.................................................................................................................................. 20
Figura 2 - Diagrama de casos de uso do sistema Odontu's - Acesso Mobile . 21
Figura 3 - Diagrama de classes do sistema Odontu's - Acesso Desktop........ 34
Figura 4 - Diagrama de classes do sistema Odontu's - Acesso Mobile .......... 34
Figura 5 - Diagrama de objetos do sistema Odontu's ..................................... 35
Figura 6 - Diagrama de sequncia do sistema Odontu's - Processo Manter
Paciente .................................................................................................................... 36
Figura 7 - Diagrama de sequncia do sistema Odontu's - Processo Agendar
Consulta .................................................................................................................... 37
Figura 8 - Diagrama de sequncia do sistema Odontu's - Processo Atender
Consulta .................................................................................................................... 37
Figura 9 - Diagrama de atividade do sistema Odontu's - Processo Agendar
Consulta .................................................................................................................... 38
Figura 10 - Diagrama de atividade do sistema Odontu's - Processo Atender
Consulta .................................................................................................................... 39
Figura 11 - Diagrama de mquina de estados do sistema Odontu's - Processo
Login Vlido............................................................................................................... 40
Figura 12 - Diagrama de mquina de estados do sistema Odontu's - Processo
Login Expirado .......................................................................................................... 40
Figura 13 - Diagrama de componentes do sistema Odontu's ......................... 41
Figura 14 - Diagrama de implantao do sistema Odontu's ........................... 42
Figura 15 - Prottipo da implementao do mdulo de pagamentos do sistema
Odontu's .................................................................................................................... 43

LISTA DE TABELAS

Tabela 1 - Matriz de Rastreabilidade .............................................................. 17

LISTA DE ABREVIATURAS E SIGLAS

UML Unified Modeling Language

RF Referncia Funcional
UC Use Case
PMBOK - Project Management Body of Knowledge
PMI - Porject Management Institute

SUMRIO
LISTA DE FIGURAS ........................................................................................ 6
LISTA DE TABELAS........................................................................................ 7
LISTA DE ABREVIATURAS E SIGLAS .......................................................... 8
INTRODUO ............................................................................................... 11
1. APRESENTAO DO CONSULTRIO .................................................... 12
1.1. PROCESSOS INTERNOS ................................................................................................................. 12
1.2. CENRIO ATUAL DA EMPRESA ..................................................................................................... 13

2. REGRAS DE NEGCIO............................................................................. 14
3. DESCRIO FUNCIONAL ........................................................................ 15
4. REFERNCIAS FUNCIONAIS ................................................................... 15
5. CASOS DE USO ........................................................................................ 16
6. MATRIZ DE RASTREABILIDADE ............................................................. 17
7. UML (UNIFIED MODELING LANGUAGE)................................................. 18
7.1. UML DEFINIO ........................................................................................................................ 18

8. DIAGRAMAS DA UML ............................................................................... 19

8.1. DIAGRAMA DE CASOS DE USO...................................................................................................... 20
8.1.1. CENRIOS FLUXO TIMO E FLUXO ALTERNATIVO ............................................................ 22
8.2. DIAGRAMA DE CLASSES................................................................................................................ 34
8.3. DIAGRAMA DE OBJETOS ............................................................................................................... 35
8.4. DIAGRAMA DE SEQUNCIA .......................................................................................................... 36
8.5. DIAGRAMA DE ATIVIDADES.......................................................................................................... 38
8.6. DIAGRAMA DE MQUINA DE ESTADOS........................................................................................ 40
8.7. DIAGRAMA DE COMPONENTES ................................................................................................... 41
8.8. DIAGRAMA DE IMPLANTAO ..................................................................................................... 42

9. IMPLEMENTAO DO SISTEMA ODONTUS ......................................... 43

CONSIDERAES FINAIS ........................................................................... 44

REFERNCIAS BIBLIOGRFICAS .............................................................. 45

ANEXO A ROTEIRO DA ENTREVISTA ..................................................... 46

11

INTRODUO

A demanda por novos projetos de software cresceu muito nos ltimos anos,
levando empresas, independente do seu porte, a buscar ferramentas de software
cada vez mais sofisticadas para atender s necessidades existentes. comum
empresas passarem por problemas ou at mesmo congelar seu faturamento por
conta de no possuir as ferramentas tecnolgicas corretas para otimizar seus
processos.
Esse documento apresenta a descrio de um produto de software que foi
elaborada utilizando como cenrio o consultrio odontolgico da Dr. Ana Paula que
atualmente no possui nenhum sistema para agilizar o atendimento ao cliente.
Para a elaborao deste trabalho, foi feito um levantamento de requisitos
atravs de entrevistas feitas com a Dr. Ana Paula e com sua atendente. Esses
requisitos foram analisados para que fossem definidos quais os recursos que o
sistema dever possuir para atender plenamente as necessidades atuais e futuras
do consultrio no que se refere a software para agendamento e controle de
consultas e criao de pronturios. O software ser utilizado para cadastro de
pacientes, criao e atualizao de pronturios, agendamento e cancelamento de
consultas e gerao de relatrios.
Aps o levantamento e anlise dos requisitos, fez-se o uso da UML para
criao de modelos de diagramas do sistema. Cada diagrama criado foi apresentado
em um tpico, no qual constam o diagrama, sua descrio e qual o seu papel no
processo de projeto de sistemas.
Toda a documentao necessria para a criao do software, denominado
Odontus, est registrada nos tpicos a seguir.

12

1. APRESENTAO DO CONSULTRIO

O consultrio odontolgico da Dr. Ana Paula uma microempresa situada na

cidade de So Paulo que presta servios de ortodontia.
A empresa conta com dois funcionrios, sendo um recepcionista e um
cirurgio dentista.
No consultrio so oferecidos servios como: odontopediatria, dentstica,
endodontia, periodontia, cirurgia, ortodontia preventiva e corretiva.

1.1. PROCESSOS INTERNOS

O consultrio trabalha, atualmente, da seguinte maneira. O paciente entra em

contato, pessoalmente ou por telefone, e agenda uma consulta. A primeira consulta
sempre para realizao de um oramento conforme o tratamento que o paciente
necessita. Caso o oramento seja aprovado pelo paciente, o tratamento se inicia,
sendo agendadas consultas semanais ou quinzenais.
Assim que um oramento aprovado, o pronturio do paciente criado para
controlar o tratamento e registrar informaes importantes de cada consulta que o
paciente tiver. Aps cada consulta, o pagamento desta deve ser efetuado, em
dinheiro, pois o consultrio no fornece outro meio de pagamento.
O consultrio no possui computadores, logo, no possui um sistema
informatizado. H um arquivo na recepo onde so guardados os pronturios dos
pacientes.
Ao

concluir

um

tratamento

especfico

paciente

passa

por

um

acompanhamento trimestral onde recebe orientaes para o cuidado correto que

deve ter para manter o resultado obtido por mais tempo.

13

1.2. CENRIO ATUAL DA EMPRESA

Atualmente, no consultrio da Dr. Ana Paula todas as tarefas de cadastro de

pacientes, agendamento de consultas, controle de pronturios, registro de
pagamentos e elaborao e emisso de relatrios, so feitos manualmente. Essas
tarefas podem ser executadas com maior rapidez e eficincia caso seja
desenvolvido um sistema que permita execut-las. O consultrio no possui
computadores e no fornece outra forma para agendamento de consulta seno por
telefone, nem fornece meios para efetuar pagamentos seno em dinheiro.

14

2. REGRAS DE NEGCIO

Como em qualquer outra empresa, o consultrio da Dr. Ana Paula tambm

possui polticas internas, interesses e objetivos que ditam o funcionamento do
negcio. Essas polticas, interesses e objetivos definem as regras de negcio da
empresa e influenciam diretamente no desenvolvimento de um produto de software,
pois so as regras de negcio que especificaro as funcionalidades a serem
implementadas no software desenvolvido.
As regras de negcio, que definem as diretrizes seguidas pelo consultrio, e
que auxiliaram no levantamento das funcionalidades do sistema, so listadas abaixo:

As consultadas devem ser agendadas pessoalmente ou por telefone;

O cancelamento de uma consulta s pode ser realizado com, no mnimo,
24 horas de antecedncia ao horrio da consulta;
O tempo mximo de tolerncia, em caso de atraso, de 15 minutos. Aps
isso o prximo paciente agendado ser atendido;
Caso no comparea no dia e horrio da consulta, o paciente obrigado a
pagar pela consulta;
Para fazer um oramento no necessrio marcar uma consulta;
No obrigatria a apresentao de um documento para fazer um
oramento;
Crianas s sero atendidas com autorizao de um responsvel;
No dia da consulta obrigatria a apresentao do carto de
agendamento/pagamento fornecido pelo consultrio no incio do
tratamento;
O atendimento feito de segunda a sexta, das 08h s 18h, e eventuais
sbados das 07h s 12h, exceto feriado;
Quando necessrio, o consultrio liga para os pacientes para agendar ou
cancelar consultas;
Todos os agendamentos so registrados na nossa agenda anual;
O consultrio no atende planos de sade;
O pagamento deve ser feito logo aps a consulta;

Todas essas informaes foram coletadas nas entrevistas realizadas com a

Dr. Ana Paula e com sua atendente.

15

3. DESCRIO FUNCIONAL

No consultrio da Dr. Ana Paula trabalham duas pessoas, a prpria Ana

Paula e um atendente.
Ser feito um sistema que permita cadastrar e/ou desativar pacientes;
agendar, atender e/ou cancelar consultas; registrar os pagamentos recebidos; criar e
atualizar pronturios dos pacientes. Essas operaes sero realizadas pelo
atendente e pela dentista. O sistema deve ter permitir tambm que, o atendente
possa gerar relatrios mensais dos pacientes atendidos.
O cadastro de pacientes feito somente aps a apresentao de um
oramento, o qual deve ser aprovado pelos mesmos. Ao finalizar o cadastro do
paciente, o seu pronturio criado automaticamente.

4. REFERNCIAS FUNCIONAIS

As

referncias

funcionais

descrevem

de

maneira

simplificada

as

funcionalidades do sistema e identificam o caso de uso ao qual cada referncia

funcional est associada. A seguir, temos as referncias funcionais para o sistema
Odontus.

RF01 Login: O atendente ganha acesso ao sistema;

RF02 Paciente: O atendente cadastra (incluir, alterar, consulta e excluir)
paciente no sistema;
RF03 Consulta: O atendente registra o agendamento, atendimento ou
cancelamento de consultas para os pacientes;
RF04

Pronturio:

Ao

cadastrar

paciente,

sistema

criar

automaticamente o seu pronturio, o qual ser atualizado pelo atendente;

RF05 Pagamento: O atendente registra no cadastro do paciente o
pagamento referente consulta que foi atendida;
RF06 Relatrios: O atendente gera relatrio mensal dos pacientes
atendidos.

16

RF07 Login mobile: O paciente ganha acesso ao sistema atravs de

plataforma mobile;
RF08 Agenda mobile: O paciente consulta agenda atravs de plataforma
mobile.

5. CASOS DE USO

Os casos de uso so utilizados para obter o comportamento pretendido do

sistema que est em desenvolvimento.
Segundo Booch (2005, p. 227), um caso de uso especifica o comportamento
de um sistema ou de parte de um sistema e uma descrio de um conjunto de
sequncias de aes.
Os casos de uso mapeados para as funcionalidades do sistema Odontus
esto listados abaixo:

UC01 Fazer login;

UC02 Manter paciente;
UC03 Carregar paciente;
UC04 Desativar paciente;
UC05 Agendar consulta;
UC06 Atender consulta;
UC07 Cancelar consulta;
UC08 Atualizar pronturio;
UC09 Registrar pagamento;
UC10 Emitir relatrio mensal;
UC11 Logar no mobile;
UC12 Consultar agenda mobile.

17

6. MATRIZ DE RASTREABILIDADE

Segundo o guia PMBOK (PMI, 2012), a matriz de rastreabilidade facilita a

visualizao global dos casos de uso e requisitos do sistema, bem como a relao
existente entre os itens de cada escopo. Ela determina que cada referncia funcional
(RF) deve se relacionar com pelo menos um caso de uso (UC).
Tabela 1 - Matriz de Rastreabilidade

UC01
UC02
UC03
UC04
UC05
UC06
UC07
UC08
UC09
UC10
UC11

RF01
X

RF02

RF03

RF04

RF05

RF06

RF07

RF08

X
X
X
X
X
X
X
X
X
X

UC12

X
FONTE: Elaborada pelo autor

18

7. UML (Unified Modeling Language)

Agora que j foi realizado o levantamento dos requisitos, bem como

identificadas as funcionalidades do sistema, deve-se iniciar a fase de modelagem do
software.
Para a modelagem do sistema Odontus, ser utilizada a linguagem UML e
alguns dos seus diagramas sero utilizados deste ponto em diante.
Como a UML apenas uma linguagem de modelagem, ela somente uma
parte do processo de desenvolvimento de software que facilita a visualizao das
funcionalidades do sistema sem que este esteja implementado.

7.1. UML DEFINIO

A UML Unified Modeling Language ou Linguagem de Modelagem Unificada

descrita por Guedes (2011) como uma linguagem visual utilizada na modelagem
de softwares desenvolvidos sob o paradigma orientado a objetos. Por ser uma
linguagem de propsito geral, a UML pode ser utilizada em todos os domnios de
aplicao.

Tornou-se

linguagem-padro

de

modelagem

sendo

adotada

mundialmente pela indstria de engenharia de software. Cabe frisar que a UML no

uma linguagem de programao:
Deve ficar bem claro, que a UML no uma linguagem de programao, e
sim uma linguagem de modelagem, uma notao, cujo objetivo auxiliar os
engenheiros de software a definirem as caractersticas do sistema, tais
como seus requisitos, seu comportamento, sua estrutura lgica, a dinmica
de seus processos e at mesmo suas necessidades fsicas em relao ao
equipamento sobre o qual o sistema dever ser implantado. Tais
caractersticas podem ser definidas por meio da UML antes do software
comear a ser realmente desenvolvido. Alm disso, cumpre destacar que a
UML no um processo de desenvolvimento de software e tampouco est
ligada a um de forma exclusiva, sendo totalmente independente, podendo
ser utilizada por muitos processos de desenvolvimento diferentes ou mesmo
da forma que o engenheiro considerar mais adequada. (GUEDES, 2011, p.
19)

19

8. DIAGRAMAS DA UML

A UML 2.0 possui 13 diagramas que so divididos em duas categorias:

diagramas estruturais e diagramas comportamentais. (GUEDES, 2011)
Os diagramas estruturais do uma viso do aspecto esttico do sistema, ou
seja, de como os componentes do sistema ficaro organizados internamente. So
diagramas estruturais:

Diagrama de classes;

Diagrama de objetos;

Diagrama de componentes;

Diagrama de implantao;

Diagrama de pacotes;

Diagrama de estrutura composta.

J os diagramas comportamentais so os que mostram a existncia de

alguma alterao de comportamento das classes. So eles:

Diagrama de casos de uso;

Diagrama de mquina de estados;

Diagrama de atividades;

Diagrama de sequncia;

Diagrama de interao;

Diagrama de comunicao;

Diagrama de tempo.

Apenas alguns dos diagramas citados acima sero utilizados nesse trabalho,
os quais sero descritos nos prximos tpicos.

20

8.1. DIAGRAMA DE CASOS

CASO DE USO

O diagrama de casos
caso de uso o mais popular diagrama da UML.
amplamente utilizado
izado na fase de levantamento e anlise de requisitos,
requisitos procura
identificar os atores, os servios
servio e a interao entre estes.
O diagrama de casos
caso de uso o diagrama mais geral e informal da UML,
utilizado normalmente nas fases de levantamento e anlise de requisitos do
sistema, embora venha a ser consultado durante todo o processo de
sistema,
modelagem e possa servir de base para outros diagramas. Apresentam
uma linguagem simples e de fcil compreenso para que os usurios
possam ter uma ideia geral de como o sistema
sistema ir se comportar. Procura
identificar os atores (usurio, outros sistemas ou at mesmo algum
hardware especial) que utilizaro de alguma forma o software, bem como os
servios, ou seja, as funcionalidades que o sistema disponibilizar aos
atores, conhecidas
conhecidas nesse diagrama como casos de uso. (GUEDES, 2011, p.
30)

A seguir, so mostrados os diagramas de casos de uso desenvolvidos para o

sistema Odontus.

Figura 1 - Diagrama de casos de uso do sistema Odontu's - Acesso Desktop

FONTE: Elaborada pelo autor

21

Figura 2 - Diagrama de casos de uso do sistema Odontu's - Acesso Mobile

FONTE: Elaborada pelo autor

22

8.1.1. CENRIOS FLUXO TIMO E FLUXO ALTERNATIVO

Um cenrio uma determinada sequncia de aes que ilustra um

comportamento do sistema. Diz-se que um cenrio uma instncia de um caso de
uso.
Voc pode especificar o comportamento de um caso de uso pela descrio
do fluxo de eventos no texto de maneira suficientemente clara para que
algum de fora possa compreend-lo facilmente. Ao descrever o fluxo de
eventos, voc dever incluir como e quando o caso de uso inicia e termina,
quando o caso de uso interage com os atores e quais objetos so
transferidos e o fluxo bsico e fluxo alternativo do comportamento.
(BOOCH, 2005, p. 232)

Os cenrios e seus fluxos, timo e alternativo, do sistema Odontus so

descritos a seguir.
FLUXO TIMO
CASO DE USO:
PR-REQUISITO:
OBJETIVO:

Fazer login
Validar usurio e senha para garantir acesso ao sistema.

AES RECEBIDAS

2 O atendente digita usurio e senha.

AES REALIZADAS

1 O sistema exibe o formulrio de

login.
3 O sistema valida o usurio e a
senha.
4 O sistema libera acesso para o
usurio.

FLUXO ALTERNATIVO

Usurio ou senha incorreto(s).

AES RECEBIDAS

AES REALIZADAS

1 O sistema envia a mensagem:

Usurio ou senha incorreto(s).
Caso no possua usurio, contate o
administrador do sistema. Voltar
ao passo 2 do fluxo timo.

Campo usurio ou senha no preenchido.
AES RECEBIDAS

AES REALIZADAS
1 O sistema envia a mensagem:
Ateno! Digite o usurio e a senha.
Voltar ao passo 2 do fluxo timo.

23

FLUXO TIMO
CASO DE USO:
PR-REQUISITO:
OBJETIVO:

Manter Paciente
Cadastrar (incluir / alterar / consultar e excluir) dados de
pacientes.

AES RECEBIDAS
2 O atendente seleciona uma opo. Caso
consulta, alterao, ou excluso.
Seleciona paciente.
4 Caso incluso: O atendente preenche os
campos.
Caso alterao: O atendente edita os
campos que deseja modificar.
Caso excluso: O atendente confirma a
excluso.

AES REALIZADAS

<<include carrega paciente>>

1 O sistema habilita as opes:
incluir, alterar, consultar e excluir
paciente.
3 Caso incluir: O sistema habilita os
campos nome, telefone e rg.
Caso alterar: O sistema exibe nome,
telefone e RG do paciente selecionado
e habilita campos para edio.
Caso consultar: O sistema exibe
nome, telefone e RG do paciente
selecionado.
Caso excluir: O sistema exibe o nome,
telefone e RG do paciente selecionado
e habilita a opo excluir.
5 Caso incluir: O sistema armazena
os dados e envia a mensagem
Cadastro realizado com sucesso.
Caso alterar: O sistema armazena os
dados alterados e envia a mensagem
Alterao realizada com sucesso.
Caso excluir: O sistema remove o
cliente selecionado e envia a
mensagem Excluso efetuada.

24

FLUXO ALTERNATIVO

Campo nome no preenchido.

AES RECEBIDAS

AES REALIZADAS
1 O sistema envia mensagem:
Campo nome obrigatrio. Voltar ao
passo 4 do fluxo timo.

Campo telefone no preenchido.

AES RECEBIDAS

AES REALIZADAS
1 O sistema envia mensagem:
Campo telefone obrigatrio. Voltar
ao passo 4 do fluxo timo.

Campo telefone preenchido com caracteres diferentes de valor numricos.

AES RECEBIDAS

AES REALIZADAS
1 O sistema envia mensagem:
Campo telefone s pode ser
preenchido com nmeros. Voltar ao
passo 4 do fluxo timo.

RG j armazenado.
AES RECEBIDAS

AES REALIZADAS
1 O sistema envia mensagem: RG j
cadastrado. Voltar ao passo 4 do
fluxo timo.

25

FLUXO TIMO
CASO DE USO:
PR-REQUISITO:
OBJETIVO:

Desativar Paciente
Cadastrar Paciente
Desativa o cadastro do paciente e bloqueia a edio dos dados
do paciente.

AES RECEBIDAS
1 O atendente seleciona a opo
desativar.

AES REALIZADAS
<<include carrega paciente>>

2 O atendente seleciona o paciente que

ser desativado.

3 O sistema exibe o nome, telefone e

RG do paciente. E solicita confirmao.

4 O atendente confirma a desativao do

paciente.

5 O sistema desativa o cadastro do

paciente e bloqueia a edio dos
dados. Em seguida envia a mensagem
Desativao Efetuada.

FLUXO ALTERNATIVO

Paciente no cadastrado.
AES RECEBIDAS

AES REALIZADAS
1 O sistema envia mensagem:
Paciente no encontrado. Voltar ao
passo 2 do fluxo timo.

Cadastro j desativado.
AES RECEBIDAS

AES REALIZADAS
1 O sistema envia mensagem:
Cadastro j foi desativado. Voltar ao
passo 2 do fluxo timo.

26

FLUXO TIMO
CASO DE USO:
PR-REQUISITO:
OBJETIVO:

Carregar Paciente
Cadastrar Paciente
Carrega as informaes do paciente selecionado.

AES RECEBIDAS

AES REALIZADAS

1 O sistema exibe nome, telefone

e RG do paciente em um objeto na
tela.
FLUXO ALTERNATIVO

Paciente no cadastrado.
AES RECEBIDAS

AES REALIZADAS
1 O sistema envia mensagem:
Paciente no encontrado. Voltar ao
passo 1 do fluxo timo.

27

FLUXO TIMO
CASO DE USO:
PR-REQUISITO:
OBJETIVO:

Agendar Consulta
Cadastrar Paciente
Agendar data e horrio de consulta para pacientes.

AES RECEBIDAS

1 O atendente seleciona a opo

agendar consulta.

AES REALIZADAS
<<include carrega paciente>>

2 O sistema exibe os dias e

3 O atendente escolhe um dia e horrio. horrios disponveis.
6 O sistema muda o status do
4 O atendente seleciona o paciente.
horrio agendado para ocupado.
7 O sistema armazena as
informaes da consulta e envia a
5 O atendente confirma o agendamento mensagem: Consulta agendada
da consulta.
com sucesso.
FLUXO ALTERNATIVO

Dia e horrio no foi escolhido.

AES RECEBIDAS

AES REALIZADAS

1 O sistema envia a mensagem:

Por favor, escolher um dia e
horrio para a consulta. Voltar ao
passo 3 do fluxo timo.

No h horrios disponveis.
AES RECEBIDAS

AES REALIZADAS
1 O sistema envia mensagem:
Ateno, no h horrios disponveis,
escolha outro dia. Voltar ao passo 3
do fluxo timo.

Paciente no foi selecionado.

AES RECEBIDAS

AES REALIZADAS
1 O sistema envia mensagem: Por
favor, selecione um paciente para o
qual deseja agendar a consulta.
Voltar ao passo 4 do fluxo timo.

28

FLUXO TIMO
CASO DE USO:
PR-REQUISITO:
OBJETIVO:

Atender Consulta
Agendar Consulta
Atende consulta previamente agendada.

AES RECEBIDAS

AES REALIZADAS

1 O atendente seleciona a consulta que 2 O sistema exibe dia, hora, nome

ser atendida.
e telefone do paciente.
4 O sistema grava o dia e horrio
3 O atendente confirma o atendimento da consulta no pronturio do
da consulta.
paciente.
5 O sistema altera o status da
consulta para atendida. E envia a
mensagem: Atendimento
efetuado.

FLUXO TIMO
CASO DE USO:
PR-REQUISITO:
OBJETIVO:

Cancelar Consulta
Agendar Consulta
Cancela consulta previamente agendada.

AES RECEBIDAS

AES REALIZADAS

1 O atendente seleciona a consulta que 2 O sistema exibe dia, hora, nome

ser cancelada.
e telefone do paciente.
4 O sistema altera o status da
consulta para disponvel. E envia a
3 O atendente confirma o
mensagem: Cancelamento
cancelamento.
efetuado.

29

FLUXO TIMO
CASO DE USO:
PR-REQUISITO:
OBJETIVO:

Atualizar Pronturio
Atender Consulta
Registrar, no pronturio do paciente, descrio da consulta que
foi atendida.

AES RECEBIDAS

1 O atendente seleciona o paciente.

3 O atendente seleciona a opo
atualizar pronturio.
5 O atendente descreve o que foi feito
durante a consulta.
6 O atendente confirma a atualizao
do pronturio.

AES REALIZADAS

2 O sistema exibe nome, telefone

e RG do paciente.
4 O sistema exibe dia e hora da
consulta que foi atendida.
7 O sistema armazena a descrio
da consulta e envia a mensagem:
Atualizao efetuada.

FLUXO ALTERNATIVO

No h consulta atendida.
AES RECEBIDAS

AES REALIZADAS

1 O sistema envia a mensagem:

No h novos atendimentos para
o paciente escolhido. Voltar ao
passo 1 do fluxo timo.

Descrio da consulta no foi preenchida.
AES RECEBIDAS

AES REALIZADAS
1 O sistema envia mensagem:
Ateno, preencher descrio da
consulta atendida. Voltar ao passo 5
do fluxo timo.

30

FLUXO TIMO
CASO DE USO:
PR-REQUISITO:
OBJETIVO:

Registrar Pagamento
Atender Consulta
Registrar, no pronturio do paciente, dia, hora e valor pago.

AES RECEBIDAS

1 O atendente seleciona o paciente.

3 O atendente seleciona a opo
registrar pagamento.
5 O atendente informa o valor pago
pela consulta.

6 O atendente confirma o pagamento.

AES REALIZADAS
<<include carrega paciente>>

2 O sistema exibe nome, telefone

e RG do paciente.
4 O sistema exibe dia e hora da
consulta que foi atendida.
7 O sistema armazena valor, data
e hora do pagamento, e envia a
mensagem: Pagamento
efetuado.

FLUXO ALTERNATIVO

No h consulta atendida.
AES RECEBIDAS

AES REALIZADAS

1 O sistema envia a mensagem:

No h novos atendimentos para
o paciente escolhido. Voltar ao
passo 1 do fluxo timo.

Valor no foi preenchido.
AES RECEBIDAS

AES REALIZADAS
1 O sistema envia mensagem:
Ateno, informar o valor pago pela
consulta. Voltar ao passo 5 do fluxo
timo.

31

FLUXO TIMO
CASO DE USO:
PR-REQUISITO:
OBJETIVO:

Emitir Relatrio Mensal

Exibe relatrio de atendimentos do ms selecionado.

AES RECEBIDAS

AES REALIZADAS

1 O atendente seleciona a opo emitir 2 O sistema habilita o campo

relatrio.
ms.
4 O sistema exibe todas as
consultas atendidas no ms
selecionado, nomes dos pacientes,
dias e horrios dos atendimentos e
3 O atendente seleciona o ms.
o valores das consultas.
FLUXO ALTERNATIVO

Ms no foi selecionado.
AES RECEBIDAS

AES REALIZADAS

1 O sistema envia a mensagem:

Selecione o ms para ver o
relatrio. Voltar ao passo 3 do
fluxo timo.

32

FLUXO TIMO
CASO DE USO:
PR-REQUISITO:
OBJETIVO:

Logar no mobile
Manter Paciente

Validar cdigo do paciente para liberar acesso ao sistema.

AES RECEBIDAS

1 O paciente acessa o sistema atravs

de uma plataforma mobile.
3 O paciente digita o seu cdigo.

AES REALIZADAS

2 O sistema exibe o campo:

cdigo do paciente.
4 O sistema valida o cdigo do
paciente.
5 O sistema libera o acesso para o
paciente.

FLUXO ALTERNATIVO

Campo cdigo no foi preenchido.

AES RECEBIDAS

AES REALIZADAS

1 O sistema envia a mensagem:

Digite o seu cdigo para acessar o
sistema. Voltar ao passo 3 do fluxo
timo.

Cdigo incorreto.
AES RECEBIDAS

AES REALIZADAS
1 O sistema envia mensagem:
Cdigo incorreto. Favor digitar um
cdigo vlido. Voltar ao passo 3 do
fluxo timo.

33

FLUXO TIMO
CASO DE USO:
PR-REQUISITO:
OBJETIVO:

Consultar agenda mobile

Exibir consulta agendadas para o paciente.

AES RECEBIDAS

2 O paciente seleciona o ms desejado.

AES REALIZADAS

1 O sistema exibe o campo para

que seja selecionado o ms.
3 O sistema exibe as consultas
agendadas para o paciente no ms
selecionado.

FLUXO ALTERNATIVO

No h consultas agendadas.
AES RECEBIDAS

AES REALIZADAS

1 O sistema envia a mensagem:

No h agendamentos para este
paciente no ms selecionado.
Voltar ao passo 2 do fluxo timo.

34

8.2.. DIAGRAMA DE CLASSES

O diagrama de classes define a estrutura das classes utilizadas pelo sistema,

determinando os atributos e mtodos existentes
existent
em cada classe e como elas se
relacionam e trocam informaes.
informa
O diagrama de classes provavelmente o mais utilizado e um dos mais
importantes da UML. Serve de apoio para a maioria dos demais diagramas.
Como o prprio nome diz, define a estrutura das classes utilizadas pelo
sistema, determinando os atributos e mtodos que cada classe tem, alm
de estabelecer como as classes se relacionam e trocam informaes entre
si. (GUEDES, 2011, p. 31)

Figura 3 - Diagrama de classes do sistema Odontu's - Acesso Desktop

FONTE: Elaborada pelo autor

Figura 4 - Diagrama de classes do sistema Odontu's - Acesso Mobile

FONTE: Elaborada pelo autor

35

8.3. DIAGRAMA DE OBJETOS

O diagrama de objetos representa um retrato, em tempo de execuo, dos

objetos do software e seus relacionamentos.
O diagrama de objetos est amplamente associado ao diagrama de classes.
Na verdade, o diagrama de objetos praticamente um complemento do
diagrama de classes e bastante dependente deste. O diagrama
diagram fornece
uma viso dos valores armazenados pelos objetos de um diagrama de
classes em um determinado momento da execuo de um processo do
software. (GUEDES, 2011, p. 32)

Figura 5 - Diagrama
rama de objetos do sistema Odontu's
FONTE: Elaborada pelo autor

36

8.4. DIAGRAMA DE SEQUNCIA

O diagrama de sequncia representa uma perspectiva, orientada por tempo,

da colaborao entre os objetos.
O diagrama de sequncia um diagrama comportamental que preocupa-se
preocupa
com a ordem temporal
temporal em que as mensagens so trocadas entre os objetos
envolvidos em um determinado processo. Em geral, baseia-se
baseia
em um caso
de uso definido pelo diagrama de mesmo nome e apoia-se
apoia
no diagrama de
classes para determinar os objetos das classes envolvidas em
e um processo.
Um diagrama de sequncia costuma identificar o evento gerador do
processo modelado, bem como o ator responsvel por este evento, e
determina como o processo deve se desenrolar e ser concludo por meio da
chamada de mtodos disparados por mensagens
mensagens enviadas entre os objetos.
(GUEDES, 2011, p. 33)

Figura 6 - Diagrama de sequncia do sistema Odontu's - Processo Manter Paciente

FONTE: Elaborada pelo autor

37

Figura 7 - Diagrama de sequncia do sistema Odontu's - Processo Agendar Consulta

FONTE: Elaborada pelo autor

Figura 8 - Diagrama de sequncia do sistema Odontu's - Processo Atender Consulta

FONTE: Elaborada pelo autor

38

8.5. DIAGRAMA DE ATIVIDADES

O diagrama de atividades representa o fluxo de tarefas que podem ser

executadas pelo sistema ou por um ator.
O diagrama de atividade era considerado um caso especial do antigo
diagrama de grfico de estados, hoje conhecido como diagrama de mquina
de estados. A partir da UML 2.0, foi considerado independente do diagrama
de mquina de estados. O diagrama de atividade preocupa-se
preocupa
em
descrever os passos a serem percorridos para a concluso de uma
atividade especfica, podendo esta ser representada por um mtodo com
certo grau de complexidade,
complexidade, um algoritmo, ou mesmo
mes
um processo
completo. Concentra-se
Concentra se na representao do fluxo de controle de uma
atividade. (GUEDES, 2011, p. 36)

Figura 9 - Diagrama de atividade do sistema Odontu's - Processo Agendar Consulta

FONTE: Elaborada pelo autor
aut

39

Figura 10 - Diagrama de atividade do sistema Odontu's - Processo Atender Consulta

FONTE: Elaborada pelo autor

40

8.6. DIAGRAMA DE MQUINA DE ESTADOS

O diagrama de mquina de estados representa um conjunto de estados que

um objeto pode estar e os eventos que estimulam a transio do objeto de um
estado para outro.
O diagrama de mquina de estados demonstra o comportamento de um
elemento por meio de um conjunto finito de transies de estado, ou seja,
uma mquina de estados. Alm de poder ser utilizado para expressar o
comportamento de uma parte do sistema, quando chamado de mquina
de estado comportamental, tambm pode ser usado para expressar o
protocolo de uso de parte de um sistema, quando identifica uma mquina de
estado de protocolo. (GUEDES, 2011, p. 35)

Figura 11 - Diagrama de mquina de estados do sistema Odontu's - Processo Login Vlido

FONTE: Elaborada pelo autor

Figura 12 - Diagrama de mquina de estados do sistema Odontu's - Processo Login Expirado

FONTE: Elaborada pelo autor

41

8.7. DIAGRAMA DE COMPONENTES

O diagrama de componentes representa uma coleo de componentes de

software e seus relacionamentos.
O diagrama de componentes est amplamente associado linguagem de
programao que ser
ser utilizada para desenvolver o sistema modelado. Esse
diagrama representa os componentes do sistema quando o mesmo for ser
implementado em termos de mdulos de cdigo-fonte,
cdigo
bibliotecas,
formulrios, arquivos de ajuda, mdulos executveis etc. e determina como
tais componentes estaro estruturados e iro interagir para que o sistema
funcione de maneira adequada. (GUEDES, 2011, p. 38)

Figura 13 - Diagrama de componentes do sistema Odontu's

FONTE: Elaborada pelo autor

42

8.8. DIAGRAMA DE IMPLANTAO

O diagrama de implantao representa uma coleo de itens e mostra como

esses so distribudos em um ou vrios ns de hardware.
O diagrama de implantao determina as necessidades de hardware do
sistema, as caractersticas
caractersticas fsicas como servidores, estaes, topologias e
protocolos de comunicao, ou seja, todo o aparato fsico sobre o qual o
sistema dever ser executado. Esse diagrama permite demonstrar tambm
como se dar a distribuio dos mdulos do sistema, em situaes
situae em que
estes forem ser executados em mais de um servidor. (GUEDES, 2011, p.
39)

Figura 14 - Diagrama de implantao do sistema Odontu's

FONTE: Elaborada pelo autor

43

9. IMPLEMENTAO
MPLEMENTAO DO SISTEMA ODONTUS

O sistema
ema Odontus, foi planejado com base nas necessidades do consultrio
da Dr. Ana Paula, embora, o sistema aqui projeto possa ser implementando em
qualquer outra empresa do mesmo ramo e porte do consultrio analisado, sem
qualquer modificao da estrutura do
d sistema.
A implementao do sistema no faz parte do escopo desse trabalho, o que
no impede sua futura implementao.
Cabe frisar que uma das partes cruciais do projeto foi executa aqui, com o
levanto e anlise de requisitos, elaborao dos diagramas do sistema com base nos
requisitos analisados,, essas tarefas tornaro a futura implementao do Odontus
uma tarefa menos complicada do que normalmente seria se a documentao no
estivesse concluda.
A seguir exibe-se
se um prottipo de um dos mdulos do sistema
siste
Odontus
implementado.

Figura 15 - Prottipo da implementao do mdulo de pagamentos do sistema Odontu's

FONTE: Elaborada pelo autor

44

CONSIDERAES FINAIS

Atualmente muito difcil para uma empresa, independente de seu porte,

manter-se atuante no mercado sem a ajuda da tecnologia. Os benefcios so tantos
que, a organizao que no conta com os benefcios da tecnologia existente, est e
sempre ficar atrs de seus concorrentes.
A implantao do sistema Odontus trar muitos benefcios para o consultrio
da Dr. Ana Paula, como por exemplo, maior eficincia para executar tarefas de
cadastros, consultas e gerao de relatrios; Maior segurana no armazenamento
dos dados usado pela empresa; Permite que os colaboradores do consultrio
foquem no que realmente interessa para o crescimento da empresa.
A utilizao da UML contribuiu bastante para o correto e gil desenvolvimento
da documentao do sistema, permitindo que esta seja clara para que qualquer
pessoa possa se situar ao consult-la.
Embora a construo do sistema no tenha sido efetuada, foi feito um estudo
de acessibilidade e ergonomia, para que pessoas que possuam algum tipo de
dificuldade possam utilizar o sistema normalmente sem que lhes cause desconforto.
Como trabalho futuro, possvel realizar a implementao do sistema e os
mdulos que foram projetados, podendo surgir novas funcionalidades a depender do
tempo da implementao.
Considera-se que todos os objetivos propostos foram alcanados de forma
correta, utilizando os conhecimentos da engenharia de software que permitiu
aprimorar o aprendizado com uma situao real.

45

REFERNCIAS BIBLIOGRFICAS

BOOCH, G., RUMBAUGH, J., & JACOBSON, I. UML - Guida do Usurio. 2

ed. Rio de Janeiro: Elsevier, 2005.
GUEDES, G. T. UML 2 - Uma Abordagem Prtica. 2 ed. So Paulo: Novatec,
2011.
PMI, P. M. Um Guia do Conhecimento em Gerenciamento de Projetos Guia Pmbok. So Paulo: Saraiva, 2012.

46

ANEXO A Roteiro da Entrevista

Perguntas feitas durante a entrevista para levantamento de requisitos:

Quem utilizar o sistema?

Como ser o cadastro dos pacientes?

Quais informaes so necessrias para o cadastro do paciente?

Quem far agendamento e/ou cancelamento de consultas?

Quais informaes so necessrias para agendar uma consulta?

Quais informaes so necessrias para agendar uma consulta para

oramento?

Em mdia, quantos agendamentos so realizados por dia?

Com que frequncia o sistema vai gerar relatrios dos pacientes atendidos?

Com que frequncia o sistema vai gerar relatrios dos pacientes que faltaram
consulta?

Como ser feito o registro de pagamento da consulta?

Como ser feita a atualizao de pronturio no sistema?

Por quem ser feita a atualizao de pronturio no sistema?

Quem ter acesso aos relatrios?

Hoje, caso a consulta seja marcada para um perodo maior que 20 dias,
vocs enviam sms para o paciente algumas horas antes da consulta. O
sistema dever ter uma opo que identifique os pacientes que precisam ser
alertados.