UNIVERSIDADE FEEVALE

MARCEL DE JESUS SILVA

SISTEMA DE GESTO PARA CLNICAS MDICAS DE PEQUENO PORTE

Novo Hamburgo 2010

MARCEL DE JESUS SILVA

SISTEMA DE GESTO PARA CLNICAS MDICAS DE PEQUENO PORTE

Trabalho de Concluso de Curso apresentado como requisito parcial obteno do grau de Bacharel em Sistemas de Informao pela Universidade Feevale

Professor Orientador: Edvar Bergmann Arajo

Novo Hamburgo 2010

RESUMO

Os sistemas de gesto tornaram-se um dos principais componentes dos sistemas de informao das empresas. Levando em considerao a importncia de as empresas terem um sistema de gesto da informao e o promissor segmento de servios, este trabalho apresenta a proposta de criao de um sistema de gesto para clnicas mdicas de pequeno porte. O projeto foi realizado seguindo a metodologia de desenvolvimento do processo unificado e a anlise de sistemas para clnicas mdicas j existentes no mercado. A utilizao da linguagem de programao Java e seus frameworks JSF, EJB e JPA contribuem para uma arquitetura robusta. Na anlise e projeto do sistema foram identificados os requisitos funcionais e os requisitos no funcionais. Foram desenvolvidos os casos de usos necessrios, uma matriz de rastreabilidade para determinar quais casos de uso atendem os requisitos e, adicionalmente, foram feitos os diagramas de casos de uso e de classes. Por fim foi desenvolvido o prottipo das telas do sistema. Este software foi planejado com o intuito de oferecer uma reduo de tempo no ciclo dos processos, informaes mais rpidas sobre as transaes da organizao, melhoria na gerncia financeira, bem como facilitar a converso do conhecimento tcito sobre o processo em conhecimento explcito. Palavras-chave: ERP. Sistema de gesto. Clnica mdica. Sistema de gesto mdica.

ABSTRACT

The management systems have become one of the most important components on companys systems information. Taking into consideration the importance of companies having an information management system and the promising area of services, this paper proposes the creation of a management system for small medical clinics. The project was made following the development methodology of unified process and the analysis of other softwares for medical clinics already on the market. The use of Java development language and its frameworks JSF, EJB and JPA contribute for a robust structure. During the analysis and project of the system the functional and non functional requirements were identified. The necessary use cases were developed, as well as a tracking matrix in order to determine which use cases resolve the requirements. Additionally the diagrams of use cases and classes were made. Finally, the prototype of the system screens was developed. This software was planned with the following objectives: to offer a time reduction on processes cycle, faster information about the company transactions, improvement of financial management and make easier the conversion of tacit knowledge about the process on explicit knowledge. Keywords: ERP. Management system. Medical clinic. Medical system management.

LISTA DE FIGURAS

Figura 2.1 - MDMed - Tela de Cadastro de Pacientes ............................................................. 22 Figura 2.2 - MDMed - Tela de Agenda .................................................................................... 23 Figura 2.3 - MDMed - Tela de Ficha Mdica........................................................................... 24 Figura 2.4 - Gerclim - Tela de Cadastro de Pacientes .............................................................. 26 Figura 2.5 - Gerclim - Tela de Agenda ..................................................................................... 27 Figura 2.6 - Gerclim - Tela de Ficha Mdica ........................................................................... 28 Figura 2.7 - ProDoctor - Tela de Cadastro de Pacientes .......................................................... 29 Figura 2.8 - ProDoctor - Tela de Agenda ................................................................................. 30 Figura 2.9 - ProDoctor - Tela de Ficha Mdica ........................................................................ 31 Figura 4.1 - Diagrama de Caso de Uso do Mdulo de Segurana............................................ 50 Figura 4.2 - Diagrama de Caso de Uso do Mdulo de Cadastro Viso da Secretria ........... 50 Figura 4.3 - Diagrama de Caso de Uso do Mdulo de Cadastro Viso do Mdico .............. 51 Figura 4.4 - Diagrama de Caso de Uso do Mdulo de Cadastro Viso do Administrativo .. 51 Figura 4.5 - Diagrama de Caso de Uso do Mdulo de Agenda ................................................ 52 Figura 4.6 - Diagrama de Caso de Uso de Pronturio .............................................................. 52 Figura 4.7 - Diagrama de Caso de Uso de Estoque .................................................................. 53 Figura 4.8 - Diagrama de Caso de Uso Financeiro................................................................... 54 Figura 4.9 - Diagrama das Classes Comuns ............................................................................. 54 Figura 4.10 - Diagrama de Classes do Mdulo de Segurana .................................................. 55 Figura 4.11 - Diagrama de Classes do Mdulo de Cadastros ................................................... 56 Figura 4.12 - Diagrama de Classes do Mdulo de Agenda ...................................................... 56 Figura 4.13 - Diagrama de Classes do Mdulo de Pronturio.................................................. 57 Figura 4.14 - Diagrama de Classes do Mdulo de Estoque...................................................... 58 Figura 4.15 - Diagrama de Classes do Mdulo de Financeiro ................................................. 59 Figura 5.1 - Prottipo da Tela de Cadastro de Pacientes .......................................................... 89 Figura 5.2 - Prottipo da Tela de Cadastro de Clnicas ............................................................ 90 Figura 5.3 - Prottipo da Tela de Agenda ................................................................................ 91 Figura 5.4 - Prottipo da Tela de Cadastro de Atendimentos .................................................. 92 Figura 5.5 - Prottipo da Tela de Fluxo de Caixa .................................................................... 93 Figura 5.6 - Prottipo da Tela de Contas a Pagar e Contas a Receber ..................................... 94

LISTA DE TABELAS

Tabela 2.1 Anlise de Caractersticas .................................................................................... 32 Tabela 4.1 - Requisitos Funcionais........................................................................................... 38 Tabela 4.2 - Requisitos No Funcionais ................................................................................... 40 Tabela 4.3 - Casos de Uso - Mdulo de Segurana .................................................................. 41 Tabela 4.4 - Casos de Uso - Mdulo de Cadastros ................................................................... 42 Tabela 4.5 - Casos de Uso - Mdulo de Agenda ...................................................................... 43 Tabela 4.6 - Casos de Uso - Mdulo de Pronturio.................................................................. 44 Tabela 4.7 - Casos de Uso - Mdulo de Estoque...................................................................... 45 Tabela 4.8 - Casos de Uso - Mdulo Financeiro ...................................................................... 46 Tabela 4.9 - Matriz de Rastreabilidade..................................................................................... 47

LISTA DE ABREVIATURAS E SIGLAS

BI CRM DAO EJB ERP JDBC JPA JSF MVC PIB RF RNF SCM SGM SQL UC UML W3C

Business Intelligence Customer Relationship Management Data Access Object Enterprise Java Beans Enterprise Resource Planning Java Data Base Connectivity Java Persistence API Java Server Faces Model View Controller Produto Interno Bruto Requisito Funcional Requisito No Funcional Supply Chain Management Sistema de Gesto Mdica Structured Query Language Use Case Unified Modeling Language World Wide Web Consortium

SUMRIO

INTRODUO ........................................................................................................................ 10 1. PROCESSO UNIFICADO .................................................................................................. 13 1.1. Introduo ao Processo Unificado .................................................................................. 13 1.1.1. Dirigido por casos de uso ........................................................................................... 13 1.1.2. Centrado em arquitetura ............................................................................................. 14 1.1.3. Iterativo e incremental ................................................................................................ 15 1.2. As quatro fases do processo unificado ............................................................................ 17 1.3. Os nove ciclos do processo unificado ............................................................................. 18 2. SISTEMAS SIMILARES .................................................................................................... 20 2.1. O sistema MDMed .......................................................................................................... 21 2.2. O sistema Gerclim ........................................................................................................... 24 2.3. O sistema ProDoctor ....................................................................................................... 28 2.4. Anlise de caractersticas dos sistemas similares............................................................ 31 3. TECNOLOGIAS ................................................................................................................. 33 3.1. Linguagem Java .............................................................................................................. 33 3.2. JSF Java Server Faces ................................................................................................. 34 3.3. EJB Enterprise Java Beans .......................................................................................... 34 3.4. JPA Java Persistence API ............................................................................................ 35 3.5. JDBC e SQL.................................................................................................................... 35 3.6. Padres de projetos: MVC e DAO .................................................................................. 36 4. ANLISE E PROJETO ....................................................................................................... 38 4.1. Requisitos Funcionais ..................................................................................................... 38 4.2. Requisitos no funcionais ............................................................................................... 40 4.3. Casos de Uso ................................................................................................................... 41 4.3.1. Mdulo de Segurana ................................................................................................. 41 4.3.2. Mdulo de Cadastros .................................................................................................. 42 4.3.3. Mdulo de Agenda ..................................................................................................... 43 4.3.4. Mdulo de Pronturio................................................................................................. 44 4.3.5. Mdulo de Estoque ..................................................................................................... 45 4.3.6. Mdulo Financeiro ..................................................................................................... 46 4.4. Matriz de Rastreabilidade ............................................................................................... 47 4.5. Diagrama de Casos de Uso ............................................................................................. 48 4.5.1. Segurana ................................................................................................................... 49 4.5.2. Cadastros .................................................................................................................... 50 4.5.3. Agenda........................................................................................................................ 52 4.5.4. Pronturio ................................................................................................................... 52 4.5.5. Estoque ....................................................................................................................... 53

4.5.6.

Financeiro ................................................................................................................... 53

4.6. Diagrama de Classes ....................................................................................................... 54 4.6.1. Segurana ................................................................................................................... 55 4.6.2. Cadastros .................................................................................................................... 55 4.6.3. Agenda........................................................................................................................ 56 4.6.4. Pronturio ................................................................................................................... 57 4.6.5. Estoque ....................................................................................................................... 57 4.6.6. Financeiro ................................................................................................................... 58 4.7. Detalhamento dos casos de uso ....................................................................................... 59 4.7.1. Cadastros .................................................................................................................... 59 4.7.2. Agenda........................................................................................................................ 68 4.7.3. Pronturio ................................................................................................................... 72 4.7.4. Estoque ....................................................................................................................... 77 4.7.5. Financeiro ................................................................................................................... 81 5. PROTTIPO DO SISTEMA............................................................................................... 89 5.1. Cadastro de Pacientes...................................................................................................... 89 5.2. Cadastro de Clnicas........................................................................................................ 90 5.3. Agenda ............................................................................................................................ 91 5.4. Cadastro de Atendimento ................................................................................................ 91 5.5. Fluxo de Caixa ................................................................................................................ 92 5.6. Contas a Pagar e Contas a Receber ................................................................................. 93 CONCLUSO .......................................................................................................................... 95 REFERNCIAS ....................................................................................................................... 97

INTRODUO

Para garantir no apenas vantagens no mercado, mas sua sobrevivncia nele, as empresas precisam estar atentas a todos os fatores ambientais, organizacionais e tecnolgicos que as cercam. Com o acesso rpido e fcil s informaes, os consumidores esto cada vez mais exigentes e o mercado est em constante mudana. As organizaes precisam integrar a grande quantidade de informaes que impactam em seu negcio para poder acess-la de forma rpida e tomar decises assertivas no menor tempo possvel. Souza e Saccol (2008) acreditam que os sistemas de informaes so recursos cada vez mais crticos para que as empresas garantam a sobrevivncia de seus empreendimentos. Os sistemas de ERP (Enterprise Resource Planning) tornaram-se um dos principais componentes dos sistemas de informao de empresas. Isto porque permitem a integrao de dados de todos os processos de negcios da empresa, fornecendo uma viso ampla da empresa aos gestores e permitindo que tenham informaes precisas e atualizadas para basear a tomada de decises.
Entre os sistemas de informao disponveis hoje no mercado, os sistemas integrados de gesto, conhecidos como Enterprise Resource Planning (ERP), vm recebendo continuamente a ateno de profissionais e acadmicos da rea de Administrao. A proposta destes sistemas a de unir e disponibilizar informaes para a organizao toda. (SOUZA e SACCOL, 2008 p. 173)

Davenport (2002) defende que alguns dos benefcios alcanados pelas empresas atravs do uso de sistemas de gesto empresarial so: 1 - Reduo de tempo do ciclo dos processos; 2 - Informaes mais rpidas sobre as transaes da organizao; 3 - Melhoria na gerncia financeira; 4 - Converso do conhecimento tcito sobre o processo em conhecimento explcito.

Padilha e Marins (2005 apud DAVENPORT 1998) apresentam as funcionalidades dos sistemas ERP separando-as em funes internas (back-office), composta por recursos humanos, manufatura e finanas, e funes externas ( front-office), composta por vendas e servios, alm da tecnologia e do chamado Gerenciamento da Cadeia de Suprimentos- SCM (Supply Chain Management). Padilha e Marins (2005) destacam que, dentre as principais tendncias e novidades incorporadas pelos principais fornecedores de ERP esto:

11

Foco nas Empresas de Pequeno e Mdio Porte (Small/Middle Market): atualmente, especialmente no Brasil, o principal alvo das produtoras de sistemas ERP o chamado "small/middle market", composto por empresas de pequeno e mdio porte; Internet: uma grande tendncia entre os fornecedores de ERP a gradual incorporao de mdulos que possam ser operacionalizados via Internet, permitindo a prtica do comrcio e outras prticas empresariais, por meio eletrnico (e-business); Business Intelligence (BI): um termo genrico para aplicaes, plataformas, ferramentas e tecnologias que suportam o processo de explorao de dados de negcio e anlise de suas correlaes e tendncias. Aplicaes de BI conferem s empresas meios para coletar e preparar dados com o objetivo de facilitar a gerao de relatrios, anlises e tomada de deciso; Supply Chain Management - SCM: ou gerenciamento da cadeia de suprimentos, o nome do recurso que permite a integrao de uma empresa com as demais organizaes envolvidas no processo produtivo (clientes e fornecedores), buscando otimizar o funcionamento como um todo, com redues de custos e ganhos de produtividade e qualidade; CRM (Customer Relashionship Management): ou gerenciamento das relaes com o cliente, est assumindo um papel muito importante nos departamentos de marketing, que tambm utilizam a expresso marketing de relacionamento para os conceitos apoiados por esta nova ferramenta.

Dentre os setores que esto implementando sistemas de gesto para ganhar competitividade em seus mercados, est o setor de servios. Os negcios com servios esto crescendo no mundo todo, sendo que, em muitos pases, j h uma predominncia deste setor nos resultados da economia. Este crescimento teve in cio nos pases desenvolvidos e em 1996 o setor de servios representava 79% de todos os empregos e pelo menos 76% do PIB dos Estados Unidos (VALARIE e BITNER, 2008, p. 31). As empresas que oferecem servios mdicos tambm esto buscando atravs de sua informatizao melhorar seus processos e oferecer servios de maior qualidade a seus clientes.

12

Levando em considerao a importncia de as empresas terem um sistema de gesto da informao e o promissor segmento de servios, este trabalho ter como objetivo estruturar o desenvolvimento de um sistema de gesto para clnicas mdicas de pequeno porte. Objetivase responder assim ao seguinte problema: como desenvolver um sistema de gesto empresarial para clnicas mdicas de pequeno porte permitindo, assim, que reduza significativamente a quantidade de papis arquivados e manuseados e facilite o acesso s informaes necessrias para a eficaz gesto desta clnica. Este trabalho prope contribuir com a informatizao das clnicas da rea de sade da regio do Vale do Sinos. A proposta oferecer para estas empresas um sistema que atenda s suas necessidades especficas, no apenas de controle, mas tambm que gere informaes com base nestes dados permitindo a tomada de decises estratgicas por parte dos gestores. Resumindo, o objetivo principal projetar um sistema de gesto para clnicas mdicas de pequeno porte, disponibilizando de forma simples e direta o acesso s informaes sobre o gerenciamento de cadastros, agendamentos, pronturios eletrnicos, custos, estoque e relatrios, facilitando a gesto da clnica, a rapidez no atendimento de seus clientes e maior segurana das informaes. Outros objetivos que podem ser destacados so as comparaes deste sistema com sistemas similares, a descrio das necessidades de clnicas mdicas e a anlise e projeto deste sistema de forma detalhada. O trabalho est organizado em cinco captulos. O primeiro captulo apresenta o processo unificado e o porqu de sua utilizao. O segundo descreve os sistemas similares ao proposto, destacando suas caractersticas. O terceiro captulo apresenta as tecnologias utilizadas, incluindo a linguagem de programao, bem como seus frameworks e os padres de projetos aplicados. O quarto captulo aborda a anlise de requisitos do sistema, descreve os requisitos funcionais e no funcionais, os casos de uso e seus diagramas divididos em mdulos. O quinto e ltimo captulo demonstra o prottipo do sistema atravs de suas principais telas.

1.

PROCESSO UNIFICADO

A engenharia de software pode ser definida como um conjunto de disciplinas que incluem a especificao, o desenvolvimento, o gerenciamento e a evoluo dos sistemas de software. Seu objetivo um maior rigor no desenvolvimento de softwares. (AUDY e PRIKLADNICKI, 2007, p.10). Pressman (2004) define a Engenharia de software como dividida em quatro camadas. A camada base o foco na qualidade, seguida de processos, mtodos e ferramentas. As ferramentas proporcionam apoio automatizado ao mtodo que, por sua vez, consiste em como fazer, ou seja, quais so os passos que devem ser seguidos para a construo de um software de alta qualidade. O processo a camada mais importante da engenharia de software, pois ela faz a intermediao entre as ferramentas e os mtodos, alm de possibilitar um desenvolvimento racional do software.
Um processo de software um conjunto de atividades e resultados associados que geram um produto de software. Um processo define a sequncia em que os mtodos sero aplicados, como os produtos sero entregues, os controles que ajudam a assegurar a qualidade e a coordenar as mudanas, e os marcos de referncia que possibilitam aos gerentes de software avaliar o progresso do desenvolvimento. (AUDY e PRIKLADNICKI, 2007, p. 11)

Neste captulo ser abordado um detalhamento do processo unificado, sendo esta a metodologia escolhida para o desenvolvimento do software em questo no presente trabalho.

1.1. Introduo ao Processo Unificado Processo unificado significa criar um sistema de software atravs de um conjunto de requisitos do cliente utilizando um conjunto de atividades. Processo unificado tambm pode ser definido como uma estrutura genrica de processo que pode ser customizado adicionando-se ou removendo-se atividades com base nas necessidades especficas e nos recursos disponveis para um projeto (SCOTT, 2003, p.19). O processo unificado caracterizado por ser dirigido por casos de uso, centrado em arquitetura e interativo e incremental. A seguir estas trs caractersticas sero abordadas de maneira mais detalhada.

1.1.1.

Dirigido por casos de uso Casos de uso so sequncias de aes, onde o prprio sistema ou atores (pessoas) as

executam, gerando resultados de valor para um ou mais atores. Um dos principais atributos do processo unificado a utilizao de casos de uso no seu desenvolvimento. A expresso

14

dirigido por casos de uso refere-se ao fato de se utilizar os casos de uso para dirigir todo o trabalho de desenvolvimento, desde a captao inicial e negociao de requisitos at a aceitao do cdigo (SCOTT, 2003, p.21). Segundo o autor, casos de uso so importantes para encontrar requisitos, elaborar a anlise, projeto e implementao, pelas seguintes razes: So demonstrados sob a tica dos usurios; So expressos de maneira simples, so intuitivos e esto na linguagem do cliente; Melhoram consideravelmente o entendimento dos requisitos reais do sistema; Atingem um alto grau de rastreamento de requisitos que resultam do desenvolvimento posterior; Simplificam a decomposio dos requisitos que permitem alocar trabalho a subequipes o que ajuda na gerncia do projeto.

1.1.2.

Centrado em arquitetura No contexto da computao, arquitetura possui diferentes significados, dependendo

de quem a define. Uma definio proposta a seguinte:

Arquitetura a organizao fundamental do sistema como um todo. Entre os aspectos de uma arquitetura, esto includos elementos estticos, elementos dinmicos o modo como estes elementos trabalham juntos e o estilo arquitetnico total que guia a organizao do sistema. A arquitetura tambm se refere a questes como desempenho, escalabilidade, reuso e restries econmicas e tecnolgicas. (SCOTT, 2003, p.21).

Os autores Bass, Clements, Kazman e Wesley (1998 apud Scott, 2003), falam que para o processo unificado, uma das principais preocupaes da equipe de projeto deve ser a arquitetura do sistema, j que ela o alicerce fundamental sobre o qual ele se erguer. Alm disso, assim como os casos de uso, a arquitetura deve orientar a explorao de todos os aspectos do sistema. Para Scott (2003), existe algumas razes-chave da importncia da arquitetura para o processo unificado, seguem elas: Entendendo a viso global - por mais que as ferramentas de desenvolvimento estejam evoluindo, no h uma perspectiva prxima de estas ferramentas alcanarem de forma satisfatria os nveis de complexidade gerados com sistemas distribudos. Em consequncia disto se torna difcil para quase todas as pessoas entender o sistema de uma maneira mais significativa. A definio da arquitetura objetiva acima de tudo entender o sistema em construo. Sendo assim a

15

modelagem e legibilidade dos diagramas UML (Unified Modeling Language) junto com os textos de apoio sero de vital importncia para melhorar o entendimento da viso global do sistema; Organizando o esforo de desenvolvimento - usar padres arquitetnicos ajuda a dar forma ao esforo de desenvolvimento em vrios nveis. Como exemplos de padres arquitetnicos bem conhecidos, pode-se citar Cliente/Servidor e Model-View-Controller (MVC) que tambm chamado de trs camadas. possvel aumentar em muito as chances de comunicao das subequipes e agregar valor ao esforo destas ao utilizar efetivamente este aspecto da arquitetura; Facilitando as possibilidades de reuso - a idia de componentes reutilizveis com um mnimo relativo de customizao um dos princpios fundamentais do desenvolvimento baseado em componentes. Uma arquitetura bem construda disponibiliza uma estrutura slida na qual os componentes podem trabalhar uns com os outros de forma simples e elegante, facilitando para as equipes de construo o possvel reuso de componentes. A linha de base que quanto menos tempo for necessrio construo de novos componentes, mais tempo haver para entender os problemas dos clientes e modelar as solues; Facilitando a evoluo do sistema - com a constante e rpida evoluo da internet, os modelos de negcio costumam mudar com maior frequncia do que antes. Ter uma arquitetura slida um timo apoio para executar estas mudanas, e se construda de modo que as mudanas em uma determinada parte do sistema no afetem as demais, tambm contribuir para a evoluo efetiva e eficiente do sistema; Dirigindo os casos de uso - se por um lado os casos de uso direcionam a arquitetura de um sistema, por outro a arquitetura guia a seleo e utilizao de casos de uso. As decises dos arquitetos possuem uma forte influncia na escolha dos casos de uso que agregaro valor a arquitetura, o que ajuda a dar forma ao contedo daqueles casos de uso e natureza do trabalho envolvido no desenvolvimento deles.

1.1.3.

Iterativo e incremental Scott (2003) descreve que iterao um miniprojeto que resulta em uma verso do

sistema. Supe-se que essa verso oferea uma melhora incremental sobre a anterior. Ele

16

ainda fala de como iteraes e incrementos se encaixam no contexto de processo completo. Os itens a seguir demonstram as vantagens do desenvolvimento iterativo e incremental: Progresso lgico para uma arquitetura robusta - o processo demonstra a forma de a equipe trabalhar, prope uma base slida para a arquitetura durante as iteraes iniciais. Aps proposta uma viso completa da arquitetura, que influencia a maior parte do desenvolvimento realizado em dada iterao. Usar o modo iterativo e incremental permite ainda no incio do processo, fazer as mudanas necessrias a um custo consideravelmente menor; Lidando com mudanas contnuas nos requisitos - processos que se baseiam no desenvolvimento em cascata enfrentam o que hoje parece ser um problema inevitvel, os requisitos costumam ser instveis e os clientes no conseguem visualizar o sistema. O processo unificado tem o objetivo de quebrar o desenvolvimento do sistema em unidades, nas quais sua construo uma verso funcional de uma parte do sistema completo. Utilizar um conjunto limitado de casos de uso e apresentar prottipos favorece a negociao de requisitos de modo progressivo, reduzindo assim o risco de tentar especificar todos os requisitos no incio do projeto; Maior Flexibilidade para mudar o plano - sendo a iterao um mini projeto, os riscos associados com o projeto devem ser tratados assim que a equipe cria uma iterao do sistema. No decorrer das iteraes possvel realizar os ajustes necessrios em uma pequena escala e propag-los por todo o projeto. O objetivo isolar os problemas dentro das iteraes e lidar com eles em uma escala relativamente pequena, em vez de permitir que se alastrem ; Integrao contnua - cada incremento cria uma funcionalidade aperfeioada e uma combinao de novas caractersticas para o sistema. Isto permite que seja medido o progresso do projeto em relao aos objetivos especficos. Com a utilizao de componentes integrados possvel separar os problemas que podem ser provocados no sistema e resolv-los de maneira a no afetar a integridade do mesmo, possibilitando decises drsticas como recomear um incremento sobre novos alicerces; Entendimento precoce - como cada atividade da equipe tem uma definio simples, o processo projetado para permitir o aprendizado e treinamento

17

contnuos. Errar e experimentar neste processo no causa um grande impacto, pois os erros sero isolados;
medida que o trabalho prossegue, possvel nivelar o entendimento sobre o que se est tentando construir e os riscos associados, o que desenvolve uma capacidade de trabalho, que, por sua vez, permite melhorias contnuas no modo de lidar com as tarefas (SCOTT, 2003, p.25).

Foco contnuo sobre riscos - a mais importante vantagem do desenvolvimento iterativo e incremental talvez seja a possibilidade de no incio do projeto concentrar os esforos nos riscos mais crticos. A equipe organiza as iteraes de acordo com as anlises de riscos de uma forma contnua, tendo como objetivo minimiz-los durante cada iterao, fazendo com que cada vez as iteraes possuam menos riscos e que estes tenham menor importncia do que os anteriores.

1.2. As quatro fases do processo unificado Booch, Rumbaugh e Jacobson (2000) afirmam que o processo unificado composto por quatro fases, que so detalhadas a seguir. Segundo os autores, uma fase o perodo de tempo entre dois importantes marcos de progresso do processo em que um conjunto de objetivos bem definidos alcanado. As principais fases do Processo Unificado so: 1. Concepo - nesta fase o caso de negcio estabelecido e o escopo delimitado para o projeto. O caso de negcio deve incluir critrios de sucesso, avaliao de riscos, definio de recursos necessrios e um plano definindo os principais marcos de progresso. Ao fim desta fase se define a viabilidade de se prosseguir com o projeto em plena escala; 2. Elaborao - so definidos o plano de projeto e a arquitetura. Os objetivos desta fase so anlise do domnio de problema, o estabelecimento da fundao de uma arquitetura slida, o desenvolvimento do plano do projeto e a eliminao dos elementos de mais alto risco do projeto. (BOOCH, RUMBAUGH e JACOBSON: 2000, p.445). Como necessria uma compreenso de todo o sistema para definir a arquitetura, se faz necessrio o detalhamento da maioria de seus requisitos. Ao fim, se decide se deve-se prosseguir com a construo; 3. Construo - consiste no desenvolvimento do sistema. Nesta fase desenvolvido um sistema completo, passando pela descrio dos requisitos restantes e de critrios de aceitao, pelo desenvolvimento em si, pela implantao e,

18

finalmente, pelos testes do software. Ao fim se analisa se o software, o ambiente e os usurios esto prontos para se tornarem operacionais; 4. Transio - quando o sistema entregue aos usurios finais. Aps o incio da utilizao do software por seus usurios, podem surgir necessidades de desenvolvimentos adicionais. Por isso, segundo os autores, esta fase normalmente se inicia com uma verso beta do sistema que, posteriormente, substituda pelo sistema de produo. No final desta fase se decide se os objetivos de ciclo de vida do projeto foram alcanados e se determina se outro ciclo de desenvolvimento deve ser iniciado.
A passagem pelas quatro principais fases chamada um ciclo de desenvolvimento e resulta na gerao de um software. O primeiro passo das quatro fases chamado o ciclo inicial de desenvolvimento. A menos que a vida do produto seja interrompida, um produto existente evoluir para sua prxima gerao pela repetio da mesma sequncia de fases de concepo, elaborao, construo e transio. Isso a evoluo do sistema, de modo que os ciclos de desenvolvimento posteriores ao ciclo inicial so seus ciclos de evoluo. (BOOCH, RUMBAUGH e JACOBSON: 2000, p.445)

1.3. Os nove ciclos do processo unificado De acordo com Audy e Prikladnicki (2007), existem nove workflows no processo unificado, que representam uma diviso das atividades em grupos lgicos e esto detalhados a seguir: 1. Modelagem de negcio - tem por objetivo entender as estruturas, a dinmica e os problemas da organizao. Assim possvel definir quais necessidades do cliente o sistema dever suprir. Alguns documentos associados so os modelos de casos de uso, modelos de objeto do negcio, glossrio de negcio e documento de arquitetura de negcios; 2. Requisitos - definio de o que o sistema deve fazer e por qu. Assim os clientes permitem que os desenvolvedores tenham um melhor entendimento dos requisitos do sistema. So definidos ainda o escopo do sistema e as bases para estimativas de tempo e custo de desenvolvimento; 3. Anlise e projeto - tem como objetivo descrever a especificao de como implementar o projeto com base nos seus requisitos. Adicionalmente, visa definir uma arquitetura robusta para o sistema e adaptar o projeto para o ambiente de implementao; 4. Implementao - o desenvolvimento do software no ambiente de implementao definido. quando o cdigo organizado em forma de

19

subsistemas de implementao organizados em camadas; as classes e objetos em termos de componentes so implementadas; os componentes so testados como unidades e os resultados produzidos so integrados em um sistema executvel; 5. Teste - o seu objetivo garantir que os resultados obtidos so aqueles solicitados pelo cliente. necessrio verificar neste workflow as interaes e a integrao entre os componentes, alm de identificar possveis defeitos. Ao fim deste ciclo deve ser certificado que o sistema est pronto para uso; 6. Implantao quando o software disponibilizado para os usurios. So realizadas atividades de instalao, distribuio, treinamento de usurios e teste em seu ambiente final de operao; 7. Gerncia de configurao e alterao - visa o controle das modificaes e a manuteno da integridade dos artefatos do projeto. So realizadas atividades de identificao dos itens de configurao, restrio e auditoria das alteraes; 8. Gerncia de projeto - tem como objetivo descrever vrias estratgias para o trabalho com um processo iterativo. Alguns artefatos envolvidos so o plano de desenvolvimento de software, caso de negcio, plano de iterao, registro de revises e plano de garantia de qualidade; 9. Ambiente - tem como objetivo fornecer processos e ferramentas para aquisio, instalao e configurao de ferramentas, configurao e melhoria de processo, assim como servios tcnicos de suporte.

Com base no que foi exposto neste captulo possvel afirmar que a utilizao de uma metodologia como o Processo Unificado de suma importncia para o bom desempenho de qualquer projeto de software. Utilizar o Processo Unificado tem como meta assegurar que um sistema possua qualidade no seu desenvolvimento, que supra as necessidades de seus usurios e tenha uma agenda previsvel (AUDY e PRIKLADNICKI: 2007, p.22).

2.

SISTEMAS SIMILARES

De acordo com Pfleeger (2004), as pessoas devem ser capazes de avaliar os produtos e o modo como os produzem. Utilizando tcnicas de avaliao consegue-se medir os principais aspectos de produtos, processos e recursos, e utilizam-se essas informaes para determinar se esto satisfazendo os objetivos de produtividade, desempenho, qualidade e outros atributos desejveis. possvel classificar uma tcnica de avaliao em uma das quatro categorias a seguir: Anlise de caractersticas; Pesquisa de opinio; Estudo de caso; Experimento formal.

No presente trabalho foram realizadas anlises em trs sistemas similares. Esta anlise teve o intuito de verificar quais as principais caractersticas destes sistemas. Os sistemas analisados seguiram a tcnica de avaliao de anlise de caractersticas. Segundo Pfleeger (2004), esta tcnica utilizada para atribuir um valor e classificar os atributos de vrios produtos, podendo assim escolher qual ferramenta comprar ou que mtodo utilizar. O autor define alguns passos para realizar a anlise de caractersticas da ferramenta. Primeiramente relacionar os cinco atributos principais que se deseja que a ferramenta possua, em seguida, identifica-se trs ferramentas (sistemas) possveis que, aparentemente atendam aos objetivos e atribui-se valores aos critrios de cada uma delas, definido 1 (no satisfaz) at 5 (satisfaz completamente). Aps so examinadas as pontuaes, criando uma pontuao total com base na importncia de cada critrio, multiplica-se ento a importncia com o valor atribudo a cada critrio e somam-se os valores obtidos. Os cinco principais atributos definidos neste trabalho foram identificados atravs de entrevistas com o gestor e mdico da clnica de quiropraxia Dr. Everett Langhans e so: Boa interface com o usurio / Simplicidade; Gesto Financeira; Servios de implantao, treinamentos e suporte; Integrao entre os mdulos; Plataforma Web.

21

Os trs sistemas identificados como similares ao que est sendo proposto so: MDMed - http://www.mdmed.com.br; Gerclim Web - http://www.gerclim.com.br; ProDoctor - http://www.prodoctor.net;

Foi feito um levantamento de informaes de cada um destes softwares atravs de pesquisa de dados secundrios, no site das empresas desenvolvedoras e em fruns de usurios dos mesmos. Os resultados obtidos neste levantamento esto detalhados a seguir.

2.1. O sistema MDMed O primeiro software similar analisado foi o MDMed, desenvolvido por uma empresa localizada no estado de Santa Catarina e que possui distribuidores em outros estados do Brasil. O software comeou a ser comercializado em 1998 e por isso a empresa parece possuir boa experincia de mercado e seu aplicativo suporta diversas necessidades dos clientes em potencial. A interface do sistema MDMed possui vrias imagens e opes de ajuda e busca, facilitando assim o entendimento do usurio quanto s funcionalidades do sistema. No entanto, no um sistema muito simples de se utilizar, j que no customizvel segundo as necessidades de cada cliente e, por isso, acaba tendo muitas opes de funcionalidades. Dentre estas funcionalidades, diversas acabam no sendo utilizadas por alguns clientes, o que torna a utilizao um pouco confusa. Alm disto, algumas telas e relatrios possuem muitas informaes, dificultando a busca pela informao exata que o usurio necessita. Outro ponto muito importante a salientar, que o sistema MDMed no possui uma gesto financeira satisfatria, segundo anlise feita junto a clnica de quiropraxia. Existe uma parte do sistema que atende o faturamento da clnica que o utiliza, mas tal faturamento muito voltado aos convnios mdicos e acaba pecando na gesto eficiente da clnica. Na sua regio de atuao a empresa oferece servios de implementao, treinamento de usurios e suporte. Cada um destes servios vendido separadamente licena de uso e os usurios realmente podem optar por no comprar tais servios, j que a empresa oferece junto com as licenas, manuais e tutoriais explicando os passos para que os prprios usurios faam a instalao e se eduquem quanto utilizao de cada um dos mdulos. Os mdulos do sistema parecem estar razoavelmente integrados entre si. No h opo de rodar este sistema atravs de uma plataforma web, necessrio que o usurio instale

22

e rode o programa em cada um dos computadores. possvel, no entanto, fazer algumas transferncias de dados via internet. A figura 2.1 demonstra a tela de cadastro de pacientes. O intuito de expor esta tela demonstrar a interface amigvel e tambm a variedade de campos disponveis.

Figura 2.1 - MDMed - Tela de Cadastro de Pacientes Fonte: http://www.mdmed.com.br

Na figura 2.2 possvel visualizar a tela de agenda, que est sendo exposta com o objetivo de demonstrar a falta de simplicidade do sistema. Tambm visvel a impossibilidade de visualizar mais de um mdico ao mesmo tempo na agenda.

23

Figura 2.2 - MDMed - Tela de Agenda Fonte: http://www.mdmed.com.br

A partir da figura 2.3, identifica-se a falta de padronizao no armazenamento dos dados da ficha mdica do paciente, o que pode ocasionar em redundncia de informaes, bem como, na dificuldade de pesquis-las.

24

Figura 2.3 - MDMed - Tela de Ficha Mdica Fonte: http://www.mdmed.com.br

A partir das imagens do sistema MDMed e da anlise do mesmo pode-se visualizar na seo 2.4 a tcnica de anlise de caractersticas comparando o MDMed com os demais sistemas avaliados.

2.2. O sistema Gerclim O segundo sistema similar verificado foi o Gerclim. Este sistema foi desenvolvido pela empresa MedSystem, de Minas Gerais que foi introduzido no mercado em 1983. O sistema foi desenvolvido utilizando a linguagem de programao C++ e usa banco de dados Microsoft SQL Server.

25

Segundo o mdico da clnica de quiropraxia, Dr. Everett Langhans, o Gerclim tem uma interface agradvel, porm no muito auto-explicativa. A empresa no oferece servio de adaptao do software segundo as solicitaes de cada cliente. Isso diminui a simplicidade de uso do sistema, uma vez que existem funes que esto disponveis mas no so usadas pelo cliente. No entanto, algo que ameniza um pouco este aspecto que o menu do sistema ajusta as opes de funes da esquerda para a direita segundo a frequncia de demanda de cada uma destas funes. Alm da falta de adaptao do sistema segundo as necessidades do cliente, outro fator onde o sistema peca na gesto financeira da clnica. A utilizao de um controle financeiro que no especfico do sistema, acaba no atendendo as necessidades especficas das clnicas que o utilizam e ocasiona uma m gesto ou a no utilizao da ferramenta. A implantao do software deve ser feita pelo prprio usurio, assim como o upgrade para novas verses. A empresa oferece servios de treinamento de usurios que pode ser feito remota ou presencialmente. Atravs do site ou de um nmero de telefone, oferecido suporte ao sistema durante 24 horas por dia / 7 dias por semana. A MedSystem possui um banco de sugestes em seu web site que analisa para desenvolver novas verses do sistema, que so disponibilizadas aos clientes que esto sob manuteno. O Gerclim oferece ainda o servio de aluguel de Data Center, para que os usurios possam armazenar backups, fazer backups remotos e banco de dados de clientes. As funes do sistema so bem integradas, sendo que uma atualizao implica na atualizao automtica das funes a ela relacionadas. Assim como o MDMed, o Gerclim roda localmente e possui conectividade web, no entanto o usurio no tem a opo de rodar este sistema pela internet. Assim como acontece com o sistema MDMed, o Gerclim possui uma interface amigvel, a tela de cadastro de pacientes demonstra esta situao (figura 2.4).

26

Figura 2.4 - Gerclim - Tela de Cadastro de Pacientes Fonte: http://www.gerclim.com.br

A figura 2.5 demonstra a tela de agenda do sistema Gerclim. possvel identificar o mesmo problema que ocorre no sistema MDMed, a impossibilidade de visualizar a agenda de dois mdicos de forma simultnea.

27

Figura 2.5 - Gerclim - Tela de Agenda Fonte: http://www.gerclim.com.br

A figura 2.6 apresenta a ficha mdica do paciente e parece mais completa e organizada que a do sistema MDMed. No entanto, ela acaba sendo complicada pelo grande nmero de janelas que so necessrias abrir.

28

Figura 2.6 - Gerclim - Tela de Ficha Mdica Fonte: http://www.gerclim.com.br

Seguindo a mesma lgica do sistema MDMed, o sistema Gerclim tambm foi avaliado e comparado com os outros sistemas utilizando a tcnica de anlise de caractersticas proposta por Pfleeger (2004).

2.3. O sistema ProDoctor Finalmente, foi feita uma anlise do terceiro software similar, o ProDoctor. Este software foi lanado no mercado em 1993 e possui hoje cerca de 40 mil usurios. De acordo com o Dr. Everett Langhans da clnica de Quiropraxia, o sistema possui uma interface amigvel e bastante clara, porm peca em sua simplicidade, mesmo sendo desenvolvido na plataforma Microsoft. O processo de vendas realizado atravs do website ou por telefone. A implantao deve ser feita pelo prprio usurio e, para receber treinamentos e suporte, o cliente deve pagar um valor adicional. Alm do valor das licenas. Os servios so oferecidos de maneira remota o que, por um lado, positivo para a empresa porque facilita seu alcance geogrfico mas, por

29

outro, priva os clientes de terem um atendimento presencial, dificultando a interatividade, a construo de relacionamento e impactando negativamente nos resultados do servio. Os mdulos do sistema parecem estar bem integrados entre si. No h opo de rodar este sistema atravs de uma plataforma web, necessrio que o usurio instale e rode o programa em cada um dos computadores. O mdulo financeiro do ProDoctor organizado e atende s necessidades das clnicas mdicas, porm, os inmeros campos desnecessrios para a maioria das clnicas de pequeno porte acabam confundindo os usurios na utilizao de seus recursos. Assim como os outros sistemas similares, o ProDoctor possui uma interface amigvel e simples, mas acaba pecando da mesma forma que o MDMed: sua interface possui campos desnecessrios que acabam no sendo utilizados pelos clientes. A tela de cadastro de pacientes ajuda a demonstrar esta situao (figura 2.7).

Figura 2.7 - ProDoctor - Tela de Cadastro de Pacientes Fonte: http://www.prodoctor.net

30

A figura 2.8 demonstra a tela de agenda do sistema ProDoctor, e assim como acontece nas telas de agendas dos outros sistemas, tambm no possvel visualizar a agenda de dois mdicos de forma simultnea.

Figura 2.8 - ProDoctor - Tela de Agenda Fonte: http://www.prodoctor.net

Diferente das telas de Ficha Mdica dos outros sistemas analisados, a Ficha Mdica do ProDoctor (figura 2.9) possui uma organizao e eficincia superior, devido aos seus modelos de fichas que so parametrizveis.

31

Figura 2.9 - ProDoctor - Tela de Ficha Mdica Fonte: http://www.prodoctor.net

Seguindo o exemplo dos outros sistemas avaliados, o ProDoctor tambm foi avaliado seguindo a tcnica proposta por Pfleeger (2004).

2.4. Anlise de caractersticas dos sistemas similares Com a anlise dos sistemas similares possvel montar uma tabela comparativa entre estes sistemas, identificar os aspectos positivos e negativos de cada um e descrever sobre o porqu de criar este novo sistema, tendo em vista que existem tantos no mercado. A tabela 2.1 faz parte da tcnica de avaliao de anlise de caractersticas proposta por Pfleeger (2004). Ela demonstra os aspectos positivos e negativos dos sistemas avaliados segundo os principais atributos j definidos.

32

Tabela 2.1 Anlise de Caractersticas

Atributos Boa Interface com o usurio / Simplicidade Gesto Financeira Servios de implementao, Treinamento e suporte Integrao entre os mdulos Plataforma Web Pontuao Sistema 1: MDMed 4 2 5 3 2 74 Sistema 2: Gerclim 3 2 4 4 2 70 Sistema 3: ProDoctor 4 3 3 3 1 65 Importncia 4 5 5 5 4

Fonte: PFLEEGER, 2004, p.416

Com base na anlise das caractersticas demonstradas na tabela 2.1 possvel identificar a carncia de um sistema que consiga atender as necessidades das clnicas mdicas de pequeno porte. A proposta deste trabalho oferecer para estas empresas um sistema que atenda s suas necessidades especficas, no apenas de controle, mas tambm que gere informaes com base nestes dados permitindo a tomada de decises estratgicas por parte dos gestores, uma gesto financeira eficiente e que possua uma interface simples e ao mesmo tempo suficiente, conseguindo assim atender com maior qualidade os usurios do sistema. Por fim, outro aspecto muito importante para o sistema , atender os usurios da forma mais clara possvel, sem a necessidade deles terem que atualizar o sistema ou ainda instalar este sistema.

3.

TECNOLOGIAS

O objetivo deste captulo apresentar as tecnologias envolvidas neste projeto. Buscase caracterizar a linguagem de programao Java, sendo que esta ser a linguagem utilizada no desenvolvimento do Sistema de Gesto Mdica (SGM), bem como buscar uma viso geral dos frameworks Java Server Faces (JSF), Java Persistence API (JPA) e Enterprise Java Beans (EJB). Ao fim, sero trazidas informaes sobre padres de projetos, dando-se um foco especial em Model-View-Controller (MVC) e Data Access Object (DAO).

3.1. Linguagem Java Java foi criada pela Sun Microsystems, sendo inicialmente destinada a dispositivos eletrnicos. No entanto, somente obteve sucesso quando passou a ser utilizada para a internet, j que sua caracterstica multiplataforma possibilita a incluso de aplicaes diretamente na pgina de internet, independente do sistema utilizado pelo usurio. O processo utilizado na programao em Java consiste em digitar o cdigo, compilar, executar e depurar quando necessrio. (THOMPSON, 2005, p.21). Thompson (2005) considera que as principais caractersticas desta linguagem so: Abstrao: a orientao a objetos to forte que permite que os desenvolvedores possam trabalhar apenas com uma parte do projeto, sem conhec-lo em sua plenitude, e obter os resultados esperados;
Abstrao a capacidade de olhar apenas uma parte de um todo, ou seja, retirar da realidade apenas as entidades e fenmenos considerados essenciais, excluindo todos os aspectos irrelevantes ou secundrios. Pelo mecanismo de abstrao, o ser humano pode entender formas complexas ao dividi-las em partes e analisar cada parte separadamente. (Thompson, 2005, p. 20)

Encapsulamento: as classes e mtodos em Java podem ser criados de maneira a no ficarem visveis s classes com as quais no haja interesse de compartilhamento de dados;

Herana: uma classe j criada ir criar outras classes com as mesmas caractersticas, porm com atributos distintos; Polimorfismo: a capacidade de dois objetos, de classes distintas, implementarem o mesmo mtodo. Isso pode acontecer por herana ou por interface;
Como programador, voc desejar uma linguagem com uma sintaxe agradvel, e semntica compreensvel (ou seja, no C++). Java se encaixa neste perfil, como

34

dzias de outras boas linguagens. Algumas linguagens lhe fornecem portabilidade, coleta de lixo, e coisas do tipo, mas elas no possuem muitas opes de bibliotecas, forando voc a se virar para programar sozinho caso queira grficos bonitos ou acesos a redes ou banco de dados. Bom, Java tem tudo, uma boa linguagem, um ambiente de execuo de alta qualidade e uma vasta biblioteca. Essa combinao o que torna Java uma proposta irresistvel para tantos programadores. (HORSTMANN e COMELL, 2005, p. 01)

Horstmann e Cornell (2005), mencionam que Java obteve tanto sucesso por ser uma linguagem simples, orientada a objetos, distribuda, robusta, segura, neutra em relao arquitetura, portvel, interpretada, de alto desempenho e dinmica. 3.2. JSF Java Server Faces JSF (Java Server Faces) pode ser definido como um framework para a criao de componentes de interface de usurio para solues baseadas na web. Ela pode ser utilizada sozinha ou em conjunto com outras tecnologias que tem objetivos similares e/ou complementares, como por exemplo, o Struts. Os recursos da JSF so a manipulao de eventos, a validao de inputs de usurios, especificao de navegao de pginas, tratamento de excees, suporte internacionalizao e conjunto padro de componentes grficos (FRANKLINT, 2006, p.128). Jacobi e Fallows (2006) definem o JSF como um framework de interface de usurio para aplicaes web J2EE que, uma vez adotado, permite que as organizaes migrem de tecnologias ultrapassadas para plataformas e tecnologias em um padro mais atualizado. Os autores afirmam que, nos ltimo 15 anos, a indstria de software tem visto muitas tecnologias e plataformas nascerem e morrerem. Geralmente o uso de uma determinada tecnologia decai por diversas razes, sendo que uma razo muito comum que as tecnologias so desenvolvidas e mantidas por uma nica empresa, forando os usurios a depender do suporte dos criadores daquela tecnologia. Sempre que o criador decide deixar de usar uma determinada tecnologia em prol de uma soluo mais avanada, o usurio fica com uma plataforma sem suporte. O JSF permite que as organizaes e consumidores passem para as tecnologias mais recentes assim que elas emergem, com um impacto mnimo nas aplicaes JSF j existentes. 3.3. EJB Enterprise Java Beans O EJB (Enterprise Java Beans) um componente servidor que roda em um container EJB do servidor de aplicao. Seu objetivo o desenvolvimento rpido e

35

simplificado de aplicaes Java, com base em componentes, distribudas, transacionais, seguras e portteis. Em definio, um framework que permite que os desenvolvedores construam aplicaes sem ter que reinventar servios como transaes e segurana, podendo assim focarem-se na lgica de negcio sem ter que investir tempo na construo de cdigo de infra-estrutura. (PANDA, RAHMAN, LANE, 2007, p.5). 3.4. JPA Java Persistence API O JPA (Java Persistence API) permite padronizar o mapeamento de objeto relacional na plataforma Java. O JPA foi definido na verso Enterprise Java Beans, version 3.0. Antes disso existia apenas uma forma bem mais complexa para mapear objetos em um banco de dados, que exigia um container EJB. (GONALVES, 2007, p.543). Biswas e Ort (2006) afirmam que a adio do Java Persistence API a maior melhoria do EJB 3.0 em relao sua verso anterior, a EJB 2.1. A nova verso mais fcil de se aprender e utilizar e deve resultar no desenvolvimento mais rpido de aplicaes. Os autores destacam como alguns dos principais benefcios do JPA o fato de que requer menor quantidade de classes e interfaces; traz as especificaes mais tpicas atravs de notas padro; permite o mapeamento de objetos relacionados de forma mais clara, fcil e padronizada; elimina a necessidade de buscas por cdigos e facilita o teste de entidades fora do container EJB.

3.5. JDBC e SQL Por causa da pluralidade de banco de dados e de seus provedores de acesso, a Sun desenvolveu a JDBC (Java Data Base Connectivity), uma API que tem por objetivo fazer a interface entre a camada do cliente, o driver do fabricante a fonte dos dados. Em outras palavras, uma ponte entre a linguagem Java e outra linguagem que todos os bancos de dados suportem. A linguagem escolhida foi o SQL, desta forma os fabricantes de bancos de dados fornecem os drivers para SQL e a JDBC cria a API de chamada genrica destes drivers (FRANKLINT, 2006, p.43). O SQL (Structured Query Language), ou linguagem de consulta estruturada, utilizada para estabelecer comunicao com o banco de dados. Thompson (2005) enfatiza que SQL se trata de uma linguagem embutida em outra linguagem, que d suporte a SQL. Os servidores SQL como, por exemplo, o da Oracle, MySQL ou MS SQL Server, possibilitam o uso de linguagem SQL em toda sua plenitude.

36

A sua facilidade de uso e simplicidade fizeram da linguagem SQL um padro de banco de dados. Ao contrrio de outras linguagens de consulta a bancos de dados, o SQL determina a forma do resultado e no o caminho para chegar a ele. Adicionalmente, enquanto a maioria das demais linguagens so procedurais, a SQL declarativa. (DATE, 2004, p.71).

3.6. Padres de projetos: MVC e DAO Segundo Gonalves (2007), as estruturas Model View Controller (MVC) e Data Access Object (DAO) so conceitos arquitetnicos muito importantes para o desenvolvimento de aplicaes web escritas em Java. Alm destes dois, existem ainda vrios outros conceitos englobando o desenvolvimento em Java, conhecidos como Design Patterns. O MVC um paradigma que tem por objetivo separar uma aplicao em trs partes distintas, sendo elas: Model: esta parte est relacionada ao trabalho atual que a aplicao administra, nela esto representados os dados do programa. O modelo no tem conhecimento especfico dos controlados e das apresentaes, pois so as classes que trabalham no armazenamento e busca de dados; View: a parte das apresentaes est relacionada a exibir os dados e informaes da aplicao, ou seja, o responsvel pela apresentao visual dos dados disponibilizados pelo Model; Controller: o controlador responsvel por coordenar os dois itens anteriores, exibindo a interface correta ou executando trabalhos que a aplicao precisa completar. Este o objeto que responde s ordens executadas pelo usurio, atuando sobre os dados apresentados pelo modelo, decidindo qual apresentao dever ser exibida.
A separao lgica da aplicao nestas partes assegura que a camada modelo no sabe nada praticamente do que exibido; restringido por apresentar as partes de componentes do problema que resolvido pela aplicao. Igualmente, a camada de apresentao s est relacionada a exibir os dados e no com implementar lgica de negcios que controlada pela camada modelo. O controlador, como um gerenciador de trfego, dirige as apresentaes a serem exibidas e com as devidas mudanas de dados e recuperaes vindas da camada modelo (GONALVES, 2007, p. 387)

O padro DAO o mais utilizado para acesso a dados contidos em um banco de dados. Gonalves (2007) cita que colocar as instrues SQL em meio os scriptlets somados ao HTML em desenvolvimento de aplicaes usando JDBC, embora funcione, um mtodo

37

confuso e desordeiro. Foi pensando nisso que os desenvolvedores passaram a adotar o padro DAO. O padro DAO fornece uma interface independente, que pode ser usada para persistir objetos de dados. A ideia colocar todas as funcionalidades encontradas no desenvolvimento de acesso e trabalho com dados em um s local, tornando simples sua manuteno (GONALVES, 2007, p. 400). Geralmente, o DAO abrange mtodos para inserir, selecionar, atualizar e excluir objetos de um banco de dados. Dependendo de como o padro DAO implementado, possvel ter um DAO para cada classe de objetos ou ter um nico DAO que responsvel por todos os objetos. A utilizao do Java como linguagem de programao, juntamente com seus frameworks e os padres de projeto MVC e DAO, facilitaro e tornaro mais gil o desenvolvimento do sistema. Com isso, encerra-se o captulo sobre as tecnologias envolvidas e parte-se para a anlise de requisitos.

4.

ANLISE E PROJETO

Para a identificao das necessidades especficas das clnicas mdicas de pequeno porte, foram feitas entrevistas com o gestor e mdico da clnica de quiropraxia Dr. Everett Langhans, localizada na rua Almirante Barroso, 66, no centro de Novo Hamburgo - RS. Tambm foram analisados os sistemas similares objetivando buscar as melhores prticas efetuadas por cada um. A experincia do autor outro fator importante no levantamento, anlise dos requisitos e projeto, tendo em vista que o mesmo j trabalhou em diversos projetos na rea da sade e tambm com sistemas de gesto de empresas. As entrevistas feitas com o gestor da clnica foram realizadas no decorrer do ano de 2010 e tiveram como objetivo levantar as necessidades de gesto da informao desta clnica, que representa os clientes em potencial para o software que este estudo se prope a projetar. As informaes coletadas nestas entrevistas e na anlise dos sistemas similares esto detalhadas neste captulo e foram estruturadas nas seguintes partes: I. II. III. IV. V. VI. VII. Requisitos Funcionais (RF); Requisitos No Funcionais (RNF); Casos de Uso; Matriz de Rastreabilidade; Diagramas de Casos de Uso; Diagrama de Classes; e Detalhamento dos Casos de Uso.

4.1. Requisitos Funcionais Segundo Pfleeger (2004), requisitos funcionais descrevem uma interao entre o sistema e o seu ambiente, como o sistema deve agir considerando uma determinada ao. Esta seo apresenta os requisitos funcionais previstos para o sistema proposto.

Tabela 4.1 - Requisitos Funcionais ID Requisitos Funcionais Segurana e Controle de Acessos RF001 Descrio: O sistema dever possuir um controle de acesso com nveis diferentes de permisses para cada tipo de usurio. RF002 Cadastros de Usurios, Perfis e Acessos

39

ID

Requisitos Funcionais Descrio: O sistema dever possuir cadastro de usurios, perfis de usurios e os diferentes acessos que estes possuem. Cadastros de Pacientes e Responsveis

RF003

Descrio: O sistema dever possuir cadastro de pacientes e de responsveis. Cadastros de Clnicas

RF004

Descrio: O sistema dever possuir cadastro de clnicas e seus horrios de atendimento. Cadastro de Funcionrios e Mdicos

RF005

Descrio: O sistema dever possuir cadastro de funcionrios, mdicos, as funes destes funcionrios e as especialidades destes mdicos. Cadastros gerais

RF006

Descrio: O sistema dever possuir cadastros gerais tais como cidade, estado, pas, sexo, profisso, estado civil, etc.. Agendas Mdicas

RF007

Descrio: O sistema dever possuir uma agenda por mdico para cada clnica e deve ser possvel definir os horrios de atendimento dos mdicos. Atendimentos Descrio: O sistema dever possuir apenas um atendimento por horrio,

RF008

cada atendimento deve possuir um tipo de consulta (Ex.: Reconsulta), estar ligado a um paciente e a um mdico. Tratamentos e Diagnsticos

RF009

Descrio: O sistema dever possuir cadastro de tratamentos e diagnsticos que sero associados a um atendimento quando este necessitar. Procedimentos

RF010

Descrio: O sistema dever possuir cadastro procedimentos, seus tipos de procedimentos e preparos de procedimentos. Anamnese de Pacientes

RF011

Descrio: O sistema dever possuir uma anamnese do paciente que demonstre o histrico mdico (atendimentos) deste paciente. Cadastros de Fornecedores e Insumos

RF012

Descrio: O sistema dever possuir cadastro de fornecedores, insumos e tipos de insumos, bem como o histrico dos insumos.

40

ID

Requisitos Funcionais Controle de estoque Descrio: O sistema dever possuir controle de entrada e sada de insumos e suas quantidades mnimas. Cadastros Financeiros

RF013

RF014

Descrio: O sistema dever possuir cadastro das formas de pagamento, tipos de lanamento, tipos de documento e Centro de custos. Fluxo de Caixa Descrio: O sistema deve permitir o cadastro de mais de um caixa para

RF015

cada clnica, este caixa deve possuir registros de movimentaes do dia com a forma de pagamento, o tipo de lanamento e o centro de custos deste movimento. Contas a Pagar e Contas a Receber Descrio: O sistema dever possuir um controle de contas a pagar e contas

RF016

a receber, os tipos de documentos destas contas e o centro de custos para o qual esta conta se destina.

4.2. Requisitos no funcionais Os requisitos no funcionais descrevem uma restrio que deve ser atendida, limitando as opes para que se possa criar uma soluo para o problema (PFLEEGER, 2004, p.115). Esta seo apresenta os requisitos no funcionais previstos para o sistema proposto.

Tabela 4.2 - Requisitos No Funcionais ID Requisitos No Funcionais Navegadores Descrio: Os navegadores utilizados podem ser o Mozilla Firefox 3.0 ou RNF001 superior, Google Chrome 6.0 ou superior e o Safari 5.0 ou superior, visto que atendem ao padro estabelecido pela W3C. Desenvolvimento Descrio: O sistema dever ser desenvolvido utilizando a tecnologia Java RNF002 Enterprise Edition 6.0 (Java EE) ou superior, bem como os frameworks Java Server Faces (JSF), Enterprise Java Beans (EJB) e Java Persistence API

41

ID (JPA).

Requisitos No Funcionais

Servidor de Aplicao RNF003 Descrio: O servidor de aplicao que deve ser utilizado o Glassfish 3 ou superior. Banco de Dados RNF004 Descrio: O banco de dados utilizado dever ser o MySQL 5.0 ou superior. Agilidade RNF005 Descrio: O sistema dever possuir um tempo de resposta (para consultas) inferior a 4 segundos. Auditoria RNF006 Descrio: Todo o sistema dever possuir controle de auditoria, bem como um espelho dos registros alterados e excludos nos ltimos 30 dias.

4.3. Casos de Uso Pfleeger (2004) diz que casos de uso descrevem as funcionalidades especficas que um sistema deve desempenhar. Cada caso de uso descreve um possvel cenrio de interao que um sistema externo ou outra entidade tem com o sistema a ser desenvolvido. Os casos de uso que foram identificados como necessrios para o sistema esto descritos nas sees a seguir, divididos de acordo com os mdulos correspondentes.

4.3.1.

Mdulo de Segurana O mdulo de segurana engloba os casos de uso responsveis pela segurana, nveis

de acessos e permisses do sistema. A tabela 4.3 apresenta os casos de uso deste mdulo.

Tabela 4.3 - Casos de Uso - Mdulo de Segurana ID Casos de Uso - Mdulo de Segurana Acesso Descrio: Tm a responsabilidade de liberar o acesso s telas do sistema UC001 para um determinado perfil de usurios. Cada acesso possui as aes permitidas para uma tela. UC002 Perfil

42

ID

Casos de Uso - Mdulo de Segurana Descrio: Sua responsabilidade separar em grupos os diferentes tipos de usurios do sistema. Tela

UC003

Descrio: responsvel pelas telas do sistema ao qual um determinado usurio pode possuir acesso. Usurio

UC004

Descrio: o mtodo de identificao individual das pessoas que utilizaro o sistema. Alterar Senha

UC005

Descrio: o responsvel por alterar as senhas dos usurios do sistema. Cada usurio poder alterar somente a sua senha, independente do seu perfil.

4.3.2.

Mdulo de Cadastros O mdulo de cadastros engloba os casos de uso responsveis pelos cadastros gerais

do sistema. A tabela 4.4 apresenta os casos de uso deste mdulo.

Tabela 4.4 - Casos de Uso - Mdulo de Cadastros ID UC006 Casos de Uso - Mdulo de Cadastros Cidade Descrio: Mantm o cadastro de cidades do sistema. Clnica UC007 Descrio: Mantm o cadastro de clnicas do sistema. Especialidade Mdica UC008 Descrio: Mantm o cadastro de especialidades mdicas do sistema. Estado Civil UC009 Descrio: Mantm o cadastro de estado civil do sistema. Funo de Funcionrio UC010 Descrio: Mantm o cadastro de funes de funcionrios do sistema. Funcionrio UC011 UC046 Descrio: Mantm o cadastro de funcionrios do sistema. Mdico

43

ID

Casos de Uso - Mdulo de Cadastros Descrio: Mantm o cadastro de mdicos do sistema. Horrios de Clnica

UC012

Descrio: Mantm o cadastro de horrios de atendimento das clnicas do sistema. Paciente

UC013

Descrio: Mantm o cadastro de pacientes do sistema. Pas

UC014

Descrio: Mantm o cadastro de pases do sistema. Profisso

UC015

Descrio: Mantm o cadastro de profisses do sistema. Responsvel

UC016

Descrio: Mantm o cadastro de responsveis do sistema. Sexo

UC017

Descrio: Mantm o cadastro de sexos do sistema. Tipo Conselho Regional

UC018

Descrio: Mantm o cadastro de tipos de conselho regional do sistema. Tipo Cor

UC019

Descrio: Mantm o cadastro de cores, para identificao de mdicos do sistema e de identificao de consultas na agenda. Tipo Logradouro

UC020

Descrio: Mantm o cadastro de tipos de logradouros do sistema. Estado (UF)

UC021

Descrio: Mantm o cadastro de estados do sistema.

4.3.3.

Mdulo de Agenda O mdulo de agenda engloba os casos de uso responsveis pelas agendas de mdicos

do sistema. A tabela 4.5 apresenta os casos de uso deste mdulo.

Tabela 4.5 - Casos de Uso - Mdulo de Agenda ID UC022 Casos de Uso - Mdulo de Agenda Agenda

44

ID

Casos de Uso - Mdulo de Agenda Descrio: Tem como responsabilidade armazenar e marcar as consultas de pacientes para cada mdico de uma clnica. Horrios de Agenda

UC023

Descrio: So definidos aqui os horrios das agendas dos mdicos para cada clnica que este mdico atenda.

4.3.4.

Mdulo de Pronturio Segundo Freire, o pronturio eletrnico est cada vez mais reconhecido perante o

Conselho Federal de Medicina.

O Conselho Federal de Medicina tem adotado diversas resolues, que regulamentam, entre outras questes, o relacionamento mdico-paciente, o relacionamento dos mdicos com operadoras de planos de sade, participao de pacientes em pesquisas, divulgao de estudos cientficos e o pronturio mdico do paciente. (FREIRE, p.13)

O mdulo de pronturio engloba os casos de uso responsveis pelas informaes mdicas dos pacientes do sistema. A tabela 4.6 apresenta os casos de uso deste mdulo.

Tabela 4.6 - Casos de Uso - Mdulo de Pronturio ID Casos de Uso - Mdulo de Pronturio Anamnese Descrio: Tem como responsabilidade armazenar o histrico dos UC024 atendimentos dos pacientes, bem como outras informaes mdicas de carter especfico. Atendimento Descrio: Tem como responsabilidade armazenar as informaes da UC025 consulta que o paciente realizou em um determinado dia. Aqui tambm so armazenadas as informaes dos procedimentos realizados e diagnsticos e tratamentos identificados pelo mdico. Diagnstico UC026 Descrio: Mantm o cadastro de diagnsticos do sistema. Preparos de Procedimentos UC027 Descrio: Mantm o cadastro de preparos de procedimentos do sistema. dos

45

ID UC028

Casos de Uso - Mdulo de Pronturio Procedimento Descrio: Mantm o cadastro de procedimentos do sistema. Tipo de Consulta

UC029

Descrio: Mantm o cadastro de tipos de consultas do sistema. Tipo de Procedimento

UC030

Descrio: Mantm o cadastro de tipos de procedimentos do sistema. Tratamento

UC031

Descrio: Mantm o cadastro de tratamentos do sistema.

4.3.5.

Mdulo de Estoque O mdulo de estoque engloba os casos de uso responsveis pelas informaes de

estoque de insumos do sistema. A tabela 4.7 apresenta os casos de uso deste mdulo.

Tabela 4.7 - Casos de Uso - Mdulo de Estoque ID UC032 Casos de Uso - Mdulo de Estoque Fornecedor Descrio: Mantm o cadastro de fornecedores do sistema. Histrico de Insumos UC033 Descrio: Mantm as informaes de todas as alteraes em um determinado insumo. Insumo UC034 Descrio: Mantm o cadastro de insumos do sistema. Lanamento de Insumo UC035 Descrio: Mantm o cadastro de lanamentos de insumos no estoque do sistema. Tipos de Insumo UC036 Descrio: Mantm o cadastro de tipos de insumo do sistema. Tipos de Lanamento de Insumo UC037 Descrio: Mantm o cadastro de tipos de lanamentos de insumos do sistema. UC038 Unidades de Insumos

46

ID

Casos de Uso - Mdulo de Estoque Descrio: Mantm o cadastro de unidades de insumos do sistema.

4.3.6.

Mdulo Financeiro O mdulo financeiro engloba os casos de uso responsveis pelas informaes

financeiras do sistema. A tabela 4.8 apresenta os casos de uso deste mdulo.

Tabela 4.8 - Casos de Uso - Mdulo Financeiro ID Casos de Uso - Mdulo Financeiro Fluxo de Caixa UC039 Descrio: Tela responsvel por todos os movimentos financeiros de um caixa de uma clnica. Contas a Pagar e Contas a Receber UC040 Descrio: Responsvel por todos os movimentos financeiros futuros de uma clnica, independente se for um lanamento de receita ou despesa. Pagamento de Consultas Descrio: Responsvel por realizar o pagamento de uma consulta e lanar UC041 no fluxo de caixa ou contas a receber. Deve ser possvel efetuar o pagamento parcelado das consultas atravs desta tela. Tipo de Documento UC042 Descrio: Mantm o cadastro de tipos de documentos do sistema. Tipo de Lanamento UC043 Descrio: Mantm o cadastro de tipos de lanamentos financeiros do sistema. Forma de Pagamento UC044 Descrio: Mantm o cadastro de formas de pagamentos do sistema. Centro de Custo UC045 Descrio: Mantm o cadastro de centro de custos do sistema.

47

4.4. Matriz de Rastreabilidade A matriz de rastreabilidade tem o intuito de demonstrar a relao entre os requisitos funcionais do sistema e os casos de uso que iro atender estes requisitos. A tabela 4.9 apresenta o mapeamento dos requisitos funcionais em relao aos casos de uso.

Tabela 4.9 - Matriz de Rastreabilidade

RF 001
UC001 UC002 UC003 UC004 UC005 UC006 UC007 UC008 UC009 UC010 UC011 UC012 UC013 UC014 UC015 UC016 UC017 UC018 UC019 UC020 UC021 UC022 UC023 UC024 UC025 UC026 UC027 UC028 UC029 UC030 UC031 X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

RF 002
X X X X X

RF 003

RF 004

RF 005

RF 006

RF 007

RF 008

RF 009

RF 010

RF 011

RF 012

RF 013

RF 014

RF 015

RF 016

48

RF 001
UC032 UC033 UC034 UC035 UC036 UC037 UC038 UC039 UC040 UC041 UC042 UC043 UC044 UC045 UC046

RF 002

RF 003

RF 004

RF 005

RF 006

RF 007

RF 008

RF 009

RF 010

RF 011

RF 012
X X X

RF 013

RF 014

RF 015

RF 016

X X X X X X X X X X X X X

4.5. Diagrama de Casos de Uso De acordo com Booch, Rumbaugh e Jacobson (2000), diagramas de casos de uso fazem parte dos diagramas disponveis na UML, e possuem papel central na modelagem de um sistema. Os diagramas de casos ajudam a visualizar, especificar e documentar o comportamento de elementos do sistema. Booch, Rumbaugh e Jacobson (2000) comentam que os diagramas de casos de uso costumam possuir os seguintes contedos: Casos de uso; Atores; e Relacionamentos de dependncia, generalizao e associao.

Na seo 4.3 foi apresentada a relao de casos de uso do sistema e na seo anterior (seo 4.4) foi realizado um mapeamento de rastreabilidade entre os requisitos funcionais e os casos de uso. Neste momento sero demonstrados os atores que afetam estes casos de uso. Todos os atores foram definidos seguindo um perfil de acessos e permisses ao sistema. Eles foram divididos em: Administrador: o ator com o perfil mais completo. Possui acesso a todos os recursos do sistema;

49

Administrativo: o ator com perfil especfico para acessar recursos com informaes administrativas e financeiras mais completas; Mdico: o ator com perfil para acessar os recursos com informaes tcnicas sobre os pacientes; Secretria: o ator com o perfil para controlar as agendas dos mdicos, cadastros gerais do sistema e algumas informaes financeiras mais superficiais. Para evitar a poluio visual, o ator Administrador s aparece nos casos de uso

onde s ele possua perfil de acesso. Nas sees seguintes so demonstrados os diagramas de casos de uso divididos em mdulos, seguindo a mesma diviso j utilizada na seo 4.3.

4.5.1.

Segurana A figura 4.1 apresenta o diagrama de caso de uso do mdulo de segurana.

50

uc Seguranca

UC001 Acessos

UC002 Perfis

Secretria

UC005 Aterar Senha

Administrador

UC003 Telas Mdico

UC004 Usurios

Figura 4.1 - Diagrama de Caso de Uso do Mdulo de Segurana 4.5.2. Cadastros A figura 4.2 apresenta o diagrama de casos de uso do mdulo de cadastros na viso do ator secretria.

uc Cadastros-Secretaria

UC006 Cidades

UC014 Pases

UC021 Estado (UF) Secretria

UC013 Pacientes

extend

Pessoa

extend UC015 Profisses UC016 Responsv eis

Figura 4.2 - Diagrama de Caso de Uso do Mdulo de Cadastro Viso da Secretria

51

A figura 4.3 apresenta o diagrama de casos de uso do mdulo de cadastros na viso do ator mdico.

uc Cadastros-Mdico

UC006 Cidades

UC014 Pases

UC021 Estado (UF) Mdico

UC013 Pacientes

extend

Pessoa

extend UC016 Responsv eis

Figura 4.3 - Diagrama de Caso de Uso do Mdulo de Cadastro Viso do Mdico A figura 4.4 apresenta o diagrama de casos de uso do mdulo de cadastros na viso do ator administrativo.

uc Cadastros-Administrativ o

UC006 Cidades

UC014 Pases

UC021 Estado (UF)

UC013 Pacientes

extend

Pessoa

extend UC046 Mdicos UC016 Responsv eis

extend

UC008 Especialidades Mdicas

UC011 Funcionrios

UC009 Estado Civ il Administrativ o

UC018 Tipo Conselho Regional

UC010 Funes de Funcionrios

UC019 Tipo Cor

UC017 Sexo

UC020 Tipo Logradouro

UC012 Horrios de Clinicas

UC015 Profisses

UC007 Clinicas

Figura 4.4 - Diagrama de Caso de Uso do Mdulo de Cadastro Viso do Administrativo

52

4.5.3.

Agenda A figura 4.5 apresenta o diagrama de casos de uso do mdulo de agenda.

uc Agenda

UC022 Agendas

Secretria

UC023 Horrios de Agendas

Mdico

Figura 4.5 - Diagrama de Caso de Uso do Mdulo de Agenda 4.5.4. Pronturio A figura 4.6 apresenta o diagrama de casos de uso do mdulo de pronturio.

uc Prontuario

UC024 Anamneses

UC028 Procedimentos

UC025 Atendimentos

UC029 Tipo de Consultas Secretria

UC026 Diagnsticos

Mdico

UC030 Tipos de Procedimentos

UC027 Preparos de Procedimento

UC031 Tratamentos

Figura 4.6 - Diagrama de Caso de Uso de Pronturio

53

4.5.5.

Estoque A figura 4.7 apresenta o diagrama de casos de uso do mdulo de estoque.

uc Estoque

UC032 Fornecedores

UC036 Tipos de Insumos

UC033 Histrico de Insumos

UC037 Tipos de Lanamentos de Insumos

Secretria

UC034 Insumos

Administrativ o

UC038 Unidades de Insumos

UC035 Lanamentos de Insumos

Figura 4.7 - Diagrama de Caso de Uso de Estoque 4.5.6. Financeiro A figura 4.8 apresenta o diagrama de casos de uso do mdulo financeiro.

uc Financeiro

UC040 Contas a Pagar e a Receber UC039 Fluxo de Caixa

UC043 Tipo de Lanamento Secretria UC041 Pagamento de Consultas Administrativ o UC044 Forma de Pagamento

UC042 Tipo de Documento UC045 Centro de Custos

54

Figura 4.8 - Diagrama de Caso de Uso Financeiro 4.6. Diagrama de Classes Booch, Rumbaugh e Jacobson (2000), dizem que os diagramas de classes so os diagramas mais usados nas modelagens de sistemas orientados a objetos, eles demonstram a viso esttica do projeto do sistema.
Os diagramas de classes so importantes no s para a visualizao, a especificao e a documentao de modelos estruturais, mas tambm para a construo de sistemas executveis por intermdio de engenharia de produo e reversa. (BOOCH, RUMBAUGH, JACOBSON, 2000, p. 104)

Todos os diagramas de classes exemplificados no decorrer da seo 4.6 possuem herana da classe Bean. Esta classe a representao de um conjunto de atributos que todas as classes do sistema devem possuir. Alm disso, a classe Bean possui uma interface chamada IBean, que garante que a classe Bean ter que implementar os mtodos necessrios para as outras classes dos sistema. Na figura 4.9 possvel visualizar esta classe e esta interface que so referncia para todas as outras classes do sistema.

class bean interface IBean + + + getId() : Long getNome() : String isPersistente() : boolean

Bean # # id: Long nome: String

Figura 4.9 - Diagrama das Classes Comuns Nas sees seguintes so demonstrados os diagramas de classes divididos em mdulos, seguindo a mesma diviso j utilizada na seo 4.5.

55

4.6.1.

Segurana A figura 4.10 apresenta o diagrama de classes do mdulo de segurana.

class seguranca

Perfil -

UsuarioClinica dataHabilitacao: Calendar clinica: Clinica usuario: Usuario perfil: Perfil -

Usuario senha: String dataCriacao: Date funcionario: Funcionario

Acesso tela: Tela usuarioClinica: UsuarioClinica inserir: Boolean consultar: Boolean alterar: Boolean excluir: Boolean imprimir: Boolean Tela nomeArquivo: String localizacaoArquivo: String telaPai: Tela imagem: String

Figura 4.10 - Diagrama de Classes do Mdulo de Segurana 4.6.2. Cadastros A figura 4.11 apresenta o diagrama de classes do mdulo de cadastros.

56

class cadastros

EstadoCiv il # # # # # # # # # # # # # # # # # #

Pessoa rg: Long cpf: Long dataNascimento: Calendar dataObito: Calendar tipoLogradouro: TipoLogradouro logradouro: String numero: Integer complemento: String bairro: String cep: Integer cidade: Cidade celular: Long telefone: Long email: String sexo: Sexo estadoCivil: EstadoCivil profissao: String observacoes: String -

Paciente codigo: String peso: Double altura: Double responsavel: Responsavel

Sexo sigla: String

FuncaoProfissional observacoes: String -

Profissional dataAdmissao: Calendar dataDemissao: Calendar funcaoProfissional: FuncaoProfissional

Responsav el isLegal: Boolean

Pais TipoCor r: Integer g: Integer b: Integer Medico tipoCR: TipoCR numeroCR: Long tipoCor: TipoCor Funcionario sigla: String

TipoLogradouro TipoCR sigla: String -

Cidade sigla: String uf: Uf -

Uf sigla: String pais: Pais

Clinica cnpj: Long inscricaoEstadual: Long inscricaoMunicipal: Long dataCriacao: Calendar tipoLogradouro: TipoLogradouro logradouro: String numero: Integer bairro: String cidade: Cidade telefone1: Long telefone2: Long responsavelAdministrativo: Funcionario responsavelTecnico: Medico observacoes: String

HorarioClinica clinica: Clinica horaEntrada: Calendar horaSaida: Calendar segundaFeira: Boolean tercaFeira: Boolean quartaFeira: Boolean quintaFeira: Boolean sextaFeira: Boolean sabado: Boolean domingo: Boolean

EspecialidadeMedica dataInicio: Calendar medico: Medico observacoes: String

Figura 4.11 - Diagrama de Classes do Mdulo de Cadastros 4.6.3. Agenda A figura 4.12 apresenta o diagrama de classes do mdulo de agenda.

class agenda

HorarioAgenda agenda: Agenda horaEntrada: Calendar horaSaida: Calendar segundaFeira: Boolean tercaFeira: Boolean quartaFeira: Boolean quintaFeira: Boolean sextaFeira: Boolean sabado: Boolean domingo: Boolean

Agenda dataHabilitacao: Calendar clinica: Clinica medico: Medico

Figura 4.12 - Diagrama de Classes do Mdulo de Agenda

57

4.6.4.

Pronturio A figura 4.13 apresenta o diagrama de classes do mdulo de pronturio.

class prontuario

Anamnese paciente: Paciente tipoSangue: TipoSangue queixaPrincipal: String descricaoDoencaAtual: String descricaoMedicaPregressa: String historicoFamiliar: String historicoPessoalSocial: String observacoes: String

Diagnostico descricao: String observacoes: String -

TipoConsulta tipoCor: TipoCor

TipoProcedimento observacoes: String

AtendimentoDiagnostico atendimento: Atendimento diagnostico: Diagnostico -

Atendimento diaHorario: Calendar reconsulta: Boolean encaixe: Boolean emergencia: Boolean agenda: Agenda tipoConsulta: TipoConsulta paciente: Paciente descricao: String -

cadastros::Paciente codigo: String peso: Double altura: Double responsavel: Responsavel -

Procedimento tipoProcedimento: TipoProcedimento custo: BigDecimal preco: BigDecimal observacoes: String

Tratamento descricao: String observacoes: String -

AtendimentoTratamento atendimento: Atendimento tratamento: Tratamento -

AtendimentoProcedimento atendimento: Atendimento procedimento: Procedimento -

PreparoProcedimento descricao: String procedimento: Procedimento nivelCriticidade: Integer observacoes: String

Figura 4.13 - Diagrama de Classes do Mdulo de Pronturio 4.6.5. Estoque A figura 4.14 apresenta o diagrama de classes do mdulo de estoque.

58

class estoque

UnidadeInsumo observacoes: String -

Fornecedor dataEntrada: Calendar telefone: Long telefone1: Long telefone2: Long tipoLogradouro: TipoLogradouro logradouro: String numero: Integer bairro: String cidade: Cidade observacoes: String

TipoInsumo observacoes: String -

Insumo tipoInsumo: TipoInsumo unidadeInsumo: UnidadeInsumo fornecedor: Fornecedor quantidadeMinima: BigDecimal valorAtual: BigDecimal -

LancamentoInsumo insumo: Insumo tipoLancamentoInsumo: TipoLancamentoInsumo clinica: Clinica quantidade: BigDecimal valorUnitario: BigDecimal dataLancamento: Calendar dataValidade: Calendar identificador: String

HistoricoInsumo insumo: Insumo tipoInsumo: String fornecedor: String quantidadeMinima: BigDecimal valor: BigDecimal dataAlteracao: Calendar -

InsumoProcedimento insumo: Insumo procedimento: Procedimento quantidadeInsumo: BigDecimal observacoes: String

TipoLancamentoInsumo

Figura 4.14 - Diagrama de Classes do Mdulo de Estoque 4.6.6. Financeiro A figura 4.15 apresenta o diagrama de classes do mdulo financeiro.

59

class financeiro

Caixa Mov imentoCaixa caixa: Caixa centroCusto: CentroCusto tipoLancamento: TipoLancamento formaPagamento: FormaPagamento valor: BigDecimal descricao: String usuario: Usuario dataHora: Calendar horario: String agencia: String conta: String saldoAtual: BigDecimal clinica: Clinica observacoes: String

TipoDocumento observacoes: String -

FormaPagamento observacoes: String -

CentroCusto observacoes: String -

TipoLancamento observacoes: String

Contas insumo: Insumo paciente: Paciente tipoDocumento: TipoDocumento tipoLancamento: TipoLancamento centroCusto: CentroCusto formaPagamento: FormaPagamento dataLancamento: Calendar dataVencimento: Calendar dataPagamento: Calendar quantidade: Double valorUnitario: BigDecimal valorTotal: BigDecimal numeroParcelas: Integer parcela: Integer parcelaFim: Integer diasAvisoVencimento: Integer observacoes: String dataLanc: String dataVenc: String dataPag: String

Figura 4.15 - Diagrama de Classes do Mdulo de Financeiro 4.7. Detalhamento dos casos de uso Casos de uso so muito populares, pois contam como um sistema ir se comportar. Os usurios do sistema conseguem enxergar o que ser o novo sistema e conseguem reagir mais rpido para aceitar ou rejeitar o caso de uso. Esta apenas uma das maneiras pelas quais os casos de uso contribuem para o desenvolvimento do sistema (COCKBURN, 2005). Cockburn (2005) cita que existem inmeros modelos de desenvolvimento de casos de uso, o modelo inteiramente completo o utilizado nos casos de uso descritos nas sees a seguir. Embora todos os casos de uso descritos na seo 4.3 tenham sido detalhados, esta seo apresenta somente o detalhamento dos principais casos de uso do sistema.

4.7.1.

Cadastros A seguir apresentado o detalhamento do caso de uso UC007 - Cadastro de

Clnicas. Este caso de uso tem por objetivo demonstrar a maneira pela qual o usurio ir interagir com o cadastro de clnicas.

1.

Nome do Caso de Uso: UC007 - Cadastro de Clnicas

60

1.1. Descrio Resumida Este caso de uso descreve e controla operaes para Criar, Alterar, Consultar e Excluir Clnicas. 1.2. Atores Administrativo; Administrador; Todos os atores so chamados de usurios no decorrer do caso de uso.

1.3. Acionadores Usurio seleciona operaes explicitamente usando a interface da tela. 2. Fluxo de Eventos 2.1. Fluxo Bsico O usurio seleciona a pesquisa de clnicas. 2.1.1. Pesquisar uma clnica 2.1.1.1. 2.1.1.2. 2.1.1.3. 2.1.1.4. Usurio informa os dados do filtro e seleciona a pesquisa; O sistema exibe uma lista com as clinicas que so atendidas por este filtro; Usurio seleciona a clnica desejada; O sistema exibe as informaes da clnica.

2.2. Fluxo Alternativo 2.2.1. Criar uma clnica 2.2.1.1. 2.2.1.2. 2.2.1.3. 2.2.1.4. Estando na tela de pesquisa, o usurio seleciona a opo de nova clnica; O sistema exibe a tela de cadastro de clnicas para o usurio; O usurio informa os dados da clnica e seleciona salvar; Se algum item obrigatrio do cadastro no for informado, o sistema informa ao usurio estes itens e retornar para a tela de cadastro, caso contrrio segue o fluxo a partir de 2.2.1.6.; O usurio informa os dados obrigatrios e seleciona salvar; O sistema salva os dados da clnica e informa ao usurio. Usurio seleciona uma clnica na pesquisa e coloca para edio; Sistema exibe a tela de cadastros para o usurio; Usurio altera os dados da clnica e seleciona salvar; Se algum item obrigatrio do cadastro no for informado, o sistema informa ao usurio estes itens e retornar para a tela de cadastro, caso contrrio segue o fluxo a partir de 2.2.2.5.;

2.2.1.5. 2.2.1.6. 2.2.2.1. 2.2.2.2. 2.2.2.3. 2.2.2.4.

2.2.2. Alterar uma clnica

61

2.2.2.5.

O sistema salva os dados da clnica e informa ao usurio.

2.2.3. Consultar uma clnica (Ocorre somente quando o usurio no possui permisso para editar uma clnica) 2.2.3.1. 2.2.3.2. 2.2.3.3. 2.2.4.1. 2.2.4.2. 2.2.4.3. 2.2.4.4. Usurio seleciona uma clnica na pesquisa e coloca para edio; Sistema exibe a tela de consulta da clnica para o usurio; Usurio visualiza os dados da clnica e seleciona sair. Usurio seleciona uma clnica da pesquisa e marca para excluso; Sistema mostra alerta de confirmao de excluso para o usurio; Se o usurio cancelar a excluso, o sistema volta para a tela de pesquisa, caso contrrio, segue o fluxo; Sistema informa para o usurio, que a clnica foi excluda ou que no possvel excluir uma clnica que possua ligaes com outros cadastros; Usurio volta para tela de pesquisa de clnicas.

2.2.4. Excluir uma clnica

2.2.4.5. 3. Requisitos Especiais

Ao incluir ou alterar uma clnica, obrigatrio o cadastro de horrios de funcionamento desta clnica. Este cadastro feito atravs UC012 Cadastro de Horrios de Clnicas.

4.

Pr-condies 4.1. Entrar no sistema Antes do caso de uso comear o usurio entrou no sistema; Ter permisso para realizar o caso de uso.

5.

Ps-condies No h ps-condies associadas a este caso de uso.

6.

Pontos de extenso Nenhum.

O caso de uso UC011 - Cadastro de Funcionrio tem por objetivo demonstrar a maneira pela qual o usurio ir interagir com o cadastro de funcionrios.

62

1. Nome do Caso de Uso: UC011 - Cadastro de Funcionrio 1.1. Descrio Resumida Este caso de uso descreve e controla operaes para Criar, Alterar, Consultar e Excluir Funcionrios. 1.2. Atores Secretria; Profissional Especializado (Ex.: Mdico); Administrativo; Administrador; Todos os atores so chamados de usurios no decorrer do caso de uso.

1.3. Acionadores Usurio seleciona operaes explicitamente usando a interface da tela. 2. Fluxo de Eventos 2.1. Fluxo Bsico O usurio seleciona a pesquisa de funcionrios. 2.1.1. Pesquisar um funcionrio 2.1.1.1. 2.1.1.2. 2.1.1.3. 2.1.1.4. Usurio informa os dados do filtro e seleciona a pesquisa; O sistema exibe uma lista com os funcionrios que so atendidos por este filtro; Usurio seleciona o funcionrio desejado; O sistema exibe as informaes do funcionrio.

2.2. Fluxo Alternativo 2.2.1. Criar um funcionrio 2.2.1.1. 2.2.1.2. 2.2.1.3. 2.2.1.4. Estando na tela de pesquisa, o usurio seleciona a opo de um novo funcionrio; O sistema exibe a tela de cadastro de funcionrios para o usurio; O usurio informa os dados do funcionrio e seleciona salvar; Se algum item obrigatrio do cadastro no for informado, o sistema informa ao usurio estes itens e retornar para a tela de cadastro, caso contrrio segue o fluxo a partir de 2.2.1.6.; O usurio informa os dados obrigatrios e seleciona salvar; O sistema salva os dados do funcionrio e informa ao usurio. Usurio seleciona um funcionrio da pesquisa e coloca para

2.2.1.5. 2.2.1.6. 2.2.2.1.

2.2.2. Alterar um funcionrio

63

edio; 2.2.2.2. 2.2.2.3. 2.2.2.4. Sistema exibe a tela de cadastros para o usurio; Usurio altera os dados do funcionrio e seleciona salvar; Se algum item obrigatrio do cadastro no for informado, o sistema informa ao usurio estes itens e retornar para a tela de cadastro, caso contrrio segue o fluxo a partir de 2.2.2.5.; O sistema salva os dados do funcionrio e informa ao usurio.

2.2.2.5.

2.2.3. Consultar um funcionrio (Ocorre somente quando o usurio no possui permisso para editar um funcionrio) 2.2.3.1. 2.2.3.2. 2.2.3.3. 2.2.4.1. 2.2.4.2. 2.2.4.3. 2.2.4.4. Usurio seleciona um funcionrio da pesquisa e coloca para edio; Sistema exibe a tela de consulta do funcionrio para o usurio; Usurio visualiza os dados do funcionrio e seleciona sair. Usurio seleciona um funcionrio da pesquisa e marca para excluso; Sistema mostra alerta de confirmao de excluso para o usurio; Se o usurio cancelar a excluso, o sistema volta para a tela de pesquisa, caso contrrio, segue o fluxo; Sistema informa para o usurio, que o funcionrio foi excludo ou que no possvel excluir um funcionrio que possua ligaes com outros cadastros; Usurio volta para tela de pesquisa de funcionrios.

2.2.4. Excluir um funcionrio

2.2.4.5. 3. Requisitos Especiais

neste cadastro que feito o lanamento da informao do tempo padro de atendimento deste funcionrio quando o mesmo for um profissional especializado. 4. Pr-condies 4.1. Entrar no sistema 5. Antes do caso de uso comear o usurio entrou no sistema; Ter permisso para realizar o caso de uso.

Ps-condies No h ps-condies associadas a este caso de uso.

6.

Pontos de extenso

64

Nenhum.

O caso de uso UC012 - Cadastro de Horrios de Clnicas tem por objetivo demonstrar a maneira pela qual o usurio ir interagir com o cadastro de horrios de clnicas.

1. Nome do Caso de Uso: UC012 - Cadastro de Horrios de Clnicas 1.1. Descrio Resumida Este caso de uso descreve e controla operaes para Criar, Alterar, Consultar e Excluir Horrios de Clnicas. 1.2. Atores Administrativo; Administrador; Todos os atores so chamados de usurios no decorrer do caso de uso.

1.3. Acionadores Usurio seleciona operaes explicitamente usando a interface da tela. 2. Fluxo de Eventos 2.1. Fluxo Bsico O usurio est no cadastro de uma clnica. 2.1.1. Criar um horrio 2.1.1.1. 2.1.1.2. 2.1.1.3. 2.1.1.4. Estando na tela de cadastro de clnicas, o usurio seleciona a opo de um novo horrio para a clnica; O sistema exibe a tela de cadastro de horrios para o usurio; O usurio informa os dados do horrio e seleciona salvar; Se algum item obrigatrio do cadastro no for informado, o sistema informa ao usurio estes itens e retornar para a tela de cadastro, caso contrrio segue o fluxo a partir de 2.1.1.6.; O usurio informa os dados obrigatrios e seleciona salvar; O sistema salva os dados do horrio, informa ao usurio e volta para o cadastro da clnica.

2.1.1.5. 2.1.1.6.

2.2. Fluxo Alternativo 2.2.1. Alterar um horrio 2.2.1.1. 2.2.1.2. 2.2.1.3. Usurio seleciona um horrio na lista de horrios no cadastro de clnicas e coloca para edio; Sistema exibe a tela de cadastro para o usurio; Usurio altera os dados do horrio e seleciona salvar;

65

2.2.1.4.

Se algum item obrigatrio do cadastro no for informado, o sistema informa ao usurio estes itens e retornar para a tela de cadastro, caso contrrio segue o fluxo a partir de 2.2.1.5.; O sistema salva os dados do horrio, informa ao usurio e volta para a tela de cadastro de clnicas. O Usurio pode visualizar os horrios de atendimento da clnica atravs da tela de edio ou consulta de uma clnica. Usurio seleciona um horrio na tela de cadastro de clnicas e marca para excluso; Sistema mostra alerta de confirmao de excluso para o usurio; Se o usurio cancelar a excluso, o sistema volta para a tela de cadastro de clnicas, caso contrrio, segue o fluxo; Sistema informa para o usurio, que o horrio foi excludo e volta para a tela de cadastro de clnicas.

2.2.1.5.

2.2.2. Consultar um horrio 2.2.2.1.

2.2.3. Excluir um horrio 2.2.3.1. 2.2.3.2. 2.2.3.3. 2.2.3.4.

3.

Requisitos Especiais Todos os horrios de clnicas so salvos no momento em que a clnica for salva, somente na tela de incluso de clnicas.

4.

Pr-condies 4.1. Entrar no sistema Antes do caso de uso comear o usurio entrou no sistema; Ter permisso para realizar o caso de uso.

5.

Ps-condies No h ps-condies associadas a este caso de uso.

6.

Pontos de extenso Nenhum.

O caso de uso UC013 - Cadastro de Paciente tem por objetivo demonstrar a maneira pela qual o usurio ir interagir com o cadastro paciente.

1. Nome do Caso de Uso: UC013 - Cadastro de Paciente

66

1.1. Descrio Resumida Este caso de uso descreve e controla operaes para Criar, Alterar, Consultar e Excluir Pacientes. 1.2. Atores Secretria; Profissional Especializado (Ex.: Mdico); Administrativo; Administrador; Todos os atores so chamados de usurios no decorrer do caso de uso.

1.3. Acionadores Usurio seleciona operaes explicitamente usando a interface da tela. 2. Fluxo de Eventos 2.1. Fluxo Bsico O usurio seleciona a pesquisa de pacientes. 2.1.1. Pesquisar um paciente 2.1.1.1. 2.1.1.2. 2.1.1.3. 2.1.1.4. Usurio informa os dados do filtro e seleciona a pesquisa; O sistema exibe uma lista com os pacientes que so atendidos por este filtro; Usurio seleciona o paciente desejado; O sistema exibe as informaes do paciente.

2.2. Fluxo Alternativo 2.2.1. Criar um paciente 2.2.1.1. 2.2.1.2. 2.2.1.3. 2.2.1.4. Estando na tela de pesquisa, o usurio seleciona a opo de um novo paciente; O sistema exibe a tela de cadastro de pacientes para o usurio; O usurio informa os dados do paciente e seleciona salvar paciente; Se algum item obrigatrio do cadastro no for informado, o sistema informa ao usurio estes itens e retornar para a tela de cadastro, caso contrrio segue o fluxo a partir de 2.2.1.6.; O usurio informa os dados obrigatrios e seleciona salvar paciente; O sistema salva os dados do paciente e informa ao usurio. Usurio seleciona um paciente da pesquisa e coloca para edio; Sistema exibe a tela de cadastros para o usurio;

2.2.1.5. 2.2.1.6. 2.2.2.1. 2.2.2.2.

2.2.2. Alterar um paciente

67

2.2.2.3. 2.2.2.4.

Usurio altera os dados do paciente e seleciona salvar paciente; Se algum item obrigatrio do cadastro no for informado, o sistema informa ao usurio estes itens e retornar para a tela de cadastro, caso contrrio segue o fluxo a partir de 2.2.2.5.; O sistema salva os dados do paciente e informa ao usurio.

2.2.2.5.

2.2.3. Consultar um paciente (Ocorre somente quando o usurio no possui permisso para editar um paciente) 2.2.3.1. 2.2.3.2. 2.2.3.3. 2.2.4.1. 2.2.4.2. 2.2.4.3. 2.2.4.4. Usurio seleciona um paciente da pesquisa e coloca para edio; Sistema exibe a tela de consulta do paciente para o usurio; Usurio visualiza os dados do paciente e seleciona sair. Usurio seleciona um paciente da pesquisa e marca para excluso; Sistema mostra alerta de confirmao de excluso para o usurio; Se o usurio cancelar a excluso, o sistema volta para a tela de pesquisa, caso contrrio, segue o fluxo; Sistema informa para o usurio, que o paciente foi excludo ou que no possvel excluir um paciente que possua ligaes com outros cadastros; Usurio volta para tela de pesquisa de pacientes.

2.2.4. Excluir um paciente

2.2.4.5. 3. Requisitos Especiais

Nenhum requisito especial foi especificado para este caso de uso. 4. Pr-condies 4.1. Entrar no sistema 5. Antes do caso de uso comear o usurio entrou no sistema; Ter permisso para realizar o caso de uso.

Ps-condies No h ps-condies associadas a este caso de uso.

6.

Pontos de extenso Nenhum.

68

4.7.2.

Agenda A seguir apresentado o detalhamento do caso de uso UC022 Agenda. Este caso

de uso tem por objetivo demonstrar a maneira pela qual o usurio ir interagir com a agenda de um ou mais mdicos.

1. Nome do Caso de Uso: UC022 Agenda 1.1. Descrio Resumida Este caso de uso tem como responsabilidade armazenar e marcar agendamentos de pacientes para cada mdico de uma clnica. 1.2. Atores Secretria; Profissional Especializado (Ex.: Mdico); Administrador; Todos os atores so chamados de usurios no decorrer do caso de uso.

1.3. Acionadores Usurio seleciona operaes explicitamente usando a interface da tela. 2. Fluxo de Eventos 2.1. Fluxo Bsico O usurio seleciona a agenda para um ou mais mdicos. 2.1.1. Pesquisar um agendamento 2.1.1.1. Usurio seleciona uma clnica na lista que aparece em tela (Caso seja um usurio com acesso a mais de uma clnica, caso contrrio aparece apenas clnica deste usurio pr-selecionada); Usurio seleciona um ou mais mdicos correspondentes clnica (Aparecem apenas os mdicos vinculados aquela clnica); O sistema exibe as agendas dos mdicos selecionados identificando cada um com a cor definida para este no seu cadastro.

2.1.1.2. 2.1.1.3.

2.2. Fluxo Alternativo 2.2.1. Criar um agendamento 2.2.1.1. 2.2.1.2. 2.2.1.3. Estando na tela de agenda, o usurio seleciona o dia e horrio para agendamento; O sistema exibe a tela de cadastro de agendamentos para o usurio; O usurio informa os dados do paciente (solicitado apenas o nome e telefone para pacientes ainda no cadastrados) e do

69

mdico escolhido, confirma o horrio e tempo do agendamento, informa o tipo de agendamento (tipo de consulta) e seleciona salvar; 2.2.1.4. Se algum item obrigatrio do cadastro no for informado, o sistema informa ao usurio estes itens e retornar para a tela de cadastro, caso contrrio segue o fluxo a partir de 2.2.1.6.; O usurio informa os dados obrigatrios e seleciona salvar; O sistema salva os dados do agendamento, informa ao usurio, fecha a tela de cadastro e atualiza a agenda com o novo agendamento. Estando na tela de agenda, o usurio seleciona o agendamento que deseja alterar; O sistema exibe a tela de cadastro do agendamento para o usurio; O usurio informa ou altera os dados desejados e seleciona salvar; Se algum item obrigatrio do cadastro no for informado, o sistema informa ao usurio estes itens e retornar para a tela de cadastro, caso contrrio segue o fluxo a partir de 2.2.2.6.; O usurio informa os dados obrigatrios e seleciona salvar; O sistema salva os dados do agendamento, informa ao usurio, fecha a tela de cadastro e atualiza a agenda com as alteraes do agendamento.

2.2.1.5. 2.2.1.6.

2.2.2. Alterar um agendamento 2.2.2.1. 2.2.2.2. 2.2.2.3. 2.2.2.4.

2.2.2.5. 2.2.2.6.

2.2.3. Consultar um agendamento (Ocorre somente quando o usurio no possui permisso para editar um agendamento) 2.2.3.1. 2.2.3.2. 2.2.3.3. 2.2.4.1. 2.2.4.2. 2.2.4.3. 2.2.4.4. 2.2.4.5. 2.2.4.6. Usurio seleciona um agendamento da agenda e coloca para edio; Sistema exibe a tela de consulta do agendamento para o usurio; Usurio visualiza os dados do agendamento e seleciona sair. Estando na tela de agenda, o usurio seleciona o agendamento que deseja excluir; O sistema exibe a tela de cadastro do agendamento para o usurio; O usurio seleciona excluir; Sistema mostra alerta de confirmao de excluso para o usurio; Se o usurio cancelar a excluso, o sistema volta para a tela de cadastro, caso contrrio, segue o fluxo; Sistema informa para o usurio, que o agendamento foi excludo ou que no possvel excluir um agendamento que possua um

2.2.4. Excluir um agendamento

70

atendimento; 2.2.4.7. 3. Requisitos Especiais Nenhum requisito especial foi especificado para este caso de uso. 4. Pr-condies 4.1. Entrar no sistema 5. Antes do caso de uso comear o usurio entrou no sistema; Ter permisso para realizar o caso de uso. O sistema volta para tela de agenda e a atualiza.

Ps-condies No h ps-condies associadas a este caso de uso.

6.

Pontos de extenso Estando em edio na tela de cadastro de um agendamento, o usurio pode selecionar a qualquer momento a opo de realizar um atendimento (UC 0025).

O caso de uso UC023 - Horrios de Agenda tem por objetivo demonstrar a maneira pela qual o usurio ir interagir com o cadastro de horrios da agenda do mdico.

1. Nome do Caso de Uso: UC023 Horrios de Agendas 1.1. Descrio Resumida Este caso de uso tem como responsabilidade definir os horrios de atendimento de cada mdico para uma clnica. 1.2. Atores Secretria; Profissional Especializado (Ex.: Mdico); Administrador; Todos os atores so chamados de usurios no decorrer do caso de uso.

1.3. Acionadores Usurio seleciona operaes explicitamente usando a interface da tela. 2. Fluxo de Eventos

71

2.1. Fluxo Bsico O usurio seleciona a pesquisa de horrios de agenda. 2.1.1. Pesquisar um horrio de agenda 2.1.1.1. Usurio seleciona uma clnica na lista que aparece em tela (Caso seja um usurio com acesso a mais de uma clnica, caso contrrio aparece apenas clnica deste usurio pr-selecionada); Usurio seleciona um mdico correspondente clnica (Aparecem apenas os mdicos vinculados aquela clnica); O sistema exibe uma lista com os horrios da agenda do mdico.

2.1.1.2. 2.1.1.3.

2.2. Fluxo Alternativo 2.2.1. Criar um horrio de agenda 2.2.1.1. 2.2.1.2. 2.2.1.3. 2.2.1.4. Estando na tela de pesquisa de horrios de agenda, o usurio seleciona novo; O sistema exibe a tela de cadastro de horrios de agenda para o usurio; O usurio informa os dados do novo horrio; Se algum item obrigatrio do cadastro no for informado, o sistema informa ao usurio estes itens e retornar para a tela de cadastro, caso contrrio segue o fluxo a partir de 2.2.1.6.; O usurio informa os dados obrigatrios e seleciona salvar; O sistema salva os dados do horrio, informa ao usurio, fecha a tela de cadastro e atualiza a lista com o novo horrio. Estando na tela de pesquisa de horrios de agenda, o usurio seleciona o horrio que deseja alterar; O sistema exibe a tela de cadastro de horrios de agenda para o usurio; O usurio informa ou altera os dados desejados e seleciona salvar; Se algum item obrigatrio do cadastro no for informado, o sistema informa ao usurio estes itens e retornar para a tela de cadastro, caso contrrio segue o fluxo a partir de 2.2.2.6.; O usurio informa os dados obrigatrios e seleciona salvar; O sistema salva os dados do horrio, informa ao usurio, fecha a tela de cadastro e atualiza a lista com as alteraes do horrio.

2.2.1.5. 2.2.1.6.

2.2.2. Alterar um agendamento 2.2.2.1. 2.2.2.2. 2.2.2.3. 2.2.2.4.

2.2.2.5. 2.2.2.6.

2.2.3. Consultar um horrio de agenda (Ocorre somente quando o usurio no possui permisso para editar um horrio de agenda) 2.2.3.1. 2.2.3.2. Usurio seleciona um horrio de agenda e coloca para edio; Sistema exibe a tela de consulta do horrio de agenda para o usurio;

72

2.2.3.3. 2.2.4.1. 2.2.4.2. 2.2.4.3. 2.2.4.4. 2.2.4.5. 2.2.4.6. 2.2.4.7. 3. Requisitos Especiais

Usurio visualiza os dados do horrio e seleciona sair. Estando na tela de pesquisa de horrio de agenda, o usurio seleciona o horrio que deseja excluir; O sistema exibe a tela de cadastro do horrio para o usurio; O usurio seleciona excluir; Sistema mostra alerta de confirmao de excluso para o usurio; Se o usurio cancelar a excluso, o sistema volta para a tela de pesquisa, caso contrrio, segue o fluxo; Sistema informa para o usurio, que o horrio foi excludo; O sistema volta para tela de pesquisa e a atualiza.

2.2.4. Excluir um horrio de agenda

Nenhum requisito especial foi especificado para este caso de uso. 4. Pr-condies 4.1. Entrar no sistema 5. Antes do caso de uso comear o usurio entrou no sistema; Ter permisso para realizar o caso de uso.

Ps-condies No h ps-condies associadas a este caso de uso.

6.

Pontos de extenso No h pontos de extenso associados a este caso de uso.

4.7.3.

Pronturio A seguir apresentado o detalhamento do caso de uso UC024 Anamnese. Este

caso de uso tem por objetivo demonstrar a maneira pela qual o usurio ir interagir com o histrico mdico de um paciente.

1.

Nome do Caso de Uso: UC024 - Anamnese 1.1. Descrio Resumida Este caso de uso tem como responsabilidade armazenar as informaes do histrico de atendimentos que o paciente j realizou, alm de informaes

73

histricas sobre a sade do paciente e de seus familiares. 1.2. Atores Profissional Especializado (Ex.: Mdico); Todos os atores so chamados de usurios no decorrer do caso de uso.

1.3. Acionadores Usurio seleciona operaes explicitamente usando a interface da tela. 2. Fluxo de Eventos 2.1. Fluxo Bsico O usurio seleciona a pesquisa de anamnese. 2.1.1. Pesquisar uma anamnese 2.1.1.1. 2.1.1.2. 2.1.1.3. 2.1.1.4. Usurio informa os dados do filtro e seleciona a pesquisa; O sistema exibe uma lista com os pacientes que so atendidos por este filtro; Usurio seleciona o paciente desejado; O sistema exibe as informaes da anamnese do paciente selecionado.

2.2. Fluxo Alternativo 2.2.1. Criar uma anamnese 2.2.1.1. 2.2.1.2. 2.2.1.3. 2.2.1.4. 2.2.1.5. 2.2.1.6. Estando na tela de pesquisa, o usurio seleciona a opo de nova anamnese; O sistema exibe a tela de cadastro de anamnese para o usurio; O usurio informa o paciente; O sistema carrega todos os atendimentos deste paciente para a anamnese; O usurio informa os dados da anamnese e seleciona salvar; Se algum item obrigatrio do cadastro no for informado, o sistema informa ao usurio estes itens e retornar para a tela de cadastro, caso contrrio segue o fluxo a partir de 2.2.1.8.; O usurio informa os dados obrigatrios e seleciona salvar; O sistema salva os dados da anamnese e informa ao usurio. Usurio seleciona uma anamnese na pesquisa e coloca para edio; O sistema exibe a tela de cadastro de anamnese para o usurio; O usurio informa ou altera os dados da anamnese e seleciona salvar;

2.2.1.7. 2.2.1.8. 2.2.2.1. 2.2.2.2. 2.2.2.3.

2.2.2. Alterar uma anamnese

74

2.2.2.4.

Se algum item obrigatrio do cadastro no for informado, o sistema informa ao usurio estes itens e retornar para a tela de cadastro, caso contrrio segue o fluxo a partir de 2.2.2.6.; O usurio informa os dados obrigatrios e seleciona salvar; O sistema salva os dados da anamnese e informa ao usurio.

2.2.2.5. 2.2.2.6.

2.2.3. Consultar uma anamnese (Ocorre somente quando o usurio no possui permisso para editar uma anamnese) 2.2.3.1. 2.2.3.2. 2.2.3.3. 2.2.4.1. 2.2.4.2. 2.2.4.3. 2.2.4.4. 2.2.4.5. 2.2.4.6. 2.2.4.7. 3. Requisitos Especiais No h requisitos especiais associados a este caso de uso. 4. Pr-condies 4.1. Entrar no sistema 5. Antes do caso de uso comear o usurio entrou no sistema; Ter permisso para realizar o caso de uso. Usurio seleciona uma anamnese da pesquisa e coloca para edio; Sistema exibe a tela de consulta da anamnese para o usurio; Usurio visualiza os dados da anamnese e seleciona sair. Usurio seleciona uma anamnese da pesquisa e coloca para edio; O sistema exibe a tela de cadastro da anamnese para o usurio; O usurio seleciona excluir; Sistema mostra alerta de confirmao de excluso para o usurio; Se o usurio cancelar a excluso, o sistema volta para a tela de cadastro, caso contrrio, segue o fluxo; Sistema informa para o usurio, que a anamnese foi excluda; O sistema volta para tela de pesquisa e a atualiza.

2.2.4. Excluir uma anamnese

Ps-condies No h ps-condies associadas a este caso de uso.

6.

Pontos de extenso No h pontos de extenso associados a este caso de uso.

75

O caso de uso UC025 - Atendimento tem por objetivo demonstrar a maneira pela qual o usurio ir interagir com o cadastro de atendimento de um paciente.

1. Nome do Caso de Uso: UC025 - Atendimento 1.1. Descrio Resumida Este caso de uso tem como responsabilidade armazenar as informaes da consulta que o paciente realizou em um determinado dia, dos procedimentos realizados e dos diagnsticos e tratamentos identificados pelo mdico. 1.2. Atores Profissional Especializado (Ex.: Mdico); Administrador; Todos os atores so chamados de usurios no decorrer do caso de uso.

1.3. Acionadores Usurio seleciona operaes explicitamente usando a interface da tela. 2. Fluxo de Eventos 2.1. Fluxo Bsico O usurio seleciona a pesquisa de atendimentos. 2.1.1. Pesquisar um agendamento 2.1.1.1. Usurio seleciona uma clnica na lista que aparece em tela (Caso seja um usurio com acesso a mais de uma clnica, caso contrrio aparece apenas clnica deste usurio pr-selecionada); Usurio pode selecionar um mdico correspondente clnica (Aparecem apenas os mdicos vinculados aquela clnica); Usurio pode selecionar um paciente; Usurio pode selecionar um dia; O sistema exibe os atendimentos realizados de acordo com o filtro informado.

2.1.1.2. 2.1.1.3. 2.1.1.4. 2.1.1.5.

2.2. Fluxo Alternativo O usurio seleciona a opo realizar atendimento a partir de um agendamento (UC022). 2.2.1. Criar um atendimento 2.2.1.1. 2.2.1.2. 2.2.1.3. Estando na tela de agenda, o usurio seleciona a opo realizar atendimento; O sistema exibe a tela de cadastro de atendimento para o usurio; O usurio informa os procedimentos realizados no paciente, alm dos dados de diagnsticos e tratamentos e seleciona salvar;

76

2.2.1.4.

Se algum item obrigatrio do cadastro no for informado, o sistema informa ao usurio estes itens e retornar para a tela de cadastro, caso contrrio segue o fluxo a partir de 2.2.1.6.; O usurio informa os dados obrigatrios e seleciona salvar; O sistema salva os dados do atendimento, informa ao usurio. Estando na tela de agenda, o usurio seleciona a opo realizar atendimento; O sistema exibe a tela de cadastro de atendimento para o usurio; O usurio informa ou altera os procedimentos realizados no paciente, alm dos dados de diagnsticos e tratamentos e seleciona salvar; Se algum item obrigatrio do cadastro no for informado, o sistema informa ao usurio estes itens e retornar para a tela de cadastro, caso contrrio segue o fluxo a partir de 2.2.2.6.; O usurio informa os dados obrigatrios e seleciona salvar; O sistema salva os dados do atendimento, informa ao usurio.

2.2.1.5. 2.2.1.6. 2.2.2.1. 2.2.2.2. 2.2.2.3.

2.2.2. Alterar um atendimento

2.2.2.4.

2.2.2.5. 2.2.2.6.

2.2.3. Consultar um atendimento (Ocorre somente quando o usurio no possui permisso para editar um atendimento) 2.2.3.1. 2.2.3.2. 2.2.3.3. 2.2.4.1. 2.2.4.2. 2.2.4.3. 2.2.4.4. 2.2.4.5. 2.2.4.6. Usurio seleciona um atendimento da pesquisa de atendimentos e coloca para edio; Sistema exibe a tela de consulta do atendimento para o usurio; Usurio visualiza os dados do atendimento e seleciona sair. Usurio seleciona um atendimento da pesquisa de atendimentos e coloca para edio; O sistema exibe a tela de cadastro do atendimento para o usurio; O usurio seleciona excluir; Sistema mostra alerta de confirmao de excluso para o usurio; Se o usurio cancelar a excluso, o sistema volta para a tela de cadastro, caso contrrio, segue o fluxo; Sistema informa para o usurio, que o atendimento foi excludo ou que no possvel excluir um atendimento que possua um ou mais procedimentos associados; O sistema volta para tela de pesquisa e a atualiza.

2.2.4. Excluir um atendimento

2.2.4.7. 3. Requisitos Especiais

O usurio pode editar o atendimento a partir de dois pontos especficos: Tela de Pesquisa de Atendimentos; e

77

4.

Tela de Cadastro de Agendamentos (Somente em edio).

Pr-condies 4.1. Entrar no sistema Antes do caso de uso comear o usurio entrou no sistema; Ter permisso para realizar o caso de uso.

5.

Ps-condies No h ps-condies associadas a este caso de uso.

6.

Pontos de extenso No h pontos de extenso associados a este caso de uso.

4.7.4.

Estoque A seguir apresentado o detalhamento do caso de uso UC034 Insumos. Este caso

de uso tem por objetivo demonstrar a maneira pela qual o usurio ir interagir com o cadastro de insumos;

1. Nome do Caso de Uso: UC034 - Cadastro de Insumos 1.1. Descrio Resumida Este caso de uso descreve e controla operaes para Criar, Alterar, Consultar e Excluir Insumos. 1.2. Atores Secretria; Administrativo; Todos os atores so chamados de usurios no decorrer do caso de uso.

1.3. Acionadores Usurio seleciona operaes explicitamente usando a interface da tela. 2. Fluxo de Eventos 2.1. Fluxo Bsico O usurio seleciona a pesquisa de insumos. 2.1.1. Pesquisar um insumo 2.1.1.1. Usurio informa os dados do filtro e seleciona a pesquisa;

78

2.1.1.2. 2.1.1.3. 2.1.1.4.

O sistema exibe uma lista com os insumos que so atendidos por este filtro; Usurio seleciona o insumo desejado; O sistema exibe as informaes do insumo.

2.2. Fluxo Alternativo 2.2.1. Criar um insumo 2.2.1.1. 2.2.1.2. 2.2.1.3. 2.2.1.4. Estando na tela de pesquisa, o usurio seleciona a opo de novo insumo; O sistema exibe a tela de cadastro de insumos para o usurio; O usurio informa os dados do insumo e seleciona salvar; Se algum item obrigatrio do cadastro no for informado, o sistema informa ao usurio estes itens e retornar para a tela de cadastro, caso contrrio segue o fluxo a partir de 2.2.1.6.; O usurio informa os dados obrigatrios e seleciona salvar; O sistema salva os dados do insumo e informa ao usurio. Usurio seleciona um insumo na pesquisa e coloca para edio; Sistema exibe a tela de cadastros para o usurio; Usurio altera os dados do insumo e seleciona salvar; Se algum item obrigatrio do cadastro no for informado, o sistema informa ao usurio estes itens e retornar para a tela de cadastro, caso contrrio segue o fluxo a partir de 2.2.2.5.; O sistema salva os dados do insumo e informa ao usurio.

2.2.1.5. 2.2.1.6. 2.2.2.1. 2.2.2.2. 2.2.2.3. 2.2.2.4.

2.2.2. Alterar um insumo

2.2.2.5.

2.2.3. Consultar um insumo (Ocorre somente quando o usurio no possui permisso para editar um insumo) 2.2.3.1. 2.2.3.2. 2.2.3.3. 2.2.4.1. 2.2.4.2. 2.2.4.3. 2.2.4.4. Usurio seleciona um insumo na pesquisa e coloca para edio; Sistema exibe a tela de consulta do insumo para o usurio; Usurio visualiza os dados do insumo e seleciona sair. Usurio seleciona um insumo da pesquisa e marca para excluso; Sistema mostra alerta de confirmao de excluso para o usurio; Se o usurio cancelar a excluso, o sistema volta para a tela de pesquisa, caso contrrio, segue o fluxo; Sistema informa para o usurio, que o insumo foi excludo ou que no possvel excluir um insumo que possua ligaes com outros cadastros; Usurio volta para tela de pesquisa de insumos.

2.2.4. Excluir um insumo

2.2.4.5.

79

3.

Requisitos Especiais No h requisitos especiais para este caso de uso.

4.

Pr-condies 4.1. Entrar no sistema Antes do caso de uso comear o usurio entrou no sistema; Ter permisso para realizar o caso de uso.

5.

Ps-condies No h ps-condies associadas a este caso de uso.

6.

Pontos de extenso Nenhum. O caso de uso UC035 Lanamentos de Insumos tem por objetivo demonstrar a

maneira pela qual o usurio ir interagir com o lanamento de insumos no sistema.

1.

Nome do Caso de Uso: UC035 - Lanamento de Insumos 1.1. Descrio Resumida Este caso de uso descreve e controla operaes para Criar e Consultar lanamentos de insumos. 1.2. Atores Secretria; Administrativo; Todos os atores so chamados de usurios no decorrer do caso de uso.

1.3. Acionadores Usurio seleciona operaes explicitamente usando a interface da tela. 2. Fluxo de Eventos 2.1. Fluxo Bsico O usurio seleciona o cadastro de lanamento de insumos. 2.1.1. Pesquisar lanamentos de insumo 2.1.1.1. 2.1.1.2. Usurio informa os dados do filtro e seleciona a pesquisa; O sistema exibe uma lista com os lanamentos de insumos que

80

so atendidos por este filtro; 2.1.1.3. 2.1.1.4. Usurio seleciona o lanamento desejado; O sistema exibe as informaes do lanamento.

2.2. Fluxo Alternativo 2.2.1. Criar um lanamento de insumo 2.2.1.1. 2.2.1.2. 2.2.1.3. 2.2.1.4. Estando na tela de pesquisa, o usurio seleciona a opo de novo lanamento; Usurio informa o insumo desejado para lanamento, o tipo de lanamento e a quantidade; Usurio seleciona salvar; Se algum item obrigatrio no for informado o sistema informa ao usurio estes itens e retornar para a tela de cadastro, caso contrrio segue o fluxo a partir de 2.2.1.6; O usurio informa os dados obrigatrios e seleciona salvar; O sistema salva os dados do lanamento do insumo e informa ao usurio. Usurio seleciona um lanamento na pesquisa e coloca para consulta; Sistema exibe a tela de consulta do lanamento para o usurio; Usurio visualiza os dados do lanamento e seleciona sair.

2.2.1.5. 2.2.1.6.

2.2.2. Consultar um lanamento de insumo 2.2.2.1. 2.2.2.2. 2.2.2.3. 3. Requisitos Especiais 4. No existe alterao de lanamentos, o usurio deve estornar o lanamento, gerando assim outro lanamento automaticamente; Todos os lanamentos alteram a quantidade total daquele insumo.

Pr-condies 4.1. Entrar no sistema Antes do caso de uso comear o usurio entrou no sistema; Ter permisso para realizar o caso de uso.

5.

Ps-condies No h ps-condies associadas a este caso de uso.

6.

Pontos de extenso Um lanamento automaticamente altera a quantidade total de um insumo.

81

4.7.5.

Financeiro A seguir apresentado o detalhamento do caso de uso UC039 Fluxo de Caixa.

Este caso de uso tem por objetivo demonstrar a maneira pela qual o usurio ir movimentar o fluxo de caixa da clnica.

1.

Nome do Caso de Uso: UC039 Fluxo de Caixa 1.1. Descrio Resumida Este caso de uso descreve e controla operaes para movimentao (fluxo) de um caixa. 1.2. Atores Secretria; Todos os atores so chamados de usurios no decorrer do caso de uso.

1.3. Acionadores Usurio seleciona operaes explicitamente usando a interface da tela. 2. Fluxo de Eventos 2.1. Fluxo Bsico O usurio seleciona o caixa. 2.1.1. Pesquisar um fluxo de caixa 2.1.1.1. 2.1.1.2. 2.1.1.3. Usurio informa a clnica, o caixa e o dia e seleciona a pesquisa; O sistema exibe uma lista com os movimentos que so atendidos por estes filtros; Usurio pode efetuar quaisquer aes de movimentao no caixa.

2.2. Fluxo Alternativo 2.2.1. Efetuar abertura de caixa 2.2.1.1. 2.2.1.2. 2.2.1.3. 2.2.1.4. 2.2.1.5. 2.2.2.1. Estando na tela de fluxo de caixa, o usurio seleciona o caixa desejado e a opo de abertura de caixa; O sistema exibe a tela de abertura de caixa para o usurio; O usurio informa o valor que o caixa ir iniciar e seleciona salvar; Se o valor no for informado, o sistema automaticamente abrir o caixa com o valor zero; O sistema salva os dados de abertura e informa ao usurio. Estando na tela de fluxo de caixa, o usurio seleciona o caixa

2.2.2. Efetuar retirada (sangria) no caixa

82

desejado e a opo de retirada; 2.2.2.2. 2.2.2.3. 2.2.2.4. 2.2.2.5. 2.2.2.6. 2.2.3.1. 2.2.3.2. 2.2.3.3. 2.2.3.4. 2.2.3.5. 2.2.3.6. 2.2.4.1. 2.2.4.2. 2.2.4.3. 2.2.4.4. O sistema exibe a tela de retirada para o usurio; O usurio informa o valor que ir retirar do caixa, o motivo e seleciona salvar; Se o valor ou o motivo no forem informados, o sistema avisa o usurio e no permite o movimento. O usurio informa todos os dados obrigatrios e seleciona salvar; O sistema salva os dados de retirada e informa ao usurio. Estando na tela de fluxo de caixa, o usurio seleciona o caixa desejado e a opo de depsito; O sistema exibe a tela de depsito para o usurio; O usurio informa o valor que ir depositar no caixa, o motivo e seleciona salvar; Se o valor ou o motivo no forem informados, o sistema avisa o usurio e no permite o movimento. O usurio informa todos os dados obrigatrios e seleciona salvar; O sistema salva os dados de depsito e informa ao usurio. Estando na tela de fluxo de caixa, o usurio seleciona o caixa desejado, o registro e a opo de estorno; O sistema pede a confirmao de estorno daquele registro para o usurio; O usurio confirma o estorno; O sistema efetua o estorno daquele registro lanando um novo registro e informa ao usurio. Estando na tela de fluxo de caixa, o usurio seleciona o caixa desejado e a opo de fechamento de caixa; O sistema pede a confirmao de fechamento de caixa para o usurio; O usurio confirma o fechamento; O sistema efetua o fechamento do caixa e informa ao usurio.

2.2.3. Efetuar depsito no caixa

2.2.4. Efetuar estorno no caixa

2.2.5. Efetuar fechamento de caixa 2.2.5.1. 2.2.5.2. 2.2.5.3. 2.2.5.4.

3.

Requisitos Especiais O caixa s pode ser aberto se estiver fechado; O caixa s pode ser fechado se estiver aberto;

83

No permitido movimentaes com o caixa fechado; O caixa pode ser aberto e fechado quantas vezes forem necessrias no decorrer de um dia; Por padro permitido o caixa ficar negativo, mas o sistema deve permitir parametrizar esta opo no cadastro de caixas; Ao efetuar a abertura de um caixa com o valor maior que zero, automaticamente efetuado um lanamento de depsito com o motivo de abertura de caixa; Ao efetuar o fechamento de um caixa com valor superior a zero, automaticamente efetuado um lanamento de retirada com o motivo de fechamento de caixa.

4.

Pr-condies 4.1. Entrar no sistema Antes do caso de uso comear o usurio entrou no sistema; Ter permisso para realizar o caso de uso.

5.

Ps-condies No h ps-condies associadas a este caso de uso.

6.

Pontos de extenso O fluxo de caixa possui ligao direta com as contas a pagar e contas a receber; Todas as contas a pagar ou a receber que estiverem vinculadas a um caixa e forem confirmadas, so automaticamente lanadas neste caixa; O pagamento de uma consulta gera um lanamento no fluxo de caixa, desde que seja um pagamento no ato.

O caso de uso UC040 Contas a Pagar e Contas a Receber tem por objetivo demonstrar a maneira pela qual o usurio ir pesquisar e criar contas a pagar e a receber para uma clnica.

1.

Nome do Caso de Uso: UC040 - Contas a pagar e a receber 1.1. Descrio Resumida Este caso de uso descreve e controla operaes para Criar, Alterar, Consultar e Excluir Contas a pagar e a receber. 1.2. Atores

84

Administrativo; Todos os atores so chamados de usurios no decorrer do caso de uso.

1.3. Acionadores Usurio seleciona operaes explicitamente usando a interface da tela. 2. Fluxo de Eventos 2.1. Fluxo Bsico O usurio seleciona a pesquisa de contas a pagar e a receber. 2.1.1. Pesquisar uma conta a pagar ou a receber 2.1.1.1. 2.1.1.2. 2.1.1.3. 2.1.1.4. Usurio informa os dados do filtro e seleciona a pesquisa; O sistema exibe uma lista com as contas que so atendidas por este filtro; Usurio seleciona a conta desejada; O sistema exibe as informaes da conta.

2.2. Fluxo Alternativo 2.2.1. Criar uma conta a pagar ou a receber 2.2.1.1. 2.2.1.2. 2.2.1.3. 2.2.1.4. Estando na tela de pesquisa, o usurio seleciona a opo de nova conta; O sistema exibe a tela de cadastro de contas para o usurio; O usurio informa os dados da conta, o tipo da conta (Pagar ou Receber) e seleciona salvar; Se algum item obrigatrio do cadastro no for informado, o sistema informa ao usurio estes itens e retornar para a tela de cadastro, caso contrrio segue o fluxo a partir de 2.2.1.6.; O usurio informa os dados obrigatrios e seleciona salvar; O sistema salva os dados da conta e informa ao usurio. Usurio seleciona uma conta na pesquisa e coloca para edio; Sistema exibe a tela de cadastro para o usurio; Usurio altera os dados da conta e seleciona salvar; Se algum item obrigatrio do cadastro no for informado, o sistema informa ao usurio estes itens e retornar para a tela de cadastro, caso contrrio segue o fluxo a partir de 2.2.2.6.; O usurio informa os dados obrigatrios e seleciona salvar; O sistema salva os dados da conta e informa ao usurio.

2.2.1.5. 2.2.1.6. 2.2.2.1. 2.2.2.2. 2.2.2.3. 2.2.2.4.

2.2.2. Alterar uma conta a pagar ou a receber

2.2.2.5. 2.2.2.6.

2.2.3. Consultar uma conta a pagar ou a receber (Ocorre somente quando o usurio no possui permisso para editar)

85

2.2.3.1. 2.2.3.2. 2.2.3.3. 2.2.4.1. 2.2.4.2. 2.2.4.3. 2.2.4.4. 2.2.4.5. 2.2.5.1. 2.2.5.2. 2.2.5.3. 2.2.5.4. 2.2.5.5. 3. Requisitos Especiais

Usurio seleciona uma conta na pesquisa e coloca para edio; Sistema exibe a tela de consulta da conta para o usurio; Usurio visualiza os dados da conta e seleciona sair. Usurio seleciona uma conta da pesquisa e marca para excluso; Sistema mostra alerta de confirmao de excluso para o usurio; Se o usurio cancelar a excluso, o sistema volta para a tela de pesquisa, caso contrrio, segue o fluxo; Sistema informa para o usurio, que a conta foi excluda ou que no possvel excluir uma conta j paga ou recebida; Usurio volta para tela de pesquisa de contas. Usurio seleciona uma conta da pesquisa e marca para lanamento; Sistema mostra alerta de confirmao de lanamento para o usurio; Se o usurio cancelar o lanamento, o sistema volta para a tela de pesquisa, caso contrrio, segue o fluxo; Sistema informa para o usurio, que a conta foi lanada e que gerou um movimento de caixa; Usurio volta para tela de pesquisa de contas.

2.2.4. Excluir uma conta a pagar ou a receber

2.2.5. Lanamento de uma conta a pagar ou a receber

S permitida a alterao de uma conta enquanto ela no for paga ou recebida, aps isso o sistema permite apenas o estorno gerando uma nova conta com as mesmas informaes da conta estornada; S permitida a excluso de uma conta que no tenha sido paga ou recebida;

4.

Pr-condies 4.1. Entrar no sistema Antes do caso de uso comear o usurio entrou no sistema; Ter permisso para realizar o caso de uso.

5.

Ps-condies No h ps-condies associadas a este caso de uso.

6.

Pontos de extenso

86

Todo lanamento de contas a pagar ou a receber, automaticamente gera um movimento no fluxo do caixa daquela conta.

O caso de uso UC041 Pagamento de Consultas tem por objetivo demonstrar a maneira pela qual o usurio conseguir efetivar o pagamento de um atendimento/consulta de uma clnica.

1.

Nome do Caso de Uso: UC041 Pagamento de Consultas 1.1. Descrio Resumida Este caso de uso descreve e controla operaes para efetuar e cancelar o pagamento de consultas, independente se for pagamento vista ou parcelado. 1.2. Atores Secretria; Todos os atores so chamados de usurios no decorrer do caso de uso.

1.3. Acionadores Usurio seleciona operaes explicitamente usando a interface da tela. 2. Fluxo de Eventos 2.1. Fluxo Bsico O usurio seleciona a agenda para um ou mais mdicos. 2.1.1. Pesquisar uma consulta 2.1.1.1. Usurio seleciona uma clnica na lista que aparece em tela (Caso seja um usurio com acesso a mais de uma clnica, caso contrrio aparece apenas clnica deste usurio pr-selecionada); Usurio seleciona um ou mais mdicos correspondentes clnica (Aparecem apenas os mdicos vinculados aquela clnica); O sistema exibe as agendas dos mdicos selecionados identificando cada um com a cor definida para este no seu cadastro.

2.1.1.2. 2.1.1.3.

2.2. Fluxo Alternativo 2.2.1. Efetuar Pagamento de Consulta 2.2.1.1. 2.2.1.2. 2.2.1.3. Estando na tela de agenda, o usurio seleciona a consulta que deseja efetuar o pagamento; O sistema exibe a tela de agendamento da consulta para o usurio; O usurio seleciona a opo de efetuar pagamento (esta opo s aparece quando existe um paciente cadastrado vinculado a

87

consulta); 2.2.1.4. 2.2.1.5. 2.2.1.6. O sistema abre uma janela de pagamento de consultas; O usurio informa os dados de pagamento e seleciona salvar; Se algum item obrigatrio do pagamento no for informado, o sistema informa ao usurio estes itens e retornar para a tela de pagamento, caso contrrio segue o fluxo a partir de 2.2.1.8.; O usurio informa os dados obrigatrios e seleciona salvar; O sistema salva os dados do pagamento, efetua o lanamento no fluxo de caixa e informa ao usurio. Estando na tela de agenda, o usurio seleciona a consulta que deseja cancelar o pagamento; O sistema exibe a tela de agendamento da consulta para o usurio; O usurio seleciona a opo de cancelar pagamento (esta opo s aparece quando existe um pagamento vinculado a consulta); O sistema abre uma janela de cancelamento do pagamento de consultas; O usurio informa o motivo do cancelamento e seleciona salvar; Se algum item obrigatrio do cancelamento no for informado, o sistema informa ao usurio estes itens e retornar para a tela de cancelamento, caso contrrio segue o fluxo a partir de 2.2.2.8.; O usurio informa os dados obrigatrios e seleciona salvar; O sistema salva os dados do cancelamento, efetua o lanamento de estorno no fluxo de caixa e informa ao usurio. A qualquer momento o usurio pode consultar o pagamento de uma consulta atravs da pesquisa de atendimentos. No permitida a excluso de um pagamento. A opo mais similar a excluso o cancelamento do pagamento.

2.2.1.7. 2.2.1.8.

2.2.2. Cancelar Pagamento de Consulta 2.2.2.1. 2.2.2.2. 2.2.2.3. 2.2.2.4. 2.2.2.5. 2.2.2.6.

2.2.2.7. 2.2.2.8.

2.2.3. Consultar um pagamento de consulta 2.2.3.1.

2.2.4. Excluir um pagamento de consulta 2.2.4.1. 2.2.4.2.

3.

Requisitos Especiais Nenhum.

4.

Pr-condies 4.1. Entrar no sistema

88

5.

Antes do caso de uso comear o usurio entrou no sistema; Ter permisso para realizar o caso de uso.

Ps-condies No h ps-condies associadas a este caso de uso.

6.

Pontos de extenso Todo pagamento gera lanamentos no fluxo de caixa e/ou contas a receber; Todo cancelamento gera lanamentos de estorno no fluxo de caixa e/ou excluso do registro de contas a receber.

Atravs da anlise de requisitos realizada neste captulo, juntamente com a anlise dos sistemas similares, foi possvel elaborar o projeto deste sistema de gesto para clnicas mdicas de pequeno porte. Para completar o projeto proposto, foram elaborados prottipos de telas do sistema, o que pode ser visto no captulo 5.

5.

PROTTIPO DO SISTEMA

Este captulo tem como objetivo abordar as principais caractersticas do prottipo do sistema proposto no presente trabalho. Houve uma ateno especial com o layout das telas, a fim de torn-las amigveis e de uso intuitivo, facilitando o entrosamento do usurio com o sistema. Uma das caractersticas presente nas telas e que merecem destaque so as caixas de campos, ou seja, as informaes so disponibilizadas em conjuntos de campos relacionados. Estas caixas podem ser individualmente minimizadas ou maximizadas segundo a necessidade do usurio, facilitando o acesso e visualizao s informaes. Alguns campos possuem mscaras, que evitam que o usurio ingresse informaes fora do padro esperado. Um exemplo so os campos de telefone e CPF, que permitem apenas nmeros, no sendo possvel informar letras ou caracteres. Finalmente, algumas informaes podem ser escolhidas em caixas de seleo com opes de respostas pr determinadas, evitando que o usurio tenha que digitar a mesma informao diversas vezes. As sees a seguir apresentam o prottipo de seis telas do sistema e, adicionalmente, descrevem seus principais objetivos e funcionalidades.

5.1. Cadastro de Pacientes O objetivo da tela cadastro de pacientes permitir o registro das informaes pessoais de cada paciente da clnica como, por exemplo, dados de identificao, contato e endereo. A figura 5.1 apresenta o prottipo desta tela.

Figura 5.1 - Prottipo da Tela de Cadastro de Pacientes

90

Caso o paciente em questo seja menor de idade, h um campo que solicita o nome do responsvel. Se este responsvel j estiver registrado no sistema, o campo permite que seja feita uma busca e que as informaes sejam vinculadas.

5.2. Cadastro de Clnicas Caso um mesmo cliente do sistema possua mais de uma sede fsica, possvel conectar os dados destas clnicas para que os administradores tenham uma viso holstica das informaes. A tela de cadastro de clnicas (figura 5.2) permite o registro destas diferentes sedes para que cada uma delas tenha operaes individuais dentro do sistema.

Figura 5.2 - Prottipo da Tela de Cadastro de Clnicas Esta tela possui as abas Geral, Horrios e Financeiro. Esta diviso de tpicos por aba foi aplicada para permitir que o usurio no tenha que utilizar a barra de rolagem para encontrar as informaes que deseja e tenha, assim, uma visualizao mais clara e dinmica da tela. Na aba geral estaro os dados de identificao, contato, responsveis e endereo da clnica. Na aba horrios ser possvel definir os dias e turnos de funcionamento da clnica em questo, sendo que esta informao ser refletida nos horrios disponveis para agendamento de consultas. Por fim, na aba Financeiro so cadastrados os caixas da empresa, como conta corrente e caixa fsico da recepo.

91

5.3. Agenda O objetivo da tela de agenda permitir que os usurios registrem, consultem e editem as consultas marcadas para os mdicos da clnica. A figura 5.3 apresenta o prottipo desta tela.

Figura 5.3 - Prottipo da Tela de Agenda O layout desta tela possui o mesmo estilo do calendrio do Google e da Agenda do Outlook. Assim, os usurios que j esto familiarizados com o formato destas outras ferramentas rapidamente entendero o conceito de uso desta tela. possvel visualizar a agenda de um mdico especfico ou de diversos mdicos simultaneamente, para determinar o modelo de visualizao basta que o usurio selecione os nomes dos mdicos na caixa esquerda da agenda.

5.4. Cadastro de Atendimento Na tela de cadastro de atendimento (figura 5.4), os mdicos podero fazer o registro de cada procedimento, diagnstico e tratamento relacionados a um atendimento. O objetivo que os mdicos formem um histrico de cada um de seus pacientes.

92

Figura 5.4 - Prottipo da Tela de Cadastro de Atendimentos Os campos de procedimento, diagnstico e tratamento traro dados pr registrados que podero ser selecionados para o atendimento em questo. A transferncia dos dados das caixas de disponveis para as caixas de realizados pode ser feita arrastando os componentes de uma caixa para a outra ou utilizando os botes em forma de setas. H ainda um campo livre de descrio para que o mdico faa anotaes adicionais sobre o atendimento.

5.5. Fluxo de Caixa A tela de fluxo de caixa permite que os usurios visualizem e registrem as transaes financeiras da clnica. Estes registros so salvos por perodos de um dia. A figura 5.5 apresenta o prottipo desta tela.

93

Figura 5.5 - Prottipo da Tela de Fluxo de Caixa As movimentaes financeiras sero exibidas em ordem cronolgica, sendo que as informaes mais recentes estaro no topo. Depois que uma entrada salva, no pode ser excluda. Junto com a descrio da movimentao tambm sero registrados o horrio da movimentao, o valor, a forma de pagamento, se a operao se trata de um dbito ou crdito e o usurio responsvel. Na parte inferior da tela haver um campo informando o saldo do caixa.

5.6. Contas a Pagar e Contas a Receber Esta tela permitir que os usurios faam o controle das contas a pagar e a receber da clnica, podendo consultar, incluir, editar e excluir entradas. A figura 5.6 apresenta o prottipo desta tela.

94

Figura 5.6 - Prottipo da Tela de Contas a Pagar e Contas a Receber Na parte superior da tela existe uma srie de filtros que o usurio poder utilizar para buscar pelos registros de contas a pagar, contas a receber ou ambos. Algumas opes de filtro so o status das contas (em dia ou com atraso), data de vencimento e paciente. Na parte central da tela so exibidas informaes como descrio, valor, forma de pagamento e data de vencimento das transaes que se enquadram na busca realizada pelo usurio. As informaes so disponibilizadas em ordem cronolgica e na parte inferior da tela o usurio poder consultar os totais. Atravs do prottipo das telas possvel confirmar o layout simples e amigvel que o sistema possui. As facilidades que as telas propem, auxiliam na agilidade das tarefas dirias dos funcionrios de uma clnica de pequeno porte. Fechando este captulo, pode-se destacar a importncia de prototipar um sistema, pois possvel visualizar de forma mais clara as opes e ferramentas que o mesmo ter.

CONCLUSO

possvel dizer que os ERPs so os principais componentes dos sistemas de informao de empresas. Esta constatao refora a importncia de projetar e desenvolver sistemas de gesto para empresas no atendidas por ERPs tradicionais, como o caso das clnicas mdias de pequeno porte. Para aumentar a produtividade e organizar o processo de desenvolvimento de ERPs , uma metodologia amplamente utilizada o processo unificado. O processo unificado ajuda a guiar todo o projeto de desenvolvimento do sistema, suas fases e os ciclos que devem ser realizados no decorrer de cada etapa, contribuindo muito para o bom andamento das atividades. Na anlise de sistemas com recursos similares foi possvel constatar que alguns dos mais populares softwares para clnicas mdicas no so to simples de usar quanto os usurios desejariam. Alm disso, os softwares concorrentes no do a ateno necessria s informaes de extrema importncia para a gesto da clnica como, por exemplo, um fluxo de caixa simples e completo. Desta forma, concluiu-se que o desenvolvimento de um software de gesto com interface simples e funcionalidades adequadas seriam um diferencial em um novo software para gesto de clnicas mdicas. A arquitetura Java, comparada a outras linguagens de programao amplamente utilizadas, possui como principais benefcios sua robustez, sua grande quantidade de frameworks e sua orientao a objetos. Java foi a linguagem escolhida para o desenvolvimento do sistema em questo, pois tal tecnologia traz mais agilidade e produtividade, alm de ajudar a aumentar a confiabilidade da arquitetura. Com base em todos os estudos e anlises realizados e de um detalhado levantamento de requisitos, foi realizada toda a anlise, projeto e prototipao do sistema proposto. Os resultados obtidos at o momento permitem afirmar que o sistema de gesto de clnicas mdicas de pequeno e mdio porte ir contribuir em muito para o cotidiano destas clnicas. Ir facilitar o cotidiano destas clnicas em tarefas j sistematizadas atualmente, como o agendamento de consultas, registro dos atendimentos, anamnese, entre outras tarefas. Mas, como maior contribuio, ir sistematizar, facilitar e organizar processos hoje no informatizados, como controle de insumos, fluxo de caixa e contas a pagar e receber.

96

Como trabalhos futuros, destacam-se a concluso do desenvolvimento do sistema proposto e a implantao em uma primeira clnica mdica, visando concluir a validao do sistema para futura comercializao

REFERNCIAS

AUDY, Jorge; PRIKLADNICKI, Rafael. Desenvolvimento distribudo de software. So Paulo: Campus, 2007. BISWAS, Rahul; ORT, Ed. The Java Persistence API - A Simpler Programming Model for Entity Persistence. Disponvel em: <http://www.oracle.com/technetwork/articles/javaee/jpa-137156.html>. Acesso em 07/11/2010. BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usurio. So Paulo: Campus, 2000. COCKBURN, Alistair. Escrevendo Casos de Uso Eficazes: Um guia prtico para desenvolvedores de software. Porto Alegre: Bookman, 2005. DATE, C.J., Introduo a Sistemas de Bancos de Dados. Traduo da 8 edio Americana. Rio de Janeiro: Campus, 2004. DAVENPORT, Thomas H. Misso Critica: Obtendo vantagem competitiva com os sistemas de gesto empresarial. Porto Alegre: Bookman, 2002. FRANKLINT, Kleitor. Java EE 5, Java Platform Enterprise Edition 5, Guia Prtico. So Paulo: Editora rica, 2006. FREIRE, Sergio Miranda. Sigilo das Informaes. Disponvel em: <http://www.ans.gov.br/data/files/8A958865266CAFE201267FB9CDED2DB2/TT_AS_19_S MirandaFreire_SigiloInformacoes.pdf>. Acesso em 27/12/2010. GERCLIM. Sistema de gesto mdica. Disponvel em: <http://www.gerclim.com.br/>. Acesso em: 12 maio 2010. GONALVES, Edson. Desenvolvendo Aplicaes Web com JSP, Servlets, Java Server Faces, HIbernate, EJB 3 Persistence e Ajax. Rio de Janeiro: Editora Cincia Moderna, 2007. HORSTMANN, Cay S.; CORNELL, Gary. Core Java, Volume I Fundamentos. Rio de Janeiro: Ed. Alta Books, 2005. JACOBI, Jonas; FALLOWS, John R. Pro JSF and Ajax Building Rich Internet Components. Apress, 2006. MDMED. Sistema de gesto mdica. Disponvel em: <http://www.mdmed.com.br/>. Acesso em: 13 maio 2010. PADILHA, Thais Cssia Cabral; MARINS, Fernando Augusto Silva. Sistemas ERP: caractersticas, custos e tendncias. Prod. [online]. 2005, vol.15, n.1, pp. 102-113. ISSN 0103-6513. Disponvel em <http://www.scielo.br/scielo.php?pid=S010365132005000100009&script=sci_arttext&tlng=es>. Acesso em 13/04/2010 PANDA, Debu; RAHMAN, Reza; LANE; Derek. EJB 3 in Action. Manning, 2007. PFLEEGER, Shari Lawrence. Engenharia de Software Teoria e Prtica. 2 ed. So Paulo: Prentice Hall, 2004. PRESSMAN, Roger S. Software Engineering: a practitioners approach, 6 edio, Mc Graw Hill, 2004.

98

PRODOCTOR. Sistema de gesto mdica. Disponvel em: <http://www.prodoctor.net/>. Acesso em: 14 maio 2010. SCOTT, Kendall. O Processo Unificado Explicado. 1 ed. Porto Alegre: Bookman, 2003. SOUZA, Cesar Alexandre de; SACCOL, Amarolinda Zanela. Sistemas ERP no Brasil. So Paulo: Atlas, 2008. THOMPSON, Marco Aurlio. Java 2 & Banco de Dados. 3 edio. So Paulo: Ed. rica Ltda; 2005 VALARIE A. Zeithaml; Mary Jo BITNER. Marketing de Servios: a empresa com foco no cliente. Traduo Martin Albert Haag e Carlos Alberto Silveira Netto Soares 2 edio Porto Alegre: Bookman, 2008.