eds iii - p2.pdf

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

FACULDADE DE TECNOLOGIA DA ZONA SUL So Paulo

2013

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.

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 o 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 o paciente, o 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

RF01 RF02 RF03 RF04 RF05 RF06 RF07 RF08 UC01 X UC02 X UC03 X UC04 X UC05 X UC06 X UC07 X UC08 X UC09 X UC10 X UC11 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.

8.1. DIAGRAMA DE CASO

O diagrama de casoamplamente utilizado na fase de levantamento e identificar os atores, os servio

O diagrama de casoutilizado normalmente nas fases de levantamento e anlise de sistemamodelagem 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 sistemidentificar 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, conheci30)

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

Figura 1 -


DIAGRAMA DE CASOS DE USO

O diagrama de casos de uso o mais popular diagrama da UML. izado na fase de levantamento e anlise de requisitos

os servios e a interao entre estes. O diagrama de casos de uso o diagrama mais geral e informal da UML, utilizado normalmente nas fases de levantamento e anlise de sistema, embora venha a ser consultado durante todo o processo de 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 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 nesse diagrama como casos de uso.

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

- Diagrama de casos de uso do sistema Odontu's - Acesso DesktopFONTE: Elaborada pelo autor

20

de uso o mais popular diagrama da UML. de requisitos, procura

de uso o diagrama mais geral e informal da UML, utilizado normalmente nas fases de levantamento e anlise de requisitos do

, embora venha a ser consultado durante todo o processo de modelagem e possa servir de base para outros diagramas. Apresentam uma linguagem simples e de fcil compreenso para que os usurios

a 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

das nesse diagrama como casos de uso. (GUEDES, 2011, p.

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

Acesso Desktop

Figura 2

FONTE: Elaborada pelo autor - Diagrama de casos de uso do sistema Odontu's - Acesso Mobile


21

Acesso Mobile

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: Fazer login PR-REQUISITO: OBJETIVO: Validar usurio e senha para garantir acesso ao sistema.

AES RECEBIDAS AES REALIZADAS

2 O atendente digita usurio e senha. 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).


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: Manter Paciente PR-REQUISITO:

OBJETIVO: Cadastrar (incluir / alterar / consultar e excluir) dados de pacientes.

AES RECEBIDAS AES REALIZADAS 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.

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: Desativar Paciente PR-REQUISITO: Cadastrar Paciente

OBJETIVO: Desativa o cadastro do paciente e bloqueia a edio dos dados do paciente.

AES RECEBIDAS AES REALIZADAS 1 O atendente seleciona a opo desativar.

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: Carregar Paciente PR-REQUISITO: Cadastrar Paciente OBJETIVO: 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: Agendar Consulta PR-REQUISITO: Cadastrar Paciente OBJETIVO: Agendar data e horrio de consulta para pacientes.

AES RECEBIDAS AES REALIZADAS 1 O atendente seleciona a opo agendar consulta.

3 O atendente escolhe um dia e horrio.

2 O sistema exibe os dias e horrios disponveis.

4 O atendente seleciona o paciente. 6 O sistema muda o status do horrio agendado para ocupado.

5 O atendente confirma o agendamento da consulta.

7 O sistema armazena as informaes da consulta e envia a mensagem: Consulta agendada 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: Atender Consulta PR-REQUISITO: Agendar Consulta OBJETIVO: Atende consulta previamente agendada.

AES RECEBIDAS AES REALIZADAS 1 O atendente seleciona a consulta que ser atendida.

2 O sistema exibe dia, hora, nome e telefone do paciente.

3 O atendente confirma o atendimento da consulta.

4 O sistema grava o dia e horrio da consulta no pronturio do paciente.

5 O sistema altera o status da consulta para atendida. E envia a mensagem: Atendimento efetuado.

FLUXO TIMO CASO DE USO: Cancelar Consulta PR-REQUISITO: Agendar Consulta OBJETIVO: Cancela consulta previamente agendada.

AES RECEBIDAS AES REALIZADAS 1 O atendente seleciona a consulta que ser cancelada.

2 O sistema exibe dia, hora, nome e telefone do paciente.

3 O atendente confirma o cancelamento.

4 O sistema altera o status da consulta para disponvel. E envia a mensagem: Cancelamento efetuado.

29

FLUXO TIMO CASO DE USO: Atualizar Pronturio PR-REQUISITO: Atender Consulta

OBJETIVO: Registrar, no pronturio do paciente, descrio da consulta que foi atendida.


1 O atendente seleciona o paciente. 2 O sistema exibe nome, telefone e RG do paciente.

3 O atendente seleciona a opo atualizar pronturio.

4 O sistema exibe dia e hora da consulta que foi atendida.

5 O atendente descreve o que foi feito durante a consulta.

7 O sistema armazena a descrio da consulta e envia a mensagem: Atualizao efetuada.

6 O atendente confirma a atualizao do pronturio.

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: Registrar Pagamento PR-REQUISITO: Atender Consulta OBJETIVO: Registrar, no pronturio do paciente, dia, hora e valor pago.


1 O atendente seleciona o paciente.

3 O atendente seleciona a opo registrar pagamento.

2 O sistema exibe nome, telefone e RG do paciente.

5 O atendente informa o valor pago pela consulta.

4 O sistema exibe dia e hora da consulta que foi atendida.

6 O atendente confirma o pagamento.

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: Emitir Relatrio Mensal PR-REQUISITO: OBJETIVO: Exibe relatrio de atendimentos do ms selecionado.

AES RECEBIDAS AES REALIZADAS 1 O atendente seleciona a opo emitir relatrio.

2 O sistema habilita o campo ms.

3 O atendente seleciona o ms.

4 O sistema exibe todas as consultas atendidas no ms selecionado, nomes dos pacientes, dias e horrios dos atendimentos e 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: Logar no mobile PR-REQUISITO: Manter Paciente OBJETIVO: Validar cdigo do paciente para liberar acesso ao sistema.

AES RECEBIDAS AES REALIZADAS 1 O paciente acessa o sistema atravs de uma plataforma mobile.

2 O sistema exibe o campo: cdigo do paciente.

3 O paciente digita o seu cdigo.

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: Consultar agenda mobile PR-REQUISITO: OBJETIVO: Exibir consulta agendadas para o paciente.


2 O paciente seleciona o ms desejado. 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.

8.2. DIAGRAMA DE CLASSES

O diagrama de classes define a estrutura das classes utilizadas pelo sistema, determinando os atributos e mtodos existentrelacionam e trocam informa

O diagrama de classes provavelmente o mais utilizadoimportantes da UML. Serve de apoio para a maioria dos demais diagramas. Como o prprio nome diz, define a estrutura dassistema, 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

Figura



. DIAGRAMA DE CLASSES

O diagrama de classes define a estrutura das classes utilizadas pelo sistema, determinando os atributos e mtodos existentes em cada classerelacionam e trocam informaes.

O diagrama de classes provavelmente o mais utilizadoimportantes da UML. Serve de apoio para a maioria dos demais diagramas. Como o prprio nome diz, define a estrutura das sistema, determinando os atributos e mtodos que cada classe tem, alm de estabelecer como as classes se relacionam e trocam informaes entre

(GUEDES, 2011, p. 31)

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

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



34

O diagrama de classes define a estrutura das classes utilizadas pelo sistema, cada classe e como elas se

O diagrama de classes provavelmente o mais utilizado e um dos mais importantes da UML. Serve de apoio para a maioria dos demais diagramas.

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

Acesso Desktop

Acesso Mobile

8.3. DIAGRAMA DE OBJETOS

O diagrama de objetos representa um retrato, em tempo deobjetos 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 diagramuma viso dos valores armazenados pelos objetos de um diagrama de classes em um determinado momento da execuo de um processo do software.

8.3. DIAGRAMA DE OBJETOS

O diagrama de objetos representa um retrato, em tempo deobjetos 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 diagramuma 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 de objetos do sistema Odontu's


35

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

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 fornece uma viso dos valores armazenados pelos objetos de um diagrama de classes em um determinado momento da execuo de um processo do

rama de objetos do sistema Odontu's

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 preocupacom a ordem teenvolvidos em um determinado processo. Em geral, baseiade uso definido pelo diagrama de mesmo nome e apoiaclasses para determinar os objetos das classes envolvidas eUm 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 men(GUEDES, 2011, p. 33)

Figura 6 - Diagrama de sequncia do sistema Odontu's


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 preocupacom a ordem temporal em que as mensagens so trocadas entre os objetos envolvidos em um determinado processo. Em geral, baseiade uso definido pelo diagrama de mesmo nome e apoiaclasses para determinar os objetos das classes envolvidas eUm 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 enviadas entre os objetos.(GUEDES, 2011, p. 33)

Diagrama de sequncia do sistema Odontu's - Processo Manter PacienteFONTE: Elaborada pelo autor

36

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

O diagrama de sequncia um diagrama comportamental que preocupa-se mporal em que as mensagens so trocadas entre os objetos

envolvidos em um determinado processo. Em geral, baseia-se em um caso de uso definido pelo diagrama de mesmo nome e apoia-se no diagrama de classes para determinar os objetos das classes envolvidas em 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

sagens enviadas entre os objetos.

Processo Manter Paciente

Figura 7 - Diagrama de

Figura 8 - Diagrama de sequncia do sistema Odontu's



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

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



37

Processo Agendar Consulta

Processo Atender Consulta

8.5. DIAGRAMA DE ATIVIDADES

O diagrama de atividades representa o fluxo de tarefasexecutadas 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 de mquina de estados. O diagrama de atividade preocupadescrever os passos a serem percorridos para a concluso de uma atividade especfica, podendo esta ser representada por um mtodo com certo grau de complexidadecompleto. Concentraatividade.

Figura 9 - Diagrama de atividade do sistema Odontu's FONTE: Elaborada pelo aut

8.5. DIAGRAMA DE ATIVIDADES

O diagrama de atividades representa o fluxo de tarefasexecutadas 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 de mquina de estados. O diagrama de atividade preocupadescrever os passos a serem percorridos para a concluso de uma atividade especfica, podendo esta ser representada por um mtodo com certo grau de complexidade, um algoritmo, ou mescompleto. Concentra-se na representao do fluxo de controle de uma atividade. (GUEDES, 2011, p. 36)

Diagrama de atividade do sistema Odontu's - Processo Agendar


38

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

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 em descrever os passos a serem percorridos para a concluso de uma atividade especfica, podendo esta ser representada por um mtodo com

, um algoritmo, ou mesmo um processo se na representao do fluxo de controle de uma

Processo Agendar Consulta

Figura 10 - Diagrama de atividade do sistema Odontu's

FONTE: Elaborada pelo autorDiagrama de atividade do sistema Odontu's - Processo Atender Consulta


39

Processo Atender Consulta

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

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



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 serdiagrama representa os componentes do sistema quando o mesmo for ser implementado em termos de mdulos de cdigoformulrios, arquivos de ajuda, mdulos executveis etc. e determina tais componentes estaro estruturados e iro interagir para que o sistema funcione de maneira adequada.

Figura


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 utilizada para desenvolver o sistema modelado. Esse diagrama representa os componentes do sistema quando o mesmo for ser implementado em termos de mdulos de cdigoformulrios, arquivos de ajuda, mdulos executveis etc. e determina 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


41

O diagrama de componentes representa uma coleo de componentes de

O diagrama de componentes est amplamente associado linguagem de 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, bibliotecas, formulrios, arquivos de ajuda, mdulos executveis etc. e determina como tais componentes estaro estruturados e iro interagir para que o sistema

(GUEDES, 2011, p. 38)

Diagrama de componentes do sistema Odontu's

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 caractersticaprotocolos 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 situaeestes forem ser executados em mais de um servidor. 39)

Figura


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 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 situaeestes forem ser executados em mais de um servidor.

Figura 14 - Diagrama de implantao do sistema Odontu's


42

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

O diagrama de implantao determina as necessidades de hardware do s 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 em que estes forem ser executados em mais de um servidor. (GUEDES, 2011, p.

Diagrama de implantao do sistema Odontu's

9. IMPLEMENTAO DO SISTEMA ODONTUS

O sistema 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 d

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 dorequisitos 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 um prottipo de um dos mdulos do sisteimplementado.

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


MPLEMENTAO DO SISTEMA ODONTUS

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 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

, essas tarefas tornaro a futura implementao do Odontus uma tarefa menos complicada do que normalmente seria se a documentao no

se um prottipo de um dos mdulos do siste

Prottipo da implementao do mdulo de pagamentos do sistema Odontu's


43

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

A implementao do sistema no faz parte do escopo desse trabalho, o que

Cabe frisar que uma das partes cruciais do projeto foi executa aqui, com o sistema com base nos

, essas tarefas tornaro a futura implementao do Odontus uma tarefa menos complicada do que normalmente seria se a documentao no

se um prottipo de um dos mdulos do sistema Odontus

Prottipo da implementao do mdulo de pagamentos do sistema Odontu's

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.

eds iii - p2.pdf

Documents