FALCULDADE SEAMA ANDRÉA SILVA FERREIRA THECE LENNON RODRIGUES FREITAS
WANDERLEY TRINDADE DE SOUZA
MODELAGEM DE SISTEMA DE ATENDIMENTO LABORATORIAL: ESTUDO DE CASO DO LABORATÓRIO CENTRAL DE SAÚDE PÚBLICA - LACEN-AP
MACAPÁ 2007
ANDRÉA SILVA FERREIRA THECE LENNON RODRIGUES FREITAS
WANDERLEY TRINDADE DE SOUZA
MODELAGEM DE SISTEMA DE ATENDIMENTO LABORATORIAL: ESTUDO DE CASO DO LABORATÓRIO CENTRAL DE SAÚDE PÚBLICA - LACEN-AP
Trabalho apresentado à Coordenação de TCC do Curso de Graduação em Bacharelado de Sistemas de Informação da Faculdade SEAMA.
Orientadora: Profª. Jucicléia Marilia Nery de Castro
MACAPÁ 2007
ANDRÉA SILVA FERREIRA THECE LENNON RODRIGUES FREITAS
WANDERLEY TRINDADE DE SOUZA
MODELAGEM DE SISTEMA DE ATENDIMENTO LABORATORIAL: ESTUDO DE CASO DO LABORATÓRIO CENTRAL DE SAÚDE PÚBLICA - LACEN-AP
Trabalho avaliado como requisito parcial para a obtenção do grau de Bacharel no Curso de Sistemas de Informação da Faculdade SEAMA pela comissão formada pelos professores:
BANCA EXAMINADORA
Orientadora: Profª. Esp. Jucicléia Marilia Nery de Castro Membros: Profº. MSc. Alcides Xavier Benicasa
Profº. Esp. Carlos Clayton Nogueira Miranda
Coordenação de Sistemas de Informação 24 de novembro de 2007
DEDICATÓRIA
Dedicamos este trabalho aos nossos familiares e in memoriam a Augusto Cherfen de Sousa que o foi idealizador do primeiro sistema informatizado do LACEN e acadêmico da Faculdade SEAMA. Temos certeza de que se não fosse seu pioneirismo em implantar um sistema naquele órgão, não teríamos a oportunidade de utilizá-lo como uma das bases para o tema deste TCC.
AGRADECIMENTOS
Agradecemos primeiramente a DEUS por nos dar saúde para realização deste trabalho.
Aos nossos familiares, pai, mãe e irmãos que nos apoiaram para a realização deste trabalho.
À Orientadora Profª. Esp. Jucicléia Marilia Nery de Castro pelo auxílio que nos deu para a realização desse estudo.
Á Profª. MSc. Klissiomara Lopes Dias, pelo apoio depositado neste grupo de estudo.
O caminho mais curto para se realizar as coisas é fazer uma de cada vez. (Confúcio)
RESUMO
O Estudo de Caso propõe analisar o sistema atual do LACEN, verificar suas deficiências, fazer uma nova análise de requisitos acerca das necessidades da Organização e apresentar uma modelagem viável com bases em técnicas de Orientação a Objetos e UML, visando melhorar a qualidade do Sistema de Informação do LACEN.
ABSTRACT
The Case Study proposes review the current system of LACEN, check its shortcomings, make a review of requirements on the needs of the organization and present a viable modeling based on the technical guidance Objects and UML, to improve the quality of the System Informing the LACEN.
LISTAS DE FIGURAS
FIGURA 01 – Atividade dos Sistemas de Informação: Entrada, Processamento e Saída .. 13
FIGURA 02 – Herança ... 20
FIGURA 03 – Polimorfismo ... 21
FIGURA 04 – Diagrama de caso de uso ... 25
FIGURA 05 – Diagrama de classes ... 26
FIGURA 06 – Diagrama de seqüência ... 27
FIGURA 07 – Tela Principal do Atual Sistema do LACEN ... 33
FIGURA 08 – Tela do Sistema de Registro do LACEN ... 34
FIGURA 09 – Tela de Cadastro de Paciente e Exames ... 35
FIGURA 10 – Tela de Relatório ... 36
FIGURA 11 – Tela de Formulários de Resultados ... 36
FIGURA 12 – Tela de cadastro de Resultados ... 37
FIGURA 13 – Diagrama de Casos de Uso da Modelagem ... 38
FIGURA 14 – Diagrama de Classes do Sistema e suas operações ... 45
FIGURA 15 – Diagrama de Seqüências relativo ao atendimento do Sistema ... 47
LISTAS DE TABELAS TABELA 01 – Efetuar Login ... 39
TABELA 02 – Cadastrar Funcionário ... 40
TABELA 03 – Cadastrar Paciente ... 40
TABELA 04 – Cadastrar Atendimento ... 41
TABELA 05 – Cadastrar Resultado ... 43
TABELA 06 – Gerar Relatório/Gráfico ... 44
TABELA 07 – Descrição do Diagrama de Classes ……… 46
LISTA DE ABREVIATURAS E SIGLAS LACEN – Laboratório Central de Saúde Pública ………... 11
SI – Sistema de Informação ……… 12
SUMÁRIO
INTRODUÇÃO ... 11
1 SISTEMA DE INFORMAÇÃO ... 12
1.1CONCEITO DE SISTEMA ... 12
1.1.1 Sistema de Informação (SI) ... 12
1.1.2 Importância dos Sistemas de Informação ... 13
1.2 GESTÃO DE RECURSOS INFORMACIONAIS ... 14
1.3 ANÁLISE DE SISTEMAS ... 16 2 ORIENTAÇÃO A OBJETOS ... 18 2.1 CONCEITO ... 18 2.1.1 Objeto ... 18 2.1.2 Classes ... 18 2.1.3 Atributos ... 19 2.1.4 Métodos ... 19 2.1.5 Encapsulamento ... 19 2.1.6 Herança ... 20 2.1.7 Polimorfismo ... 21 2.2 UML ... 22 2.2.1 Conceito ... 22
2.2.2 Diagrama de Casos de Uso ... 25
2.2.3 Diagrama de Classe ... 26
2.2.4 Diagrama de Interação ou Seqüência ... 31
3 METODOLOGIA ... 28
3.1 CARACTERIZAÇÃO DA PESQUISA ... 28
3.2 PARTICIPANTES ... 29
3.3 INSTRUMENTOS E COLETA DE DADOS ... 30
3.4 ANÁLISE E INTERPRETAÇÃO DOS DADOS ... 31
4 ANÁLISE DO SISTEMA ATUAL DO LACEN-AP ... 32
4.1 HISTÓRICO DO LACEN ... 32
4.2 ANÁLISE DO ATUAL SISTEMA ... 33
5 MODELAGEM DO PROJETO ... 38
5.2 DIAGRAMA DE CLASSES ... 45
5.3 DIAGRAMA DE SEQÜÊNCIAS ... 47
CONCLUSÃO ... 48
REFERÊNCIAS ... 49
INTRODUÇÃO
A proposta deste trabalho é modelar um sistema de gerenciamento das informações relativas ao atendimento da demanda de exames realizados no Laboratório Central de Saúde Pública – LACEN-AP. Os exames realizados neste laboratório atualmente ficam armazenados em um banco de dados da plataforma Microsoft Access 97, o qual não possui uma interface adequada ao usuário.
Pelo fato de o atual sistema não se utilizar da estrutura de redes com uma base centralizada, há muita inconsistência nos dados. O atual sistema permite somente consultar informações do cliente no computador que ele foi atendido. Se um cliente é cadastrado em um dos 03 (três) computadores do atendimento, em uma próxima vez que este vier a ser atendido novamente, tem que se dirigir ao mesmo computador para buscar os laudos expedidos relativos ao seu exame.
Uma solução viável para este problema é se utilizar de uma base de dados centralizada, que será acessada por uma possível aplicação, resultante da modelagem proposta, instalada nos terminais de atendimento.
1 SISTEMAS DE INFORMAÇÃO
1.1 CONCEITO DE SISTEMA
Num mundo em que sempre se ouve falar em sistemas de toda espécie como sistema de pagamento, sistema de cadastro, sistema de estoque, sistema de vendas, etc. muitas pessoas se deparam com a indagação do que vem a ser um sistema. “Sistema de Informação é um conjunto de elementos ou de componentes que interagem em busca de um só objetivo, uma necessidade ou em função de uma dada finalidade, visando atender à missão da empresa.” (ALBERTÃO 2005, p. 66).
Alguns autores também expressam sua concepção de sistema:
(CHIAVENATO 1983, P.515) diz que um sistema é um conjunto de objetos unidos por alguma forma de interação ou interdependência.
Conjuntos de partes coordenadas que concorrem para realização de um conjunto de objetivos. (DIAS & GAZZANEO, 1989, p. 4).
Sistema pode ser definido como um conjunto de elementos interdependentes que interagem com objetivos comuns formando um todo. (BALLESTERO-ALVAREZ, 1990, p. 17).
Podemos perceber que todas as conclusões são muito semelhantes, portanto, tem-se a idéia de que um sistema, em sua essência, é um conjunto de várias partes agindo em prol de um objetivo em comum, formando algo que chamamos de sinergia, quando está funcionando em perfeita harmonia com os sistemas ao seu redor e consigo mesmo.
1.1.1 Sistema de Informação (SI)
Todo sistema, usando ou não os recursos da tecnologia da informação, que manipula e gera informação pode ser genericamente considerado Sistema de Informação (REZENDE, 2003, p. 61).
Um Sistema de informação (SI) pode ser definido como um conjunto de componentes inter-relacionados trabalhando juntos para coletar, recuperar, processar, armazenar e distribuir informação com a finalidade de facilitar o planejamento, o controle, a análise e o processo decisório nas organizações (LAUDON, 1999, p. 4).
Figura 1.1 - Atividade dos Sistemas de Informação: Entrada, Processamento e Saída,
Adaptado de Rezende (2003).
É uma série de elementos ou componentes inter-relacionados em uma ordem específica, que coletam dados (entrada), manipulam e armazenam (processamento), e disseminam (saída) os dados e informações e fornecem um mecanismo de feedback (retroalimentação), que se refere a uma saída destinada a ajustes ou modificações nas atividades de entrada ou de processamento, fundamental para o sucesso da operação do sistema de Informação (ALBERTÃO, 2005, p. 67).
As empresas agregam processos de valor para atingir suas metas, através da transformação do feedback de um subsistema de processos de valor agregado em uma informação relevante extremamente precioso para a organização. Os Sistemas de Informações podem servir de base nas decisões para alteração de um procedimento de valor agregado (ALBERTÃO, 2005, p. 67).
1.1.2 Importância do Sistema de Informação
A importância de um Sistema de Informação (SI) em uma empresa está diretamente relacionada com o envolvimento dos tomadores de decisões, e é fundamental para o sucesso dos gestores. Os Sistemas de Informações permitem que as empresas aumentem seus lucros e baixem seus custos. Nesse sentido, percebe-se que a informação é uma peça
valiosa quando ela é precisa e está no lugar certo no momento exato, ou seja, que as organizações façam uso estratégico das informações (ALBERTÃO, 2005, p. 67).
O Sistema de Informação é um elemento bastante relevante nos casos em que a empresa decide delegar poder de decisão a seus empregados, no qual este permite preestabelecer critérios e limites para essa tomada de decisão (ALBERTÃO, 2005, p. 68).
A Informação é eficiente quando flui com rapidez dos pontos sensores aos centros de decisão, tem uma periodicidade, um determinado grau de análise e de coordenação. A velocidade das informações variam de empresa para empresa, dependendo do grau de decisão.
1.2 GESTÃO DE RECURSOS INFORMACIONAIS
Na atualidade a informação assume uma importância sem proporções, tornando-se fundamental para a empresa na descoberta e introdução de novas tecnologias, exploração das oportunidades de investimento e, ainda, na planificação de toda a atividade. E isso em qualquer setor de atividade humana é indispensável mesmo que a sua procura não seja ordenada ou sistemática, mas resultante apenas de decisões casuísticas e/ ou intuitivas (CHIAVENATO, 2000, p. 65).
A gestão de administração de empresas tem como objeto às organizações compostas de equipamentos, material (objetos), instalações físicas, pessoas com conhecimento e experiências pessoais diversificadas (habilidades, formação, práticas, responsabilidades) atuando de modo coordenado em prol de determinado fim ou missão organizacional. Esta complexidade exige a integração de múltiplos saberes e práticas necessários a sua execução.
Em uma época de complexidades, mudanças e incertezas como a que se atravessa hoje, onde o mundo atual e uma sociedade institucionalizada são compostos de organizações, sendo que todas as atividades são voltadas para a produção de bens (produtos) ou a prestação de serviços (atividades especializadas são planejadas, coordenadas, dirigidas e controladas) dentro das organizações. Todas as organizações são constituídas de pessoas e recursos não-humanos (como recursos físicos e materiais, financeiros, tecnológicos, mercadológicos). As organizações são extremamente heterogêneas e diversificadas, de tamanhos diferentes, de características diferentes, de estruturas diferentes, de objetivos diferentes (CHIAVENATO, 2000, p. 65).
Nas organizações a informação sofre influência a cada minuto pelo poder, pela política e pela economia. Essa situação é notória, assim como poucos gerentes se dão ao trabalho de lidar consciente e sistematicamente com a política da informação, talvez por medo de ferir a hierarquia já existente da empresa. O caminho para a sociedade do saber, onde o valor da informação tende a suplantar a importância do capital, é mudar a maneira como as pessoas usam a informação como objetivo maior, construindo uma cultura informacional. Sendo que informação e conhecimento são as chaves da produtividade e da competitividade nas organizações, o mais importante é controlar e atualizar a informação que existe em todas as organizações (DAVENPORT, 1998, p. 5).
Nos últimos anos a maioria dos empresários se prende na idéia de surpreender clientes, encantá-los e deixá-los super-satisfeitos. A partir daí estes investem alto com contratação de consultores para desenvolver marketing, objetivando o sucesso de sua empresa. Mas para esse sucesso acontecer, a empresa necessita investir em sua principal riqueza: o funcionário. Assim, o ser humano precisa ser bem capacitado para transformar a informação em conhecimento, para descobrir as melhores aplicações tecnológicas e colocá-las a serviço do cliente (SOUZA, 2006, p. 7).
As empresas se utilizam de terceirização para execução de implantação, manutenção e capacitação dos sistemas informacionais a serem implantados, pois durante a alteração desse processo os funcionários percebem que haverá uma importante reestruturação empresarial. A implantação de novo sistema faz com que a organização perceba o valor da habilidade do funcionário.
O parque computacional das empresas cresce a cada dia. São muitas estações de trabalho e servidores instalados e operantes entre si. É essencial, portanto, a implantação de uma política de gerenciamento do acervo corporativo dos recursos informáticos, otimizando-se a utilização destes recursos, e reduzindo-otimizando-se os custos totais de Tecnologia da Informação – TI da Empresa. Com esta política, reduz-se a duplicação de software, evitam-se upgrades desnecessários e otimizam-se contratos de compras e manutenção usando-se economia de escala (ALBERTÃO, 2005, p. 85).
O uso de informações é um dos pontos decisivos, nos dias de hoje, para que pequenos e médios varejistas tenham oportunidade de se manter no mercado ou crescer dentro do atual contexto mercadológico e diante do crescimento da concorrência de grandes empresas. A eficiência e a produtividade em toda organização é fator fundamental para a manutenção e o aumento do lucro (ALBERTÃO, 2005, p. 90).
A utilização de sistemas informacionais proporciona uma série de vantagens operacionais, como: o controle de termos reais de estoque, vendas e compras; conhecer os produtos de maior e menor giro e os de maiores e menores margens; pedidos pendentes; recepção de mercadorias; controle adequado de margens de lucros, preços e muitas outras. Os dirigentes passam a ter acesso à situação da organização a qualquer momento, sem depender de uma pessoa específica.
1.3 ANÁLISE DE SISTEMAS
Atualmente, com os recursos escassos e a competitividade acirrada pela falta de novos segmentos e outras dificuldades internas às empresas, fica difícil para muitas destas fazerem um sistema sem que este tenha sido planejado em seus mínimos detalhes para atender às suas necessidades, quando não optam por algum software de prateleira.
Capers Jones, citado por Pressman (2006, p. 118) afirma que “as sementes dos principais desastres de softwares são usualmente lançadas nos primeiros três meses de início do projeto de software.”.
Partindo-se do princípio de quanto mais um sistema é analisado e detalhado menor é a sua chance de ter algum problema durante sua produção, podemos dizer que a quantidade de surpresas que se encontram na fase de produção de um sistema é inversamente proporcional ao nível de detalhamento decorrente de sua análise. Logo, analisar um sistema antes de programá-lo significa diminuir consideravelmente o seu custo de produção, afinal menos imprevistos ocorrerão. A implementação de um sistema não planejado aumenta consideravelmente os custos de produção haja vista que não se sabe, ao certo, o que se está produzindo.
Analisar um sistema não é fácil, e se torna uma tarefa ainda mais cansativa, se o profissional de TI falha em estabelecer uma fundamentação sólida para o sistema ou software, ou seja, se em vez de empregar mecanismos para controlar as modificações ele permitir que as modificações o controlem. (PRESSMAN, 2006, p. 116).
Para evitar esse problema é preciso fazer a analise dos requisitos de um sistema com eficiência, devemos construir e/ou adotar meios específicos para tal fim. Muitos desses meios podem ser encontrados numa seção da Engenharia de Software: a Engenharia de Requisitos, que nos fornecerá uma sólida abordagem para enfrentar os desafios.
A Engenharia de Software possui, em sua gama de soluções para cumprir seu objetivo fim, uma vertente chamada Engenharia de Requisitos que serve, justamente, para estabelecer processos sólidos de análise que ajudam o engenheiro ou analista a compreender melhor o problema que eles vão trabalhar para resolver. (PRESSMAN, 2006, p. 116).
Segundo Pressman (2006, p. 117) a engenharia de requisitos, como todas as outras atividades de engenharia de software, precisa ser adaptada às necessidades do processo, do projeto, do produto e do pessoal que está fazendo o trabalho.
No caso em questão, faz-se uso da técnica orientada a objetos, juntamente com a Linguagem de Modelagem Unificada – UML, utilizada como padrão de modelagem, a fim de expor os diagramas necessários à compreensão dos requisitos do sistema (Diagramas de Casos de Uso).
Engenharia de requisitos é o uso sistemático de princípios, técnicas, linguagens e ferramentas comprovadas para a análise, documentação, evolução continuada das necessidades do usuário e especificação do comportamento externo de um sistema para satisfazer as necessidades do usuário, que sejam efetivas em termos de custo. (PRESSMAN, 2006, p. 265)
Com a utilização da Engenharia de Requisitos podemos projetar um sistema de maneira organizada, metódica e com maior clareza nas expectativas dos resultados. Porém, apesar de todo o aparato fornecido pela engenharia de requisitos para elencar as informações relevantes a partir da análise, o trabalho do Analista de Sistemas não se resume a apenas utilizar estes mecanismos.
O trabalho do Analista de Sistemas não é fácil. Ele tem de ser capaz de lidar, ao mesmo tempo, com um grupo de usuários, outros profissionais de informática e um corpo administrativo (gerentes/diretores). Cada qual trazendo informações, pontos de vistas, vivências, experiências e maturidade totalmente distintas.
Os usuários, ou estarão preocupados em dinamizar seu serviço, tornando-o automático e extremamente rápido, aumentando a confiabilidade de resultados, ou ainda, estarão com medo da informatização, às vezes, até obstruindo o trabalho do Analista de Sistemas.
O pessoal técnico estará se preocupando com aspectos de performance, bits, bytes, técnicas de randomização, topologia de hardware e diversidade de recursos.
Por fim, na administração, têm-se aqueles que só querem saber do retorno sobre o investimento e a proporção custo benefício, lembrando a cada momento, que aquilo que você estará fazendo era necessário para ontem. (TONSIG, 2003, p. 21).
A modelagem resultante da análise proposta para o sistema do LACEN basea-se em conceitos de orientação a objetos, nos dias hoje amplamente utilizados, os quais veremos no próximo capítulo.
2 ORIENTAÇÃO A OBJETOS
2.1 CONCEITO
Orientação a objetos é uma forma que expõe uma série de técnicas para soluções para problemas computacionais. A análise e projeto orientados a objetos tem como alvo identificar o melhor grupo de objetos para expor um sistema de software. Esta abstração é feita por representações do mundo real, chamadas de objetos.
A grande vantagem que obtemos com a orientação a objetos é o fato de podermos abstrair, de uma maneira fidedigna, as situações do dia-a-dia. (MELO, 2002, p. 14).
A proposta da orientação a objetos é permitir que os programadores organizem os programas da mesma forma que as nossas mentes enxergam os problemas: não como um conjunto de espaços de memória, mas como um conjunto de coisas que fazem parte do problema. (MATOS, 2002, p. 20).
2.1.1 Objeto
Na concepção de modelagem de sistemas, um objeto é qualquer coisa existente no mundo real em formato concreto ou abstrato, ou seja, que exista fisicamente ou apenas conceitualmente. (MELO, 2002, p. 15).
Um objeto é uma abstração de alguma coisa no domínio do problema que reflete os recursos de um sistema de reter informações sobre ele, interagir com ele, ou ambas as coisas. (LEE; TEPFENHART, 2002, p. 91).
2.1.2 Classes
Uma classe é a representação de um conjunto de objetos que compartilham a mesma estrutura de atributos, operações e relacionamentos, dentro de um mesmo contexto. (MELO, 2002, p. 17).
Descreve um grupo de objetos com atributos idênticos, comportamentos e relacionamentos comuns (vínculo e agregação) e semântica comum. Exemplos de Classes
são: pessoa, funcionário, planilha de tempo, empresa e departamento. (LEE; TEPFENHART, 2001, p. 179).
2.1.3 Atributos
São características de um objeto, basicamente a estrutura de dados que vai representar a classe. Ex: Funcionário: nome, endereço e CPF.
São recursos de uma classe ou qualquer outro elemento que represente propriedades ou elementos de dados. Em algumas linguagens, os atributos são denominados variáveis de instância de classe ou membro de dado. (LIMA, 2005, p. 23).
As coisas do mundo real apresentam características. Por exemplo, uma pessoa pode ser descrita por sua altura, peso e assim por diante. Cada característica comum a todas as instâncias do objeto/classe é abstraída como um atributo. (LEE; TEPFENHART, 2001, p. 92).
2.1.4 Métodos
Tecnicamente, um método é um conjunto detalhado de operações que um objeto executa quando outro objeto solicita um serviço. Entretanto, por definição, um comportamento é um conjunto de ações que um objeto é responsável por exibir. (LEE; TEPFENHART, 2001, p. 94).
Para invocar um método de um objeto, envia-se uma mensagem para ele especificando o nome do objeto, o método a ser executado e a lista de argumentos requeridos. Após a execução, o objeto pode ou não retornar um valor com resposta à mensagem recebida. (LIMA, 2005, p. 24).
2.1.5 Encapsulamento
É um mecanismo usado para ocultar os dados, a estrutura e os detalhes de implementação de um objeto. Toda interação com um objeto é feita através de uma interface pública constituída de operações. (LARMAN, 2000, p. 480).
A idéia do Encapsulamento nos remete ao fato de que a utilização de um sistema orientado a objetos não deve depender de sua implementação interna, e sim de sua interface. (MELO, 2002, p. 19).
2.1.6 Herança
É o mecanismo pelo qual uma classe (sub-classe) pode estender outra classe (super-classe), aproveitando seus comportamentos (métodos) e estados possíveis (atributos).
2.1.7 Polimorfismo
É a possibilidade de dar a um mesmo método, por exemplo, variadas formas, de acordo com o momento em que você decide utilizá-lo. (MATOS, 2002, p. 26).
É o principio em que classes derivadas de uma mesma superclasse podem invocar operações que têm a mesma assinatura, mas comportamento diferente em cada subclasse. (LIMA, 2005, p. 26).
Figura 2.2 - Polimorfismo, Adaptado de Cirne (2003).
Dentre todos os conceitos expostos neste capítulo, os que serão válidos para uma compreensão mais didática dos diagramas do modelo a ser apresentado serão objetos, classes,
2.2 UML
2.2.1 Conceito
Uma das maiores dificuldades em se desenvolver software está relacionada à adoção de padrões para tal prática. A necessidade de tais padrões se dá pelo fato de sempre serem necessários o entendimento e a comunicação de um sistema quer seja por parte de uma equipe de desenvolvimento, ou por parte de uma equipe de manutenção do mesmo.
Para Melo (2002, p. 29) essa dificuldade se mostrou incômoda principalmente no período compreendido entre 1989 e 1994, quando mais de 50 métodos foram apresentados à comunidade. Apesar de haverem tantos projetos, a grande maioria dos projetistas pecou por tentar estender os métodos estruturados. Os maiores prejudicados eram os usuários que não conseguiram encontrar uma completa satisfação no uso do que havia disponível. Essa situação gerou o que se conheceu como “a guerra dos métodos”. Em meados da década de 90, surgiram novas abordagens que procuraram trabalhar mais ativamente a idéia do novo paradigma.
De acordo com Larman (2004, p. 34), dentre os vários métodos existentes na época, haviam dois mais difundidos e aceitos. Eram os métodos Booch - de Grady Booch - e OMT (Object Modeling Technique) - de Jim Rumbaugh. A combinação dessas notações diagramáticas deu início à UML (Unified Modeling Language ou, em português, Linguagem de Modelagem Unificada). Posteriormente, Ivar Jacobson, criador do método Objectory, se juntou àqueles dois e o trio passou a ser conhecido como os três amigos. Muitos outros contribuíram para a UML, e talvez a contribuição mais notável tenha sido a de Cris Kobryan, um dos líderes de seu contínuo refinamento.
A UML é uma linguagem criada com o propósito de permitir especificações, visualizações e documentação de artefatos de sistemas. Ou seja, é permitido usar a UML para atender e manipular todos os elementos que direta ou indiretamente influenciam na construção do software. Dessa forma, é possível, também, a avaliação da modelagem do negócio ou de quaisquer outros aspectos não necessariamente computacionais. (MATOS, 2002, p. 29).
Entende-se, logo, que a UML não serve apenas para modelar software ou apenas sistemas computacionais, mas, qualquer tipo de sistema. Entre os seus diversos diagramas ela consegue expressar, com propriedade, os requisitos e características de qualquer parte de um sistema em suas diversas perspectivas.
Lima (2005, p. 32) diz, com muita propriedade, que “além de flexível, a UML é extensível e independente de processos ou linguagens de programação, o que garante a liberdade para o desenvolvedor adotar qualquer meio de desenvolvimento sem deixar de expressar-se claramente aos seus usuários e outros desenvolvedores, pois utiliza uma notação padrão, comum a todos os ambientes e empresas por ser um conjunto das melhores práticas, ela tem suporte de alcance mundial”.
A UML foi adotada, em 1997, como um padrão pela OMG (Object Manangement Group, uma instituição de criação de padrões para a indústria de software), e continua a ser refinada em novas versões OMG UML.
Segundo a especificação da OMG, a UML “é uma linguagem para especificação, construção, visualização e documentação de artefatos de um sistema de software intensivo”. A UML também é uma linguagem gráfica para representar projetos orientados a objetos utilizando uma notação comum, abrangendo todo o sistema desde o desenvolvimento à implantação. (LIMA, 2005, p. 32).
A UML se constitui como notação útil nas diversas etapas de desenvolvimento de software, desde a concepção de projeto - que envolve a análise de requisitos realizada com o diagrama de casos de uso - até sua implantação - envolvendo a utilização do diagrama de componentes e diagrama de implantação, se assim o projeto de software exigir.
Na UML, os sistemas são constituídos por modelos que conectados entre si permitem a compreensão de qualquer aspecto, mesmo sendo ele o sistema mais comum. Esses modelos representam diferentes pontos de vista, cada um descrevendo um aspecto particular da mesma solução. Os pontos de vista são denominados visões, isto é, perspectivas e focos em ângulos diferentes de um mesmo sistema. (LIMA, 2005, p. 33).
Segundo Booch, Rumbaugh e Jacobson (2005, p. 33), “a UML permite representar o sistema em cinco visões interligadas (caso de uso, projeto, processo, implementação e a visão de implantação)”:
Visão de Casos de Uso: esta visão abrange os casos de uso que descrevem o
comportamento do sistema conforme é visto pelos seus usuários finais, analista e pessoal de teste. Ela existe para especificar as forças que determinam a forma da arquitetura do sistema. Com a UML os aspectos estáticos dessa visão são apreendidos em diagramas de casos de uso e os aspectos dinâmicos através de diagramas de interação, diagramas de gráfico de estados e diagramas de atividades.
Visão de projeto: abrange as classes, interfaces e colaborações que formam o
vocabulário do problema e de sua solução. Essa visão proporciona principalmente um suporte para os requisitos funcionais do sistema. Com a UML, os aspectos estáticos dessa visão são captados em diagramas de classes e de objetos; os aspectos dinâmicos são captados em diagramas de interações, diagrama de gráfico de estados e diagramas de atividades.
Visão de processo: abrange os threads e os processos que formam os mecanismos
de concorrência e de sincronização do sistema. Essa visão cuida principalmente de questões referentes ao desempenho, à escalabilidade e ao throughput do sistema. Com a UML, os aspectos estáticos e dinâmicos dessa visão são apreendidos nos mesmos tipos de diagrama da visão de projeto, mas com o foco voltado para as classes ativas que representam esses threads e processos.
Visões de implementação: abrange os componentes dos arquivos utilizados para
a montagem e fornecimentos do sistema físico. Essa visão envolve o gerenciamento da configuração das versões do sistema, compostas por componentes e arquivos de uma maneira independente, que podem ser reunidos de diferentes formas para a produção de um sistema executável. Com a UML, os aspectos estáticos dessa visão são capturados em diagramas de componentes; os aspectos dinâmicos são capturados em diagramas de interações, de gráfico de estados e de atividades.
Visão de implantação: abrange os nós que formam a topologia de hardware em
que o sistema é executado. Essa visão direciona principalmente a distribuição, o fornecimento instalação das partes que constituem o sistema físico. Com a UML os aspectos estáticos apreendem em diagramas de implantação e os dinâmicos em diagramas de interações, de gráficos de estados e diagramas de atividades.
Apesar de a UML apresentar várias visões, bem como seus diagramas, o intuito deste trabalho não necessita da utilização de todos para conduzir sua proposta. As visões a serem utilizadas serão de casos de uso e projeto, contudo, não em toda sua íntegra.
Para se conceber um sistema, isto é, saber se vale à pena investir num projeto de software, é necessário que se esboce suas características e requisitos. Normalmente, nas reuniões que se fazem com os usuários para tratar dos requisitos de um sistema, fazem-se rascunhos das abstrações deste, contudo, estes mesmos rascunhos não seguem nenhum padrão a ser documentado e representam meras expressões de desejos em relação ao sistema, por parte dos usuários, e podem ter diferentes interpretações de acordo com cada profissional que vier analisá-las.
Apesar das diversas visões da UML bem como seus diversos diagramas, para modelar o sistema proposto neste trabalho, utilizar-se-ão apenas as visões de casos de uso e a visão de projeto através do diagrama de casos de uso e a visão de projeto, através do diagrama de classes. Ambos os diagramas subsidiarão o diagrama de seqüências, o qual também será utilizado.
2.2.2 Diagrama de Casos de Uso
O Diagrama de casos de uso é apropriado para organizar a tarefa e torná-la mais compreensível. Ele nos fornece uma visão das relações que o sistema tem com o ambiente ao seu redor, principalmente com seus usuários. Esse diagrama possui dois principais conceitos: ator e casos de uso.
Ator: Um ator é um humano ou entidade máquina que interage com o sistema para executar um significante trabalho.
Segundo Lima (2005, p. 62), “o ator é sempre externo ao sistema, isto é, ele não faz parte do sistema correspondente, e pode representar papéis executados por usuários humanos, hardware externo, e outros sistemas; portanto, ele não representa necessariamente uma entidade física específica, mas somente um papel, um aspecto particular de alguma entidade”.
Caso de uso: representa serviços ou a funcionalidade provida pelo sistema aos usuários.
2.2.3 Diagrama de Classe
Definem o modelo de estrutura estática do sistema que identifica os objetos, classes e relacionamentos entre eles, ou seja, descreve como o sistema é estruturado e não como ele se comporta.
O diagrama de classes possui algumas principais características: atributos e métodos, que são detalhados nos tópicos 2.1.2 e 2.1.3, respectivamente, neste trabalho.
2.2.4 Diagrama de Interação ou Seqüência
Capturam os requisitos funcionais. Podem ser utilizados como ferramenta para ajudar na decisão de como será distribuída entre as classes, a funcionalidade requerida que servirá de suporte para os casos de uso. Podem também, serem utilizados como mecanismo de mapeamento da funcionalidade exigida do sistema em objetos para que venha gerar funcionalmente classes coerentes, manuteníveis, reutilizáveis e extensíveis.
Figura 2.5 – Diagrama de seqüência do sistema, Adaptado de Larman (2000, p. 146).
O diagrama de seqüências mostra como o fluxo de eventos ocorre por meio do casso de uso e como o sistema deve implementar as ações:
O ator que inicia a ação, os objetos envolvidos que servirão para determinar as classes que existirão no diagrama de classes, as mensagens que eles trocam entre si e a ordem em que isso acontece. (LIMA, 2007, p. 147).
3 METODOLOGIA
3.1 CARACTERIZAÇÃO DA PESQUISA
A pesquisa possui o tema “MODELAGEM DE SISTEMA DE ATENDIMENTO LABORATORIAL: ESTUDO DE CASO DO LABORATÓRIO CENTRAL DE SAÚDE PÚBLICA - LACEN-AP” se realizou devido à necessidade de se
elucidar de que forma foi desenvolvido o Sistema de Atendimento Laboratorial no LACEN, quais suas limitações. O tema se propõe, ainda, a captar quais os anseios dos usuários quanto à implantação de uma visão metodológica diferenciada, que proporcione agilidade e integração desta aos serviços da Divisão de Biologia Médica e tenta, dentro dos padrões da UML, modelar um novo sistema de atendimento laboratorial.
Para a realização do estudo, optou-se pelo método dialético, por se tratar de “um método de investigação da realidade pelo estudo de sua ação recíproca (...) é o contrário a todo o conhecimento rígido, tudo é visto em constante mudança (...)” (LAKATOS, 1990, p.75). A dialética procura investigar modificações internas, a ligação com outros processos e o fim para o qual se dirige.
Utilizaram-se, como método de procedimento, a pesquisa bibliográfica descritiva, na qual se observam os fatos para posterior registro. Será utilizada pesquisa monográfica por consistir nos estudos de determinados grupos de indivíduos para buscar subsídios teóricos em livros, revistas, jornais, etc. É uma pesquisa exploratória por obter diversas informações do assunto, e explicativa, pois consiste em analisar, registrar e interpretar os fenômenos estudados, procurando identificar seus fatores determinantes e suas causas.
De acordo com a metodologia estabelecida para a pesquisa, visando à análise qualitativa, de maneira que o referido estudo sirva como base para mudanças na prática cotidiana dos funcionários do LACEN, dando ênfase à qualidade dos serviços oferecidos pela empresa, contemplando às necessidades humanas; e quantitativa de modo que, através dos questionários, quantifique os dados colhidos para se obterem dados estatísticos que comprovem a veracidade das respostas optou-se por um plano de amostra intencional não probabilístico e voluntário tendo, como critério fundamental, a obrigatoriedade dos sujeitos abordados estarem inseridos no contexto do assunto discutido.
Após a revisão bibliográfica sobre os sistemas de informações, em que foram consideradas as necessidades de contextualização e natureza coletiva da estrutura do sistema a ser implantado, quanto à modalidade da pesquisa, optou-se pelo estudo de caso.
Para diversos autores “a utilidade do estudo de caso se baseia na descrição e compreensão dos padrões de relações dos fenômenos estudados e seus significados para o caso”. (LAKATOS, 1990, p.76).
O estudo de caso é qualitativo porque é o estudo de um sistema delimitado no tempo e no espaço. “A pesquisa de estudo de caso representa a estratégia preferida quando se colocam questões do tipo “como” e “por que”, quando o pesquisador tem pouco controle sobre os eventos e quando o foco se encontra em fenômenos contemporâneos inseridos em algum contexto da vida real”. (SEVERINO, 1985, p. 39).
3.2 PARTICIPANTES
Esta pesquisa teve a participação de 08 (oito) funcionários, que ocupam a função de 01 (um) diretora presidente, 01 (um) chefe da biologia médica, 01 (um) chefe da unidade de informática, 03 (três) atendentes e 02 (dois) bioquímicos (analistas). A proposta de pesquisa foi apresentada à Empresa (autarquia) LACEN - Laboratório Central de Saúde Pública, representada por sua diretora presidente Juvanete Amoras Távora Miranda, bem como a solicitação de autorização para o início dos trabalhos, consolidado pelo Termo de Consentimento livre e esclarecido para a gerência.
A participação dos funcionários foi de livre adesão que consistia em, depois da exposição dos objetivos da pesquisa, recrutar apenas os que fariam parte para responder aos questionários. Justifica-se a relevância de tal número de participantes porque, para um estudo com contribuições de teorias sobre o Sistema de Atendimento Laboratorial, numa abordagem qualitativa, não existe um número mínimo obrigatório de sujeitos como é exigido nas análises estatísticas. Segundo Severino (1995, p, 73), “poucos colaboradores são necessários” porque, quando devidamente contextualizados, formam “sujeitos genéricos” que têm o poder de representar o grupo, por estarem envolvidos com o objeto da representação.
3.3 INSTRUMENTOS E COLETA DE DADOS
Utilizaram-se contribuições técnicas e aplicação de questionários e a observação participante. A observação participante é o “contato direto com o fenômeno observado para obter informações sobre a sua aplicabilidade e eficácia”. Para Gonçalves, (2001, p. 59) sua origem é na antropologia durante um método histórico que procura a inserção, negociação e compartilhamento da interação social entre pesquisador e grupo estudado em suas atividades. O pesquisador compartilha situações e experiências nem sempre possíveis de serem identificadas e verbalizadas pelos sujeitos pesquisados.
A amostragem retirada para subsidiar as análises dos dados foi da aplicação de um questionário estruturado com perguntas de conteúdo exploratório, visando obter respostas precisas em relação à análise do Sistema já em uso e à modelagem do sistema no padrão UML na empresa. Nessa perspectiva, Menezes (1993, p.31) afirma que: “não existe a possibilidade do profissional fazer o habitual, inconsciente e cômodo uso da neutralidade como meio para mascarar ou até mesmo fantasiar uma determinada realidade”, ou seja, este deve estar sempre conectado às mudanças, adaptando suas habilidades de acordo com as reais necessidades da clientela, sempre objetivando a melhor forma de levar ao cliente o melhor serviço e produto.
Faz-se necessário salientar que, para constatar a veracidade das respostas obtidas no questionário, efetuaram-se visitas periódicas à Empresa LACEN, observando seu espaço, departamentos e as práticas de serviços de informática. Na análise quantitativa, buscou-se compreender melhor a concepção dos profissionais de informática quanto aos métodos utilizados na implantação do sistema. Procurou-se, também, conhecer a fundo a prática desenvolvida pelo sistema e o planejamento, visando um desenvolvimento metodológico inovador.
A pesquisa se deu no LACEN, a qual teve como objeto o estudo de caso sobre a Modelagem do Sistema Laboratorial. Colaboraram, com o trabalho, (02) técnicos da área de Informática. Segundo Maccariello (2003, p.63): “torna-se fundamental para compreensão do universo social, o qual se pretende investigar ou atuar, considerar os dados objetivos deste universo e as representações dos atores sociais ali presentes”.
3.4 ANÁLISE E INTERPRETAÇÃO DOS DADOS
Para analisar e interpretar os dados obtidos se partiu, em primeiro lugar, da observação do funcionamento do sistema na empresa para, em seguida, realizar a aplicação de questionários, constantes dos anexos deste trabalho, a respeito do assunto em tela.
A primeira etapa procedeu através da observação não participante, não intervindo nas atividades desenvolvidas no contexto da empresa. Nesta, se realizaram apenas registros fotográficos dos departamentos da empresa, observando de que forma se dá o desenvolvimento do trabalho com a utilização do atual sistema.
A segunda etapa se deu através de aplicação de questionários aos colaboradores da pesquisa, como gerentes e funcionários técnicos que, depois de breve explicação sobre os objetivos do trabalho, responderam ao questionário de acordo com seus conhecimentos e experiências obtidas no próprio local de trabalho.
A terceira etapa foi reservada à análise dos dados obtidos, com o intuito de tecer diagnósticos sobre o tema pesquisado, na referida empresa, assim como a análise dos resultados.
4 ANÁLISE DO SISTEMA ATUAL DO LACEN-AP
4.1 HISTÓRICO DO LACEN
As atividades do LACEN Amapá tiveram inicio em 21 de dezembro de 1978, sob o governo Territorial de Arthur de Azevedo Hennig, quando da então criação do Sistema Nacional de Laboratório e Saúde Pública, através da Portaria Ministerial nº 280 de 21 de julho de 1977, sistema este coordenado pela Divisão Nacional de Laboratórios de Saúde Pública da Secretaria Nacional de Ações Básica de Saúde/MS - ESNABS (já extinto). O laboratório faz parte de um sistema hierarquizado de acordo com o interesse sanitário e organizado segundo seu grau de complexidade.
Na condição de Divisão, subordinado ao Departamento de Saúde da Secretaria de Estado da Saúde do Amapá, perdurando dezoito anos com esse "status", sofrendo com isso limitações em sua rotina de trabalho continuamente. Hoje, o LACEN Amapá é uma Unidade de Saúde (autarquia), vinculada à Secretaria de Saúde, com autonomia administrativa e financeira e com uma história de saúde pública. Tem como missão promover ações de saúde na área laboratorial, como referência estadual, atuando diretamente ou em parceria, garantindo serviços de qualidade em benefício da população.
O LACEN apresentou marcante atuação desde sua criação. Foi transformado em autarquia em abril de 1997, o Governador JOÃO ALBERTO CAPIBERIBE, em comum acordo com a Reforma Administrativa do estado, instituída a partir da lei estadual nº 0338/97, transformou o LACEN de Divisão do Departamento de Saúde para Autarquia. Como entidade autárquica abriram-se novos horizontes para implementação das pesquisas de interesse epidemiológico com órgãos afins como: Instituto Oswaldo Cruz (FIOCRUZ), Instituto Evandro Chagas (IEC), Instituto Nacional de Controle de Qualidade em Saúde (INCQS), Instituto Adolfo Lutz (IAL), subsidiados por instituições de apoio à pesquisa – CNPq (Conselho Nacional de Desenvolvimento Científico e Tecnológico), buscado recurso, aprimoramento técnico, desenvolvimento científico e tecnológico, através de parcerias com instituições nacionais e internacionais consoante as bases do programa de governo.
Atualmente o LACEN conta com equipamentos automatizados que tem permitido rapidez e precisão nos diagnósticos. Portanto, está estruturado para atender às necessidades nosológicas e ao controle sanitário da área de sua abrangência.
4.2 ANÁLISE DO ATUAL SISTEMA
O sistema atual do LACEN foi construído sobre a plataforma de banco de dados do pacote de aplicativos Microsoft Office 97, conhecida pelo nome Microsoft Access 97, sendo desenvolvido pelo pela Unidade de Informática do LACEN. A aplicação não foi projetada para rodar em rede, mas, pela necessidade do serviço ao qual ela se destina, teve que ser instalada em vários computadores.
O Sistema por ter sido instalado em vários computadores não permite a centralização das informações dos dados coletados, o que acarreta alguns problemas. Quando o cliente necessita consultar seu exame, se faz necessário acessar o mesmo computador do numero de registro anterior emitido para o cliente, pois, só assim o atendente conseguirá recuperar as informações referentes e rastrear todo percurso do exame solicitado.
Figura 4.1 - Tela Principal do Atual Sistema do LACEN.
Conforme a figura 4.1, da tela principal do sistema atual do LACEN, existem 5 (cinco) opções: “Entrada de dados”, “Visualiza relatório por data”, “Imprime relatório geral”, “Resultados” e “Sair”. Porém, apenas as opções “Entrada de dados”, “Visualiza relatório por data” e “Resultados” funcionam. A primeira dá acesso aos cadastros dos dados dos pacientes e de seus exames, já a segunda dá acesso ao relatório por período de exames registrados e a terceira dá acesso aos resultados dos exames solicitados pelos pacientes.
Quando o usuário acessa a opção “Entrada de dados”, aparece a seguinte mensagem para o usuário: “Senhor usuário! Verifique na coluna registro acima, o último registro digitado.”, isto quer dizer que usuário tem que anotar o último registro, que aparece exemplificado na figura 4.2, para poder cadastrar os exames de um paciente dando seqüência aos números de registro de exames manualmente. Logo, no exemplo, o usuário teria que cadastrar o próximo registro de exame manualmente digitando o número 50.004 no campo “Registro” da tabela de exame, situada na parte mais abaixo da figura 4.3.
O maior problema de o usuário ter que anotar e digitar um número de exame é a falta de agilidade que o sistema lhe proporciona, fazendo com que perca tempo realizando uma tarefa que poderia ser desempenhada pelo próprio sistema.
Figura 4.2 - Tela do Sistema de Registro do LACEN.
Após o usuário ter anotado o número que o sistema indica, logo em seguida é mostrada a tela de cadastro de pacientes e exames, como se vê na figura 4.3 e que, na verdade são duas tabelas relacionadas.
No campo Nº de Registro, logo abaixo do campo Nome, o usuário tem que digitar o mesmo número que a aplicação gera na parte inferior da tela, entre os botões de navegação entre registros, para que haja um relacionamento entre esses dois campos, permitindo-se, assim, que se referenciem os exames através do número de registro do paciente.
Após digitar o número de registro do paciente e cadastrar algum exame, os registros das tabelas ficam atrelados, sendo possível, agora, navegar entre os mesmos sem que o registro do paciente perca a referência dos exames relacionados.
O problema que existe nesta tela de cadastro é o fato de que, mesmo se o número de registro do paciente for alterado, suas informações permanecem na tela; o que muda são apenas o exames que, agora, serão aqueles que fazem referência ao novo número.
A falha que existe neste método de navegação é a falta de um comando do tipo POST para atualizar as informações relacionadas ao paciente no momento da mudança do número de registro. Esta falha não ocorre quando se muda o número de registro pelo navegador, visto que, todas as informações são atualizadas de acordo com o número de registro que se visualiza naquele instante. Logo, tanto as informações do paciente quanto as dos exames do mesmo são mostradas coerentemente.
O maior risco que se corre ao preencher os dados requisitados nessa janela de cadastro é o de digitar um outro valor no campo Nº de registro do paciente que não o seu próprio número de registro, o que acabaria causando a perda da referência dos exames deste.
Após tomar todos os cuidados necessários, o usuário poderá completar o atendimento ao paciente.
Figura 4.3 - Tela de Cadastro de Paciente e Exames.
Com relação à segunda opção “Visualiza relatório por data” é onde se visualizam todos os registros filtrados por período em intervalos diário, semanal ou mensal, conforme se vê na figura 4.4.
Figura 4.4 - Tela de Relatório.
Com relação ao cadastro de resultados, o usuário acessa a opção “Resultados” como mostra a figura 4.1. Na janela que se abre, chamada “Menu de controle (Resultados Finais)” aparecem vários links que dão acesso aos resultados de vários tipos de exames, cada um nomeado de acordo com sua própria definição, conforme mostra a Figura 4.5.
Figura 4.5 - Tela de Formulários de Resultados.
Ao acessar um dos links o usuário visualiza, de acordo com a figura 4.6, um formulário com aparência de relatório, o qual serve para cadastrar os resultados do exame em questão, além de navegar entre os vários resultados de exames daquele tipo. A qualquer tempo este formulário pode ser impresso, pois, já se encontra nos moldes para tal ação.
Figura 4.6 - Tela de cadastro de Resultados.
Através da análise do sistema atual, constata-se a existência de várias falhas de projeto ou mesmo a inexistência de um, para a construção do sistema. Alguma delas como: falta de login, necessidade de recadastro de pacientes a cada interação deste com o sistema, falta de relatórios estatísticos, falta de um sistema de backup, etc. podem ser vistas no primeiro contato com a aplicação.
Percebemos que pelo fato de o LACEN não possuir rede de computadores na época do desenvolvimento do sistema, este não tem essa utilidade até os dias atuais, exigindo sua instalação em cada computador no qual se queira utilizá-lo, gerando diversos bancos de dados isolados, causando o que chamamos de redundância de dados, se visto como uma base única.
5 MODELAGEM DO PROJETO
A modelagem proposta fará uso da UML utilizando o software de código aberto JUDE, versão 5.0. A escolha desta ferramenta para a diagramação se deu pelo fato de ser de fácil utilização e livre de licenças.
5.1 DIAGRAMA DE CASO DE USO
Figura 5.1 - Diagrama de Casos de Uso do Sistema.
O paciente chega ao LACEN solicitando exames através de uma guia, ele é atendido por um funcionário do LACEN que inicia o sistema de atendimento e verifica se o paciente já é cadastrado verificando seus dados pessoais, caso o paciente ainda não seja
cadastrado no laboratório, seu cadastro é solicitado, e logo é dado prosseguimento no atendimento, se positivo o exame será inserido no seu registro e coletado o material de exame no local. O paciente é encaminhado ao setor competente finalizado o atendimento, por ultimo é emitido o recibo ao paciente com a data de retorno para ele receber seu laudo com os resultados dos exames.
Casos de uso que serão detalhados neste trabalho:
1. Efetuar Login 2. Cadastrar Funcionário 3. Cadastrar Paciente 4. Cadastrar Atendimento 5. Cadastrar Resultado 6. Gerar Relatório/Gráfico
Nome do Caso de Uso Efetuar Login
Descrição Este caso de uso permite efetuar a entrada no sistema. Ator envolvido Atores: Administrador, Atendente e Bioquímico.
Funcionário Sistema Este caso de uso
começa quando o ator clica no arquivo de inicialização do sistema.
O sistema apresenta a tela de login contendo os campos necessários à entrada no sistema.
O Atendente
preenche os campos com seu usuário e senha.
Interação ator-sistema
O sistema inicializa de fato ou emite uma mensagem dizendo que “o usuário e/ou senha são inválidos.” e pede para repetir a operação. Neste momento o caso de uso é encerrado.
Nome do Caso de Uso Cadastrar Funcionário
Descrição Este caso de uso permite o cadastro de um novo funcionário.
Ator envolvido Ator: Administrador
Administrador Sistema Este caso de uso
inicia quando o Administrador clica
no botão
Funcionários da tela inicial do sistema.
O sistema apresenta a tela de manutenção dos cadastros de Funcionários.
O Administrador clica no botão “Novo”.
O sistema se prepara para receber as informações do novo funcionário, limpando os campos a serem preenchidos.
O Atendente preenche todos os campos necessários e clica no botão “Salvar”. Interação ator-sistema
O sistema valida os dados e emite uma mensagem de alerta, se houver algum campo irregular ou o Funcionário já estiver cadastrado no sistema, ou informa que o “novo Funcionário foi cadastrado com sucesso”.
Nome do Caso de Uso Cadastrar Paciente
Descrição Este caso de uso permite ao usuário inserir um novo paciente no sistema.
Ator envolvido Ator: Atendente
Atendente Sistema
Este caso de uso inicia quando o Atendente clica no botão “Pacientes” da tela inicial do sistema. Interação ator-sistema
O sistema apresenta a tela de manutenção dos cadastros de Pacientes.
O Atendente clica no botão “Novo”.
O sistema se prepara para receber as informações do novo paciente, limpando os campos a serem preenchidos.
O Atendente
preenche todos os campos necessários e clica no botão “Salvar”.
O sistema valida os dados e emite uma mensagem de alerta, se houver algum campo irregular ou o Paciente já estiver cadastrado no sistema, ou informa que o “novo Paciente foi cadastrado com sucesso”.
Nome do Caso de Uso Cadastrar Atendimento
Descrição Este caso de uso permite a inserção de um novo atendimento no sistema.
Ator envolvido Atendente
Funcionário Sistema Este caso de uso
inicia quando o Atendente clica no botão “Atendimento” na tela inicial do sistema. O sistema imediatamente apresenta a tela de consulta de pacientes.
O atendente digita o nome do Paciente e clica no botão “Pesquisar”.
O sistema apresenta uma lista com todos os registros dos prováveis Pacientes.
O atendente seleciona a linha com o nome do Paciente desejado, caso exista e clica no botão “Consultar”. Interação ator-sistema
tela de Pacientes, desta vez com todos os campos, relativos ao Paciente selecionado, preenchidos. O sistema emite a mensagem: “Deseja utilizar este Paciente neste Atendimento?”. O Atendente responde positivamente, se for o caso, ou cadastra um novo Paciente para utilizar no Atendimento.
O sistema exibe a tela de Atendimento, já sobre o Paciente a ser atendido.
O Atendente clica no botão “Inserir exame”.
O sistema apresenta uma nova tela contendo os campos relativos à inserção de um novo exame àquele Atendimento.
O atendente preenche
os campos
necessários e clica no botão “Salvar”.
O sistema insere o novo exame na lista de exames do Atendimento e volta à tela de Atendimento, que permite ao Atendente inserir novos exames.
O atendente clica no botão “Salvar”.
O sistema apresenta a mensagem: “Deseja imprimir o Recibo do Atendimento”? O atendente escolhe a
opção desejada.
O sistema imprime o recibo do atendimento e volta a sua tela inicial. Neste momento este caso de uso é encerrado.
Nome do Caso de Uso Cadastrar Resultado
Descrição Este caso de uso permite a visualização e impressão dos diversos relatórios que o sistema disponibiliza. Ator envolvido Ator: Bioquímico
Administrador Sistema Este caso de uso
inicia quando o Bioquímico clica no botão “Resultados”, na tela inicial do sistema.
O sistema apresenta uma tela contendo os campos necessários ao cadastro do resultado de um exame. O Bioquímico informa o número de um Atendimento.
O sistema apresenta uma relação dos exames daquele Atendimento.
O Bioquímico selecionará o exame que se quer cadastrar os resultados e clicar no botão “Consultar”.
O sistema volta à tela de resultados de exame contendo os dados prévios do exame em questão. O Bioquímico deverá digitar os resultados do exame e clicar em Salvar. O sistema perguntará se se quer imprimir o Resultado de Exame. O Bioquímico selecionará a opção desejada. Interação ator-sistema O sistema imprimirá o Resultado de exame, se assim tiver sido desejado, e voltará à tela inicial do sistema. Neste momento este caso de uso é encerrado.
Nome do Caso de Uso Gerar Relatório/Gráfico Descrição
Este caso de uso permite a visualização e impressão dos diversos relatórios ou gráficos que o sistema disponibiliza.
Ator envolvido Ator: Administrador
Administrador Sistema Este caso de uso
inicia quando o administrador clica
no botão
“Relatórios”, na tela inicial do sistema.
O sistema apresenta uma tela contendo links para todos os tipos de relatórios disponíveis. O administrador deverá escolher o relatório de sua preferência clicando no link correspondente.
O sistema apresenta o relatório em questão.
Interação ator-sistema
O administrador imprime o relatório, se assim desejar. Neste momento este caso de uso é encerrado.
5.2 DIAGRAMA DE CLASSES
Após ter concluído os diagramas de caso de uso, podemos identificar as classes do projeto (diagrama de classe).
O diagrama visto na Fig. 5.2 esta dividido em doze classes que se relacionam entre si.
Nº Ordem Nome da Classe Descrição
01 Atendimento
É classe da qual se instancia objetos para registrar os atendimentos, mediante as informações: funcionário que está realizando o atendimento, paciente e data do atendimento.
02 ExameAtendimento
Esta classe existe para satisfazer a necessidade de Atendimento possuir vários exames distintos. Todos com diferentes características, como: tipo de exame, procedência, responsável pela coleta, data da coleta, hora da coleta e material coletado. Vários objetos desta classe podem se referenciar ao mesmo objeto Atendimento.
03 Exame
Esta classe nos possibilita instanciar os diversos exames cujas referências se fazem necessárias pelos objetos da classe ExameAtendimento.
04 Procedência
Tem as informações da procedência do paciente, para saber de qual unidade de saúde veio aquela guia de exame, esta classe também é chamada pela classe ExameAtendimento.
05 ValorReferencia
Tem as informações dos valores de referencias de cada exame, esse valores são consultados na hora de cadastrar os resultados dos exames. Esta classe tem relacionamento com a classe exame
06 MaterialColetado Classe que consta as informações dos materiais coletados do paciente.
07 ResultdoExame Esta classe cadastra os resultados dos exames dos pacientes.
08 Paciente Tem as informações referente ao cadastro de paciente que solicitam exames no LACEN.
09 Pessoa É uma classe que tem atributos que são herdados pelas classes Paciente e Funcionário.
10 Funcionário Tem as informações de cadastro de funcionários do LACEN.
11 Categoria Esta classe tem as informações de categorias de funcionários do LACEN.
12 Usuário Possui as informações inerentes a um usuário do sistema.
5.3 DIAGRAMA DE SEQÜÊNCIAS
O seguinte Diagrama de Seqüências foi elaborado a partir do Caso de Uso Cadastrar Atendimento.
CONCLUSÃO
Através da análise de requisitos verificamos que o LACEN dispõe de recursos computacionais entre equipamentos, materiais, instalações físicas, pessoas, porém, todo seu aparato não possui gestão que atue de modo coordenado em prol da informatização como missão organizacional.
Contudo, após a análise do seu ambiente e do sistema de informação de atendimento laboratorial foi possível, através da UML, realizar a modelagem do mesmo. Desse modo pudemos subsidiar uma melhor compreensão do problema através das perspectivas abordadas pelos diagramas ora expostos.
Tomar a situação sob uma visão orientada a objetos trouxe muitos benefícios no que concerne à elucidação dos detalhes, mesmo porque a ferramenta utilizada para a representação gráfica, através de diagramação, se referencia exclusivamente a esse tipo de abordagem.
Essa modelagem possibilitará o uso de uma base de dados unificada em um servidor de banco de dados e cada ponto de atendimento, com a aplicação devidamente instalada, se utilizará desta base.
Se continuado, no intuito de se chegar à fase de implementação, implantação e treinamento, o modelo proposto deverá resolver o problema da carência de um sistema realmente eficaz e, primordialmente, eficiente para o atendimento laboratorial, tanto na visão dos clientes quanto dos usuários.
REFERÊNCIAS
ALBERTÃO, Sebastião, E. ERP Sistemas de Gestão Empresarial: Metodologia para Avaliação, Seleção e Implantação para Pequenas e Médias Empresas. São Paulo: Iglu, 2005.
BALLESTERO ALVARES, M, E. Manual de Organização, Sistemas e Métodos. São Paulo: Atlas, 1990.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. São Paulo: Editora Campus, 2000.
CHIAVENATO, Idalberto, Teoria Geral da Administração, 6ª edição revista atualizada.Editora Campus – Rio de Janeiro, 2000.
CHIAVENATO, Idalberto. Introdução à Teoria Geral da Administração. 3.ed. São Paulo: Atlas, 1983.
CIANCONI, Regina. Gestão da informação na sociedade do conhecimento: Série SENAI Formação de Formadores. 2. ed. Brasília, SENAI/DN, 2001.
CIRNE, Walfredo. polifiguras.gif. 2003. Largura: 470 pixels. Altura: 433 pixels. 96 dpi. 8
BIT RGB. 5,44KB. Formato GIF. Disponível em:
<http://walfredo.dsc.ufcg.edu.br/cursos/2003/progII20031/aulas/polifiguras.gif>. Acesso em: 24 nov. 2007.
DAVENPORT, T. H. Ecologia da informação: Porque só a Tecnologia não Basta para o Sucesso na Era da Informação. São Paulo: Futura, 1998.
DIAS, Donaldo, S; GAZZANEO, G. Projeto de Sistemas de Processamento de Dados. Rio de Janeiro: Livros Técnicos e Científicos Editora S. A, 1989.
LAKATOS, Eva Maria. Fundamentos de Metodologia Científica: 2a ed. São Paulo: Atlas, 1990.
LARMAN, Craig. UTILIZANDO UML E PADRÕES: Uma introdução á análise e ao projeto orientados a objetos. Porto Alegre: Bookman, 2000. 493 p. ISBN 85-7307-651-8 LAUDON, Kenneth c. LAUDON, jane Price. Sistema de Informação. 4 ed. Rio de Janeiro: JC, 1991.
LAUDON, Kenneth, C; LAUDON, Jane, P. Sistemas de Informação: Com Internet. Rio de Janeiro: LTC, 1999.
LEE, Richard, C; TEPFENHART, William, M. UML e C++: Guia Prático de Desenvolvimento Orientado a Objeto. São Paulo: MAKRON Books, 2001.
LIMA, Adilson, S. UML 2.0: Do Requisito à Solução. São Paulo: Editora Érica, 2005.
MACCARIELLO, Maria do Carmo. A Construção Coletiva da Escola: consciência, representação e prática social. In: GRINSPUN, Mirian Paura S. Zippin (org.) Supervisão e Orientação Educacional: perspectivas de integração na escola. São Paulo: Cortez, 2003.
MATOS, Alexandre, V. UML: Prático de Descomplicado. São Paulo: Editora Érica, 2002.
MELO, Ana, C. Desenvolvendo aplicações com UML: do conceito à implementação. São Paulo: Editora Brasport, 2002.
MENEZES, M. B. Estudo sobre Reformulação de Cursos: Licenciaturas. 3º Seminário ‘Á Didática em questão’, 1993.
PRESSMAN, ROGER S., Engenharia de Software. São Paulo, Ed. McGrawHill, 2006.
PRESSMAN, Roger, S. Engenharia de Software. Rio de Janeiro: Mcgraw-Hill Interamericana do Brasil Ltda, 2002.
REZENDE, Denis, A. Planejamento de Sistemas de Informação e Informática. São Paulo: Atlas S. A. 2003.
SEVERINO, A. J. Metodologia do Trabalho Científico. São Paulo: Editora Cortez, 1985.
SEVERINO, A. J. Metodologia do Trabalho Cientifico. São Paulo: Editora Cortez, 1995.
SOUZA, Jader. Gestão Empresarial: Administrando Empresas Vencedoras. São Paulo: Saraiva, 2006.
TONSIG, Sérgio L. Engenharia de Software: Análise e Projeto de Sistemas. São Paulo: Editora Futura, 2003.
Clientes aguardando serem atendidos
