Sistema de informação de apoio ao dermatologista pediátrico

UNIVERSIDADE FEDERAL DE SANTA CATARINA

CURSO DE CIÊNCIAS DA COMPUTAÇÃO

ROSANA MÜLLER

SISTEMA DE INFORMAÇÃO DE APOIO AO

DERMATOLOGISTA PEDIÁTRICO

FLORIANÓPOLIS – SC

2004

ROSANA MÜLLER

SISTEMA DE INFORMAÇÃO DE APOIO AO

DERMATOLOGISTA PEDIÁTRICO

Trabalho de Conclusão de Curso

apre-sentado como exigência para a

obten-ção do título de Bacharel em Ciências

da Computação à Universidade Federal

de Santa Catarina - UFSC, no curso de

Ciências da Computação.

Orientador:

LEANDRO J. KOMOSINSKI

FLORIANÓPOLIS – SC

2004

ROSANA MÜLLER

SISTEMA DE INFORMAÇÃO DE APOIO AO

DERMATOLOGISTA PEDIÁTRICO

Trabalho de Conclusão de Curso

apre-sentado como exigência para a

obten-ção do título de Bacharel em Ciências

da Computação à Universidade Federal

de Santa Catarina - UFSC, no curso de

Ciências da Computação.

Banca Examinadora

Prof. Dr. Leandro J. Komosinski __________________________________

Universidade Federal de Santa Catarina

Profª. Carmen Dolores de F. de Lacerda __________________________________

Universidade Federal de Santa Catarina

Prof Dr. Ronaldo dos Santos Mello __________________________________

Universidade Federal de Santa Catarina

DEDICATÓRIA

Dedico este

tra-balho aos meus pais, que

sempre torceram muito

por mim, me incentivando

a continuar e acreditando

que eu conseguiria.

AGRADECIMENTOS

A Deus, pela

força concedida para a

realização deste trabalho.

Aos meus pais,

por todo esforço feito para

que eu me tornasse a

pessoa que sou hoje e

pudesse chegar até aqui.

Ao meu

orien-tador, Leandro José

Ko-mosinski, pela atenção

dispensada.

A todos que de

uma forma ou outra

con-tribuíram para a

conclu-são deste trabalho.

SUMÁRIO

1 INTRODUÇÃO ...14

1.1 Contexto...14

1.2 Motivação...15

1.3 Objetivo Geral...15

1.4 Objetivos Específicos ...16

1.5 Estrutura do Trabalho ...16

2 METODOLOGIA E FERRAMENTAS ...18

2.1 A Linguagem Java...18

2.2 A notação UML ...19

2.2.1 Caso de Uso...20

2.2.2 Diagrama de Casos de Uso ...21

2.2.3 Diagrama de Classes (Diagramas de Estrutura Estática) ...21

2.2.4 Diagrama de Interação ...21

2.2.4.1 Diagrama de Seqüência ...22

2.2.4.2 Diagrama de Colaboração...22

2.3 A Metodologia RUP ...22

2.3.1 Conceituação Inicial ...23

2.3.2 Características ...23

2.3.3 A Estrutura do Processo...24

2.3.3.1 Estrutura Dinâmica ...25

2.3.3.2 Estrutura Estática ...26

2.3.3.2.1 Workflow de Modelagem de Negócios ...27

2.3.3.2.2 Workflow de Requisitos ...27

2.3.3.2.3 Workflow de Análise e Projeto...28

2.3.3.2.4 Workflow de Implementação ...28

2.3.3.2.5 Workflow de Teste...28

2.3.3.2.6 Workflow de Implantação ...29

2.4 Padrões de Projeto...29

2.4.1 Especialista (Expert)...30

2.4.2 Criador (Creator) ...30

2.4.3 Controlador (Controller)...31

2.4.4 Fabricação Pura (Pure Fabrication) ...31

2.4.5 Singleton ...32

2.4.6 Fachada (Facade) ...32

2.5 Ambiente de Desenvolvimento ...32

2.5.1 Kawa ...33

2.5.2 Together ...33

2.6 O banco de dados MySQL ...33

3.1 Visão Geral...34

3.2 Vantagens ...35

4 DESENVOLVIMENTO DO SISTEMA ...36

4.1 Primeiro Ciclo de Desenvolvimento ...36

4.1.1 Levantamento de Requisitos ...36

4.1.1.1 Diagrama de Casos de Uso ...38

4.1.1.2 Casos de Uso Expandidos ...39

4.1.1.2.1 Caso de Uso “CadastrarPaciente”...39

4.1.1.2.2 Caso de Uso “AbrirFichaPaciente” ...40

4.1.1.2.3 Caso de Uso “DescreverConsultaInicial”...41

4.1.1.2.4 Caso de Uso “DescreverRetorno” ...42

4.1.1.2.5 Caso de Uso “PesquisarConsultaPaciente” ...44

4.1.2 Análise Orientada a Objetos...44

4.1.2.1 Diagrama de Classes Conceituais ...45

4.1.3 Projeto Orientado a Objetos ...46

4.1.3.1 Diagramas de Seqüência ...46

4.1.3.1.1 Diagrama “CadastrarPaciente” ...47

4.1.3.1.2 Diagrama “AbrirFichaPaciente” ...47

4.1.3.1.3 Diagrama “DescreverConsultaInicial” ...48

4.1.3.1.4 Diagrama “DescreverRetorno” ...48

4.1.3.1.5 Diagrama “PesquisarConsultaPaciente”...49

4.1.3.2 Diagrama de Classes de Projeto ...50

4.1.3.3 Modelo de Dados ...52

4.1.3.4 Interface ...53

4.1.4 Implementação e Testes ...57

4.2 Segundo Ciclo de Desenvolvimento...59

4.2.1 Levantamento de Requisitos ...59

4.2.1.1 Diagrama de Casos de Uso ...59

4.2.1.2 Casos de Uso Expandidos ...59

4.2.1.2.1 Caso de Uso “EscreverReceita” ...60

4.2.1.2.2 Caso de Uso “VisualizarReceita”...61

4.2.1.2.3 Caso de Uso “EscreverAtestado” ...62

4.2.1.2.4 Caso de Uso “VisualizarAtestado”...63

4.2.1.2.5 Caso de Uso “PesquisarModeloAtestado”...64

4.2.2 Análise Orientada a Objetos...65

4.2.2.1 Diagrama de Classes Conceituais ...65

4.2.3 Projeto Orientado a Objetos ...66

4.2.3.1 Diagramas de Seqüência ...66

4.2.3.1.1 Diagrama “EscreverReceita” ...66

4.2.3.1.2 Diagrama “VisualizarReceita” ...67

4.2.3.1.3 Diagrama “EscreverAtestado” ...68

4.2.3.1.4 Diagrama “VisualizarAtestado” ...69

4.2.3.1.5 Diagrama “PesquisarModeloAtestado”...70

4.2.3.2 Diagrama de Classes de Projeto ...71

4.2.3.3 Modelo de Dados ...72

4.2.3.4 Interface ...73

4.2.4 Implementação e Testes ...77

4.3.1 Levantamento de Requisitos ...79

4.3.1.1 Diagrama de Casos de Uso ...79

4.3.1.2 Casos de Uso Expandidos ...79

4.3.1.2.1 Caso de Uso “PesquisarPlano” ...80

4.3.1.2.2 Caso de Uso “PesquisarFormula” ...80

4.3.1.2.3 Caso de Uso “PesquisarProcedimento” ...81

4.3.2 Análise Orientada a Objetos...82

4.3.2.1 Diagrama de Classes Conceituais ...82

4.3.3 Projeto Orientado a Objetos ...83

4.3.3.1 Diagramas de Seqüência ...83

4.3.3.1.1 Diagrama “PesquisarPlano” ...83

4.3.3.1.2 Diagrama “PesquisarFormula” ...84

4.3.3.1.3 Diagrama “PesquisarProcedimento”...84

4.3.3.2 Diagrama de Classes de Projeto ...85

4.3.3.3 Modelo de Dados ...86

4.3.3.4 Interface ...86

4.3.4 Implementação e Testes ...89

4.4 Quarto Ciclo de Desenvolvimento ...90

4.4.1 Levantamento de Requisitos ...90

4.4.1.1 Diagrama de Casos de Uso ...90

4.4.1.2 Casos de Uso Expandidos ...90

4.4.1.2.1 Caso de Uso “PesquisarCID” ...91

4.4.1.2.2 Caso de Uso “VisualizarHistorico” ...92

4.4.1.2.3 Caso de Uso “GerarRelatorioFinanceiro” ...92

4.4.2 Análise Orientada a Objetos...93

4.4.2.1 Diagrama de Classes Conceituais ...93

4.4.3 Projeto Orientado a Objetos ...95

4.4.3.1 Diagramas de Seqüência ...95

4.4.3.1.1 Diagrama “PesquisarCID” ...95

4.4.3.1.2 Diagrama “VisualizarHistorico” ...96

4.4.3.1.3 Diagrama “GerarRelatorioFinanceiro” ...96

4.4.3.2 Diagrama de Classes de Projeto ...97

4.4.3.3 Modelo de Dados ...98

4.4.3.4 Interface ...99

4.4.4 Implementação e Testes ...101

5 CONSIDERAÇÕES FINAIS ...103

5.1 Dificuldades e Facilidades Encontradas ...103

5.2 Trabalhos Futuros ...103

5.3 Conclusão Final...104

REFERÊNCIAS BIBLIOGRÁFICAS ...105

BIBLIOGRAFIA ...106

Anexo 01 – Script de geração do banco de dados ...107

Anexo 02 – Código Fonte ...110

LISTA DE ILUSTRAÇÕES

Figura 1

- Arquitetura completa do Processo Unificado Rational ...25

Figura 2

- Diagrama de casos de uso – Ciclo 1...38

Figura 3

- Diagrama de classes conceituais – Ciclo 1 ...45

Figura 4

- Diagrama de seqüência “CadastrarPaciente” ...47

Figura 5

- Diagrama de seqüência “AbrirFichaPaciente” ...47

Figura 6

- Diagrama de seqüência “DescreverConsultaInicial”...48

Figura 7

- Diagrama de seqüência “DescreverRetorno” ...49

Figura 8

- Diagrama de seqüência “PesquisarConsultaPaciente” ...50

Figura 9

- Diagrama de classes de projeto – Ciclo 1 ...51

Figura 10 - Modelo de dados – Ciclo 1 ...52

Figura 11 - Diagrama de classes - Interface – Ciclo 1 ...53

Figura 12 - Interface Principal...54

Figura 13 - Tela “FrameFicha”...54

Figura 14 - Tela “FrameAbrirFicha” ...55

Figura 15 - Tela “FrameConsultaInicial” ...56

Figura 16 - Tela “FrameRetorno”...56

Figura 17 - Tela “FrameAbrirConsulta” ...57

Figura 18 - Diagrama de classes conceituais – Ciclo 2 ...65

Figura 19 - Diagrama de seqüência “EscreverReceita” ...67

Figura 20 - Diagrama de seqüência “VisualizarReceita” ...68

Figura 21 - Diagrama de seqüência “EscreverAtestado” ...69

Figura 22 - Diagrama de seqüência “VisualizarAtestado” ...70

Figura 23 - Diagrama de seqüência “PesquisarModeloAtestado” ...70

Figura 24 - Diagrama de classes de projeto – Ciclo 2 ...71

Figura 25 - Modelo de dados – Ciclo 2 ...72

Figura 26 - Diagrama de classes - Interface – Ciclo 2 ...73

Figura 27 - Tela “FrameNovaReceita” ...74

Figura 28 - Tela “FrameReceitas”...74

Figura 29 - Tela “FrameNovoAtestado” ...75

Figura 30 - Tela “FrameAtestado” ...75

Figura 31 - Tela “FrameAtestados”...76

Figura 32 - Tela “FrameAtestadosSistema”...77

Figura 33 - Diagrama de seqüência “PesquisarPlano” ...83

Figura 34 - Diagrama de seqüência “PesquisarFormula” ...84

Figura 35 - Diagrama de seqüência “PesquisarProcedimento” ...84

Figura 36 - Diagrama de classes de projeto – Ciclo 3 ...85

Figura 37 - Diagrama de classes - Interface – Ciclo 3 ...86

Figura 38 - Tela “FramePlanos”...87

Figura 39 - Tela “FrameFormulas”...88

Figura 40 - Tela “FrameProcedimentos”...88

Figura 41 - Diagrama de classes conceituais – Ciclo 4 ...94

Figura 42 - Diagrama de seqüência “PesquisarCID” ...95

Figura 43 - Diagrama de seqüência “VisualizarHistorico”...96

Figura 44 - Diagrama de seqüência “GerarRelatorioFinanceiro” ...96

Figura 46 - Modelo de dados – Ciclo 4 ...98

Figura 47 - Diagrama de classes - Interface – Ciclo 4 ...99

Figura 48 - Tela “FrameCID” ...100

Figura 49 - Tela “FrameHistorico”...100

AON

Antecedentes Obstétricos Neonatais

CID

Código Internacional de Doenças

IDE Integrated

Development

Environment (Ambiente Integrado de

De-senvolvimento)

JVM

Java Virtual Machine (Máquina Virtual Java)

OMG

Object Management Group (Grupo de Gerenciamento de Objetos)

OMT

Object Modeling Technique (Técnica de Modelagem de Dados)

OOSE

Object Oriented Software Engineering (Engenharia de Software

Orientada a Objetos)

RUP

Rational Unified Process (Processo Unificado Rational)

RESUMO

Este trabalho descreve o desenvolvimento de uma aplicação utilizando o

processo de desenvolvimento de software Rational Unified Process, a linguagem de

programação Java e o Sistema de Gerenciamento de Banco de Dados MySQL.

O software desenvolvido é uma aplicação para o gerenciamento de

infor-mações médicas, mais especificamente da área de dermatologia pediátrica. A

apli-cação permite o acompanhamento, pelo médico, da evolução de seus pacientes, a

geração de relatório financeiro, o acesso ao Código Internacional de Doenças, entre

outros.

ABSTRACT

This work describes the development of an application which uses the

Rational Unified Process, the Java programming language and the MySQL Database

Management System.

The developed software is an application that manages medical

information, more specifically in the area of pediatrics dermatology. The application

allows the doctor to watch the patients’ progress, the generation of a financial report,

the access to the International Code of Diseases among others.

Key-words: Rational Unified Process, Unified Modeling Language

1 INTRODUÇÃO

1.1 Contexto

Desde os primórdios da humanidade e surgimento dos estudos médicos

ha-via-se necessidade de registrar dados importantes em relação aos pacientes, doenças e

evolução dos mesmos.

O “médico de família”, aquele que comparecia ao leito do paciente, já era

co-nhecido na comunidade, fazia parte do contexto social e ele próprio conhecia os

familia-res e o paciente. Com o passar dos anos a população cfamilia-resceu, o médico já não fazia

mais este tipo de atendimento, e sim, o paciente que vinha ao encontro dele (consultório,

clínica, hospital). Esse aumento da densidade demográfica, novos métodos e

tecnologi-as médictecnologi-as fizeram com que esses registros tivessem que ser armazenados de forma a

facilitar o acesso às informações sobre os dados dos pacientes.

A informática veio para facilitar o dia a dia do médico, registrando os dados

cadastrais, de história clínica, doença, de tratamento, evolução e também controle de

consultas, agilidade no atendimento, controle financeiro, etc.

Contudo, é bom salientar que a informática veio para complementar, nunca

substituir, a relação médico-paciente, que é imprescindível no exercício da prática

médi-ca.

1.2 Motivação

“O avanço da tecnologia da informação e seu uso na área médica têm

influen-ciado, cada vez mais, a qualidade da assistência médica, aumentando, assim a

necessi-dade de software médico de alta qualinecessi-dade” (ROCHA).

Como a maioria dos sistemas de informação médicos não é específica o

sufi-ciente para um determinado profissional, viu-se a necessidade de desenvolver um

pro-grama que gerencie informações específicas para um profissional especializado na área

de dermatologia pediátrica (subespecialidade da pediatria).

1.3 Objetivo Geral

O objetivo deste trabalho é desenvolver um software que gerencie

informa-ções médicas utilizando, para isto, uma metodologia de desenvolvimento.

Segundo Rocha, “ao se desenvolver um produto de software, o objetivo não é

atingir a qualidade perfeita, mas sim a qualidade necessária e suficiente para cada

con-texto de uso especificado”. Sendo assim, o objetivo principal deste trabalho é dar

assis-tência ao profissional médico especializado em dermatologia pediátrica.

1.4 Objetivos Específicos

Os objetivos específicos do presente trabalho (software médico) são os

se-guintes:

(a) Respeitar a individualidade do profissional médico: dependendo de cada

especialidade e até mesmo dentro da mesma especialidade, considerando

as divergências no registro de informações sobre dados clínicos do

pacien-te, modelos de receitas, fórmulas, atestados, etc.

(b) Disponibilizar dados clínicos a qualquer tempo: possibilidade de revisar o

histórico integral do paciente antes mesmo de ele entrar em sua sala.

(c) Facilitar o aprendizado e o uso do software.

(d) Prover controle financeiro: é muito difícil e pouco seguro ter-se o controle

efetivo sobre contas a receber de convênios (diversos) feitos

manualmen-te. Com isso viu-se a necessidade de automatizar esta tarefa,

possibilitan-do o controle eficaz da contabilidade possibilitan-do médico.

1.5 Estrutura do Trabalho

O capítulo 1 contextualiza o trabalho, apresentando os objetivos e motivações

do seu desenvolvimento.

No capítulo 2 é feita uma conceituação inicial do Processo Unificado Rational,

da notação UML, de padrões de projeto e da linguagem de programação Java, além de

uma breve descrição sobre o banco de dados (MySQL) e os ambientes de

desenvolvi-mento (Kawa e Together) utilizados.

O capítulo 3 apresenta uma visão geral do sistema desenvolvido e comenta

suas vantagens.

O capítulo 4 descreve todos os passos do desenvolvimento do sistema,

pas-sando por cada uma das etapas dos quatro ciclos de desenvolvimento.

No capítulo 5 são descritas as dificuldades e facilidades encontradas durante

o desenvolvimento, algumas sugestões para trabalhos futuros e a conclusão final do

tra-balho.

2 METODOLOGIA E FERRAMENTAS

2.1 A Linguagem Java

Java é uma linguagem de programação de alto nível desenvolvida pela Sun

Microsystems, baseada em outras duas linguagens, C e C++, e disponibilizada

gratuita-mente a partir de 1995. É uma linguagem orientada a objetos, ou seja, apresenta

concei-tos como herança, polimorfismo, reuso e hierarquia, e possui forte suporte para técnicas

de engenharia de software. Segundo Deitel (2003), “Java se tornou a linguagem

preferi-da para atender às necessipreferi-dades de programação de uma organização”.

Um programa em Java é composto de classes e seus métodos. As classes

podem ser desenvolvidas pelo próprio programador para o seu programa em específico,

ou podem ser utilizadas das diversas bibliotecas de classes já existentes. Estas

bibliote-cas são uma das grandes facilidades de Java, pois muitas das classes que o

programa-dor irá utilizar em seu desenvolvimento já estão prontas e disponibilizadas gratuitamente

na Internet.

Quando comparado com outras linguagens de programação, o Java

apresen-ta diversas vanapresen-tagens e facilidades, como coleapresen-ta automática de lixo (garbage collection)

e recursos para produzir interfaces gráficas, aplicações para redes e processamento

dis-tribuído. Porém, uma das principais características desta linguagem é a independência

de plataforma, ou seja, um programa escrito em Java é compilado em um código

inde-pendente de arquitetura (bytecode Java), que pode ser executado em qualquer

platafor-ma que suporte um interpretador Java, sem que o prograplatafor-ma precise ser reescrito ou

re-compilado. Além destas características, Java é multitarefa, dinâmico, robusto, seguro e

simples.

A tecnologia Java fornece diversas ferramentas, como, um compilador, um

in-terpretador e um gerador de documentação. O núcleo da plataforma Java é a Máquina

Virtual Java (JVM), que executa os bytecodes.

2.2 A notação UML

De acordo com a especificação da Linguagem de Modelagem Unificada

(U-ML), esta “é uma linguagem para especificar, visualizar e documentar os artefatos de

sistemas de software e representa uma coleção das melhores práticas de engenharia

que tem tido sucesso na modelagem de sistemas grandes e complexos”.

A UML surgiu da necessidade de uma notação padrão para os diversos

pro-cessos de desenvolvimento de software e seu principal objetivo é descrever sistemas

através de diagramas orientados a objetos. Foi desenvolvida em meados da década de

90, por Grady Booch, James Rumbaugh e Ivar Jacobson da Rational Software

Corpora-tion e liberada, em versões preliminares, em 1996. Em 1997, o Object Management

Group

TM

(OMG

TM

) assumiu a responsabilidade sobre a UML. Cada um dos três

Booch), OMT (de James Rumbaugh) e OOSE (de Ivar Jacobson). UML é a junção do

que havia de melhor em cada uma destas três metodologias.

“UML é uma linguagem para modelagem; ela não guia um desenvolvedor em

como fazer análise e projeto orientado a objetos, ou qual o processo de desenvolvimento

a ser seguido” (LARMAN, 2000).

Algumas das características da UML são flexibilidade, extensibilidade e

inde-pendência de processos. A flexibilidade da UML permite a definição de diversos

mode-los, que podem ser estáticos ou dinâmicos, de análise ou de projeto. Os modelos são

compostos de diagramas e documentos descritivos (artefatos).

“A Unified Modeling Language é agora o esquema de representação gráfica

mais amplamente utilizado para modelagem de sistemas orientados a objetos” (DEITEL,

2003).

Abaixo estão descritos alguns dos artefatos especificados pela UML.

2.2.1 Caso de Uso

Um caso de uso é um texto que descreve uma determinada funcionalidade do

sistema, através de mensagens trocadas entre o ator (agente externo que interage com

o sistema) e o sistema e ações executadas pelo ator ou pelo sistema.

2.2.2 Diagrama de Casos de Uso

Um diagrama de casos de uso mostra os relacionamentos entre os atores e

os casos de uso do sistema.

2.2.3 Diagrama de Classes (Diagramas de Estrutura Estática)

O diagrama de classes representa a estrutura estática do sistema. Neste

dia-grama são representadas as classes com suas operações, atributos e relacionamentos,

que podem ser associação ou generalização.

2.2.4 Diagrama de Interação

Diagramas de interação mostram as interações dinâmicas entre os objetos (e

classes) do sistema. Há dois tipos de diagramas de interação: o diagrama de seqüência

e o diagrama de colaboração. Estes mostram a mesma informação, porém, enfatizam

aspectos diferentes.

2.2.4.1 Diagrama de Seqüência

Através deste diagrama percebe-se a seqüência de mensagens trocadas

en-tre os objetos. No eixo horizontal do diagrama de seqüência estão os objetos envolvidos

em uma determinada atividade, e no eixo vertical é representado o tempo.

2.2.4.2 Diagrama de Colaboração

Um diagrama de colaboração apresenta, essencialmente, a mesma

informa-ção de um diagrama de seqüência, porém, de outra forma. Neste diagrama, percebe-se,

além da troca de mensagem entre os objetos, os seus relacionamentos. Ao contrário do

diagrama de seqüência, o diagrama de colaboração não apresenta o tempo como uma

dimensão separada.

2.3.1 Conceituação Inicial

Rational Unified Process (RUP) é um processo de desenvolvimento de

softwa-re desenvolvido e mantido pela Rational Softwasoftwa-re. Em outras palavras, é um conjunto de

passos a serem seguidos para se chegar ao objetivo final, que é um software de alta

qualidade desenvolvido no tempo previsto, atendendo as necessidades do usuário final.

Ele não descreve somente as atividades a serem exercidas por cada membro da equipe

de projeto, mas também os produtos a serem gerados em cada atividade.

2.3.2 Características

O RUP é dirigido por casos de uso, é centrado na arquitetura, é iterativo e

in-cremental. Devido à complexidade dos sistemas de hoje, não é possível

seqüencialmen-te definir o problema inseqüencialmen-teiro, projetar a solução inseqüencialmen-teira, implementar o software e então

testar o produto no final. No RUP cada iteração termina com o lançamento de um

execu-tável. Sua abordagem iterativa tem a capacidade de atacar os maiores riscos desde o

início do desenvolvimento.

Além da iteratividade, o RUP possui outras características que auxiliam a

e-quipe durante o desenvolvimento de um software, como a modelagem visual, a avaliação

da qualidade, o controle de mudanças, o desenvolvimento baseado em componentes e a

gerência de requisitos, que é uma tarefa a ser executada durante todo o ciclo de vida do

desenvolvimento de um software, pois os requisitos mudam continuamente. Estas

carac-terísticas são definidas por Kruchten (2000) como algumas das melhores práticas no

de-senvolvimento de software moderno.

2.3.3 A Estrutura do Processo

O RUP pode ser descrito em duas dimensões, uma representa o tempo (eixo

horizontal) que é a parte dinâmica (ciclos, iterações, fases, etc) e a outra o contexto (eixo

vertical) que representa o aspecto estático (trabalhadores, atividades, artefatos e

work-flows) do processo.

A estrutura do RUP está mostrada na figura abaixo, retirada de Kruchten

(2000):

Figura 1 - Arquitetura completa do Processo Unificado Rational

2.3.3.1 Estrutura Dinâmica

A estrutura dinâmica do RUP é definida pela organização do processo ao

lon-go do tempo. O ciclo de vida do software é quebrado em ciclos e cada ciclo trabalha em

uma nova geração do produto.

2.3.3.2 Estrutura Estática

A estrutura estática deste processo define quatro elementos básicos de

mode-lagem: os trabalhadores, as atividades, os artefatos e os workflows.

O trabalhador define a responsabilidade de um membro da equipe de

desen-volvimento. Este executa certas atividades, que têm como entrada e saída artefatos. Um

artefato é algo tangível que foi produzido ou usado durante o desenvolvimento.

No RUP há nove workflows principais, que descrevem as seqüências de

ativi-dades necessárias para produzir um resultado de valor considerável, mostrando as

itera-ções entre os trabalhadores. São divididos em seis workfows “de engenharia” e três “de

suporte”, que são opcionais. Os workflows de engenharia são: de modelagem de

negó-cios, de requisitos, de análise e projeto, de implementação, de teste e de implantação. E

os workflows de suporte são: de gerência de projeto, de gerência de configuração e

mu-danças e de ambiente.

Em um processo iterativo, como o RUP, estes workflows são revisitados

vá-rias vezes durante o ciclo de vida do projeto.

Abaixo se encontra uma breve descrição de cada um dos seis workflows de

engenharia.

2.3.3.2.1 Workflow de Modelagem de Negócios

Segundo Kruchten (2000), “este workflow é recomendado apenas quando há

pessoas diretamente envolvidas no uso do sistema e mais informação a ser manipulada

pelo sistema”.

2.3.3.2.2 Workflow de Requisitos

Um requisito é uma capacidade que o sistema deve possuir ao final de seu

desenvolvimento. Estes podem ser funcionais ou não-funcionais.

O workflow de requisitos tem por objetivo analisar o problema e determinar o

que o sistema deve fazer, para que haja um entendimento entre desenvolvedores e

cli-entes.

2.3.3.2.3 Workflow de Análise e Projeto

Durante a execução deste workflow, os requisitos são traduzidos para uma

especificação que descreve como o sistema deve ser implementado sem ambigüidades,

garantindo que tanto os requisitos funcionais como os não funcionais sejam tratados.

2.3.3.2.4 Workflow de Implementação

Aqui ocorre a implementação do sistema propriamente dito (organização em

subsistemas, implementação das classes, etc). O teste de unidade também é feito

du-rante este workflow.

2.3.3.2.5 Workflow de Teste

Este workflow avalia a qualidade do produto durante todo o seu

desenvolvi-mento.

2.3.3.2.6 Workflow de Implantação

Aqui o software é implantado em seu ambiente final. Inclui instalação do

soft-ware, treinamento dos usuários, etc.

2.4 Padrões de Projeto

Um padrão de projeto é uma solução pronta para um determinado problema

que ocorre com freqüência durante o projeto de um sistema. Ele é composto da

descri-ção do problema, da descridescri-ção da soludescri-ção e de um nome, que deve ser sugestivo.

Durante o projeto orientado a objetos são feitas as atribuições de

responsabi-lidades aos objetos, normalmente durante a criação dos diagramas de interação. A

esco-lha durante a atribuição de responsabilidade a um objeto pode influenciar muito na

quali-dade do projeto. Por isso, existem os padrões, que ajudam o projetista a fazer a escolha

mais adequada.

Abaixo estão descritos seis dos diversos padrões existentes (retirados de

Larman, 2000).

2.4.1 Especialista (Expert)

Problema: A quem deve ser atribuída uma determinada responsabilidade?

Solução: Ao especialista da informação, ou seja, aquele que tem todas as

in-formações necessárias para cumprir a responsabilidade.

2.4.2 Criador (Creator)

Problema: A quem deve ser atribuída a responsabilidade de criar uma nova

instância de uma classe?

Solução: Deve-se atribuir a responsabilidade de criar uma instância da classe

A à classe B se ocorrer uma das seguintes alternativas:

a) B agrega instâncias de A

b) B contém instâncias de A

c) B registra instâncias de A

d) B usa instâncias de A

e) B tem os dados de inicialização que serão passados para uma instância de

A quando esta for criada

2.4.3 Controlador (Controller)

Problema: Quem deve ser o responsável pelo tratamento de um evento de

en-trada do sistema?

Solução: O responsável pelo tratamento de um evento de entrada do sistema

deve ser uma classe que represente uma das seguintes alternativas:

a)Representa o “sistema” como um todo (controlador fachada)

b)Representa todo o negócio ou organização (controlador fachada)

c)Representa algo ativo no mundo real e executaria esta tarefa (controlador

do papel)

d)Representa um tratador artificial dos eventos do sistema de um caso de uso

(controlador de caso de uso)

2.4.4 Fabricação Pura (Pure Fabrication)

Problema: A quem deve ser atribuída uma responsabilidade quando deseja-se

manter a alta coesão e o baixo acoplamento e não se encontra alternativa?

Solução: Deve-se criar uma classe artificial, que não representa um conceito

no domínio do problema, e atribuir a ela um conjunto de responsabilidades altamente

coeso que mantenha o baixo acoplamento.

2.4.5 Singleton

Problema: Deseja-se garantir que exista exatamente uma instância de uma

classe, e esta deve possuir um ponto global e único de acesso.

Solução: Deve-se definir um método de classe que retorna o singleton.

2.4.6 Fachada (Facade)

Problema: Precisa-se de uma interface unificada para um conjunto de

interfa-ces em um subsistema.

Solução: Defina uma interface de nível mais alto responsável pela

colabora-ção com o subsistema.

2.5 Ambiente de Desenvolvimento

Para o desenvolvimento do sistema foram utilizados basicamente dois

ambi-entes de desenvolvimento, o Kawa Professional 5.0 e o Together 6.0.1, descritos abaixo.

2.5.1 Kawa

O Kawa é um ambiente integrado de desenvolvimento (IDE) Java da Allaire

que é usado para desenvolver aplicações Java. É um ambiente simples e fácil de usar.

2.5.2 Together

O Together é um ambiente para modelagem e desenvolvimento de aplicações

orientadas a objetos com suporte a UML.

2.6 O banco de dados MySQL

O MySQL é um banco de dados desenvolvido e distribuído pela MySQL AB.

Além de ser rápido, confiável e fácil de usar, tem a vantagem de ser código aberto.

3 O SISTEMA

3.1 Visão Geral

O software desenvolvido busca suprir as dificuldades de se registrar todos os

dados referentes aos pacientes, controle financeiro e funcionalidades das atividades

mé-dicas.

Ele será utilizado por um profissional especialista em problemas de pele na

in-fância (subespecialidade da pediatria).

Com o software o médico poderá acompanhar a evolução de seus pacientes,

cadastrando os dados iniciais dos mesmos e descrevendo suas consultas. Durante uma

consulta o médico poderá elaborar receitas e atestados para o paciente. O médico terá

acesso ao Código Internacional de Doenças (CID), à tabela de fórmulas e à tabela de

procedimentos. Além disso, o software permitirá ao médico ter um controle financeiro,

podendo gerar relatórios e cadastrar os planos de saúde com os quais trabalha.

3.2 Vantagens

A vantagem principal deste sistema é a especificidade, pois é direcionado a

uma subespecialidade pediátrica (dermatologia pediátrica), que possui particularidades

que devem ser consideradas.

4 DESENVOLVIMENTO DO SISTEMA

O desenvolvimento do sistema baseou-se na metodologia de desenvolvimento

de software RUP, descrita na seção 2.3 deste trabalho. Como RUP é uma metodologia

bastante completa, podendo ser usada para sistemas de grande porte, não foram

utiliza-dos toutiliza-dos os seus recursos, apenas os necessários.

O sistema foi desenvolvido em diversos ciclos, ou seja, iterativamente. Cada

ciclo trata de determinados requisitos ou funcionalidades do sistema e é dividido em:

le-vantamento de requisitos, análise orientada a objetos, projeto orientado a objetos,

im-plementação e testes.

4.1 Primeiro Ciclo de Desenvolvimento

4.1.1 Levantamento de Requisitos

O primeiro passo para o desenvolvimento do sistema foi a definição dos

re-quisitos do sistema, ou seja, o que o sistema deve fazer, quais as funcionalidades

exigi-das pelos stakeholders.

Para o sistema em questão, sistema de informação de apoio ao

dermatologis-ta pediátrico, os sdermatologis-takeholders são o médico e o paciente, e foram definidas as seguintes

funcionalidades:

a) Cadastrar um paciente;

b) Abrir a ficha de um paciente;

c) Descrever uma consulta inicial;

d) Descrever um retorno;

e) Pesquisar uma consulta de um paciente;

f) Escrever uma receita para um paciente;

g) Visualizar uma receita de um paciente;

h) Escrever um atestado para um paciente;

i) Visualizar um atestado de um paciente;

j) Pesquisar, incluir, alterar ou excluir um modelo de atestado;

k) Pesquisar, incluir, alterar ou excluir uma fórmula;

l) Pesquisar, incluir, alterar ou excluir um procedimento;

m) Pesquisar, incluir, alterar ou excluir um plano de saúde;

n) Pesquisar Código Internacional de Doenças (incluir, alterar ou excluir uma

doença);

o) Visualizar o histórico de um paciente;

p) Gerar relatório financeiro.

É importante ressaltar que esta lista de funcionalidades não é algo estático,

podendo ser modificada ao longo de todo o desenvolvimento.

No RUP, um dos artefatos principais a ser desenvolvido durante o

levanta-mento de requisitos é o Modelo de Casos de Uso. Este modelo tem por objetivo

confir-mar que o sistema se tornará o que os clientes esperam e é constituído de casos de uso

e atores. Os casos de uso provêm das funcionalidades definidas acima, e os atores são

os stakeholders que interagem com o sistema, neste caso, o médico.

4.1.1.1 Diagrama de Casos de Uso

O diagrama de casos de uso é mostrado abaixo.

4.1.1.2 Casos de Uso Expandidos

A seguir, cada caso de uso é descrito em detalhes, com o objetivo de mostrar

a interação entre os atores e o sistema. Para este primeiro ciclo de desenvolvimento

fo-ram descritos apenas os cinco primeiros casos de uso definidos anteriormente, que

tra-tam de determinadas funcionalidades do sistema.

4.1.1.2.1 Caso de Uso “CadastrarPaciente”

Ator: médico.

Finalidade: cadastrar um novo paciente no sistema.

Visão Geral: o médico irá cadastrar um paciente no sistema.

Seqüência típica de eventos:

1. O sistema gera um número de registro (seqüencial) e mostra para o médico.

2. O sistema mostra a data para o médico.

3. O médico pergunta ao informante os dados do paciente.

4. O médico entra com os dados do paciente (nome, endereço, telefone(s), nome da

mãe, nome do pai, nome do informante, data de nascimento, cor (branco/ negro/

pardo/ amarelo), sexo (F/M), naturalidade, procedência).

6. O médico pergunta ao informante os antecedentes obstétricos neonatais (AON) do

paciente e entra com as informações no sistema.

7. O médico pergunta ao informante os antecedentes alimentares do paciente e entra

com a informação no sistema.

8. O médico pergunta ao informante se as vacinas do paciente estão em dia, se não

estiverem, pergunta qual(is) falta(m) e entra com as informações no sistema.

9. O médico pergunta ao informante o histórico de doenças do paciente e de sua

famí-lia, bem como seus hábitos e condições de vida e entra com as informações no

sis-tema.

10. O médico confirma o cadastro.

11. O sistema grava as informações.

Extensões:

11.a. O médico imprime a ficha do paciente.

4.1.1.2.2 Caso de Uso “AbrirFichaPaciente”

Ator: médico.

Finalidade: abrir a ficha de um paciente.

Visão Geral: o médico irá abrir a ficha de um paciente entrando com o nome no sistema.

Seqüência típica de eventos:

1. O médico entra com o nome do paciente (parcial ou completo).

2. O sistema retorna uma lista com os nomes dos pacientes que correspondem ao

no-me do paciente que o médico procura.

3. O médico seleciona o nome procurado.

4. O sistema retorna a ficha do paciente selecionado.

Extensões:

4.a. O médico imprime a ficha do paciente.

4.1.1.2.3 Caso de Uso “DescreverConsultaInicial”

Ator: médico.

Finalidade: descrever a consulta inicial de um paciente no sistema.

Visão Geral: o médico irá descrever a consulta inicial de um paciente.

Pré-condição: AbrirFichaPaciente ou CadastrarPaciente.

Seqüência típica de eventos:

1. O sistema mostra a data para o médico.

2. O médico entra com o plano do paciente.

3. O sistema mostra o valor da consulta.

4. O médico pergunta ao informante a queixa principal do paciente e entra com a

mes-ma no sistemes-ma.

5. O médico pergunta ao informante a história da doença atual (HDA) e entra com a

mesma no sistema.

6. O médico pergunta ao informante o uso de medicamentos e entra com a informação

no sistema.

7. O médico realiza o exame físico.

8. O médico entra com as informações do exame físico (tipo de pele (I, II, III, IV), couro

cabeludo, face/pescoço, tronco, dobras, genitais, membros, unhas, peso, estatura,

perímetro cefálico, dermatoscopia, testes).

9. O médico entra com a hipótese diagnóstica e com o tratamento.

10. O médico finaliza a consulta.

11. O sistema grava as informações.

Extensões:

3.a. O médico altera o valor da consulta (dá um desconto para o paciente).

9.a. O médico entra com o(s) procedimento(s), se houver(em).

4.1.1.2.4 Caso de Uso “DescreverRetorno”

Ator: médico.

Finalidade: descrever a o retorno de um paciente no sistema.

Visão Geral: o médico irá descrever o retorno de um paciente.

Pré-condição: AbrirFichaPaciente ou CadastrarPaciente.

Seqüência típica de eventos:

1. O sistema mostra a data para o médico.

2. O médico entra com o plano do paciente.

3. O sistema mostra o valor da consulta.

4. O médico pergunta ao informante as queixas atuais do paciente.

5. O médico entra com as queixas atuais (S – subjetivo).

6. O médico realiza o exame físico.

7. O médico entra com as informações do exame físico (O – objetivo).

8. O médico entra com o peso, a estatura e o perímetro cefálico do paciente.

9. O médico entra com a análise (A – análise).

10. O médico entra com o tratamento (P – plano).

11. O médico finaliza a consulta.

12. O sistema grava as informações.

Extensões:

3.a. O médico altera o valor da consulta.

4.1.1.2.5 Caso de Uso “PesquisarConsultaPaciente”

Ator: médico.

Finalidade: pesquisar uma consulta de um paciente.

Visão Geral: o médico irá pesquisar uma consulta de um paciente.

Pré-condição: AbrirFichaPaciente ou CadastrarPaciente.

Seqüência típica de eventos:

1. O médico solicita ao sistema as consultas do paciente.

2. O sistema retorna uma lista das consultas do paciente (mostrando a data da consulta

e algumas outras informações).

3. O médico seleciona a consulta que deseja visualizar.

4. O sistema retorna a consulta selecionada.

4.1.2 Análise Orientada a Objetos

“Na análise orientada a objetos deve-se descobrir os conceitos relacionados

ao domínio do problema” (LARMAN, 2000) e garantir que os requisitos definidos

anteri-ormente sejam tratados. Isto é feito analisando o modelo de casos de uso construído

durante o levantamento de requisitos e construindo um modelo conceitual, representado

aqui pelo diagrama de classes conceituais.

4.1.2.1 Diagrama de Classes Conceituais

As classes e os relacionamentos encontrados analisando-se os casos de uso

descritos anteriormente são mostrados no seguinte diagrama:

Figura 3 - Diagrama de classes conceituais – Ciclo 1

A análise omite a maioria dos detalhes de como o sistema opera, mostrando

apenas um esboço aproximado do sistema que será refinado no projeto.

4.1.3 Projeto Orientado a Objetos

De acordo com Larman (2000), “no projeto orientado a objetos deve-se definir

elementos lógicos de software”. Para isto, deve-se primeiro alocar responsabilidades aos

objetos, mostrando como eles interagem entre si. Esta interação é mostrada nos

diagra-mas de seqüência.

4.1.3.1 Diagramas de Seqüência

Para este trabalho foi desenvolvido um diagrama de seqüência para cada

ca-so de uca-so.

4.1.3.1.1 Diagrama “CadastrarPaciente”

Figura 4 - Diagrama de seqüência “CadastrarPaciente”

4.1.3.1.2 Diagrama “AbrirFichaPaciente”

4.1.3.1.3 Diagrama “DescreverConsultaInicial”

Este diagrama apresenta como pré-condição o diagrama “AbrirFichaPaciente”,

detalhado em 4.1.3.1.2, ou “CadastrarPaciente”, detalhado em 4.1.3.1.1.

Figura 6 - Diagrama de seqüência “DescreverConsultaInicial”

4.1.3.1.4 Diagrama “DescreverRetorno”

Este diagrama apresenta como pré-condição o diagrama “AbrirFichaPaciente”,

detalhado em 4.1.3.1.2, ou “CadastrarPaciente”, detalhado em 4.1.3.1.1.

Figura 7 - Diagrama de seqüência “DescreverRetorno”

4.1.3.1.5 Diagrama “PesquisarConsultaPaciente”

Este diagrama apresenta como pré-condição o diagrama “AbrirFichaPaciente”,

detalhado em 4.1.3.1.2, ou “CadastrarPaciente”, detalhado em 4.1.3.1.1.

Figura 8 - Diagrama de seqüência “PesquisarConsultaPaciente”

4.1.3.2 Diagrama de Classes de Projeto

Após a criação dos diagramas de seqüência, ou talvez, simultaneamente, é

criado o diagrama de classes de projeto, que mostra elementos de software, e não

con-ceitos do mundo real, como no modelo conceitual. Neste primeiro ciclo de

desenvolvi-mento, o diagrama de classes de projeto criado é o seguinte:

Figura 9 - Diagrama de classes de projeto – Ciclo 1

O projeto é um refinamento da análise, que deve levar em consideração os

requisitos não funcionais e o ambiente de implementação. Os artefatos resultantes do

projeto devem prover o comportamento do sistema.

4.1.3.3 Modelo de Dados

Na etapa de projeto deve ser realizada também, quando necessário, a

mode-lagem do banco de dados (persistência).

O modelo de banco de dados criado para este sistema, neste primeiro ciclo, é

o seguinte:

4.1.3.4 Interface

Para representar a interface foi criado um diagrama de classes (Figura 11).

Este poderia ser incluído no diagrama de classes de projeto, mostrado anteriormente.

Porém, por questões de melhor visualização, foi feito separado.

Figura 11 - Diagrama de classes - Interface – Ciclo 1

O sistema apresenta uma interface principal (Figura 12) a partir da qual

pode-se acessar as outras telas.

Figura 12 - Interface Principal

Um paciente pode ser cadastrado através da tela “FrameFicha” (Figura 13),

que é acessada pela opção “Novo Paciente”, no menu “Arquivo” da interface principal.

A ficha de um paciente pode ser aberta através da tela “FrameAbrirFicha”

(Figura 14), que é acessada pela opção “Abrir Ficha de Paciente”, no menu “Arquivo” da

interface principal.

Figura 14 - Tela “FrameAbrirFicha”

Uma consulta inicial e um retorno podem ser descritos, respectivamente, nas

telas “FrameConsultaInicial” (Figura 15) e “FrameRetorno” (Figura 16), através da opção

“Novo/Consulta Inicial” e “Novo/Retorno”, no menu “Paciente” da interface principal.

Figura 15 - Tela “FrameConsultaInicial”

Uma consulta de um paciente pode ser aberta através da tela

“FrameAbrir-Consulta” (Figura 17), que é acessada pela opção “Consultas”, no menu “Paciente” da

interface principal.

Figura 17 - Tela “FrameAbrirConsulta”

4.1.4 Implementação e Testes

Na etapa de implementação as classes são desenvolvidas, gerando o código

final. Neste primeiro ciclo de desenvolvimento, foram implementadas apenas as classes

que tratam das funcionalidades discutidas aqui, ou seja, o cadastro de pacientes, o

a-cesso a ficha de pacientes, a descrição de consultas e o aa-cesso às consultas de um

pa-ciente. As classes implementadas estão em anexo a este trabalho.

Durante toda a etapa de implementação foram executados testes. Foram

tes-tados o cadastro de pacientes, a descrição de consultas e o acesso à ficha de uma

paci-ente e suas consultas.

Os principais casos verificados durante os testes foram:

• Entrada de dados válidos, verificando o correto funcionamento em cada

ca-so.

• Entrada de dados inválidos, verificando o tratamento de erros em cada

ca-so.

• A necessidade de haver uma ficha de paciente aberta para que uma

con-sulta possa ser descrita ou aberta.

• Que se há uma ficha de paciente aberta quando solicitada outra ficha, a

primeira é fechada após a confirmação de salvamento ou não da mesma.

• Que se houver uma consulta aberta quando a ficha for fechada, a mesma

é fechada após a confirmação ou não do seu salvamento.

4.2 Segundo Ciclo de Desenvolvimento

4.2.1 Levantamento de Requisitos

Os requisitos do sistema não sofreram nenhuma alteração, e também não

surgiram novos requisitos, portanto a lista de funcionalidades continua a mesma do ciclo

anterior.

4.2.1.1 Diagrama de Casos de Uso

Como a lista de funcionalidades não sofreu nenhuma alteração do primeiro

para o segundo ciclo, o diagrama de casos de uso permanece o mesmo mostrado na

seção 4.1.1.1 deste trabalho (Figura 2).

4.2.1.2 Casos de Uso Expandidos

Este segundo ciclo trata as seguintes funcionalidades do sistema: escrever

uma receita, escrever um atestado, visualizar uma receita, visualizar um atestado e

pes-quisar por um modelo de atestado. A seguir estão descritos os casos de uso

correspon-dentes a cada uma destas funcionalidades.

4.2.1.2.1 Caso de Uso “EscreverReceita”

Ator: médico.

Finalidade: escrever uma receita para um paciente.

Visão Geral: o médico irá escrever uma receita para o paciente.

Pré-condição: DescreverConsultaInicial ou DescreverRetorno ou

PesquisarConsultaPa-ciente.

Seqüência típica de eventos:

1. O médico entra com as fórmulas e/ou descreve a receita.

2. O médico confirma a receita.

3. O sistema armazena a receita.

Extensões:

4.2.1.2.2 Caso de Uso “VisualizarReceita”

Ator: médico.

Finalidade: visualizar uma receita de um paciente.

Visão Geral: o médico irá visualizar uma receita do paciente.

Pré-condição: AbrirFichaPaciente ou CadastrarPaciente.

Seqüência típica de eventos:

1. O médico solicita ao sistema as receitas do paciente.

2. O sistema retorna uma lista com todas as receitas do paciente (mostrando a data em

que a receita foi escrita e o início de sua descrição).

3. O médico seleciona a data correspondente à receita que procura.

4. O sistema retorna a receita selecionada.

Extensões:

4.a. O médico imprime a receita.

4.b. O médico exclui a receita.

4.c. O médico altera a receita.

4.2.1.2.3 Caso de Uso “EscreverAtestado”

Ator: médico.

Finalidade: escrever um atestado para um paciente.

Visão Geral: o médico irá escrever um atestado para o paciente.

Pré-condição: DescreverConsultaInicial ou DescreverRetorno ou

PesquisarConsultaPa-ciente.

Seqüência típica de eventos:

1. O médico solicita ao sistema os atestados.

2. O sistema retorna a lista de atestados.

3. O médico seleciona um atestado na lista.

4. O sistema retorna o atestado selecionado.

5. O médico confirma o atestado.

6. O sistema armazena o atestado.

Extensões:

4.a. O médico altera o atestado.

6.a. O médico imprime o atestado.

4.2.1.2.4 Caso de Uso “VisualizarAtestado”

Ator: médico.

Finalidade: visualizar um atestado de um paciente.

Visão Geral: o médico irá visualizar um atestado do paciente.

Pré-condição: AbrirFichaPaciente ou CadastrarPaciente.

Seqüência típica de eventos:

1. O médico solicita ao sistema os atestados do paciente.

2. O sistema retorna uma lista com todos os atestados do paciente (mostrando a data

em que o atestado foi escrito e o início de sua descrição).

3. O médico seleciona a data correspondente ao atestado que procura.

4. O sistema retorna o atestado selecionado.

Extensões:

4.a. O médico imprime o atestado.

4.b. O médico exclui o atestado.

4.c. O médico altera o atestado.

4.2.1.2.5 Caso de Uso “PesquisarModeloAtestado”

Ator: médico.

Finalidade: pesquisar um modelo de atestado.

Visão Geral: o médico irá pesquisar um modelo de atestado.

Seqüência típica de eventos:

1. O médico solicita ao sistema os modelos de atestados.

2. O sistema retorna uma lista com os modelos de atestados.

3. O médico seleciona o modelo de atestado desejado.

4. O sistema retorna o modelo selecionado.

Extensões:

2.a. O médico inclui um novo modelo de atestado.

4.a. O médico exclui o modelo de atestado selecionado.

4.b. O médico altera o modelo de atestado selecionado.

4.2.2 Análise Orientada a Objetos

4.2.2.1 Diagrama de Classes Conceituais

No diagrama de classes conceituais do primeiro cliclo de desenvolvimento

fo-ram incluídas algumas classes e relacionamentos que resultafo-ram da análise dos casos

de uso detalhados neste segundo ciclo. O diagrama resultante é o seguinte:

4.2.3 Projeto Orientado a Objetos

4.2.3.1 Diagramas de Seqüência

Os diagramas de seqüência de cada um dos casos de uso detalhados neste

ciclo são mostrados a seguir.

4.2.3.1.1 Diagrama “EscreverReceita”

Este diagrama apresenta como pré-condição o diagrama

“DescreverConsulta-Inicial”, detalhado em 4.1.3.1.3, ou o diagrama “DescreverRetorno”, detalhado em

4.1.3.1.4, ou o diagrama “PesquisarConsultaPaciente”, detalhado em 4.1.3.1.5.

Figura 19 - Diagrama de seqüência “EscreverReceita”

4.2.3.1.2 Diagrama “VisualizarReceita”

Este diagrama apresenta como pré-condição o diagrama “AbrirFichaPaciente”,

detalhado em 4.1.3.1.2, ou “CadastrarPaciente”, detalhado em 4.1.3.1.1.

Figura 20 - Diagrama de seqüência “VisualizarReceita”

4.2.3.1.3 Diagrama “EscreverAtestado”

Este diagrama apresenta como pré-condição o diagrama

“DescreverConsulta-Inicial”, detalhado em 4.1.3.1.3, o diagrama “DescreverRetorno”, detalhado em 4.1.3.1.4,

ou o diagrama “PesquisarConsultaPaciente”, detalhado em 4.1.3.1.5.

Figura 21 - Diagrama de seqüência “EscreverAtestado”

4.2.3.1.4 Diagrama “VisualizarAtestado”

Este diagrama apresenta como pré-condição o diagrama “AbrirFichaPaciente”,

detalhado em 4.1.3.1.2, ou “CadastrarPaciente”, detalhado em 4.1.3.1.1.

Figura 22 - Diagrama de seqüência “VisualizarAtestado”

4.2.3.1.5 Diagrama “PesquisarModeloAtestado”

4.2.3.2 Diagrama de Classes de Projeto

O diagrama de classes de projeto deste ciclo, mostrado a seguir, foi feito

atua-lizando-se o diagrama do primeiro ciclo de acordo com a análise das funcionalidades

tratadas neste.

4.2.3.3 Modelo de Dados

Neste ciclo foram acrescentados algumas tabelas e alguns relacionamentos

ao modelo de dados do primeiro ciclo. O modelo resultante é mostrado a seguir.

4.2.3.4 Interface

Foram identificadas mais algumas classes de interface para as

funcionalida-des tratadas aqui. O diagrama de classes da interface funcionalida-deste ciclo é o seguinte:

Figura 26 - Diagrama de classes - Interface – Ciclo 2

O médico descreve uma receita através da tela “FrameNovaReceita” (Figura

27), que pode ser acessada pela opção “Novo/Receita” no menu “Paciente” da interface

principal e é mostrada abaixo.

Figura 27 - Tela “FrameNovaReceita”

As receitas de um determinado paciente podem ser visualizadas na tela

“Fra-meReceitas” (Figura 28) acessada pela opção “Receitas” no menu “Paciente” da

interfa-ce principal.

O médico descreve um atestado na tela “FrameAtestado” (Figura 30), que

po-de ser acessada pela opção “Novo/Atestado” no menu “Paciente” da interface principal.

Antes desta tela ser mostrada é exibida a tela “FrameNovoAtestado” (Figura 29), para

que o médico possa selecionar um modelo de atestado, se desejar.

Figura 29 - Tela “FrameNovoAtestado”

Para visualizar os atestados de um paciente, o médico deve acessar a tela

“FrameAtestados” (Figura 31) através da opção “Atestados” no menu “Paciente” da

inter-face principal.

Figura 31 - Tela “FrameAtestados”

Os modelos de atestados do sistema podem ser visualizados, alterados,

cria-dos ou excluícria-dos através da tela “FrameAtestacria-dosSistema” (Figura 32), acessado pela

opção “Atestados” no menu “Editar” da interface principal.

Figura 32 - Tela “FrameAtestadosSistema”

4.2.4 Implementação e Testes

Nesta etapa foram implementados os métodos e as classes que tratam das

funcionalidades analisadas neste ciclo. São estas, a descrição e visualização de receitas

e atestados e a inclusão, alteração e exclusão de modelos de atestados.

Durante toda a etapa de implementação foram executados testes para

verifi-car se as funcionalidades implementadas são executadas corretamente.

Os principais casos verificados durante os testes foram:

• Entrada de dados válidos, verificando o correto funcionamento em cada

ca-so.

• Entrada de dados inválidos, verificando o tratamento de erros em cada

ca-so.

• A necessidade de haver uma consulta aberta para que uma receita ou um

atestado possam ser descritos.

• A necessidade de que a ficha do paciente esteja aberta para que suas

re-ceitas e seus atestados possam ser visualizados.

• A possibilidade de se escolher um modelo de atestado previamente

descri-to no sistema quando da descrição de um atestado de um paciente.

4.3 Terceiro Ciclo de Desenvolvimento

4.3.1 Levantamento de Requisitos

Assim como no segundo ciclo, neste não houveram alterações nos requisitos

do sistema, continuando a lista de funcionalidades a mesma do primeiro ciclo.

4.3.1.1 Diagrama de Casos de Uso

O diagrama de casos de uso, assim como a lista de funcionalidades,

perma-nece o mesmo do ciclo 1, mostrado na Figura 2.

4.3.1.2 Casos de Uso Expandidos

As funcionalidades tratadas neste terceiro ciclo são a pesquisa de planos de

saúde, fórmulas e procedimentos. Os casos de uso correspondentes a estas

funcionali-dades são descritos a seguir.

4.3.1.2.1 Caso de Uso “PesquisarPlano”

Ator: médico.

Finalidade: visualizar os planos de saúde cadastrados no sistema.

Visão Geral: o médico irá pesquisar os planos de saúde cadastrados no sistema

Seqüência típica de eventos:

1. O médico solicita ao sistema os planos.

2. O sistema retorna uma lista com os planos (nome do plano, valor da consulta e

ou-tras informações).

Extensões:

2.a. O médico inclui um novo plano.

2.b. O médico exclui um plano.

2.c. O médico altera as informações de um plano.

4.3.1.2.2 Caso de Uso “PesquisarFormula”

Ator: médico.

Finalidade: visualizar as fórmulas cadastradas no sistema.

Seqüência típica de eventos:

1. O médico solicita ao sistema as fórmulas.

2. O sistema retorna uma lista dos tipos de fórmulas.

3. O médico seleciona o tipo de fórmula desejada.

4. O sistema retorna uma lista das fórmulas do tipo selecionado.

5. O médico seleciona a fórmula desejada.

6. O sistema retorna as informações sobre a fórmula selecionada.

Extensões:

2.a. O médico inclui uma nova fórmula.

6.a. O médico exclui a fórmula selecionada.

6.b. O médico altera as informações da fórmula selecionada.

4.3.1.2.3 Caso de Uso “PesquisarProcedimento”

Ator: médico.

Finalidade: visualizar os procedimentos cadastrados no sistema.

Visão Geral: o médico irá pesquisar os procedimentos cadastrados no sistema

Seqüência típica de eventos:

1. O médico solicita ao sistema os procedimentos.

2. O sistema retorna uma lista dos procedimentos.

3. O médico seleciona o procedimento desejado.

4. O sistema retorna as informações do procedimento selecionado (número, descrição,

valor para cada plano).

Extensões:

2.a. O médico inclui um novo procedimento.

4.a. O médico exclui o procedimento selecionado.

4.b. O médico altera as informações do procedimento selecionado.

4.3.2 Análise Orientada a Objetos

4.3.2.1 Diagrama de Classes Conceituais

Neste terceiro ciclo de desenvolvimento não foi necessário adicionar novas

classes ou relacionamentos ao diagrama de classes conceituais do ciclo anterior. O

dia-grama continua o mesmo mostrado anteriormente na Figura 18.

4.3.3 Projeto Orientado a Objetos

4.3.3.1 Diagramas de Seqüência

Os diagramas de seqüência de cada um dos casos de uso detalhados neste

ciclo são mostrados a seguir.

4.3.3.1.1 Diagrama “PesquisarPlano”

4.3.3.1.2 Diagrama “PesquisarFormula”

Figura 34 - Diagrama de seqüência “PesquisarFormula”

4.3.3.1.3 Diagrama “PesquisarProcedimento”

4.3.3.2 Diagrama de Classes de Projeto

Neste ciclo foi necessário acrescentar alguns métodos em algumas classes no

diagrama de classes de projeto do ciclo anterior, resultando no seguinte diagrama:

4.3.3.3 Modelo de Dados

O modelo de dados não foi alterado do segundo para o terceiro ciclo,

continu-ando o mesmo mostrado na Figura 25.

4.3.3.4 Interface

Foram identificadas mais algumas classes de interface para as

funcionalida-des tratadas aqui. O diagrama de classes da interface funcionalida-deste ciclo é o seguinte: