CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA

CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA CURSO SUPERIOR DE TECNOLOGIA EM BANCO DE DADOS GABRIEL GOMES DE OLIVEIRA THOMAZ SILVA MENDES SISTEMA GERENCIADOR DE MEDICAMENTOS LINS/SP 2º SEMESTRE/2014

CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA CURSO SUPERIOR DE TECNOLOGIA EM BANCO DE DADOS GABRIEL GOMES DE OLIVEIRA THOMAZ SILVA MENDES SISTEMA GERENCIADOR DE MEDICAMENTOS Trabalho de Conclusão de Curso apresentado à Faculdade de Tecnologia de Lins para obtenção do Título de Tecnólogo em Banco de Dados. Orientador: Prof. Dr. Paulo Augusto Nardi LINS/SP 2º SEMESTRE/2014

GABRIEL GOMES DE OLIVEIRA THOMAZ SILVA MENDES SISTEMA GERENCIADOR DE MEDICAMENTOS Trabalho de Conclusão de Curso apresentado à Faculdade de Tecnologia de Lins Prof. Antonio Seabra, como parte dos requisitos necessários para a obtenção do título de Tecnólogo em Banco de Dados sob orientação do Prof. Dr. Paulo Augusto Nardi Data de aprovação: 03 de Dezembro de 2014 Orientador: Prof. Dr. Paulo Augusto Nardi Prof. Me. Fábio Lúcio Meira Prof. Me. Rodrigo Moura Juvenil Ayres

Dedicamos este trabalho aos nossos Familiares que nos incentivaram, pilares de nossa existência e que acreditaram em nossos esforços. Gabriel Gomes de Oliveira Thomaz Silva Mendes

AGRADECIMENTOS Primeiramente, gostaríamos de agradecer a Deus pelas oportunidades que nos foram dadas na vida e que nos capacitou e fortaleceu nos momentos mais difíceis, iluminando nosso caminho nessa jornada. Agradecemos a Faculdade de Tecnologia de Lins Prof. Antônio Seabra pela oportunidade e a todos os professores, funcionário e companheiros de classe. Em especial agradecemos ao nosso Orientador Prof. Dr. Paulo Augusto Nardi pelos conselhos e também aos Professores que nos acompanharam nessa jornada. Gabriel Gomes de Oliveira Thomaz Silva Mendes

RESUMO Este trabalho tem como objetivo o desenvolvimento de um sistema gerenciador de entrada e saída de medicamentos para o Ambulatório de Saúde Mental, visto que o excesso de planilhas e documentos de texto pode ocasionar erros, inconsistências e insegurança nas informações, causando lentidão no acesso aos dados necessários. Foi observado que os principais processos administrativos do ambulatório são realizados manualmente e o mesmo não possui um software para gerenciar esses processos. Sendo assim, o propósito deste sistema é minimizar o risco decorrente desses problemas, fornecendo facilidade de acesso aos dados, segurança e agilidade na tomada de decisões, garantindo a fidedignidade dos dados. As principais funcionalidades do sistema são cadastros para pacientes, medicamentos, pedidos e um controle de entrada e saída de medicamentos, que são os processos realizados com maior frequência pela administração do ambulatório. Palavras-chave: Banco de Dados, Sistema Gerenciador de Medicamentos, Delphi.

ABSTRACT This work aims to develop a system to manage the input and output of medicines in Mental Health Clinic, considering that the excess of spread sheets and text documents can cause error, inconsistency and insecurity in information, causing slowness to access the necessary datum. It was observed that the main management a software to manage those process. In that way, the purpose of this system is to minimize the risk resulting from those problems, providing facility t the data access, security and agility on decision making, guaranteeing the reliability of the data. The main function of the system are register the patients, medicines and give a control of input and output of the medicines, which are the frequently processes done by the administrator in the clinic. Keywords: Database, Management System of Medicines, Delphi.

LISTA DE ILUSTRAÇÕES Figura 2.1 Diagrama de Casos de Uso... 22 Figura 4.1 Modelo Lógico... 37 Figura 4.2 Modelo Relacional... 38 Figura 4.3 Diagrama de Atividade Efetuar Login... 40 Figura 4.4 Diagrama de Atividade Lançar Pedido... 41 Figura 4.5 Diagrama de Atividade Lançar Doação... 42 Figura 4.6 Diagrama de Atividade Manter Usuário... 43 Figura 4.7 Diagrama de Atividade Manter Paciente... 44 Figura 4.8 Diagrama de Atividade Manter Medicamento... 45 Figura 4.9 Diagrama de Atividade Manter Responsável... 46 Figura 4.10 Diagrama de Atividade Efetuar Entrada... 47 Figura 4.11 Diagrama de Atividade Efetuar Retirada... 48 Figura 4.12 Diagrama de Atividade Emitir Relatório... 49 Figura 4.13 Diagrama de Sequência Efetuar Login... 51 Figura 4.14 Diagrama de Sequência Lançar Pedido... 52 Figura 4.15 Diagrama de Sequência Lançar Doação... 53 Figura 4.16 Diagrama de Sequência Manter Usuário... 54 Figura 4.17 Diagrama de Sequência Manter Paciente... 55 Figura 4.18 Diagrama de Sequência Manter Medicamento... 56 Figura 4.19 Diagrama de Sequência Manter Responsável... 57 Figura 4.20 Diagrama de Sequência Efetuar Entrada... 58 Figura 4.21 Diagrama de Sequência Efetuar Retirada... 59 Figura 4.22 Diagrama de Sequência Emitir Relatório Entrada... 60 Figura 4.23 Diagrama de Sequência Emitir Relatório Retirada... 61 Figura 5.1 Tela de Login... 62 Figura 5.2 Tela Inicial... 63 Figura 5.3 Tela Cadastro de Medicamentos... 64 Figura 5.4 Tela Pesquisa de Medicamentos... 64 Figura 5.5 Tela de Cadastro de Paciente... 65 Figura 5.6 Tela de Pesquisa de Paciente... 66 Figura 5.7 Tela de Cadastro de Responsável... 66 Figura 5.8 Tela de Pesquisa de Responsável... 67 Figura 5.9 Tela de Retirada de Medicamentos.... 68 Figura 5.10 Tela de Pesquisa de Retirada... 69 Figura 5.11 Tela de Doação de Medicamentos... 70 Figura 5.12 Tela de Cadastro Usuário... 71

LISTA DE ABREVIATURAS E SIGLAS ANSI American National Standards Institute DRS - Departamento Regional de Saúde IDE - Integrated Development Environment ISO International Standards Organization ISVS The International Society for Vascular Surgery LME Laudo para Solicitação de Medicamento Especializado PDF Portable Document Format RAD Rapid Application Development SQL Structured Query Language SUS Sistema Único de Saúde UML Unified Modeling Language

SUMÁRIO INTRODUÇÃO... 8 1 FUNDAMENTAÇÃO TEORICA... 10 1.1 BANCO DE DADOS... 10 1.2 SQL... 10 1.3 DELPHI... 11 1.3.1 Fortes Report... 12 1.4 ASTHA COMMUNITY... 13 2 ANÁLISE E PROJETO DE SISTEMA... 15 2.1 ANÁLISE DE NEGÓCIO... 15 2.1.1 Instrução do Problema... 15 2.1.2 Análise de Mercado... 17 2.1.3 Atores e Envolvidos no Processo... 17 2.1.4 Descrição do Ambiente Atual... 17 2.2 VISÃO GERAL DO PRODUTO... 20 2.2.1 Perspectiva do Produto... 20 2.2.2 Características... 20 2.3 ANÁLISE DE REQUISITOS... 21 2.3.1 Análise de Requisitos Funcionais... 21 2.3.2 Diagrama de Caso de Uso... 21 3 CASOS DE USO E SUAS ESPECIFICAÇÕES... 23 3.1 ESPECIFICAÇÃO DE CASO DE USO: EFETUAR LOGIN... 23 3.2 ESPECIFICAÇÃO DE CASO DE USO: EFETUAR RETIRADA... 24 3.3 ESPECIFICAÇÃO DE CASO DE USO: EFETUAR ENTRADA... 26 3.4 ESPECIFICAÇÕES DE CASO DE USO: LANÇAR PEDIDO... 27 3.5 ESPECIFICAÇÃO DE CASO DE USO: MANTER PACIENTE... 29 3.6 ESPECIFICAÇÃO DE CASO DE USO: MANTER USUÁRIO... 30 3.7 ESPECIFICAÇÃO DE CASO DE USO: MANTER MEDICAMENTO... 32 3.8 ESPECIFICAÇÃO DE CASO DE USO: EMITIR RELATÓRIO... 33 3.9 ESPECIFICAÇÃO DE CASO DE USO: MANTER RESPONSÁVEL... 33 3.10 ESPECIFICAÇÃO DE CASO DE USO: LANÇAR DOAÇÃO... 35 4 DIAGRAMAS E MODELAGEM DOS DADOS... 36 4.1 DIAGRAMAS DE ATIVIDADE... 39

4.2 DIAGRAMAS DE SEQUÊNCIA... 50 5 PROTÓTIPO E DESENVOLVIMENTO DO SISTEMA... 62 CONCLUSÃO... 72 REFERÊNCIAS BIBLIOGRÁFICAS... 74 ANEXO A... 76 ANEXO B... 77

8 INTRODUÇÃO O Ambulatório Municipal de Saúde Mental de Promissão realiza todo o controle de entrada e saída de medicamentos do Programa de Medicamentos Excepcionais manualmente através de planilhas eletrônicas e documentos de texto, tornando o trabalho dos funcionários demorado e complexo, dificultando a pesquisa nos registros e a acessibilidade aos dados. Uma solução para melhorar o controle de medicamentos no Ambulatório Municipal de Saúde Mental de Promissão é desenvolver um sistema que possibilite armazenar todas as informações em um banco de dados e eliminar as planilhas e as pilhas de papeis que são usadas atualmente. Isso possibilitará ao funcionário um retorno rápido das informações, otimizando seu trabalho e atendendo ao paciente de forma mais ágil. O sistema pode tornar o controle mais confiável que o atualmente utilizado, tornando a entrega do medicamento ao paciente mais hábil e o controle mais rigoroso. Esse trabalho visa à redução das dificuldades anteriormente descritas e ainda presentes neste local. Para isso, serão criadas as seguintes funcionalidades: Cadastro de usuários; Cadastro de medicamentos; Cadastro de pacientes; Cadastro de responsáveis; Controle de entrada de medicamentos que chegam à unidade; Controle de retirada de medicamentos que são entregues aos pacientes; Relatório de retirada de medicamentos; O objetivo principal desse sistema de controle é tornar o sistema mais confiável, facilitando os cadastros, agilizando as buscas e atendimento e principalmente poupando o tempo do funcionário e do paciente. A metodologia utilizada será caracterizada pelo levantamento bibliográfico das tecnologias utilizadas, fichas de cadastros e das planilhas eletrônicas que serão disponibilizadas pelo Ambulatório Municipal de Saúde Mental de Promissão.

9 Implementar um Banco de Dados SQL Server; Implementar um protótipo de sistema; Analisar os resultados obtidos. O levantamento bibliográfico será focado na área de Banco de Dados e Delphi, através da revisão de literatura existente sobre o tema e consultas via internet. No capítulo um são abordado as tecnologias utilizadas para o desenvolvimento do trabalho, desde ferramentas aplicadas na modelagem dos diagramas e do banco de dados até a implementação do sistema desktop. O capítulo dois trata-se da análise de negócio. Nele são compreendidas as especificações do projeto, onde são detalhadas as etapas necessárias para a construção do software. Fornecendo ainda a descrição dos problemas identificado através de uma análise de mercado, oferecendo uma visão geral do produto a ser desenvolvido e suas principais características. No capitulo três, é apresentado a especificação do caso de uso com seus fluxos, subfluxos e cenário chave do software desenvolvido, tais como, Efetuar login, efetuar retirada, efetuar entrada, lançar pedido, manter paciente, manter usuário, manter medicamento, emitir relatório, manter responsável e lançar doação. No capítulo quatro são apresentados os diagramas do software, tais como, atividades, sequência e projeto de modelagem dos dados. No capitulo cinco são apresentadas as telas do sistema desktop, utilizando a visão do usuário e parte de suas funcionalidades.

10 1 FUNDAMENTAÇÃO TEORICA Nesse capítulo são abordadas todas as tecnologias utilizadas para o desenvolvimento de um sistema para o controle de entrada e saída e medicamentos, assim como o controle dos pacientes. 1.1 BANCO DE DADOS De acordo com o Elmasri e Navathe (2011), dados são observações documentadas ou resultado de medições podem ser registradas e que possuem significado implícito, exemplo: nome, endereço, telefones de pessoas que podem ser armazenados em uma agenda. É uma entidade na qual é possível armazenar dados de maneira estruturada e com a menor redundância possível. Um banco de dados permite a disposição dos dados aos usuários para uma consulta, uma introdução ou uma atualização, assegurando-se dos direitos atribuídos a estes últimos 1.2 SQL A Structured Query Language (SQL) ou Linguagem de Consulta Estruturada, inicialmente chamada de SEQUEL (Structured English Query Language) foi projetada e implementada pela IBM Research como um sistema experimental de um banco de dados relacional, o SISTEMA R. (ELMASRI; NAVATHE, 2005, p. 148). A SQL é padronizada pelo American National Standards Institute (ANSI) e pela International Standards Organization (ISO). De acordo com Meira (2013), a SQL é uma linguagem composta por comandos de manipulação, definição e controle de dados. Groof e Weinberg (1999) definem ainda a SQL como uma ferramenta de organização, gestão e recuperação de dados armazenados por um banco de dados, funcionando como um tipo específico de base de dados, chamada de banco de dados relacional.

11 O programa escolhido para a implementação do sistema foi a SQL Server 2008 Express, edição gratuita da Microsoft que constitui uma plataforma de dados para o aprendizado e a criação de aplicativos de desktop e pequenos aplicativos de servidor, e para redistribuição por Independent Software Vendor (ISVs). O Microsoft SQL Server 2008 Express é um sistema de gerenciamento de dados, que oferece um conjunto de recursos para a implementação de um banco, seja ele utilizado para aplicativos incorporados, aplicativos leves da Web ou repositórios de dados locais, fornecendo ainda ferramentas adicionais que podem ser executadas no prompt de comando. (MICROSOFT, 2014) O SQL Server Management Studio é um ambiente de desenvolvimento integrado para acessar, configurar, gerenciar e administrar todos os componentes do SQL Server, reúne um amplo grupo de ferramentas gráficas com um editor de scripts para fornecer acesso ao SQL Server para desenvolvedores e administradores de todos os níveis de conhecimento. (MICROSOFT, 2014) 1.3 DELPHI O Delphi é uma ferramenta de desenvolvimento de aplicativos baseada na linguagem Object Pascal. Desenvolvido pela empresa Borland Software Corporation em 1995 para ser instalado, inicialmente, em sistemas da Microsoft (Windows 3.11 e posteriormente Windows95). Ele foi criado seguindo o conceito RAD e seu ambiente de desenvolvimento é Integrated Development Environment Ambiente de Desenvolvimento Integrado (IDE). (BARCELOS, 2012) Nesse ambiente a forma de construção da interface dos programas segue o padrão de janelas com todas as facilidades que elas possuem. Assim, durante todo o desenvolvimento, o programador visualiza o formato de sua aplicação, podendo arrastar e soltar componentes que irão compor sua interface. (BARCELOS, 2012) Como dito anteriormente, o Delphi utiliza Object Pasçal, uma linguagem híbrida que manteve o melhor da programação estruturada associada às facilidades das interfaces. As características mais marcantes dessa linguagem são: Tratamento de exceção e programação multithread.(barcelos, 2012) No ambiente multithread, cada processo pode responder a várias solicitações concorrentemente ou mesmo simultaneamente, se houver mais de um processador.

12 Com esse mix de vantagens a programação, para ambiente desktop, ganhou muitos adeptos e várias empresas migraram gradativamente para sistemas desenvolvidos nessa plataforma. (BARCELOS, 2012) Diversas versões foram lançadas ao longo de décadas, entre as quais destacam-se: a versão Delphi 4 com Interface Gráfica melhorada, barra de ferramentas e janelas de encaixe, IDE com recursos diferenciados; à versão Delphi 5 foram integrados componentes para ambiente multicamada e internet; Delphi 7 com a suíte Intraweb, surgia a possibilidade de desenvolver aplicações web para rodar num servidor Apache com muito mais facilidade e Delphi 2009: Suporte a PNG e suporte para interface do Vista, aplicações para web com outras tecnologias como PHP,.NET, etc. (BARCELOS, 2012) O programa escolhido para o desenvolvimento do sistema foi Embarcadero Delphi XE, é um ambiente integrado para o desenvolvimento (IDE) composto por compilador, editor de texto, ferramenta de depuração e alguns acessórios que trazem recursos a mais ao processo de desenvolvimento. Também é atribuída para esta ferramenta uma característica fundamental, Rapid Application Development (RAD). Ou seja, à medida que os componentes visuais disponíveis pelo IDE são incluídos em seu projeto o Delphi XE escreve o código-fonte referente a esses componentes na respectiva linguagem escolhida para o desenvolvimento. (CECILIA, 2011) 1.3.1 Fortes Report O Fortes Report é um gerador de relatórios disponibilizado como pacote de componentes para Delphi.Nele, os relatórios são compostos de bandas que têm funções específicas no fluxo de impressão sendo definidos agrupamentos, subníveis e totalizações simplesmente pela relação hierárquica entre as bandas. Além disso, o Fortes Report possui uma ampla paleta de componentes para texto, gráficos, fórmulas, códigos de barra, filtros e layout. Com este componente é possível exportar qualquer relatório em um documento de alta fidelidade no formato PDF, Portable Document Format. (FORTES, 2011) O Report Designer integrado possibilita que se faça relatórios estilizados de forma intuitiva com o designer integrado ao IDE do Delphi. Arrastando componentes

13 da paleta, usando o object inspector e todas as facilidades do IDE como se estivesse modelando um novo form. (FORTES, 2011) Peças de design repetidas em vários relatórios como bandas de cabeçalho e painéis complexos, podem ser desenhadas apenas uma vez utilizando frames comuns do Delphi. Esses frames podem ser então compartilhados entre os relatórios, gerando reaproveitamento de código. (FORTES, 2011) 1.4 ASTHA COMMUNITY É importante dizer que ao se falar de processo no contexto da Engenharia de Software, há uma referência direta às etapas de criação e conclusão de um software, desde a sua aprovação ao treinamento do usuário do produto final. (MEDEIROS, 2004) O Unified Modeling Language(UML) ou Linguagem de Modelagem Unificada, é definido pelos autores Silva e Videira (2011) como uma linguagem diagramática, utilizável para especificação, visualização e documentação de sistemas de software. Silva e Videira (2011) apontam como características do UML: Independencia de domínio de aplicação; Independencia de processo ou metodologia de desenvolvimento; Independencia das ferramentas de modelação; Apresentação de mecanismos de extensão; Agregamento de diferentes diagramas/técnicas dispersos por diferentes linguagens. Assim, o UML não é um processo de desenvolvimento de softwares, mas sim uma linguagem. Por meio de diagramas, esta linguagem deve fazer a comunicação entre duas partes: o desenvolvedor do software e o cliente que pediu a ferramenta. (MEDEIROS, 2004) Considerando as ferramentas utilizadas, os diagramas do UML serão desenvolvidos com o auxílio do Astah Community uma ferramenta gratuita voltada para a modelagem de diagramas UML. Além do Astah Community, existem outras. Três versões: Astah UML, Astah Professional e Astah Share que disponibilizam

14 outras funcionalidades além da modelagem UML, porém, sua licença é comercial. (HÜBNER, 2014) A escolha da ferramenta Astah Community deve-se ao fato de sua praticidade e simplicidade em elaborar diagramas, como por exemplo: diagramas de classe, caso de uso, sequência, atividade, comunicação, componentes, implantação, estrutura de composição, objetos e pacotes. (HÜBNER, 2014).

15 2 ANÁLISE E PROJETO DE SISTEMA 2.1 ANÁLISE DE NEGÓCIO A análise de negócio é o conjunto de atividades e técnicas utilizadas para servir como ligação entre partes interessadas no intuito de compreender a estrutura, políticas e operações de uma organização e para recomendar soluções que permitam que a organização alcance suas metas. (SIMOES, 2009, p.3) É possível, com a análise de negócio, identificar falhas no processo de negócios e/ou tarefas passiveis de melhorias. Segundo Kerber (2009, p.4) Uma condição ou capacidade que deve ser alcançada ou possuída por uma solução ou componente de solução para satisfazer um contrato, padrão, especificação ou outros documentos formalmente imposto Para melhor organização de entrada e saída de medicamentos é feito um modelo que auxilia no processo de compreensão do sistema. Para essa análise de negócio foi utilizado o modelo de caso de uso, que é um modelo das funcionalidades do sistema utilizado para identificar os papeis e os medicamentos na organização. 2.1.1 Instrução do Problema Buscando adaptar as exigências do mercado e melhorar a eficiência no atendimento aos pacientes surgiu a necessidade de um sistema para suprir as dificuldades dos funcionários, que utilizam diversas planilhas eletrônicas para controle interno e entrega dos medicamentos de excepcionais ou de alto custo. O termo medicamentos excepcionais, foi estabelecido em 1982 por meio da Portaria Interministerial nº 3 MPAS/MS/MEC, de 15 de dezembro de 1982 (BRASIL, 1982). Conforme o Manual Técnico dos Protocolos Clínicos e Diretrizes Terapêuticas entendia-se que os medicamentos do Programa de Medicamentos

16 Excepcionais (BRASIL, 2002b) são aqueles de elevado valor unitário, ou que, pela cronicidade do tratamento, se tornam excessivamente caros para o paciente. O Ministério da Saúde, até aquele momento, não havia publicado nenhuma legislação para constituir um programa específico para financiamento de tais medicamentos. Tampouco, definiu o conceito de medicamentos de alto custo, apesar de que tais definições, ainda informais, foram importantes para a constituição do Componente de Medicamentos de Dispensação Excepcional. O Componente de Medicamento de Dispensação Excepcional é uma estratégia da Política de Assistência Farmacêutica, que tem por objetivo disponibilizar medicamentos no âmbito do Sistema Único de Saúde para tratamento de agravos inseridos nos seguintes critérios: Doença rara ou de baixa prevalência, com indicação de uso de medicamento de alto valor unitário ou que, em caso de uso crônico ou prolongado, seja um tratamento de custo elevado; Doença prevalente, com uso de medicamento de alto custo unitário ou que, em caso de uso crônico ou prolongado, seja um tratamento de custo elevado desde que haja tratamento previsto para o agravo no nível da atenção básica, ao qual o paciente apresentou necessariamente intolerância, refratariedade ou evolução para quadro clínico de maior gravidade, ou o diagnóstico ou estabelecimento de conduta terapêutica para o agravo estejam inseridos na atenção especializada. Ao dirigir-se pela primeira vez ao Ambulatório de Saúde Mental de Promissão, o paciente, portando receita com prescrição de medicamento de alto custo, recebe orientações do funcionário tais como: Informações relativas ao funcionamento do Programa de Medicamentos Excepcionais; Preenchimento do Laudo de Solicitação, Avaliação e Autorização de Medicamento (LME) do Componente Especializado da Assistência Farmacêutica - pelo médico solicitante; Cópia de exames, quando exigidos pelo Programa para determinados medicamentos, que comprovem ou justifiquem seu uso; Cópia dos documentos pessoais do paciente e do responsável, em caso de paciente menor ou incapaz.

17 Após toda documentação completa necessária, o funcionário dará abertura no processo do paciente junto à Farmácia de Alto Custo de Bauru, pois o município de Promissão é integrante do Departamento Regional de Saúde (DRS) VI - Bauru. 2.1.2 Análise de Mercado A cidade de Promissão não conta com um sistema para controlar os medicamentos. O Ambulatório de Saúde Mental, atualmente, não dispõe de um sistema para controlar a dispensação dos medicamentos de alto custo na cidade. A construção de um sistema tem o intuito de auxiliar no processo de controle de entrada e principalmente saída de medicamentos na unidade, auxiliando a organização dos dados, mantendo-os no computador e evitando o acumulo de recibos nos prontuários dos pacientes. 2.1.3 Atores e Envolvidos no Processo Os funcionários responsáveis por cadastros, consultas e controle de entrada e saída de medicamentos: Escriturário: Responsável por cadastrar, entrada e saída e medicamentos, controlar as renovações, cadastrar novos usuário e cadastrar novos paciente no sistema. Farmacêutico: Pesquisará no sistema situação do paciente para ver se consta pendência de documentação, vai poder consultar pacientes e também remédios existentes. 2.1.4 Descrição do Ambiente Atual A retirada dos medicamentos excepcionais é realizada semanalmente na Farmácia de Alto Custo. Os medicamentos retirados referem-se aos pedidos feitos na semana anterior, que são entregues na Farmácia através de malotes. Os pedidos dos medicamentos a serem entregues na Farmácia, são separados pelo funcionário do Ambulatório, de acordo com a situação do processo:

18 Processo inicial: nestes malotes, como o nome já diz, trata-se do envio da documentação para abertura de processo dos pacientes a serem cadastrados no Programa de Medicamentos Excepcionais. A inclusão do paciente no Programa depende da aprovação de um médico auditor, que avaliará por meio do Laudo de Solicitação, Avaliação e Autorização de Medicamento (LME) e exames, quando exigido pelo próprio Programa; LME: por meio deste laudo o médico solicita o medicamento para o paciente por três meses. Para o quarto mês é necessário ser enviado o LME para confirmação do medicamento e quantidade para o trimestre seguinte, ou quando há alteração na dosagem ou até mesmo mudança do medicamento. Neste caso, a documentação não passa por auditoria; Renovação: ao término do sexto mês, quando há continuidade no tratamento, o paciente precisar renovar seu processo. A renovação é similar ao início do processo com relação à documentação a ser enviada, inclusive quanto aprovação pela auditoria médica para confirmação e continuação do tratamento. A diferença é que para a renovação a quantidade de exames pode ser menor ou nula, e neste caso, o paciente já tem seu cadastro na Farmácia de Alto Custo; Receitas avulsas: refere-se ao pedido simples do medicamento, na qual o processo já passou por aprovação da auditora e não está em confirmação nem alteração do medicamento; Colírio: malote específico para pacientes que fazem uso de colírios para glaucoma. Refere-se a um processo com tratamento distinto, pois o início do processo é feito em hospital de referência e sua documentação não passa por auditoria na Farmácia de Alto Custo. Para estes pacientes, o Ambulatório não necessita enviar LME nem exames comprobatórios, e seu processo tem validade de um ano, tendo como base a data da receita médica. A casa possui apenas dois computadores, neles são gravados e armazenados os dados dos pacientes que necessitam dos medicamentos, é neles que também é feito o backup ou seja grava as informações para que não haja perda. O cadastro dos pacientes é feito em fichas que ficam armazenadas em pastas, chamadas de prontuários, onde também são armazenados: os recibos do medicamento recebido da matriz de Bauru, as receitas médicas, que são solicitadas mensalmente, e as cópias dos documentos do paciente.

19 A listagem de medicamentos vem de Bauru em uma planilha eletrônica, e nela constam todos os medicamentos que são disponibilizados pela Saúde Mental de Promissão. Para dar início ao processo paciente vai até a unidade com a receita médica, retira o laudo que é a ficha de autorização e então retorna ao médico para que o mesmo possa preencher o laudo de solicitação e dar início ao processo. Em outros casos, o próprio médico entrega o laudo preenchido para evitar que o paciente volte ao consultório. O escriturário preenche a planilha com os dados da receita para efetuar o pedido na matriz em Bauru, que são enviados semanalmente, e os mesmos dados em outra planilha para controle interno. Cada processo do paciente tem validade de seis meses e pode ser renovado; no primeiro mês é feita a abertura do processo e enviado um Laudo de Solicitação, Avaliação e Autorização de Medicamento (LME), que é renovado a cada três meses, no segundo e terceiro mês para a retirada do medicamento o paciente apresenta somente a receita médica, já no quarto mês, ele traz novamente o LME, para saber se não houve alteração de medicamento. Esses processos são feitos mensalmente e quando chegar ao sexto mês será pedida a renovação e voltara para o primeiro mês, dando continuidade com o medicamento passado pelo médico. O LME vem para a unidade somente com dados dos medicamentos preenchidos, ficando para o funcionário a responsabilidade de procurar os dados do paciente nos mais de 800 prontuários, para o seu preenchimento. Para realizar consultas específicas, como por exemplo, quais remédios foram entregues em determinada data ou quais os medicamentos o paciente já retirou na unidade o funcionário tem que fazer uma solicitação para a matriz em Bauru. A implantação de um sistema tornará o trabalho para os funcionários da unidade mais ágil e manteria as informações em um único Banco de Dados, diminuindo quantidade de planilhas eletrônicas, e a necessidade de fazer buscas em grande quantidade de prontuários.

20 2.2 VISÃO GERAL DO PRODUTO 2.2.1 Perspectiva do Produto A construção de um sistema para Saúde Mental terá como o objetivo, cadastrar funcionário no qual será o farmacêutico e escriturário, para que seja controlado quem altera dados do paciente, para fazer saída e entrada de medicamentos. Na consulta encontrada no sistema, será mostrado, quais os remédios que foram retirados seguido de sua data e hora, qual a situação do mesmo, ou seja, em qual mês do processo ele está. O principal destaque do sistema é na área de saída, onde será inserido o número pedido, depois de digitado aparecerá o nome do paciente e os medicamentos referentes ao pedido. O atendente selecionará a situação do processo, caso a situação precisar de atualizações no processo será dado a informação para que o paciente possa estar em dia com o sistema, mas caso esteja em dia o atendente finalizara colocando as informações de um ou mais remédios do qual consta na receita. Para a implementação do sistema, serão necessários a instalação do sistema nas máquinas já existentes na unidade, e um servidor de Banco de Dados, onde ficarão armazenados todos os dados referentes aos medicamentos e pacientes, assim como os pedidos dos medicamentos. 2.2.2 Características Cadastro de funcionário, para obter o controle de quem faz as mudanças no sistema e de quem trabalha no local, esse cadastro será realizado pelo escriturário e auxiliar. Cadastro de paciente, realizado pelo escriturário e auxiliar, onde terá as informações pessoais como nome, endereço, número do cartão e entre outros dados necessários. Cadastro de medicamentos, também realizado pelo escriturário e auxiliar. O Cadastro dos medicamentos terá suas dosagens, como usar, uma descrição do produto, em qual situação usar.

21 Consulta no sistema, feito por todos os funcionários. A consulta tem como objetivo mostrar um determinado paciente ou medicamento. Saída do sistema, realizado pelo escriturário e farmacêutico. Na saída constara, paciente e número do pedido, remédio retirado, data e hora. 2.3 ANÁLISE DE REQUISITOS 2.3.1 Análise de Requisitos Funcionais A análise de requisitos é a fase onde se identifica o que o cliente deseja e o que espera do sistema. Requisitos definem a estrutura e o comportamento do sistema. O desenvolvimento do sistema para controle de medicamentos da Casa da Saúde Mental de Promissão tem como intuito permitir a agilidade no preenchimento dos medicamentos que serão solicitados à matriz, eliminando assim, o uso de planilhas eletrônicas, facilitar a consulta dos medicamentos disponíveis para a entrega aos pacientes e manter em um único local os dados dos pacientes, medicamentos e funcionários. Para isso deseja-se implementar as funcionalidades de cadastros e consulta: Pacientes; Medicamentos; Usuários; Responsáveis; Pedidos; Deseja-se também implementar as funcionalidades de: Relatório de Entrada; Relatório de Saída 2.3.2 Diagrama de Caso de Uso O diagrama de casos de uso é feito com os casos de uso, atores e relacionamentos que os envolvem (SILVIA, 2007). Casos de uso são etapas executadas para realização de outras atividades.

22 Estas são atividades maiores que encerram outras menores. (MEDEIROS, 2004) Eles são executados por atores, que nada mais são como eram chamados em análise estruturada, Entidades Externas. Eles não são necessariamente pessoas físicas, podem ser máquinas, bancos etc. (MEDEIROS, 2004) A seguir, encontra-se o diagrama de casos de uso do software desenvolvido. Figura 2.1 Diagrama de Casos de Uso Fonte: Elaborado pelos autores, 2014.

23 3 CASOS DE USO E SUAS ESPECIFICAÇÕES Este capítulo é composto por casos de uso e suas especificações para elaboração do Sistema de Informação proposto. Um caso de uso representa uma funcionalidade e não faz referência de como é executado. No capítulo anterior pode ser encontrado o diagrama de caso de uso e a seguir, há o detalhamento de cada uma das funcionalidades dos casos de uso especificados. 3.1 ESPECIFICAÇÃO DE CASO DE USO: EFETUAR LOGIN Este caso de uso tem como principal objetivo efetuar o login de um usuário no sistema. Dois atores podem atuar neste caso de uso: FARMACÊUTICO/ESCRITURÁRIO. Fluxo Básico de Eventos FB1 INICIAR CASO DE USO Esse caso de uso é iniciado quando o FARMACÊUTICO/ESCRITURÁRIO executa o sistema. FB2 INSERIR DADOS A(O) FARMACÊUTICO/ESCRITURÁRIO adiciona o login e senha. FB3 CONFIRMAR LOGIN/SENHA Se os dados forem válidos a(o) FARMACÊUTICO/ESCRITURÁRIO, terá acesso ao sistema. FB4 ENCERRAR CASO DE USO Esse caso de uso é encerrado normalmente. Fluxos Alternativos Área de Funcionalidade FB3 CONFIRMAR LOGIN Primeiro Fluxo Alternativo LOGIN/SENHA INVÁLIDO Ao adicionar os dados no sistema, caso o login/senha não forem válidos o sistema emitirá uma mensagem informando o usuário.

24 Cenários Chaves CnC1 Fluxo Básico Esse fluxo básico é composto pelos passos FB1 a FB4 do Fluxo Básico. CnC2 LOGIN/ SENHA INVÁLIDO FB1 INICIAR CASO DE USO FB2- INSERIR DADOS FB3 CONFIRMAR LOGIN/SENHA LOGIN/SENHA INVÁLIDO FB4 ENCERRAR CASO DE USO 3.2 ESPECIFICAÇÃO DE CASO DE USO: EFETUAR RETIRADA Este caso de uso tem como principal objetivo efetuar a retirada de medicamentos aos pacientes. Dois atores podem atuar neste caso de uso: FARMACÊUTICO/ESCRITURÁRIO. Fluxo Básico (FB) de Eventos FB1 INICIAR CASO DE USO Esse caso de uso é iniciado quando o FARMACÊUTICO/ESCRITURÁRIO seleciona a opção RETIRADA no sistema. FB2 INSERIR DADOS OFARMACÊUTICO ou ESCRITURÁRIO começa a informar os dados ao sistema, inserindo os dados necessários para gerar a retirada do medicamento. FB3 CONFIRMAR RETIRADA OFARMACÊUTICO ou ESCRITURÁRIO conclui o preenchimento das informações e o sistema verifica a validade dos dados. FB4 ENCERRAR CASO DE USO Esse caso de uso é encerrado normalmente. Fluxos Alternativos Área de Funcionalidade FB3 CONFIRMAR RETIRADA Primeiro Fluxo Alternativo PEDIDO NÃO ENCONTRADO - Ao efetuar o preenchimento do formulário, caso o paciente não possua um pedido cadastrado, o sistema emitirá uma mensagem de aviso ao usuário do sistema informando a situação.

25 Primeiro Subfluxo CONSULTAR RETIRADA esta funcionalidade é iniciada quando o FARMACÊUTICO ou ESCRITURÁRIO seleciona a guia PESQUISAR na opção RETIRADA no sistema e este apresenta um histórico com todos os pedidos retirados. Segundo Subfluxo CANCELAR RETIRADA Esse caso de uso é cancelado quando a FARMACÊUTICO ou ESCRITURÁRIO seleciona a opção CANCELAR no sistema. Cenários Chaves CnC1 Fluxo Básico Esse fluxo básico é composto pelos passos FB1 a FB4 do Fluxo Básico. CnC2 PEDIDO NÃO ENCONTRADO FB1 INICIAR CASO DE USO FB2 INSERIR DADOS FB3 CONFIRMAR RETIRADA PEDIDO NÃO ENCONTRADO FB4 ENCERRAR CASO DE USO CnC2 CONSULTAR RETIRADA FB1 INICIAR CASO DE USO CONSULTAR RETIRADA FB3 CONFIRMAR RETIRADA FB4 ENCERRAR CASO DE USO CnC3 CANCELAR RETIRADA FB1 INICIAR CASO DE USO CANCELAR RETIRADA FB4 ENCERRAR CASO DE USO Pontos de Extensão Cadastrar Pedido No fluxo básico FB3 CONFIRMAR RETIRADA, caso o paciente não tenha um pedido cadastrado, executar o Ponto de Extensão <<Cadastrar Pedido>> Cadastrar Medicamento

26 No fluxo básico FB3 SELECIONAR MEDICAMENTO, caso o medicamento não esteja cadastrado, executar o Ponto de Extensão <<Cadastrar Medicamento>> 3.3 ESPECIFICAÇÃO DE CASO DE USO: EFETUAR ENTRADA Este caso de uso tem como principal objetivo efetuar a entrada de algum medicamento à unidade. Dois atores podem atuar neste caso de uso: FARMACÊUTICO ou o ESCRITURÁRIO. Fluxo Básico de Eventos FB1 INICIAR CASO DE USO Esse caso de uso é iniciado quando a FARMACÊUTICO ou ESCRITURÁRIO seleciona a opção ENTRADA. FB2 INSERIR DADOS OFARMACÊUTICO ou o ESCRITURÁRIO começa o cadastro do formulário, inserindo os dados necessários para entrada do medicamento. FB3 CONFIRMAR ENTRADA OFARMACÊUTICO ou o ESCRITURÁRIO conclui o cadastro do formulário e o sistema verifica a validade dos dados. FB4 ENCERRAR CASO DE USO Caso de uso é encerrado normalmente. Fluxos Alternativos Área de Funcionalidade FB3 CONFIRMAR ENTRADA Primeiro Fluxo Alternativo MEDICAMENTO NÃO CADASTRADO Ao iniciar o preenchimento do formulário, caso o medicamento não esteja cadastrado, será necessário o caso de uso CADASTRAR MEDICAMENTO. Primeiro Subfluxo CONSULTAR ENTRADA esta funcionalidade é iniciada quando o FARMACÊUTICO ou o ESCRITURÁRIO seleciona a opção PESQUISAR no sistema e este apresenta um histórico com todas as entradas. Segundo Subfluxo

27 CANCELAR ENTRADA Caso de uso cancelado quando o FARMACÊUTICO ou o ESCRITURÁRIO seleciona a opção CANCELAR, então a entrada é cancelada. Cenários Chaves CnC1 Fluxo Básico Esse fluxo básico é composto pelos passos FB1 a FB4 do Fluxo Básico. CnC2 MEDICAMENTO NÃO CADASTRADO FB1 INICIAR CASO DE USO FB2 INSERIR DADOS FB3 CONFIRMAR ENTRADAMEDICAMENTO NÃO CADASTRADO FB4 ENCERRAR CASO DE USO CnC3 CONSULTAR ENTRADA FB1 INICIAR CASO DE USO CONSULTAR ENTRADA FB3 CONFIRMAR ENTRADA FB4 ENCERRAR CASO DE USO CnC4 CANCELAR ENTRADA FB1 INICIAR CASO DE USO CANCELAR ENTRADA FB4 ENCERRAR CASO DE USO Pontos de Extensão Cadastrar Medicamentos No fluxo básico FB2 - INSERIR DADOS, caso o medicamento não esteja cadastrado, executar o Ponto de Extensão <<Cadastrar Medicamento>> 3.4 ESPECIFICAÇÕES DE CASO DE USO: LANÇAR PEDIDO Este caso de uso tem como principal objetivo lançar o pedido efetuado por um (a) paciente. Dois atores podem atuar neste caso de uso: FARMACÊUTICO ou o ESCRITURÁRIO. Fluxo Básico de Eventos

28 FB1 INICIAR CASO DE USO Esse caso de uso é iniciado quando o FARMACÊUTICO ou o ESCRITURÁRIO seleciona a opção PEDIDO. FB2 INSERIR DADOS O FARMACÊUTICO ou o ESCRITURÁRIO começa o cadastro do formulário, Selecionando o Paciente e selecionando o medicamento que está sendo solicitado e a quantidade. FB3 CONFIRMAR PEDIDO O FARMACÊUTICO ou o ESCRITURÁRIO conclui o preenchimento do formulário e o sistema verifica a validade dos dados. FB4 ENCERRAR CASO DE USO Esse caso de uso é encerrado normalmente. Fluxos Alternativos Área de Funcionalidade FB3 CONFIRMAR PEDIDO Primeiro Fluxo Alternativo PACIENTE NÃO CADASTRADO Caso o paciente não esteja cadastrado, será necessário primeira mente efetuar o cadastro na opção PACIENTE. Cenários Chaves CnC1 Fluxo Básico Esse fluxo básico é composto pelos passos FB1 a FB4 do Fluxo Básico. CnC2 PACIENTE NÃO CADASTRADO FB1 INICIAR CASO DE USO FB2 - INSERIR DADOS FB3 CONFIRMAR PEDIDO PACIENTE NÃO CADASTRADO. FB4 ENCERRAR CASO DE USO Pontos de Extensão Efetuar Pagamento No fluxo básico FB2 INSERIR DADOS, caso o paciente não esteja cadastrado executar o ponto de extensão <<Cadastrar Paciente>>

29 3.5 ESPECIFICAÇÃO DE CASO DE USO: MANTER PACIENTE Este caso de uso tem como principais objetivos o cadastro, atualizar, excluir e selecionar dados de determinado paciente. Dois atores podem atuar neste caso de uso: FARMACÊUTICO ou o ESCRITURÁRIO. Fluxo Básico de Eventos FB1 INICIAR CASO DE USO Esse caso de uso é iniciado quando o FARMACÊUTICO ou o ESCRITURÁRIO seleciona a opção PACIENTE/NOVO. FB2 INSERIR DADOS Esse caso de uso é iniciado quando o FARMACÊUTICO ou o ESCRITURÁRIO começa o cadastro do Paciente. (Ex.: nome, CPF, RG etc.). FB3 CONFIRMAR CADASTRO Esse caso de uso é iniciado quando o/a FARMACÊUTICO ou o ESCRITURÁRIO conclui o cadastro do Paciente. FB4 ENCERRAR CASO DE USO Caso de uso é encerrado normalmente. Fluxos Alternativos Área de Funcionalidade FB3 CONFIRMAR CADASTRO Primeiro Fluxo Alternativo CADASTRO EXISTENTE Ao efetuar o cadastro caso este já exista, o sistema emitirá uma mensagem de erro para o usuário. Primeiro Subfluxo ATUALIZAR CADASTRO Esse caso de uso é editado quando o FARMACÊUTICO ou o ESCRITURÁRIO seleciona o paciente no sistema, podendo alterar qualquer dado da Paciente. Segundo Subfluxo EXCLUIR CADASTRO Esse caso de uso é excluído quando o FARMACÊUTICO ou o ESCRITURÁRIO seleciona a opção EXCLUIR no sistema, podendo eliminar o cadastro do Paciente. Cenários Chaves CnC1 Fluxo Básico Esse fluxo básico é composto pelos passos FB1 a FB4 do Fluxo Básico

30 CnC2 CADASTRO EXISTENTE FB1 INICIAR CASO DE USO FB2 INSERIR DADOS FB3 CONFIRMAR CADASTRO EXISTENTE FB4 ENCERRAR CASO DE USO CnC3 ATUALIZAR CADASTRO FB1 INICIAR CASO DE USO SELECIONAR CADASTRO FB3 CONFIRMAR CADASTRO FB4 ENCERRAR CASO DE USO CnC5 EXCLUIR CADASTRO FB1 INICIAR CASO DE USO SELECIONAR CADASTRO EXCLUIR CADASTRO FB2 INSERIR DADOS FB4 ENCERRAR CASO DE USO 3.6 ESPECIFICAÇÃO DE CASO DE USO: MANTER USUÁRIO Este caso de uso tem como principal objetivo iniciar o cadastro, atualizar, excluir e conceder permissão aos dados de um determinado usuário. Dois atores podem atuar neste caso de uso: FARMACÊUTICO ou o ESCRITURÁRIO. Fluxo Básico de Eventos FB1 INICIAR CASO DE USO Esse caso de uso é iniciado quando o FARMACÊUTICO ou o ESCRITURÁRIO.Seleciona a opção USUÁRIO. FB2 INSERIR DADOS Esse caso de uso é iniciado quando o FARMACÊUTICO ou o ESCRITURÁRIO começa o cadastro do Usuário. (ex.: nome, login, senha etc.). FB3 CONFIRMAR CADASTRO Esse caso de uso é iniciado quando o FARMACÊUTICO ou o ESCRITURÁRIO conclui o cadastro do Usuário. FB4 ENCERRAR CASO DE USO Esse caso de uso é encerrado normalmente. Fluxos Alternativos Área de Funcionalidade FB3 CONFIRMAR CADASTRO

31 Primeiro Fluxo Alternativo CADASTRO EXISTENTE Ao efetuar o cadastro caso ele já exista, o sistema emitirá uma mensagem de erro para o Usuário. Primeiro Subfluxo ATUALIZAR CADASTRO Esse caso de uso é editado quando o FARMACÊUTICO ou o ESCRITURÁRIO seleciona o usuário no sistema, podendo alterar qualquer dado do Usuário. Segundo Subfluxo EXCLUIR CADASTRO - Esse caso de uso é excluído quando o FARMACÊUTICO ou o ESCRITURÁRIO seleciona a opção EXCLUIR e elimina o cadastro do Usuário. Cenários Chaves CnC1 Fluxo Básico Esse fluxo básico é composto pelos passos FB1 a FB4 do Fluxo Básico CnC2 CADASTRO EXISTENTE FB1 INICIAR CASO DE USO FB2 INSERIR DADOS FB3 CONFIRMAR CADASTRO EXISTENTE FB4 ENCERRAR CASO DE USO CnC3 EDITAR CADASTRO FB1 INICIAR CASO DE USO SELECIONAR CADASTRO EDITAR CADASTRO FB2 INSERIR DADOS FB3 CONFIRMAR CADASTRO FB4 ENCERRAR CASO DE USO CnC4 EXCLUIR CADASTRO FB1 INICIAR CASO DE USO SELECIONAR CADASTRO EXCLUIR CADASTRO FB2 INSERIR DADOS FB4 ENCERRAR CASO DE USO

32 3.7 ESPECIFICAÇÃO DE CASO DE USO: MANTER MEDICAMENTO Este caso de uso tem como principal objetivo iniciar o cadastro, verificar e atualizar os dados dos medicamentos no sistema. Dois atores podem executar este caso de uso: FARMACÊUTICO ou o ESCRITURÁRIO que terá acesso ao sistema. Fluxo Básico de Eventos FB1 INICIAR CASO DE USO Esse caso de uso é iniciado quando a FARMACÊUTICO ou o ESCRITURÁRIO seleciona a opção MEDICAMENTOS. FB2 INSERIR DADOS OFARMACÊUTICO ou o ESCRITURÁRIO começa o preenchimento do formulário de dados do medicamento. FB3 CONFIRMAR DADOS OFARMACÊUTICO ou o ESCRITURÁRIO conclui o preenchimento do formulário e o sistema verifica a validade dos dados. FB4 ENCERRAR CASO DE USO O caso de uso é encerrado normalmente. Fluxos Alternativos Área de Funcionalidade FB3 CONFIRMAR DADOS Primeiro Fluxo Alternativo CADASTRO EXISTENTE Ao confirmar o formulário, caso haja um medicamento já com esse nome, o sistema emitirá uma mensagem de aviso ao usuário do sistema. Primeiro Subfluxo EDITAR CADASTRO OFARMACÊUTICO ou o ESCRITURÁRIO seleciona o medicamento no sistema, podendo alterar qualquer dado do mesmo. Segundo Subfluxo CONSULTAR CADASTRO OFARMACÊUTICO ou o ESCRITURÁRIO seleciona a opção PESQUISAR no sistema e este apresenta os dados dos medicamentos já cadastrados. Cenários Chaves CnC1 CADASTRO EXISTENTE FB1 INICIAR CASO DE USO FB2 INSERIR DADOS FB3 CONFIRMAR CADASTRO EXISTENTE

33 FB4 ENCERRAR CASO DE USO CnC2 EDITAR CADASTRO FB1 INICIAR CASO DE USOEDITAR CADASTRO FB2 INSERIR DADOS FB3 CONFIRMAR CADASTRO FB4 ENCERRAR CASO DE USO CnC3 CONSULTAR CADASTRO FB1 INICIAR CASO DE USO CONSULTAR CADASTRO FB4 ENCERRAR CASO DE USO 3.8 ESPECIFICAÇÃO DE CASO DE USO: EMITIR RELATÓRIO Este caso de uso tem como principal objetivo emitir relatórios padronizados pelo usuário do sistema.dois atores podem executar este caso de uso: FARMACÊUTICO ou o ESCRITURÁRIO que terá acesso ao sistema. Fluxo Básico de Eventos FB1 INICIAR CASO DE USO Este caso de uso é iniciado quando o FARMACÊUTICO ou o ESCRITURÁRIO seleciona a opção RELATÓRIO. FB2 SELECIONAR TIPO DE RELATORIO OFARMACÊUTICO ou o ESCRITURÁRIO seleciona o tipo de relatório no menu de opções. FB3 CONFIRMAR RELATORIO O FARMACÊUTICO ou o ESCRITURÁRIO confirma os dados apresentados e escolhe entre imprimir ou salvar. FB4 ENCERRAR CASO DE USO Caso de uso é encerrado normalmente. 3.9 ESPECIFICAÇÃO DE CASO DE USO: MANTER RESPONSÁVEL Este caso de uso tem como principais objetivos o cadastro, atualizar, excluir e selecionar dados do responsável de um determinado paciente. Dois atores podem atuar neste caso de uso: FARMACÊUTICO ou o ESCRITURÁRIO.

34 Fluxo Básico de Eventos FB1 INICIAR CASO DE USO Esse caso de uso é iniciado quando o FARMACÊUTICO ou o ESCRITURÁRIO seleciona a opção RESPONSAVEL/NOVO. FB2 INSERIR DADOS Esse caso de uso é iniciado quando o FARMACÊUTICO ou o ESCRITURÁRIO começa o cadastro do responsável. Primeiramente é selecionado o paciente cadastrado previamente e depois completar as informações do formulário (ex.: nome, RG etc.). FB3 CONFIRMAR CADASTRO Esse caso de uso é iniciado quando o/a FARMACÊUTICO ou o ESCRITURÁRIO conclui o cadastro do Responsável. FB4 ENCERRAR CASO DE USO Caso de uso é encerrado normalmente. Fluxos Alternativos Área de Funcionalidade FB3 CONFIRMAR CADASTRO Primeiro Fluxo Alternativo PACIENTEINEXISTENTE Ao efetuar o INSERIR DADOS caso o paciente não esteja cadastrado, será necessário iniciar o cadastro do paciente. Primeiro Subfluxo ATUALIZAR CADASTRO Esse caso de uso é editado quando o FARMACÊUTICO ou o ESCRITURÁRIO seleciona o responsável no sistema, podendo alterar os dados do mesmo. Segundo Subfluxo EXCLUIR CADASTRO Esse caso de uso é excluído quando o FARMACÊUTICO ou o ESCRITURÁRIO seleciona a opção EXCLUIR no sistema, podendo eliminar o cadastro do responsável de um determinado paciente. Cenários Chaves CnC1 Fluxo Básico Esse fluxo básico é composto pelos passos FB1 a FB4 do Fluxo Básico CnC2 CADASTRO EXISTENTE FB1 INICIAR CASO DE USO FB2 INSERIR DADOS

35 FB3 CONFIRMAR CADASTRO INEXISTENTE FB4 ENCERRAR CASO DE USO CnC3 ATUALIZAR CADASTRO FB1 INICIAR CASO DE USO SELECIONAR CADASTRO FB2 INSERIR DADOS FB3 CONFIRMAR CADASTRO FB4 ENCERRAR CASO DE USO CnC5 EXCLUIR CADASTRO FB1 INICIAR CASO DE USO SELECIONAR CADASTRO FB2 INSERIR DADOS FB3 EXCLUIR CADASTRO FB4 ENCERRAR CASO DE USO Pontos de Extensão Cadastrar Paciente No fluxo básico FB2 INSERIR DADOS, caso o paciente não esteja cadastrado, executar o Ponto de Extensão <<Cadastrar Paciente>> 3.10 ESPECIFICAÇÃO DE CASO DE USO: LANÇAR DOAÇÃO Este caso de uso tem como principal objetivo lançar os medicamentos que não foram retirados por um (a) paciente. Dois atores podem atuar neste caso de uso: FARMACÊUTICO ou o ESCRITURÁRIO. Fluxo Básico de Eventos FB1 INICIAR CASO DE USO Esse caso de uso é iniciado quando o FARMACÊUTICO ou o ESCRITURÁRIO seleciona a opção Doação. FB2 SELECIONAR DADOS O FARMACÊUTICO ou o ESCRITURÁRIO começa selecionando o medicamento que está sendo doado. FB3 CONFIRMAR DOAÇÃO O FARMACÊUTICO ou o ESCRITURÁRIO conclui a doação após selecionar o medicamento e clicar no botão DOAR. FB4 ENCERRAR CASO DE USO Esse caso de uso é encerrado normalmente.

36 4 DIAGRAMAS E MODELAGEM DOS DADOS No decorrer deste capítulo, serão explicados e apresentados todos os diagramas necessários para a elaboração e desenvolvimento do software proposto pelo trabalho. Os diagramas apresentados são: Diagrama de Atividade, Classes e Sequencia. Na concepção de Silva e Videira (2011), a modelagem é a arte e ciência da criação de modelos de uma determinada realidade. Para BOCH (apud SILVA; VIDEIRA,2011, p.35) os benefícios oferecidos pela modelagem são: Visualização do sistema em uma situação passada, presente ou futura; Permissão para especificar a estrutura ou o comportamento do sistema; Permissão para controle e guia do processo de construção do sistema. Documentação das decisões tomadas. A seguir, será apresentado o modelo lógico, ele é para definir como o banco de dados serão implementados no SGBD nele é encontrada suas chaves primárias e estrangeiras. O modelo relacional representa os dados em um banco de dados como um conjunto de tabelas, sendo que cada delas terá seus próprios nomes únicos e cada tabela carregara seus atributos com seus respectivos nomes e domínios.

Figura 4.1 Modelo Lógico Fonte: Elaborado pelos autores, 2014. 37

Figura 4.2 Modelo Relacional Fonte: Elaborado pelos autores, 2014 38

39 4.1 DIAGRAMAS DE ATIVIDADE Diagramas de Atividade descrevem o passo a passo de cada um dos casos de uso e suas funcionalidades. Ao fazer uma breve analise dos diagramas de atividade, Medeiros (2004) explica que estes diagramas não são imprescindíveis e que mesmo sem sua confecção, o desenvolvimento do software pode ter continuidade com base apenas nos diagramas de casos de uso. Seguindo os pensamentos de Silva (2007), um diagrama de atividade representa uma parte do comportamento do sistema modelado. Um conjunto de atividade e um conjunto de ações pode ser descrito como uma atividade. O diagrama possui além dos elementos que compõem o conjunto da modelagem, os fluxos de controle que conduzem da execução de um elemento expositor de comportamento para um outro, de forma repetitiva, execução condicional e concorrência com todos os que estabelecem mais de um recurso de execução. (SILVA, 2007) De acordo com Silva (2007), o diagrama de atividade vai desde modelagem com o mais alto nível, como por exemplo a dinâmica do sistema ou a sagacidade de caso de uso, até mesmo a modelagem de mais baixo nível, como a de algoritmo de método da classe. Com o objetivo de deixar este trabalho completo e bem elaborado, optou-se pelo desenvolvimento e exposição dos diagramas de atividades baseados em todos os casos de uso, apesar de Medeiros (2004) recomendar o uso destes diagramas apenas com os cenários mais complexos. A seguir serão apresentados os diagramas desenvolvidos nesta aplicação.