DESENVOLVIMENTO DE UM SISTEMA DE INFORMAÇÕES VISANDO APOIAR ESTUDO DE TRAUMATISMOS GRAVES EM CRIANÇAS DA CIDADE DE
FLORIANÓPOLIS E REGIÃO METROPOLITANA
Palhoça 2008
DARLAN MANOEL GUIMARÃES
DESENVOLVIMENTO DE UM SISTEMA DE INFORMAÇÕES VISANDO APOIAR ESTUDO DE TRAUMATISMOS GRAVES EM CRIANÇAS DA CIDADE DE
FLORIANÓPOLIS E REGIÃO METROPOLITANA
Trabalho de conclusão de curso apresentado ao Curso de Sistemas de Informação da Universidade do Sul de Santa Catarina como requisito parcial à obtenção do grau de Bacharel em Sistemas de Informação.
Orientador: Prof. Marcelo Medeiros
Palhoça 2008
DARLAN MANOEL GUIMARÃES
DESENVOLVIMENTO DE UM SISTEMA DE INFORMAÇÕES VISANDO APOIAR ESTUDO DE TRAUMATISMOS GRAVES EM CRIANÇAS DA CIDADE DE
FLORIANÓPOLIS E REGIÃO METROPOLITANA
Este trabalho de conclusão de curso foi julgado adequado à obtenção do grau de Bacharel em Sistemas de Informação e aprovado em sua forma final pelo Curso de Sistemas de Informação da Universidade do Sul de Santa Catarina.
Palhoça – SC, 17 de novembro de 2008.
______________________________________________________ Prof. Marcelo Medeiros
Universidade do Sul de Santa Catarina
______________________________________________________ Prof. Dr. Ricardo Villarroel Dávalos
Universidade do Sul de Santa Catarina
______________________________________________________ Dra. Daniele Morando Blanco
Primeiramente a Deus por estarmos concluindo este projeto.
À minha esposa Daniele Morando Blanco, que não se conformou somente com me apoiar durante todos estes anos de formação e foi além, participando deste projeto de forma ativa e fundamental para o sucesso e a conclusão do mesmo.
À minha esposa Sirlene Maciel Alexandre Guimarães, pelo completo incentivo em concluir os estudos, até mesmo nos momentos difíceis desta caminhada acadêmica. Aos meus pais, Mario e Custódia Guimarães pelo incentivo para a conclusão de mais uma etapa de minha vida. Aos meus irmãos, Kevin, Douglas, Mariana, e Letícia Rampazzo, a qual nos auxiliou muito na conclusão deste trabalho. A minha avó Maria Ondina Silva (Ia), que sempre me apoiou e incentivou para nunca desistir da faculdade.
Ao nosso querido mestre, Prof. Marcelo Medeiros, pela orientação deste projeto e por seus ensinamentos durante todos estes anos de faculdade. À professora Fernanda Oviedo, que ajudou muito no começo deste projeto, quando ele era apenas um esboço, e sempre tomou seu tempo para dar conselhos e ajudar melhorar nossa idéia. À Profa. Maria Inés Castiñeira, pela sua visão sobre nosso projeto no primeiro semestre, o que nos levou a reforçar os fundamentos para que nossa idéia original prevalecesse no final.
Ao terceiro mosqueteiro dessa longa caminhada na faculdade, nosso amigo e colega Daniel Luciano, com quem dividimos caronas, risadas, trabalhos, e estes anos que foram dos melhores de nossas vidas e dos quais vamos, com certeza, sentir saudades.
e falhou, mas com aquilo que ainda é possível a você fazer”.
Este trabalho analisou, especificou e desenvolveu uma ferramenta computacional, de baixo custo, dentro das necessidades técnicas exigidas pelo mercado, e destinada essencialmente ao estudo de traumas em crianças na região da grande Florianópolis. Os traumatismos representam a principal causa de morte entre crianças no mundo, e no Brasil isto não é diferente. Entretanto, existem poucos estudos sobre o tema na cidade de Florianópolis e por este motivo, o corpo médico do Hospital Infantil Joana de Gusmão (HIJG), da cidade de Florianópolis, iniciou um estudo estatístico com o objetivo de determinar características destes traumas para delinear ações de prevenção. Para uma análise mais apurada dos dados tornou-se fundamental a utilização de um sistema de tecnologia de informação que auxiliasse os médicos no levantamento, armazenamento e análise dos dados dos pacientes. Para gerenciar as informações o sistema utiliza ferramentas gráficas e ambiente web para maior integração entre os médicos envolvidos com o projeto. Com o protótipo elaborado, chamado de MedGraph, é possível realizar análises mais rápidas e seguras sobre os dados dos pacientes do estudo. A ferramenta foi desenvolvida e validada pelo usuário final, passando por todas as etapas necessárias para obtenção de um produto capaz de atender aos requerimentos da equipe médica pesquisadora.
Palavras Chaves: Sistemas de Informação. MedGraph. Traumatismos Graves. Tecnologia da Informação.
This work aims to create a computational instrument of low cost for the study of the trauma in children living in Florianópolis and surroundings. The trauma represents the most common cause of children’s mortality in the world, and it is not different in Brazil. However, there are few studies about this subject involving this region. For this reason, the staff of children’s Hospital Joana de Gusmão, in Florianópolis, started a statistical study aiming to outline the causes of the trauma and enumerate actions to prevent it. In order to analyze this database, the development of a specific framework become necessary, which will provide help to the staff in the survey, storage and subsequent analysis of the data. This new system, called MedGraph, was created with the purpose of being a simple and effective tool to evaluate the data; making tests fast and safe. The system utilizes graphical tools and web environment for better integration between the doctors involved with the project. The tool was developed and validated by the user and through all the steps needed to obtain a product able to meet the requirements of the medical staff researcher.
SUMÁRIO 1 INTRODUÇÃO ... 13 1.1 PROBLEMÁTICA... 14 1.2 OBJETIVO GERAL... 15 1.3 OBJETIVOS ESPECÍFICOS ... 15 1.4 JUSTIFICATIVA... 16 1.5 PROPOSTA DA SOLUÇÃO ... 16 1.6 DELIMITAÇÕES ... 18 1.7 METODOLOGIA CIENTÍFICA ... 18 1.8 ESTRUTURA DO PCC ... 19 2 FUNDAMENTAÇÃO TEÓRICA... 21 2.1 TRAUMA... 21
2.2 HOSPITAL INFANTIL JOANA DE GUSMÃO ... 22
2.3 PROTOCOLO DE PESQUISA ... 23
2.3.1 Dados gerais ... 23
2.3.2 Dados específicos de traumatismos... 24
2.3.3 Dados dos tipos de acidentes... 26
2.3.4 Dados do tipo de atendimento ... 28
2.4 ESTATÍSTICA... 28
2.4.1 Divisões da estatística ... 29
2.4.1.1 Estatística descritiva ... 29
2.4.1.2 Estatística indutiva ... 30
2.4.2 Fases do método estatístico ... 30
2.4.3 População ... 31
2.4.4 Amostra ... 31
2.4.5 Amostragem ... 32
2.4.6 Distribuição de freqüências ... 32
2.4.7 Apresentação gráfica... 32
2.4.7.1 Gráficos em colunas ou em barras... 33
2.4.7.2 Gráficos em setores ... 33
3 MODELAGEM DO SISTEMA MEDGRAPH... 34
3.1 UML (UNIFIED MODELING LANGUAGE)... 34
3.2 DIAGRAMAS DE UML ... 35
3.2.1 Modelo de domínio e diagrama de classes... 35
3.2.2 Requisitos funcionais... 37 3.2.3 Casos de uso ... 38 3.2.4 Diagrama de pacotes ... 39 3.2.5 Ator ... 40 3.2.6 Diagrama de seqüência ... 41 3.2.7 Diagrama de interfaces ... 43 3.2.8 Diagrama de robustez ... 44 3.3 ICONIX ... 44 4 IMPLEMENTAÇÃO E VALIDAÇÃO... 46 4.1 FERRAMENTAS UTILIZADAS... 46 4.2 LINGUAGEM DE PROGRAMAÇÃO... 48 4.3 FERRAMENTAS DEGRÁFICOS ... 49 4.4 APRESENTAÇÃO DO SISTEMA... 49 4.5 VALIDAÇÃO DO SISTEMA... 56
5 CONCLUSÕES E RECOMENDAÇÕES ... 59 5.1 CONCLUSÕES... 59 5.1.1 Escolha... 59 5.1.2 Contexto ... 60 5.1.3 Desenvolvimento... 60 5.1.4 Validação... 61 5.1.5 Solução... 61 5.2 RECOMENDAÇÕES FINAIS... 62 REFERÊNCIAS... 63
ANEXO 1 – PARECER DA COMISSÃO DE ÉTICA DO HIJG ... 65
FIGURAS
Figura 1 – Proposta da solução ...17
Figura 2 – Fluxograma da Metodologia de estudo. ...19
Figura 3 – Escala de trauma pediátrica. ...24
Figura 4 – Escala de trauma revisada. ...25
Figura 5 – Resultado do preenchimento da Escala de trauma revisada...26
Figura 6 – Tipos de acidentes. ...28
Figura 7 - Modelo de Domínio. ...35
Figura 8 – Diagrama de Classe de Domínio ...37
Figura 9 – Exemplo de Requisito Funcional. ...37
Figura 10 – Exemplo de Caso de Uso. ...39
Figura 11 – Diagrama de Pacotes. ...40
Figura 12 – Exemplo de Ator. ...41
Figura 13 – Diagrama de Seqüência. ...42
Figura 14 – Exemplo de Interfase...43
Figura 15 – Exemplo de Diagrama de Robustez. ...44
Figura 16 – Ferramentas utilizadas...46
Figura 17 – Tela inicial do sistema...50
Figura 18 – Tela de cadastro de paciente inicial...51
Figura 19 – Tela de cadastro de paciente para trauma de evenenamento...52
Figura 20 – Exemplo de mensagem explicativa de erro...52
Figura 21 – Tela de cadastro de paciente finalizada com sucesso...53
Figura 22 – Exemplo de consulta por tipo de trauma ...53
Figura 23 – Gráfico de pizza gerado pelo sistema...54
Figura 24 – Gráfico de barras gerado pelo sistema ...55
QUADROS
1 INTRODUÇÃO
Atualmente os traumatismos são a principal causa de mortes em crianças e adolescentes em todo o mundo e segundo a American Heart Association (AHA) “os traumas são responsáveis por mais mortes infantis do que todas as outras causas juntas” (AHA, 2007). Os poucos estudos estatísticos divulgados sobre traumatismos graves em crianças na cidade de Florianópolis motivou os profissionais que trabalham na Unidade de Terapia Intensiva (UTI) do Hospital Infantil Joana de Gusmão (HIJG) a iniciar um levantamento entre os pacientes atendidos pelo seu serviço.
Os responsáveis por este estudo, os Drs. Daniele Morando Blanco e César Lemos, objetivam determinar as características destes traumatismos em crianças e adolescentes. A pesquisa científica tem como corpus de estudo os atendimentos realizados no período de janeiro de 2001 a dezembro de 2006. Para complemento deste estudo os autores deste projeto se interessaram pelo desenvolvimento de um sistema computacional capaz de colaborar com a pesquisa dos médicos.
Inicialmente foram observadas para a solução algumas ferramentas já existentes no mercado muito usadas na área da medicina, algumas proprietárias, outras sem custo, que possibilitariam o atendimento às necessidades. Entre as ferramentas proprietárias analisadas a mais prática e conhecida foi a "Sphinx", um software para coleta e análise de dados, especializado em análises quantitativas e qualitativas para posteriores cruzamentos e exploração de dados. Em paralelo, foram analisados pacotes de software de domínio público. O de maior destaque e que mais se adequou ao nosso estudo especificamente, foi o "EpiInfo", um software bastante utilizado na área médica por profissionais que administram investigações de epidemias e coordenam pequenos bancos de dados e análises estatísticas.
Após o levantamento das possíveis soluções no mercado, uma análise de prova de conceito foi apresentada à equipe médica responsável pelo estudo e verificou-se que tanto o Sphinx quanto o EpiInfo poderiam atender as necessidades. Porém, o desenvolvimento de um software específico e voltado para os cenários específicos do estudo realizado seria o ideal, pois trataria exatamente das necessidades levantadas pelos médicos, sem recursos desnecessários e dentro de um modelo já conhecido.
Com base na escolha dos médicos por uma ferramenta específica e também com a intenção dos alunos no desenvolvimento de uma ferramenta computacional, a fim de validar os conhecimentos adquiridos no curso de sistemas de informação, optou-se por desenvolver
um sistema que atenda as necessidades deste corpo médico e dos estudos relacionados a traumas infantis.
É neste contexto que teve início este projeto na área de informática para desenvolver um aplicativo de auxílio no estudo sobre “Traumatismos graves em crianças e adolescentes na cidade de Florianópolis e região”.
1.1 PROBLEMÁTICA
O levantamento dos dados necessários para o estudo foi feito pelos próprios doutores por meio de um questionário que estudou os prontuários dos pacientes internados na UTI do HIJG que sofreram traumatismos graves. O principal problema é que estes dados foram registrados em papel e não por meio eletrônico, além de que a quantidade de prontuários relacionados a traumatismos graves é muito elevada, contendo um conjunto de informações muito variadas e específicas.
Existem inúmeros tipos de traumatismos que deverão ser analisados, como queimaduras, acidentes de trânsito, envenenamentos, dentre outros. Cada um destes deverá ser avaliado de forma específica, pois a cinemática e o desfecho de cada um é diferente. Pode-se citar, por exemplo, que o tipo de lesão corporal sofrida por fogo é diferente da lesão por um atropelamento e que as dificuldades respiratórias de uma criança afogada são diferentes das de uma vítima de um ferimento de arma de fogo no abdômen.
Cada caso deverá ser analisado de maneira global (dados que são comuns a todos os tipos de trauma), e após de maneira específica (dados que diferem de um trauma para outro). Uma vez registrados, os dados deverão ser submetidos a um levantamento estatístico por meio de cruzamentos das variáveis coletadas. Este processo sem uma ferramenta computacional tornar-se-ia lento e difícil de interpretar, sendo praticamente inviável.
1.2 OBJETIVO GERAL
Desenvolver um aplicativo de cadastro, cruzamento de variáveis e análise gráfica dos resultados obtidos, referentes aos prontuários de crianças e adolescentes que sofreram traumatismos graves na cidade de Florianópolis e região metropolitana com a finalidade de auxiliar os estudos do corpo médico.
1.3 OBJETIVOS ESPECÍFICOS
Abaixo são descritos os objetivos específicos deste trabalho:
1. Implementar um sistema informatizado realizando todas as etapas inerentes ao processo de desenvolvimento envolvendo: análise de requisitos, definição de modelo de dados, escolha das ferramentas de desenvolvimento e construção do software na forma de protótipo para validação das principais funcionalidades, de forma a aprofundar e validar os conhecimentos obtidos na faculdade;
2. Realizar um levantamento sobre os conceitos de traumatismo grave;
3. Estudar os conceitos de estatística, fórmulas matemáticas e como estas podem auxiliar na implementação do sistema;
4. Reforçar os conhecimentos adquiridos na linguagem de programação Java, e poder na conclusão deste projeto ter um sistema desenvolvido totalmente pelos autores nessa linguagem.
1.4 JUSTIFICATIVA
Atualmente os sistemas de informação estão presentes em todas as áreas da ciência e auxiliam estudos e pesquisas de qualquer natureza. Em 2007, quando começou seu estudo, a Dra. Daniele Morando Blanco verificou a necessidade de uma ferramenta de tecnologia da informação que viesse a ajudá-la na conclusão da sua pesquisa científica. Neste mesmo ano os autores deste projeto verificaram a importância que este significaria para a sociedade, e que tal projeto justificava a realização de um estudo na área de sistemas de informação para desenvolver uma ferramenta que permitisse concluir a pesquisa médica. Desde então modelos foram estudados, requisitos definidos e pesquisas de possíveis ferramentas a serem utilizadas no projeto foram realizadas. Para tal, utilizou-se de matérias como: Engenharia de Software, Banco de Dados, Sistemas de Apoio a Decisão e Modelagem de Processos.
Os médicos do HIJG pretendem publicar os resultados de seu estudo em importantes periódicos médicos nacionais e internacionais. Assim, a ferramenta desenvolvida também divulga no âmbito da saúde o nome da Unisul e de seu curso de Sistemas de Informação. Além disso, é pretensão dos autores a publicação deste trabalho em artigos de informática como exemplo de um aplicativo voltado à área de medicina com benefícios diretos para a sociedade.
O foco deste projeto está voltado para criar uma aplicação em uma área muito abrangente, a pesquisa médica, que necessita cada vez mais de soluções computacionais que sejam voltados para realizar análises de dados de saúde e posteriores estudos médicos preventivos.
1.5 PROPOSTA DA SOLUÇÃO
A ferramenta proposta como solução é um sistema de informações o qual foi batizado de “MedGraph”.
- Cadastro de Dados - Nesta etapa é realizado o cadastro das informações históricas dos pacientes;
- Análise dos Dados - Nesta etapa os médicos analisam os dados a partir de cruzamento de variáveis, como por exemplo: idade, local de moradia, tipo de trauma.
Como as análises podem ser realizadas por médicos de vários locais e em momentos diferentes, o sistema é desenvolvido para o ambiente de internet, acessado por um navegador de internet padrão. A figura 1 representa a solução implementada.
Figura 1 – Proposta da solução Fonte autores.
O acesso aos dados de cadastro e alteração destes se dá por meio de uma interface similar ao prontuário original, através de um navegador de internet na estação de trabalho. O acesso é restrito aos médicos (pesquisadores) por meio de um login e senha.
Os dados são armazenados em um computador centralizador, chamado de servidor, através de um sistema gerenciador de banco de dados gratuito. No mesmo servidor a aplicação que elabora e permite a análise dos dados por meio de gráficos é implantada. Esta aplicação é desenvolvida em linguagem de programação multi-plataforma, podendo ser executada em qualquer sistema operacional.
1.6 DELIMITAÇÕES
O software resultante deste projeto tem algumas delimitações que são enumeradas a seguir:
- O projeto é voltado para um cenário específico, enquadrado no HIJG e com os dados que a Instituição coleta de seus pacientes.
- As variáveis do questionário foram escolhidas pela equipe médica que realiza o estudo, sem interferência dos autores deste projeto.
- Os tipos de gráficos e as variáveis de cruzamento de dados também foram especificados pela equipe médica.
- O software desenvolvido representa um protótipo para validação de conceito, o que não impede a sua correta utilização, porém não representa ainda um produto comercializável.
1.7 METODOLOGIA CIENTÍFICA
Inicialmente é importante mencionar a importância de um método para desenvolver um estudo científico, para Marconi e Lakatos,
Método é a forma de proceder ao longo de um caminho. Na ciência os métodos constituem os instrumentos básicos que ordenam de início o pensamento em sistemas, traçam de modo ordenado a forma de proceder do cientista ao longo de um percurso para alcançar um objetivo (TRUJILLO, 1974 apud MARCONI, LAKATOS, 2004).
Para realizar este projeto os autores precisaram se familiarizar com o objeto de estudo principalmente por envolver vários conceitos de medicina desconhecidos até o momento. Para isso, o conceito de Koche sobre pesquisa exploratória está diretamente associado aos objetivos deste trabalho,
Nesses casos é necessário desencadear um processo de investigação que identifique a natureza do fenômeno e aponte as características essenciais das variáveis que se quer estudar. Na pesquisa exploratória não se trabalha com a relação entre variáveis, mas com o levantamento da presença das variáveis e da sua caracterização quantitativa ou qualitativa (KOCHE, 1997).
A figura abaixo descreve em forma de fluxograma a metodologia usada para realizar este estudo e posterior desenvolvimento do sistema.
Figura 2 – Fluxograma da Metodologia de estudo. Fonte: Autores.
1.8 ESTRUTURA DO PCC
A estrutura deste projeto foi dividida em capítulos que estão detalhados a seguir: - Capítulo 1: Introdução – este capítulo contém: uma breve introdução para descrever do que se trata o projeto, qual a problemática identificada, são enumerados o objetivo geral e os objetivos específicos do trabalho, qual é a justificativa para realizar o estudo, a proposta para a solução do problema, as delimitações e a metodologia a ser usada.
- Capítulo 2: Fundamentação teórica – no segundo capítulo agrupamos os conceitos teóricos estudados e revisados para desenvolver o projeto, são eles: conceito de
trauma e sua relevância na saúde da população infantil, características do serviço de saúde onde é feito o estudo médico, análise do protocolo de pesquisa usado para coletar os dados, revisão de conceitos de Estatística para definição de técnicas a serem utilizadas.
- Capítulo 3: Diagramas UML e ICONIX – neste capítulo são abordados conceitos sobre UML e os diferentes diagramas usados no projeto, além de explicar como a técnica Iconix foi utilizada para o processo de desenvolvimento do software.
- Capítulo 4: Implementação e validação – descreve como foi feito o processo de construção do sistema, as ferramentas utilizadas e a validação do software.
- Capítulo 5: Conclusões e recomendações – enumera as conclusões que surgem deste projeto e algumas recomendações para o futuro do mesmo.
- Referências Bibliográficas – Nesta seção são enumerados os livros e artigos utilizados como referenciais para este projeto.
- Anexos – contém o material referenciado neste trabalho que pertence a outros autores.
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo serão apresentados alguns conceitos de medicina que são necessários para o entendimento do tipo de trabalho de pesquisa que o aplicativo irá dar apoio. Além disso, serão descritas algumas características do serviço de saúde do qual são provenientes os pacientes alvos deste estudo e a seguir uma análise descritiva do protocolo de pesquisa que é a base para a estruturação e a modelagem do sistema que irá ser desenvolvido.
Também detalharemos alguns conceitos estatísticos sobre tipos de amostras e tipos de gráficos os quais são necessários para o entendimento das técnicas utilizadas para desenvolver o sistema.
2.1 TRAUMA
Para Elias Knobel(2006).
Definir o trauma é extremamente difícil devido à ampla variedade das causas; para englobá-las, podemos usar a definição de trauma como sendo um evento que provoca uma laceração funcional, com ou sem tradução morfológica, perceptível ou não à primeira vista, que advém da liberação de formas específicas de energia (mecânica, química, térmica, por irradiação ou elétrica) ou de barreiras físicas ao fluxo normal de energia.
A gravidade do trauma esta geralmente relacionada à forma e quantidade de energia envolvida no evento traumático, conforme o Manual de Socorro de Emergência do Corpo de Bombeiros Militar do Rio de Janeiro (1999).
Os pacientes envolvidos em eventos de alta energia são propensos a possuir lesões graves, e 5% a 15% deles, apesar de sinais vitais normais e de não possuírem lesões corporais na primeira avaliação, evidenciam lesões graves em exames posteriores.
No Manual para provedores da American Heart Association (2007), principal referência mundial em estudo de atendimento ao trauma, é citado como fato fundamental a diferença entre Trauma versus Acidente da seguinte forma: “Enfatiza-se o termo trauma em lugar do termo acidente porque um trauma é freqüentemente evitável. O termo acidente implica que nada pode ser feito para evitar o episódio”.
Cabe ressaltar também que, ainda segundo o Manual para provedores da American Heart Association (2007), internacionalmente os traumas são a principal causa de morte de crianças de 1 a 14 anos de idade e são responsáveis por mais mortes infantis do que todas as outras causas juntas.
2.2 HOSPITAL INFANTIL JOANA DE GUSMÃO
Os prontuários analisados no projeto são pertencentes ao Hospital Infantil Joana de Gusmão pelo qual é necessário relatar algumas características importantes desta instituição para entender a importância do estudo e como é feita a preservação das informações dos pacientes.
Situado na cidade de Florianópolis, Santa Catarina, o HIJG é pólo de referencia estadual em atendimento a crianças provenientes de todo o estado, sendo 65,19% pacientes oriundos de Florianópolis e da Grande Florianópolis (São José, Palhoça, Biguaçu, Santo Amaro da Imperatriz) e 34,81% de outros municípios do Estado de Santa Catarina (HIJG, 2008). Devido a isso o estudo adquire relevância estadual e serve de referência para outros estados do Brasil.
O HIJG conta com um Comitê de Ética em Pesquisa (CEP) que por sua vez está associado à Comissão Nacional de Ética em Pesquisa (CONEP) do Conselho Nacional de Saúde. Este comitê tem a função de implementar as normas e diretrizes regulamentadoras de pesquisas envolvendo seres humanos.
Para a realização deste estudo o CEP autorizou os médicos a utilizar as informações dos pacientes mediante parecer com registro 009/2008 e data 03 de julho de 2007(anexo 1).
2.3 PROTOCOLO DE PESQUISA
Foram analisados e avaliados os prontuários hospitalares dos pacientes e coletados os dados com ajuda do protocolo de pesquisa (anexo 2), criado pela Dra. Daniele M. Blanco com base na literatura específica da área. Para melhor compreensão do que seja um protocolo de pesquisa e a sua aplicação neste projeto, a seguir este será descrito com suas diferentes seções do ponto de vista da análise dos dados.
Este protocolo analisa um conjunto de dados epidemiológicos, composto por: idade, sexo, época do ano, cidade, escala de trauma pediátrico, escala de trauma revisado, tipo de acidente (traumatismo craniano, acidentes por exposição a forças inanimadas, acidentes causados por forças mecânicas animadas, afogamentos, envenenamentos, transporte, corrente elétrica, queimaduras, contato com animais e plantas venenosas, lesões auto-provocadas intencionalmente, múltiplas injúrias), local do primeiro atendimento, prestador do atendimento pré-hospitalar, tempo entre o primeiro atendimento e chegada ao hospital de referência, tempo de internação em UTI, necessidade de ventilação mecânica, mortalidade e doação de órgãos.
Para uma análise mais detalhada, os dados do protocolo foram divididos em quatro partes:
- Dados gerais.
- Dados específicos de traumatismos. - Dados dos tipos de acidente.
- Dados do tipo de atendimento.
2.3.1 Dados gerais
Estes dados estão presentes em todos os protocolos, são eles: Idade, sexo, cidade, época do ano. O campo cidade terá somente valores das cidades que o estudo abrange, e a data em que o acidente aconteceu foi delimitada no campo “época do ano” que tem somente quatro valores (verão, inverno, outono e primavera) para ajudar nos cruzamentos estatísticos futuros.
2.3.2 Dados específicos de traumatismos
O protocolo conta com duas escalas: Escala de Trauma Pediátrica e Escala de Trauma Revisada, que foram idealizadas por estudos internacionais (THE JOURNAL OF TRAUMA, 2006), e que são mundialmente reconhecidos como marcadores de gravidade. Estas escalas têm a finalidade de estabelecer os principais parâmetros usados pela medicina para avaliar traumas e posteriormente serão usados pelo sistema computacional para realizar cruzamentos. Estas escalas são formadas por parâmetros clínicos estabelecidos com base nas referências bibliográficas da área e pelo corpo médico do hospital. Estes termos médicos não serão aprofundados por se tratarem de informações já pré-determinadas pelos idealizadores do questionário, o que será avaliado neste projeto é como transportá-lo para o software de avaliação da pesquisa em si. A figura 3 apresenta a Escala de trauma pediátrica e todos os parâmetros clínicos que a compõem:
Figura 3 – Escala de trauma pediátrica.
Fonte: The Journal of Trauma adaptado pela Dra. Daniele Morando Blanco.
A escala esta formada por:
- parâmetro clínico, que informa a descrição do parâmetro;
Parâmetro clínico Categoria Escore
20 2 10- 19 1 Peso (Kg) < 10 -1 Normal 2 Preservada 1 Via aérea Não preservada -1 > 90 2 50- 89 1 PAS < 50 -1 Acordado 2
Confusão ou perda consciência 1
SNC Coma ou descerebração -1 Nenhum 2 Pequeno 1 Ferimento aberto Grande ou penetração -1 Normal 2 Fratura fechada 1 Esqueleto
- categoria, que contêm descrições dos valores que cada parâmetro clínico pode adquirir;
- escore, que existe um para cada categoria, e é um valor numérico resultante da categoria escolhida.
Para cada item da escala o médico deve marcar um e apenas um item da escala, a fim de determinar uma pontuação que será resultante do grau de cada marcação. Portanto, cada parâmetro representa uma e somente uma categoria, e esta funcionalidade deve ser implementada no sistema, garantindo a associação automática da categoria e do seu respectivo escore. Esse escore final (soma dos graus) serve para o médico realizar cruzamentos posteriores com outros parâmetros como, por exemplo: mortalidade, tempo de internação entre outros.
A figura 4 detalha a Escala de trauma revisada, que segue as mesmas regras de escore e escolha de categoria da Escala pediátrica.
Parâmetro clínico Categoria Escore
10 –24 4 25- 35 3 > 35 2 < 10 1 FR (respmin) 0 0 > 90 4 70 -89 3 50 –69 2 < 50 1 PAS 0 0 14- 15 4 11- 13 3 8- 10 2 5 –7 1
Escala de coma de glasgow
3 –4 0
Figura 4 – Escala de trauma revisada.
Fonte: The Journal of Trauma adaptado pela Dra. Daniele Morando Blanco.
Exemplificando, um médico ao realizar o atendimento de um determinado paciente, preencheu na fichas as seguintes informações, com relação a escala de trauma pediátrica:
Figura 5 – Resultado do preenchimento da Escala de trauma revisada. Fonte: Dra. Daniele Morando Blanco.
Apenas os itens selecionados serão considerados na definição do grau final, que corresponde a soma de todos os escores: 2+1+2-1+2+2, totalizando em 8 (oito). Este escore final deve ser calculado automaticamente pelo sistema e armazenado para posteriormente agilizar os cruzamentos.
2.3.3 Dados dos tipos de acidentes
Na UTI são atendidos vários tipos de acidentes, porém para o levantamento que faz parte deste estudo, um mesmo paciente não pode ser avaliado por tipos de traumas diferentes, para o mesmo atendimento, logo, cada paciente é avaliado a partir de um tipo de acidente predominante, uma vez que cada acidente tem características específicas. Caso um paciente seja atendido por queimadura e afogamento, no questionário este paciente será avaliado por um único trauma, resultante da avaliação do médico especialista. Os tipos de acidentes possíveis são: quedas, acidentes por exposição a forças inanimadas, acidentes causados por forças mecânicas animadas, afogamentos, envenenamentos, acidentes de trânsito, exposição à corrente elétrica, queimaduras, contato com animais e plantas venenosas, lesões auto-provocadas intencionalmente, múltiplas injúrias.
Para cada registro, o sistema deve oferecer ao usuário a possibilidade de selecionar o tipo de acidente, previamente cadastrado, e a partir desta escolha cadastrar as informações pertinentes a este tipo de acidente.
Por exemplo, em caso de um trauma por afogamento, o usuário do sistema deverá selecionar dentre uma lista de traumas previamente cadastrados a opção "afogamento". A
Parâmetro clínico Categoria Escore
Peso (Kg) 20 2
Via aérea Preservada 1
PAS > 90 2
SNC Coma ou descerebração -1
Ferimento aberto Nenhum 2
partir desta escolha, apenas os campos pertinentes serão apresentados ao usuário, como: Piscina, Mar, Rio ou Outros.
A figura 6 detalha cada tipo de acidente e suas características específicas, que representa as possíveis escolhas por parte do usuário, e para cada uma destas escolhas quais opções estarão disponíveis para cadastro.
A) Quedas:
Altura da queda: _____+ de 1 metro _____- de 1 metro Tipo de injúria cerebral: _____ hemorragia intracraniana
_____ hemorragia extracraniana _____ swelling
Escala de coma de Glasgow na admissão: ____ B) Acidentes por exposição a forças inanimadas: Aspiração de corpo estranho: ______
Ferimento por arma de fogo:
Parte do corpo: cabeça/pescoço ___ tórax ___ abdômen ___ Local do acidente: casa ____ colégio ____ rua ____
F e r i me n t o p o r a r ma b r a n c a :
P a r t e d o c o r p o : cabeça/pescoço ___ tórax ___ abdômen ___ Local do acidente: casa ____ colégio ____ rua ____
C) Acidentes por exposição a forças animadas: Agressão: terceiros____ maus-tratos _____ Mordedura de animais: cão ____ outros _____ D) Afogamento:
Piscina ____ Mar ____ Rio ____ Outros ____ E) Envenenamentos:
Por medicamentos e substâncias biológicas: Tipo subst _____________________ Por substâncias de origem não- medicinal: Tipo subst _____________________ F) Acidentes de trânsito:
Atropelamento: bicicleta ___ moto ___ automóvel ___ ônibus ___ caminhão____ Colisão: Tipo:_______________________________________________________ G) Exposição a corrente elétrica: ________________________________________ H) Queimaduras:
Parte do corpo: ___________________ % queimada: ___________________ Grau: ____________________ Tipo substância: _____________________ I) Contato com animais e plantas venenosas:
Serpentes____ Abelhas____ Escorpiões ____ Aranhas____ Plantas ___________ J) Lesões auto-provocadas intencionalmente: _______________________________ K) Múltiplas injúrias: _________________________________________________
Figura 6 – Tipos de acidentes. Fonte Dra. Daniele Morando Blanco.
2.3.4 Dados do tipo de atendimento
É importante para as análises e cruzamentos posteriores que cada registro contenha dados sobre como foi feito o atendimento do paciente, antes, durante e depois da chegada ao hospital. Para isso o protocolo contém os seguintes dados:
- local do primeiro atendimento, será o nome da instituição em que foi realizado o primeiro atendimento do paciente antes de ser encaminhado ao centro de referência do estado, o HIJG;
- Samu, indica se o paciente foi ou não transportado pelo Serviço de atendimento médico de urgência (SAMU);
- tempo entre o primeiro atendimento e chegada ao hospital, tempo este medido em horas;
- tempo de internação na UTI, tempo este medido em dias;
- necessidade de ventilação mecânica, que deve indicar se foi necessário ou não e em caso de ter sido necessário deverá ser informado o número de dias que o paciente precisou ser ventilado mecanicamente;
- mortalidade, indica se o paciente evoluiu para óbito ou não.
2.4 ESTATÍSTICA
A estatística é uma ciência muito utilizada tanto na área acadêmica quanto fora dela. A estatística auxilia o pesquisador a realizar cálculos e tomar decisões a respeito de seu estudo, principalmente quando é necessário realizar tratamentos de uma grande massa de dados e por simplificar os resultados a serem obtidos.
A estatística possui um conceito bem definido entre diversos autores. Segundo Akanine (1998, p. 01) “estatística é a ciência que estuda as técnicas necessárias para coletar, organizar, apresentar, analisar e interpretar dados, a fim de extrair informações a respeito de uma população”.
Para Crespo (2001, p. 13), “A estatística é a parte da Matemática Aplicada que fornece métodos para a coleta, organização, descrição, análise e interpretação de dados e para a utilização dos mesmos na tomada de decisões”.
Toledo (1985, p. 14 e 15) explica que “a Estatística não é, de forma alguma, um método mediante o qual se pode provar tudo aquilo que deseja” e também diz que “a Estatística não é simplesmente uma coleção de dados (estatísticos)”. A estatística nos fornece os meios de conseguirmos analisar de forma clara e objetiva os dados de uma pesquisa, de forma simples, com a possibilidade de facilmente tomarmos conclusões que facilitem a tomada de decisões.
2.4.1 Divisões da estatística
A estatística está dividida em duas partes bem definidas, a serem descritas abaixo.
2.4.1.1 Estatística descritiva
É a parte da estatística que se dedica a análise e interpretação dos dados, desde que estes dados possuam alguma informação em comum. Os dados podem ser coletados através de pesquisas, questionários e a classificação dos dados podem ser apresentados através de gráficos ou relatórios. Também são utilizados para a análise os coeficientes estatísticos para uma maior compreensão dos resultados obtidos.
Toledo (1985, p.15) define estatística descritiva como:
uma função cujo objetivo é a observação de fenômenos da mesma natureza, a coleta de dados numéricos referentes a esses fenômenos, a organização e a classificação desses dados e a sua apresentação através de gráficos e tabelas.
Em nosso estudo utilizaremos a estatística descritiva, pois é a que trata de todas as fases e não somente a análise final dos dados.
2.4.1.2 Estatística indutiva
Trata da análise e interpretação dos dados, com um processo de generalização a partir dos resultados. Essa generalização trabalha com um nível de incerteza dos resultados, o que através de técnicas fundamentam a teoria da probabilidade.
Toledo (1985, p.15 e 16) define a estatística indutiva como: “Consiste em obter e generalizar conclusões, ou seja, inferir propriedades para o todo com base na parte, no particular”.
2.4.2 Fases do método estatístico
Para realizar um estudo estatístico existem diversas fases para poder obter uma completa análise e uma perfeita compreensão dos resultados estudados. Segundo Toledo (p 21), as fases são: a definição do problema, o planejamento, a coleta dos dados, apuração dos dados, apresentação dos dados e a análise e interpretação dos dados e serão descritas a seguir.
Definição do problema – consiste na definição completa do que será estudado e quais ferramentas serão utilizadas.
Planejamento – determina quais métodos serão levados em consideração para a realização da pesquisa e como os dados serão obtidos.
Coleta dos dados – é a parte operacional, onde os dados são colhidos e reunidos para um estudo posterior. Toledo (p. 22) define a coleta de dados como “a coleta de dados se refere a obtenção, reunião e registro sistemático dos dados, com um objetivo determinado”. Os dados podem ser primários, que são os dados publicados pelo próprio pesquisador, ou secundários quando publicados por terceiros. Os dados podem ser obtidos de forma direta
(estes são obtidos diretamente da fonte por um pesquisador), ou de forma indireta (com os dados oriundos de um jornal ou revista).
Apuração dos dados – é a fase onde os dados passam por um tratamento inicial, são verificados se os dados realmente farão parte da pesquisa e se contem informações relevantes para o estudo. Esta apuração pode ser feita de forma manual sem o auxílio de ferramentas; de forma mecânica com ajuda de calculadoras ou outros objetos ou de forma eletrônica com o auxílio de um computador por exemplo.
Apresentação dos dados - é quando os dados já tratados são expostos para um estudo posterior. A apresentação pode ser de forma tabular, com o uso de tabelas ou na forma de gráficos.
Análise e interpretação dos dados – nesta última fase o pesquisador pode retirar suas conclusões sobre o estudo.
2.4.3 População
Toledo (p. 16) define como “O conjunto da totalidade de indivíduos sobre o qual se faz uma inferência”. Portanto, é a totalidade de indivíduos que é estudado, desde que tenham alguma característica em comum, que o pesquisador tenha interesse em estudar. Neste caso a população consiste nos atendimentos realizados no HIJG.
2.4.4 Amostra
Segundo Akanime (1998, p. 08) “amostra é qualquer subconjunto da população”. Toledo (p 16) a descreve como “A amostra pode ser definida como um subconjunto, uma parte selecionada da totalidade de observações abrangidas pela população”. É utilizada para poder retirar conclusões mais rápidas sobre o assunto sem realizar um estudo muito complexo, quando o tempo para o término do estudo é reduzido ou quando a população original é muito extensa.
2.4.5 Amostragem
Amostragem é o processo em qual o pesquisador retira os dados de seu interesse para a pesquisa da população, ela se baseia no que convém ao pesquisador. Para esse estudo a equipe médica utilizou a amostragem de conveniência, onde essa amostra pode não representar a população de origem, porém são os dados que o pesquisador possui em mãos e foram atendidos no local da pesquisa. Fletcher (2005, p.91) diz sobre amostras de conveniências que “... a maior virtude é que são convenientes de obter, como amostras de pacientes que estão fazendo uma consulta em uma clínica médica, que são cooperativos e bem articulados”.
2.4.6 Distribuição de freqüências
A distribuição de freqüência auxilia na visualização dos resultados de um estudo, pois os dados são exibidos de uma forma mais simples, através de tabelas. As tabelas são constituídas por dados organizados em linhas ou colunas, sendo uma contendo uma variável do estudo e a outra contendo as freqüências encontradas.
2.4.7 Apresentação gráfica
A utilização de gráficos possibilita uma rápida compreensão das conclusões que o pesquisador quer repassar com uma interface limpa e de fácil visualização. Crespo (p. 38) define gráficos estatísticos como: “O gráfico estatístico é uma forma de apresentação dos dados, cujo objetivo é o de produzir, no investigador ou no público em geral, uma impressão mais rápida e viva do fenômeno em estudo”. Toledo (p. 75) confirma dizendo que “A principal vantagem de um gráfico sobre a tabela prende-se ao fato de que ele permite conseguir uma visualização imediata da distribuição dos valores observados”.
Crespo (p. 38) diz que os gráficos são extremamente úteis para as conclusões de um estudo, mas devem ter que seguir algumas regras. Devem possuir simplicidade na sua construção, não devem ter informações desnecessárias que complicariam o entendimento ou que possam levar o usuário ao erro. Deve ser claro para gerar uma correta interpretação e ter veracidade, ou seja, deve expressar perfeitamente o que foi estudado.
Para o nosso estudo, iremos utilizar os gráficos em colunas ou em barras e os gráficos em setores, que serão descritos abaixo.
2.4.7.1 Gráficos em colunas ou em barras
Conforme afirma Crespo (p. 41) “é a representação de uma série por meio de retângulos, dispostos verticalmente (em colunas) ou horizontalmente (em barras)”.
2.4.7.2 Gráficos em setores
É a forma de representação onde os dados ficam inseridos em um círculo e cada dado específico ocupa uma fatia ou um setor deste. Crespo (p. 43) diz que “é empregado sempre que desejamos ressaltar a participação do dado no total”, porém, o gráfico em setores só deve ser empregado quando não existe muita variedade de dados.
3 MODELAGEM DO SISTEMA MEDGRAPH
Neste capítulo são definidos:
- Conceitos de Linguagem UML e tipos de diagramas que a linguagem utiliza, apresentando as principais características da análise e modelagem realizado para o desenvolvimento do sistema MedGraph;
- ICONIX, metodologia utilizada pelos autores para o processo de
desenvolvimento e características que colaboraram nesse processo.
3.1 UML (UNIFIED MODELING LANGUAGE)
Conforme Bezerra (2002, p. 14), UML (linguagem de modelagem unificada): “é uma linguagem visual para modelar sistemas orientados a objetos. Isso quer dizer
que a UML é uma linguagem constituída de elementos gráficos (visuais) utilizados na modelagem que permitem representar os conceitos do paradigma da orientação a
objetos”.
Bezerra ainda conclui afirmando que “A UML é independente tanto de linguagens de programação quanto de processos de desenvolvimento”.
UML é uma linguagem muito recente, no início da utilização de computadores, nas décadas de 1950 e 1960, os programas eram feitos sem a utilização de modelagem, apenas com utilização de fluxogramas. Na década de 1970, os computadores começaram a evoluir e houve uma expansão no mercado de software, gerando sistemas mais complexos e com isso surgiu a programação estruturada e o projeto estruturado. Na década de 1980, os computadores ficaram mais acessíveis e os sistemas tiveram que evoluir com interfaces mais sofisticadas surgindo a análise estruturada. No início da década de 1990, surge o paradigma de orientação a objetos e com ele a análise de sistemas orientada a objetos. Com a grande evolução destes sistemas no fim da década de 1990 surgem várias ferramentas que auxiliam no desenvolvimento deles e então é criado a UML por Grady Booch, James Rumbaugh e Ivar Jacobson com o objetivo de padronizar a modelagem de sistemas, a qual em 1997 é aprovada como um padrão.
3.2 DIAGRAMAS DE UML
A UML utiliza vários tipos de diagramas, nesta seção, são descritos de forma resumida os que foram utilizados na modelagem do sistema .
3.2.1 Modelo de domínio e diagrama de classes
Para Maia (2008), “Basicamente, o modelo de domínio consiste em descobrir objetos de um problema do mundo real”. A figura 7 apresenta o modelo de domínio do sistema MedGraph.
Figura 7 - Modelo de Domínio. Fonte: Autores.
O Modelo de Domínio ajuda desde as primeiras etapas da análise e com ele deve-se descobrir a maior quantidade de clasdeve-ses possíveis num primeiro momento, analisando o problema real. O modelo de domínio não retrata o cenário completo e à medida que o processo de desenvolvimento avança algumas classes são adicionadas e outras excluídas, portanto, ele auxilia durante todo o processo de criação do software.
Segundo Bezerra (2002, p. 96), “O modelo de classes de domínio representa as classes do domínio do negócio em questão. Este modelo é construído na fase de análise.”.
O Diagrama de Classes de Domínio que se observa na figura 8 é o modelo de Domínio da figura 7, que foi atualizado ao longo das diferentes etapas de análise do projeto e representa as funcionalidades do sistema sem a interação com o usuário e de forma estática.
Figura 8 – Diagrama de Classe de Domínio Fonte: Autores.
3.2.2 Requisitos funcionais
Conforme Bezerra (2002, p. 20) “um requisito é uma condição ou capacidade que deve ser alcançada ou possuída por um sistema ou componente deste para satisfazer um contrato, padrão, especificação ou outros documentos formalmente impostos”.
Os requisitos funcionais são na grande maioria definidos em conjunto com o usuário final e associados com as regras do negócio em si, no exemplo da figura a seguir, o requisito funcional “RF04 - Consulta registros”, esta diretamente relacionado a uma regra de negócio chamada “RN07 – Resultados da pesquisa”, que indica como devem ser apresentados os dados para o usuário na tela do sistema.
Figura 9 – Exemplo de Requisito Funcional. Fonte: Autores.
Para este projeto os requisitos funcionais foram definidos na etapa inicial visando identificar quais eram as necessidades da equipe clínica do HIJG, por meio de entrevistas com os médicos e da análise do protocolo de pesquisa já descrito no capítulo 2, os autores
identificaram e definiram os requisitos funcionais do sistema, destes se destacam os principais, descritos no quadro 1.
Requisitos funcionais Descrição
RF01 – Cadastro de registros Descrição: O sistema deverá prover funcionalidades que
permitam ao usuário fazer a inclusão de novos Registros no sistema, bem como atualizar e completar os dados e também excluir um registro se necessário.
RF02 - Consulta de registros Descrição: O sistema deve prover consultas sobre os dados dos registros, possibilitando os seguintes filtros: Tipo de acidente; Cidade; Local; Número de Registro.
RF03 – Dados de tipo de acidente
Descrição: O sistema deve prover funcionalidades que permitam ao usuário diferentes visualizações dos dados a serem cadastrados dependendo do “Tipo de acidente”.
RF04 – Geração de gráficos Descrição: O sistema deve gerar gráficos de forma
automática baseados na escolha de parâmetros feita pelo usuário e nos tipos de gráficos disponíveis predefinidos pela equipe médica.
Quadro 1 – Requisitos funcionais do sistema. Fonte: Autores.
3.2.3 Casos de uso
Para Bezerra (2002, p. 46) “um caso de uso é a especificação de uma seqüência de interações entre sistemas e os agentes externos que utilizam esses sistemas”.
Numa segunda etapa do processo de modelagem do projeto os autores iniciaram a identificação de casos de uso, desta análise podemos destacar um caso de uso principal denominado “Registro Geral – dados do paciente” o qual estende para dois registros auxiliares: Cidades e Locais de atendimento, criados para “Normalizar” o banco de dados e evitar inconsistências. Além disso, foi identificado um caso de uso para cada tipo de acidente existente, devido a que cada um deles tem campos e regras específicas as quais deviam ser
detalhadas. A figura 10 detalha a interação de caso de uso usado como exemplo com outros casos de uso do sistema e com o ator (médico pesquisador).
Figura 10 – Exemplo de Caso de Uso. Fonte: Autores.
3.2.4 Diagrama de pacotes
Segundo Bezerra (2002, p. 69) “Os pacotes podem ser utilizados para agrupar elementos do modelo de casos de uso”.
Na figura 11 se detalha como o diagrama de pacotes foi implementado para este projeto para auxiliar no planejamento e organização do sistema, os autores realizaram a implementação em 3 módulos:
- Módulo 1 - Cidades e Locais de atendimento: Neste primeiro módulo foram implementados os cadastros de cidades e locais de atendimento, que por serem cadastros
simples e com pouca informação (campos), permitiram aos autores se focar em como um cadastro deve ser feito, com isso foi criado um padrão de inclusão, deleção, atualização e consulta para poder ser usado no resto do sistema.
- Módulo 2 – Registros gerais: Na segunda etapa do projeto foi desenvolvido o cadastro dos registros gerais, baseados nos cadastros do módulo 1, este cadastro requeria muito mais tempo e dedicação por envolver a maioria das regras de negócio do projeto. É importante ressaltar que uma vez concluído este módulo o sistema informatizado foi entregue aos médicos para iniciar o cadastramento dos dados, e esse planejamento teve como objetivo gerar uma massa de dados reais cadastrada na hora de iniciar os testes e geração de gráficos implementada na etapa seguinte.
- Módulo 3 – Gráficos e Estatísticas: A última etapa do projeto foi para implementar os gráficos do sistema. Esta etapa requeria de mais estudo do que as anteriores porque os autores não tinham nenhum tipo de conhecimento sobre o tema, para isso no planejamento do tempo total do projeto foram dedicados 50% para este módulo.
Figura 11 – Diagrama de Pacotes. Fonte: Autores.
3.2.5 Ator
Bezerra (2002, p. 51) diz que “qualquer elemento externo que interage com o sistema é determinado ator”. Bezerra conclui explicando que o termo “interage” significa que o ator é quem envia ou recebe informações do sistema.
Figura 12 – Exemplo de Ator. Fonte: Autores.
No exemplo da figura 12 está representado como o Ator, chamado de Pesquisador (médico), interage diretamente com os cadastros de Cidades e Locais de atendimento.
Para este projeto a figura do ator foi única devido a que todos os usuários que utilizam o sistema têm os mesmos privilégios e acessam a todas as áreas.
3.2.6 Diagrama de seqüência
Para Maia (p. 12), “O Diagrama de Seqüência tem como objetivo construir um modelo dinâmico entre o usuário e o sistema”. Maia também afirma que “um diagrama de seqüência captura o comportamento de um único caso de uso, ou seja, mostra a interação entre os objetos ao longo do tempo, apresentando os objetos que participam da interação e a seqüência das mensagens trocadas”.
Mediante os diagramas de seqüência é possível ver quais os objetos que estão presentes em cada caso de uso, como interagem entre eles e a partir disso poder partir para o desenvolvimento do software como se detalha na figura 13.
Figura 13 – Diagrama de Seqüência. Fonte: Autores.
Estes diagramas foram os mais utilizados para o projeto, eles auxiliaram em muito o desenvolvimento porque permitem de forma objetiva representar como os casos de uso devem-se comportar, quais telas e tabelas do banco de dados são acessadas, regras de negócio que estão presentes, dentre outros.
3.2.7 Diagrama de interfaces
Para Maia (p. 4), é a partir deste diagrama que se constroem os casos de uso, ele afirma que “O objetivo da interface não é codificação do sistema e pode ser feito usando qualquer ferramenta ou tecnologia mesmo que esteja longe da realidade do sistema proposto pelo cliente”.
A visualização de interfaces permite ao usuário final imaginar como o sistema irá funcionar uma vez concluído, é por essa razão que metodologias como o Iconix, por exemplo, indicam começar com a construção destas interfaces para, a partir delas, construir os casos de uso.
Na figura 14 podemos ver um exemplo de uma interface que foi construída no início do projeto para apresentar aos médicos. Posteriormente estas tiveram que ser alteradas quando comparadas com as versões iniciais, porém, o fato de ter os diagramas de interfaces iniciais ajudou em muito a desenvolver o sistema e entender como ele deveria se comportar.
Figura 14 – Exemplo de Interfase. Fonte: Autores.
3.2.8 Diagrama de robustez
Maia (p. 8) afirma que “A Análise Robusta focaliza construir um modelo analisando as narrativas de texto de caso de uso, identificando um conjunto de objetos que participarão de cada caso de uso”.
O Diagrama de Robustez do exemplo abaixo mostra como este tipo de diagrama auxilia a detalhar os objetos que fazem parte do caso de uso dos registros gerais (figura 15).
Figura 15 – Exemplo de Diagrama de Robustez. Fonte: Autores.
3.3 ICONIX
Para o desenvolvimento do sistema escolheu-se a metodologia Iconix, por se tratar de uma metodologia prática e ao mesmo tempo poderosa, como Maia (p. 2) define “ICONIX é considerado uma metodologia pura, prática e simples, mas também poderosa e com um componente de análise e representação dos problemas sólido e eficaz”.
A metodologia ICONIX é descrita como um Processo de Desenvolvimento de Software criado pela ICONIX Software Engineering, e se caracteriza por se desenvolver
através de um protótipo de interfaces, onde são desenvolvidos os diagramas de caso de uso. Após, são desenvolvidos os diagramas de robustez para cada caso de uso e os diagramas de seqüência. (MAIA, 2007)
Ainda segundo Maia, no Iconix, os sistemas são concebidos a partir da visão do usuário para com o sistema, para isso o uso de um protótipo construído “na presença do cliente” e de acordo com suas necessidades é a base para o desenvolvimento posterior.
Para este projeto em particular esta metodologia foi uma ótima escolha, já que ela não exige muita documentação o qual não era necessário neste caso. Além disso, a metodologia colaborou muito, principalmente no começo do projeto, porque os autores não conheciam as regras de negócio e como o sistema deveria se comportar. Graças ao mecanismo de criação de interfaces iniciais foi possível assimilar e entender os requisitos.
4 IMPLEMENTAÇÃO E VALIDAÇÃO
Neste capítulo são enumeradas:
- As ferramentas computacionais utilizadas para a implementação da solução; - A linguagem de programação e as tecnologias associadas;
- Detalhado o processo que foi seguido para o desenvolvimento do software o qual foi batizado de “MedGraph”.
4.1 FERRAMENTAS UTILIZADAS
A figura 16 ilustra os aplicativos utilizados e como eles se interligam.
Figura 16 – Ferramentas utilizadas. Fonte: Autores.
Para iniciar o projeto seguindo o procedimento metodológico Iconix foi necessário a escolha de uma ferramenta para desenhar as “telas” do protótipo inicial que seria apresentado para o cliente, o qual, uma vez aprovado seria utilizado como base para o resto do desenvolvimento do projeto. A ferramenta escolhida foi o Dreamweaver, software que permite desenhar, desenvolver e manter web sites. Esta ferramenta resultou ser muito intuitiva, de fácil aprendizado, e ajudou na fase inicial do projeto para criar as telas e realizar as consistências de campos (máscaras e validação) a partir da biblioteca “Adobe Spry” de Javascript e CSS (versão CS3). É uma biblioteca livre que pode ser utilizada mesmo sem o software.
Uma vez criado o protótipo inicial, foi utilizada a ferramenta Enterprise Architect (EA) para modelar o sistema, este software permite projetar, documentar, construir e gerenciar projetos de software. O EA foi de fácil aprendizado e possibilitou o trabalho em equipe, já que permite dividir o projeto em pacotes (packages).
Para criação do sistema de gerenciamento de banco de dados (SGBD) foi escolhido o PostgreSQL, ele permite consultas complexas, integridade transacional, suporte ao modelo híbrido objeto-relacional dentre outras características. A principal destas características e motivo da escolha foi por se tratar de um sistema de software livre (com código aberto), e por trabalhar com SQL padrão ANSI, sendo possível migrar de banco de dados no futuro.
O acesso ao banco de dados para criação e manipulação das tabelas relacionais foi feito mediante utilização da ferramenta PgAdmin, que é desenvolvida especificamente para trabalhar com PostgreSQL e também de código aberto.
Para o desenvolvimento da aplicação foi utilizado Eclipse, ferramenta de desenvolvimento de aplicações multiplataforma e multilinguagem, que permitiu desenvolver o software. Esta IDE (ambiente integrado de desenvolvimento de software), permitiu integrar o código com as demais ferramentas mediante a utilização de “plugins” que estão disponíveis na internet de forma gratuita, como por exemplo, o “plugin” para acesso ao banco de dados do PostgreSQL.
No servidor web foi instalada a aplicação acessível de qualquer computador ligado a Internet por meio de algum navegador web. Neste servidor foi instalado o Apache Tomcat que é um servidor de aplicação Java para web, mais especificamente um container de servelts. O Tomcat é eficiente e distribuído como software livre.
Muitas das ferramentas que foram utilizadas neste projeto já eram conhecidas, porém, através do trabalho de conclusão de curso foi possível adquirir mais experiência. Este aprendizado se deu a medida que várias das ferramentas foram sendo estudadas e usadas de acordo com as necessidades que surgiam com o andamento do projeto. A escolha de desenvolver um projeto que criasse uma ferramenta ao invés de usar um software já existente e validado pelo mercado foi o que levou a tanto aprimoramento cognitivo.
4.2 LINGUAGEM DE PROGRAMAÇÃO
A linguagem de programação utilizada foi Java, linguagem orientada a objetos, desenvolvida em princípio pela SUN Microsystems e que atualmente esta quase com todo seu código aberto e controlada pela comunidade internacional. Essa linguagem é a ferramenta com a qual os autores aprenderam todos os conceitos de programação durante o curso de Sistemas de Informação, foi por esse motivo e com a intenção de aperfeiçoar-se na sua utilização que escolheram Java para o desenvolvimento deste projeto.
A tecnologia para desenvolver o conteúdo para web foi JSP (Java Server Pages), que é baseada em Java e com isso tem a vantagem de portabilidade de plataformas, permitindo sua execução nos principais sistemas operacionais da atualidade. O JSP permitiu: a criação de páginas de Internet, elaborar aplicações para acessar ao banco de dados e capturar as informações que os usuários enviam para o servidor por meio de formulários.
A aplicação foi baseada em Servlet’s que são uma tecnologia que insere recursos no servidor web e permite ao programador Java utilizá-los como uma camada de interface entre a aplicação e o servidor. Estes servlet’s permitem a interação da aplicação com os usuários utilizando o modelo request/response (solicitação/resposta). Uma vez inseridos no servidor os servlet’s geram o conteúdo dinâmico HTML das páginas de Internet que são acessadas pelos usuários. O Servlet precisa de um container web para ser executado, o container escolhido foi o Apache Tomcat descrito na seção anterior.
A aplicação foi desenvolvida para ser acessada através de qualquer browser web pelos usuários, com isso não é necessário nenhum tipo de instalação de software nos computadores do qual se acessa o sistema. Isso representa uma grande vantagem na hora da manutenção ou atualização do sistema, já que a mesma será feita somente no servidor web.
Todas as ferramentas para o funcionamento do sistema são de código aberto e não possuem custo de utilização.
4.3 FERRAMENTAS DE GRÁFICOS
Como foi mencionado anteriormente, para a realização deste projeto os autores precisaram fazer um estudo de estatística e gráficos para decidir qual era a melhor forma de apresentar os resultados dos cruzamentos de dados para os usuários do sistema. Após definir que os gráficos de setores e os de barras (quando mais variáveis estavam envolvidas), eram os dois tipos de gráficos que melhor apresentavam os resultados, foi preciso encontrar uma ferramenta capaz de criar este tipo de gráfico. Além disso, deveria ser relativamente fácil de aprender pelo tempo que se dispunha.
A ferramenta escolhida foi o Cewolf, que se trata de um framework (biblioteca de classes) de código aberto que auxilia na construção de gráficos para utilizar em páginas JSP. O Cewolf é baseado em outra biblioteca Java, o JFreeChart, que é outro framework específico para construção de gráficos, porém é um pouco mais complexa a sua utilização. O Cewolf facilita seu uso por meio de “tags” de JSP nas páginas, o usuário não precisa escrever código em Java, o que facilita o entendimento e agiliza a construção de vários gráficos. Mediante estas tags, para construir um gráfico o único necessário era escolher o tipo de gráfico desejado e enviar os dados para o Cewolf que mediante a utilização de suas bibliotecas monta o gráfico consultando diretamente o banco de dados. Assim, o médico terá condição de gerar gráficos atualizados, conectados com a base de dados, mantendo-os atualizados.
4.4 APRESENTAÇÃO DO SISTEMA
Após o usuário digitar seu login e senha de acesso ao sistema ele tem acesso a tela principal a qual inclui ícones para consultas e um menu para adicionar novos cadastros (figura 17).
Figura 17 – Tela inicial do sistema. Fonte: Autores.
O processo de cadastro de novos pacientes (feito com base no protocolo de pesquisa do hospital) foi dividido em duas etapas:
- Numa primeira tela (ver figura 18) são digitados os dados comuns a todos os tipos de trauma, inclusive ambas escalas de trauma pediátrica e trauma revisada. Por último o usuário deve preencher o tipo de trauma e clicar no botão “avançar”.
- A partir da escolha feita o sistema irá montar dinamicamente a segunda tela do cadastro (ver figura 19) com os campos específicos pertencentes ao tipo de trauma escolhido.
Para facilitar a navegação durante o processo de cadastro existem links diretos para cadastros de novas cidades e/ou locais de atendimentos.
Figura 18 – Tela de cadastro de paciente inicial. Fonte: Autores.
Figura 19 – Tela de cadastro de paciente para trauma de evenenamento. Fonte: Autores.
Entre ambas as telas é realizado um processo de validação dos campos obrigatórios e de existência do número de registro digitado, em caso de erro uma mensagem explicativa é apresentada (ver figura 20).
Figura 20 – Exemplo de mensagem explicativa de erro. Fonte: Autores.
Uma vez que o cadastro é finalizado corretamente apresenta-se uma tela ao usuário informando o número do registro cadastrado e os totais das Escalas calculados automaticamente pelo programa, melhoria esta solicitada pela equipe médica durante o processo de validação do sistema (ver figura 21).
Figura 21 – Tela de cadastro de paciente finalizada com sucesso Fonte: Autores.
Para consultar os dados cadastrados o usuário pode escolher entre: mostrar todos, filtrar pelo número de registro, ou filtrar pelo tipo de trauma como mostra a figura 22.
Figura 22 – Exemplo de consulta por tipo de trauma Fonte: Autores.
Nas figuras 23 e 24 são apresentados dois exemplos de tipos de gráficos que o usuário pode gerar com o sistema.
Figura 23 – Gráfico de pizza gerado pelo sistema Fonte: Autores.
Figura 24 – Gráfico de barras gerado pelo sistema Fonte: Autores.
4.5 VALIDAÇÃO DO SISTEMA
O processo de validação do sistema teve por finalidade verificar com a equipe médica se os objetivos iniciais foram alcançados e se o software permite aos médicos realizar os estudos e pesquisas propostos. O diagrama a seguir detalha o processo.
Figura 25 – Diagrama do processo de validação do sistema. Fonte: Autores.