AUTOMATIZAÇÃO DO PROCESSO DE MAPEAMENTO DE LAUDOS MÉDICOS PARA UMA REPRESENTAÇÃO ESTRUTURADA

Transcrição

1 UNIVERSIDADE ESTADUAL DO OESTE DO PARANÁ CAMPUS DE FOZ DO IGUAÇU PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA DE SISTEMAS DINÂMICOS E ENERGÉTICOS DISSERTAÇÃO DE MESTRADO AUTOMATIZAÇÃO DO PROCESSO DE MAPEAMENTO DE LAUDOS MÉDICOS PARA UMA REPRESENTAÇÃO ESTRUTURADA JEFFERSON TALES OLIVA FOZ DO IGUAÇU 2014

2

3 Jefferson Tales Oliva Automatização do Processo de Mapeamento de Laudos Médicos para uma Representação Estruturada Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Engenharia de Sistemas Dinâmicos e Energéticos como parte dos requisitos para obtenção do título de Mestre em Engenharia de Sistemas Dinâmicos e Energéticos. Área de concentração: Sistemas Dinâmicos e Energéticos. Orientador: Huei Diana Lee Co-orientador: Wu Feng Chung Co-orientador: Cláudio Saddy Rodrigues Coy Foz do Iguaçu 2014

4 FICHA CATALOGRÁFICA O48 Oliva, Jefferson Tales Automatização do processo de mapeamento de laudos médicos para uma representação estruturada / Jefferson Tales Oliva. - Foz do Iguaçu, p.: tab.: graf. Orientadora: Prof a. Dra. Huei Diana Lee. Co-orientador: Prof. Dr. Wu Feng Chung. Co-orientador: Prof. Cláudio Saddy Rodrigues Coy. Dissertação (Mestrado) - Programa de Pós-Graduação em Engenharia de Sistemas Dinâmicos e Energéticos - Universidade Estadual do Oeste do Paraná. 1. Engenharia de software. 2. Bioinformática. 3. Laudo médico. 4. Ontologia. 5. Endoscopia digestiva. 6. Sistema Computacional Colaborativo. I. Título. CDU :61 Miriam Fenner R. Lucas - CRB/9:268 - Unioeste - Campus de Foz do Iguaçu ii

5

6 iv

7 Resumo Na área da saúde, grandes quantidades de dados provenientes de diversas fontes, como exames clínicos e de procedimentos, são armazenadas em bases de dados de hospitais e clínicas médicas. As características observadas nesses exames são descritas em laudos médicos textuais. Esses laudos constituem ferramenta indispensável para profissionais de qualquer especialidade médica para a manutenção do histórico clínico de pacientes. Os dados contidos nesses laudos podem ser analisados, de modo mais completo, através de recursos computacionais, como o processo de Mineração de Dados apoiado por técnicas de Inteligência Computacional. No entanto, para a aplicação desse processo, é imprescindível que os dados estejam representados em formato estruturado, como as Bases de Dados Computacionais. Nesse sentido, no Laboratório de Bioinformática da Universidade Estadual do Paraná em parceria com o Serviço de Coloproctologia da Faculdade de Ciências Médicas da Universidade Estadual de Campinas foi desenvolvido o Processo de Mapeamento de Laudos Médicos (PMLM) por ontologias com o propósito de prover apoio para a transformação de laudos médicos textuais não estruturados em uma representação estruturada. Entretanto, as técnicas empregadas no PMLM devem ser executadas separadamente e manualmente por meio de instruções computacionais, dificultando o seu uso por profissionais que não sejam da área computacional. Assim, o objetivo deste trabalho consiste em automatizar e otimizar o PMLM por ontologias mediante a integração de suas técnicas de processamento de textos em uma ferramenta computacional. Para isso, foi construído um Sistema Computacional Colaborativo (SCC) utilizando o modelo de desenvolvimento por prototipagem, que é aplicado de cinco etapas: comunicação; plano rápido; modelagem; construção do protótipo; e avaliação e feedback. Esse sistema computacional foi avaliado em conjunto com especialistas do domínio, os quais constataram que o SCC atende às especificações determinadas e apresenta-se de grande valia para a extração e o estudo de padrões que podem ser encontrados em textos médicos. O SCC foi também submetido a uma avaliação experimental, por meio da aplicação do PMLM automatizado em um conjunto de 100 laudos médicos textuais artificiais que simulam descrições de exames de Endoscopia Digestiva Alta (EDA), apresentando bons resultados. Desse modo, com o PMLM por ontologias automatizado, implementado no SCC, é possível a realização de estudos mais completos e detalhados, contribuindo com a geração de novos conhecimentos. Palavras-chave: Laudo Médico, Ontologia, Engenharia de Software, Endoscopia Digestiva Alta, Sistema Computacional Colaborativo. v

8 Abstract In the health area, large amounts of data from different sources, such as clinical examinations and procedures, are stored in hospitals and medical clinics databases. Characteristics observed in these examinations and procedures are described in textual medical reports. These findings are indispensable for professionals of any medical specialty, as they are used to maintain the clinical history of the patients. The data contained in these reports can be analyzed, in a more complete manner, through the use of computational resources, such as the Data Mining process supported by computational intelligence techniques. However, for the application of such process, it is essential that the data is represented in a structured format, as Computational Data Bases. In this sense, the Laboratory of Bioinformatics from the West Paraná State University in partnership with the Coloproctology Service of the Faculty of Medical Sciences from the State University of Campinas, developed the Mapping Medical Digital Findings Process (PMLM) using ontologies with the aim of providing support for the transformation of unstructured textual medical reports into a structured representation. Nevertheless, the techniques employed in PMLM must be performed manually and separately by means of computer instructions, hampering its use by professionals who are not from the computational area. The objective of this work is to automate and optimize PMLM using ontologies by integrating its preprocessing methods in a computational tool. For this purpose, a Collaborative Computer System (SCC) was built using the prototyping development model, which is applied in five stages: communication, fast plan, modeling, prototype construction, and evaluation and feedback. The developed computational system was evaluated in conjunction with domain experts, confirming that SCC meets the required specifications and presents a great value for the extraction and the study of patterns that may be discovered in medical findings. SCC was also evaluated experimentally, using a set of 100 artificial medical reports that simulate the Upper Digestive Endoscopy (EDA), showing good results. Thus, the automated PMLM using ontologies, implemented in the SCC, enables the performance of more complete and detailed studies, contributing to the generation of new knowledge. Keywords: Medical Findings, Ontology, Software Engineering, Upper Digestive Endoscopy, Collaborative Computational System. vi

9 vii Aos meus pais, Carmem e Ilia. Aos meus orientadores, Huei e Wu. À minha noiva e futura esposa, Danieli. Ao meu irmão (in memoriam), Ivo.

10 viii

11 Agradecimentos Ao longo dessa árdua caminhada, várias pessoas, de alguma forma, fizeram parte desse trajeto e proporcionaram momentos de alegria, bem como ajudaram a superar os momentos difíceis e contribuíam com a minha formação pessoal e profissional. Nesse sentido, é difícil eu expressar por meio de palavras a minha gratidão a essas pessoas que ajudaram diretamente e indiretamente. Desse modo, a seguir são descritos meus sinceros agradecimentos e reconhecimento pelas contribuições recebidas nesta minha fase de vida e acadêmica. À toda minha família, pelo incentivo na minha trajetória para a minha formação. Aos meus amados pais, Carmem e Ilia, pelo amor, dedicação e educação incondicionais. Pelo apoio e incentivo para lutar pela realização de todos os meus sonhos pessoais e profissionais. Por sempre acreditarem na minha capacidade em superar todos os obstáculos na vida. Ao meu irmão Ivo (in memoriam), pelo carinho, incentivo e sempre estar preocupado com o meu bem estar. Também, por termos compartilhados vários bons momentos juntos. Apesar de não estar entre nós, sempre carregarei comigo as nossas boas lembranças como motivação e amenização da saudade e da dor de sua perda. Às minhas avós, Benedita e Vitalina pelos "mimos", carinho e apoio para a realização dos meus objetivos de vida. À minha amada noiva e futura esposa, Danieli, pela compreensão dos vários momentos que não podemos passar juntos nessa trajetória acadêmica, bem como pelo apoio, incentivo e amor incondicional. Também gostaria de agradecê-la não apenas por compartilharmos os momentos felizes, mas também por ter me apoiado nos momentos mais difíceis. À minha futura nova família, Armelinda, Pedro e Tatiana pelo apoio e compreensão dos momentos em que estive ausente. Aos meus mestres e orientadores, os professores Huei e Wu, pelos valiosos ensinamentos tanto na parte técnica quanto na parte pessoal, os quais levarei pelo resto da minha vida. Por incontáveis vezes em que assumiram o papel dos pais para nos educarem. Por abdicar de muitas noites de descanso para trabalharem com a finalidade de criar oportunidades para os alunos do LABI. Pela nossa amizade e paciência em nos orientar em momentos de turbulência. Aos professores e amigos, André, Andrés, Joylan, Renato e Richardson, pela amizade e ix

12 x ensinamentos compartilhados. Aos meus amigos do LABI, Altamira, Antônio, Bianca, Caio, Chris, Dabna, Everton, Felipe, Fonteque, Jediel, Jorge, Leandro, Paulo, Maurício, Neimar, Newton, Rafaela, Ricardo, Vanize, Willian e Wilson, pela amizade, respeito, apoio e sugestões nas minhas decisões. Ao meu amigo Narco, pela amizade e os bons momentos compartilhados nesses quase três anos vivenciados na mesma casa. Pela nossa invenção do prato Macalango ("Miojo" com farinha e molho de pimenta habanero). Aos meus amigos da Pós-graduação, Katiani, Marcos Ricardo, Mariana, Rodrigo, Willian, Jhonny (Dionísio do Sertão), pela amizade e os momentos inesquecíveis que vivenciamos nessa trajetória. Aos meus amigos de infância, Alex, André, Eduardo (Dudu), Guilherme (Totão), Gustavo (Legal), Helton Alegra (Heltroo), Helton (Tibira), Luiz Fernando (Nando), Renam, Tiago, Vitor Angeli e Vitor Hugo, por essa amizade duradoura e compreensão dos momentos de minha ausência. Aos demais amigos, pela amizade e contribuição de forma direta e indireta na minha formação. Aos profissionais da área médica do Serviço de Coloproctologia da Faculdade de Ciências Médicas da UNICAMP que confeccionaram laudos textuais artificiais de exames de endoscopia digestiva alta. À Fabiana, secretária do PGESDE, que não mediu esforços para nos apoiar e ajudar em diversas situações que envolvam a pós-graduação. Aos professores do PGESDE e aos funcionários da UNIOESTE. À UNIOESTE, pelo apoio financeiro em despesas com viagens para a apresentação de trabalhos científicos em congressos. À CAPES (Coordenação de Aperfeiçoamento de Pessoal de Nível Superior), pelo apoio por intermédio da concessão de bolsas de pós-graduação. Todas as demais pessoas que, de alguma forma, contribuíram com desenvolvimento deste trabalho.

13 O mundo é perigoso não por causa daqueles que fazem o mal, mas por causa daqueles que vêem e deixam o mal ser feito. Albert Einstein xi

14 xii

15 Sumário Lista de Figuras xvi Lista de Tabelas xix Lista de Símbolos xxi 1 Introdução Objetivos Premissas Hipótese Organização do Trabalho Fundamentos de Ontologia Considerações Iniciais Definição de Ontologia Aplicações da Ontologia Tipos de Ontologias Construção de Ontologias Linguagens de Representação de Ontologias Knowledge Interchange Format Ontolingua Resource Description Framework Ontology Inference Layer DAML + OIL xiii

16 xiv Ontology Web Language Ferramentas para Representação de Ontologias Chimaera OilED Protégé Servidor Ontolingua Considerações Finais Processo de Mapeamento de Laudos Médicos utilizando Ontologias Considerações Iniciais Mapeamento de Laudos Médicos Primeira Fase do PMLM Construção do Conjunto de Frases Únicas Normalização do Conjunto de Frases Únicas Construção do Arquivo de Padronização Remoção de Stopwords Aplicação de Stemming Aplicação de Lematização Definição dos Atributos da Tabela Atributo-Valor e da Ontologia Segunda Fase Considerações Finais Desenvolvimento de Sistemas Computacionais Considerações Iniciais Processo de Software Levantamento de Requisitos Projeto de Software Implementação

17 4.6 Testes de Software Considerações Finais xv 5 Ferramentas e Tecnologias Considerações Iniciais Linguagem de Programação Java Linguagem de Programação Ruby Framework Ruby on Rails Ambiente de Desenvolvimento NetBeans Linguagem de Programação Perl Linguagem de Marcação HTML Linguagem de Marcação XML Linguagem CSS Linguagem de Programação Javascript Considerações Finais Processo de Desenvolvimento do Sistema Computacional Colaborativo Considerações Iniciais Etapa de Comunicação Etapa de Plano Rápido Etapa de Modelagem Etapa de Construção Apresentação do Sistema Computacional Colaborativo Desenvolvido Etapa de Avaliação e Feedback Considerações Finais Estudo de Caso Considerações Iniciais Avaliação Experimental do SCC

18 xvi 7.3 Construção do Arquivo de Padronização Elaboração da Stoplist Definição de Atributos da Base de Dados e de Regras de Mapeamento Ontologia Construída no Estudo de Caso Aplicação do Método Mapeamento por Ontologias em Laudos Médicos Artificiais Considerações Finais Resultados e Discussão Considerações Iniciais Aplicação do PMLM em Trabalhos Anteriores Construção do Sistema Computacional Colaborativo Avaliação Experimental em Laudos Médicos Artificiais Considerações Finais Conclusão Principais Desfechos deste Trabalho Limitações Principais Contribuições Trabalhos Futuros Referências Bibliográficas 132 A Arquivos Definidos para a Avaliação Experimental do Estudo de Caso 141 A.1 Stoplist A.2 Arquivo de Padronização

19 Lista de Figuras 2.1 Exemplo de definição de classes KIF Exemplo de definição de classes Ontolingua Exemplo de definição de classes RDFS Exemplo de definição de classes OIL Exemplo de representação de um conjunto de dados DAML+OIL Exemplo de representação de definição de classes OWL Exemplo de uso de propriedade da linguagem OWL Exemplo de transcrição manual de um laudo textual artificial Estrutura do Dicionário de Conhecimento Primeira fase do PMLM baseado em ontologia Processo de identificação de frases únicas Normalização de um exemplo de CFU Exemplo de estrutura do Arquivo de Padronização Exemplo de stoplist Exemplo de aplicação de stemming Exemplo de conjunto de regras para lematização de verbos Exemplo de esquema de ontologia para mapeamento de laudos médicos Segunda fase do PMLM baseado em ontologia Modelo de desenvolvimento por prototipagem Processo de gerenciamento de projetos Etapas do teste de software xvii

20 xviii 5.1 Padrão MVC Exemplo de documento HTML e página web equivalente Exemplo de estrutura de documento XML Diagrama de casos de uso do SCC Modelo de arquitetura do SCC Exemplos de AP antigos Exemplo de nova estrutura otimizada de AP Tela de acesso ao sistema Exemplo de estrutura do arquivo de parâmetros do SCC Funcionalidade "Gerenciamento do Conjunto de Laudos Médicos" da primeira fase Telas de gerenciamento de carregamento de laudos textuais Funcionalidade "Construção e Gerenciamento do Conjunto de Frases Únicas" da primeira fase Funcionalidade "Definição e Gerenciamento da Lista de Stopwords" da primeira fase Funcionalidade "Construção e Gerenciamento do Arquivo de Padronização" da primeira fase Tela para definição de uma nova RP Funcionalidade "Definição e Gerenciamento do Conjunto de Atributos" da primeira fase Tela para definição de nova RM Funcionalidade "Aplicação de Pré-Processamento" da segunda fase Funcionalidade "Realização de Mapeamento" da segunda fase Exemplo de laudo textual de exame EDA da região do esôfago Fragmento do AP desenvolvido no Estudo de Caso Exemplo de transcrição de stopwords Hierarquia de classes da ontologia do SCC

21 xix 7.5 Esquema detalhado de ontologia com um exemplo de instância para cada classe Exemplo de atributo representado na linguagem OWL Exemplo de esquema de ontologia criada automaticamente pelo SCC Avaliação dos CFU gerados por quantidade de frases Avaliação dos CFU gerados por quantidade de palavras Avaliação do desempenho em relação ao tempo para o mapeamento manual e automático

22 xx

23 Lista de Tabelas 5.1 Tabela de exemplos de metacaracteres utilizados em ER Resultados da avaliação dos CFU gerados Quantidade de termos não-processados Complexidade dos métodos empregados no PMLM xxi

24 xxii

25 Lista de Siglas AP BD CFU CSS DAML DARPA DC DOM DRY ECMA EDA ER FCM FO HTML IC IDE INPI JDK JRE JSON KIF KISS LABI MD MeSH MJV MVC NLM OIL OWL PERL Arquivo de Padronização Base de Dados Conjuntos de Frases Únicas Cascading Style Sheets DARPA Agent Markup Language US Defense Advanced Research Projects Agency Dicionário do Conhecimento Document Object Model Don t Repeat Yourself European Computer Manufacturers Association Endoscopia Digestiva Alta Expressões Regulares Faculdade de Ciências Médicas Frame Ontology HyperText Markup Language Inteligência Computacional Integrated Development Environment Instituto Nacional de Propriedade Industrial Java Development Kit Java Runtime Environment Javascript Object Notation Knowledge Interchange Forma Keep It Simple, Stupid Laboratório de Bioinformática Mineração de Dados Medical Subject Headings Máquina Virtual Java Model-View-Controller National Lybrary of Medicine Ontology Inference Layer Ontology Web Language Practical Extraction and Report Language xxiii

26 xxiv PMLM RDF RDFS RDR RL RM RP RoR SC SCAIMED- Mobile SCC sed SGML SNOMED- CT TMTOWTDI UML UMLS UNICAMP UNIOESTE W3C XML Processo de Mapeamento de Laudos Médicos Resource Description Framework Resource Description Framework Schema Ripple Down Rule Regras de Lematização Regra de Mapeamento Regra de Padronização Ruby on Rails Sistema Computacional Sistema Computacional para Análise de Imagens Médicas Sistema Computacional Colaborativo Stream EDitor Standard Generalized Markup Language Systematized Nomenclature of Medicine Clinical Terms There s More Than One Way To Do It Unified Modeling Language Unified Medical Language System Universidade Estadual de Campinas Universidade Estadual do Oeste do Paraná Wide World Web Consortium extensible Markup Language

27 Capítulo 1 Introdução Com os avanços tecnológicos da área computacional, são armazenadas crescentemente grandes quantidades de dados provenientes de diversas fontes. Na área da saúde, os exames médicos podem ser representados em diversos formatos, como áudio, vídeo, imagens, formulários, entre outros (Wiederhold and Shortliffe, 2006). Uma parte importante das informações contidas nesses exames é descrita por meio de linguagem natural em laudos textuais, com a finalidade de registrar observações à respeito do estado clínico do paciente (Lee, Oliva, Maletzke, Machado, Voltolini, Coy, Fagundes and Wu, 2013). Nesse contexto, os laudos e os exames médicos são armazenados com o objetivo de manter o histórico clínico do paciente e auxiliar nos diagnósticos de futuras enfermidades. Adicionalmente, esses laudos, quando registrados em bases de dados computacionais, podem ser utilizados para a construção de modelos de predição para o auxílio no diagnóstico de enfermidades em pacientes, por meio da descoberta de padrões nesses laudos (Cherman, Spolaôr, Lee, Costa, Fagundes, Coy and Wu, 2008; Lee, Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundes and Chung, 2011). No entanto, o crescente armazenamento de dados médicos, ao mesmo tempo em que se apresenta como um fato positivo, inviabiliza a análise manual dos mesmos, tornando necessário o desenvolvimento de métodos e ferramentas computacionais que auxiliem na análise e no gerenciamento dessas informações (Han, 2005). Para prover suporte a análise e ao gerenciamento de dados em distintas áreas do conhecimento, diversos processos computacionais podem ser usados, dos quais se destaca o de Mineração de Dados (MD), que tem o intuito de explorar conjuntos de dados mediante a identificação de padrões, auxiliando na descoberta de conhecimento. Esses padrões podem ser identificados por meio de métodos de Inteligência Computacional (IC) para a criação de modelos descritivos e preditivos a partir do conhecimento presente nos dados analisados (Witten and Frank, 2005). Para a aplicação da MD, é necessário que os dados sejam representados em formato estruturado, 1

28 2 como a tabela atributo-valor 1, na qual cada linha dessa tabela é um elemento do conjunto de dados analisados e cada coluna é uma característica observada (atributo) (Rezende, 2003). Na área médica, os dados registrados em base de dados não estão geralmente representados em formato adequado para a aplicação do processo de MD. Para isso ser possível, é necessário o desenvolvimento de métodos e ferramentas para transformar esses dados para um formato estruturado, como as tabelas atributo-valor (Cherman, Spolaôr, Lee and Wu, 2008; Lee, Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundes and Chung, 2011; Lee, Oliva, Maletzke, Machado, Voltolini, Coy, Fagundes and Wu, 2013). Nesse sentido, no Laboratório de Bioinformática (LABI) da Universidade Estadual do Oeste do Paraná (UNIOESTE / Foz do Iguaçu) em parceria com o Serviço de Coloproctologia da Faculdade de Ciências Médicas (FCM) da Universidade Estadual de Campinas (UNICAMP) e outros parceiros, está sendo desenvolvido o projeto interdisciplinar denominado Análise Inteligente de Dados, que tem como objetivo pesquisar e propor métodos e ferramentas para prover suporte à análise de dados médicos. Esse projeto inclui o desenvolvimento do Processo de Mapeamento de Laudos Médicos (PMLM), que tem o propósito de transformar conjuntos de laudos médicos para uma representação estruturada (Lee, Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundes and Chung, 2011). Em Honorato, Cherman, Lee, Monard and Wu (2007) foi proposta a primeira versão do PMLM, a qual utiliza uma estrutura de dados denominada Dicionário do Conhecimento (DC) para representação de informações de laudos textuais médicos. Nessa abordagem, o DC é utilizado para a transcrição de laudos, por meio de casamento de padrões, para base de dados computacionais. No DC encontram-se Regras de Mapeamento (RM), as quais representam possíveis combinações de termos para as frases de cada laudo e o modo como devem ser mapeadas para a tabela atributo-valor (Cherman, Spolaôr, Lee and Wu, 2008). Esse processo é aplicado em duas fases. Na primeira fase, o conjunto de laudos médicos é submetido à aplicação de técnicas de processamento de textos com o propósito de definir as seguintes estruturas com o auxílio de especialistas da área médica: Arquivo de Padronização (AP), que é aplicado para a uniformização de laudos, com a finalidade de reduzir a complexidade de cada frase presente nos laudos; características que irão compor a tabela atributo-valor, que é utilizada para a representação do conhecimento presente nos laudos; e DC, que é aplicado no mapeamento de laudos médicos para sua representação na tabela atributo-valor. Na segunda fase, primeiramente os laudos selecionados são padronizados por meio do AP. Em seguida, os laudos uniformizados são processados e o conhecimento dos mesmos é mapeado para a tabela atributo-valor por meio de um algoritmo especializado utilizando o DC. Nesse contexto, com a aplicação do PMLM baseado em DC a alguns domínios foi possível 1 Neste trabalho os termos tabela atributo-valor e base de dados serão usadas indistintamente.

29 3 obter resultados considerados satisfatórios (Spolaôr, Lee, Cherman, Honorato, Fagundes, Góes, Coy and Chung, 2007; Cherman, Spolaôr, Lee, Honorato, Coy, Fagundes and Wu, 2008). No entanto, o DC gerado por meio da aplicação desse método apresenta-se como uma estrutura de dados com pouca flexibilidade no contexto de representação de RM, dificultando a tarefa de descrição de regras mais complexas. Assim, caso seja necessária a representação de regras mais complexas e completas, é imprescindível a definição de um novo esquema para o DC, bem como realizar as modificações no método, de modo a adaptar o algoritmo para o processamento desses laudos (Lee, Oliva, Maletzke, Machado, Voltolini, Coy, Fagundes and Wu, 2013). Sendo assim, com a finalidade de aumentar a flexibilidade e a capacidade de representação desse método, foi proposta uma variação do PMLM com o intuito de substituir o DC por uma ontologia, que é uma estrutura que apresenta maior flexibilidade para a representação do conhecimento (Lee, Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundes and Chung, 2011). Nessa abordagem é eliminada parte do problema de definição de novas regras para mapeamento de laudos. Embora o método possa ser utilizado amplamente, inclusive por profissionais que não sejam da área de computação, atualmente todas as técnicas utilizadas no PMLM devem ser executadas separadamente por meio de instruções computacionais, dificultando o seu uso por profissionais de áreas não relacionadas com a computação. Desse modo, para prover suporte ao usuário e tornar o uso do método amigável e intuitivo, é necessário que todas as técnicas que compõem o PMLM estejam integradas em um sistema computacional. Adicionalmente, outras técnicas de processamento de textos podem ser aplicadas para auxiliar na transformação de laudos médicos, de modo que o alcance do método seja aumentado para a realização do mapeamento nesses laudos. 1.1 Objetivos Esse trabalho tem como objetivo geral automatizar e otimizar o PMLM por ontologias mediante a integração de técnicas de processamento de laudos textuais em uma ferramenta computacional. Para alcançar o objetivo principal deste trabalho, os seguintes objetivos específicos foram definidos: Levantamento bibliográfico sobre conceitos relacionados com ontologias e PMLM; Desenvolvimento de um Sistema Computacional Colaborativo (SCC) para prover suporte à aplicação automatizada do método de mapeamento de laudos médicos;

30 4 Auto-suficiência do SCC para a construção e a alteração da ontologia empregada em um determinado domínio; Pesquisa e desenvolvimento de outros métodos de processamento de textos para aprimorar a representação dos laudos; Realização de um estudo de caso para a aplicação do SCC no mapeamento de um determinado conjunto de laudos médicos; Avaliação e validação dos resultados do trabalho em conjunto com especialistas do domínio. 1.2 Premissas As premissas deste trabalho são: Cada técnica de processamento de textos implementada no PMLM é executada manualmente e separadamente por intermédio de instruções computacionais; As estruturas auxiliares utilizadas como apoio ao PMLM devem ser construídas manualmente e separadamente utilizando a linguagem de marcação XML (extensible Markup Language); A ontologia deve ser elaborada utilizando outras ferramentas computacionais, como o Protégé; Uma das técnicas de processamento de textos utilizada no PMLM pode acarretar na perca de legibilidade e/ou na transformação errônea de alguns termos. 1.3 Hipótese A hipótese deste trabalho é que a integração e a automatização de todas as técnicas e as etapas do PMLM por ontologias em um SCC pode tornar o processo de mapeamento mais eficiente, tanto em termos de custo de tempo quanto em termos de precisão, bem como torná-lo mais amigável. 1.4 Organização do Trabalho Este trabalho está organizado do seguinte modo:

31 5 Capítulo 2 Fundamentos de Ontologia: neste capítulo são abordados os principais conceitos sobre ontologias, suas definições e utilidades. Também, são apresentados os tipos de ontologias, método de construção dessas estruturas, linguagens aplicadas para representação de conhecimento e ferramentas comumente utilizadas para a construção de ontologias; Capítulo 3 Processo de Mapeamento de Laudos Médicos utilizando Ontologias: neste capítulo o processo como um todo é apresentado juntamente com as técnicas de processamento de textos utilizadas no PMLM bem como o método de lematização, abordagem proposta para a substituição do método de stemming neste trabalho; Capítulo 4 Desenvolvimento de Sistemas Computacionais: neste capítulo são abordados conceitos de engenharia de software focados na construção de sistemas computacionais. Também são apresentados conceitos de processo de software utilizado para o desenvolvimento do SCC; Capítulo 5 Ferramentas e Tecnologias: neste capítulo são apresentadas as ferramentas utilizadas para a construção da solução computacional deste trabalho, como as linguagens de programação Java, Javascript, Perl e Ruby, o ambiente de desenvolvimento NetBeans, as linguagens de marcação HTML e XML, a linguagem de estilo CSS e o framework para desenvolvimento de sistemas web Ruby on Rails; Capítulo 6 Processo de Desenvolvimento do Sistema Computacional Colaborativo: neste capítulo são descritas a aplicação de uma abordagem disciplinada de engenharia de software e ferramentas utilizadas para a construção do SCC; Capítulo 7 Estudo de Caso: neste capítulo é apresentado o estudo de caso realizado neste trabalho, utilizando o SCC desenvolvido para a aplicação do PMLM automatizado em um conjunto de laudos médicos textuais artificiais que simulam exames de Endoscopia Digestiva Alta (EDA); Capítulo 8 Resultados e Discussão: neste capítulo são apresentados e discutidos os resultados da avaliação experimental do SCC desenvolvido. Essa avaliação foi realizada por meio da aplicação do PMLM automatizado em um conjunto de laudos médicos textuais artificiais de exames de EDA. Também foi comparado o desempenho da execução do mapeamento manual e automático; Capítulo 9 Conclusão: neste capítulo são apresentadas as conclusões deste trabalho, suas possíveis e principais contribuições, limitações identificadas durante o seu desenvolvimento, e sugestões de trabalhos futuros.

32 6

33 Capítulo 2 Fundamentos de Ontologia 2.1 Considerações Iniciais Com o crescente aumento no volume e no armazenamento de informações em base de dados, é imprescindível a construção de métodos e de ferramentas para a organização e o gerenciamento dessas informações de modo que possam ser utilizadas futuramente em aplicações de processos para a descoberta de conhecimento, como Mineração de Dados (MD). Para isso, é necessário que esses dados sejam representados de forma estruturada para que esses processos desempenhem as suas tarefas de forma rápida e eficiente. Nesse sentido, o uso de ontologias pode auxiliar na representação e na organização dessas informações. Sendo assim, na Seção 2.2 são descritas as principais definições de ontologia. Na Seção 2.3 são discutidos alguns domínios em que as ontologias podem ser empregadas. Na Seção 2.4 são apresentados os tipos de ontologias. Na Seção 2.5 é descrito o método geral para a construção de ontologias proposto por Uschold and Gruninger (1996). Na Seção 2.6 são demonstradas algumas linguagens que podem ser utilizadas para representação do conhecimento. Na Seção 2.7 são apresentadas algumas ferramentas que provém suporte para a representação e o processamento de ontologias. 2.2 Definição de Ontologia Ontologia, palavra oriunda dos termos gregos ontos (ser) e logia (conhecimento), consiste em um campo da filosofia que tem o propósito de estudar as características do ser, da existência e das questões que envolvem a metafísica (Harper, 2010). A definição de ontologia teve origem na Grécia Antiga e ocupou a mente de filósofos como Platão, Aristóteles e Parmênides. No século XVII, enquanto uns filósofos consideravam o termo ontologia equivalente à palavra metafísica, outros definiam esse termo como uma divisão da metafísica. Atualmente, a metafísica e a ontologia são consideradas sinônimos, filosoficamente (Guarino and Giaretta, 1995). Na 7

34 8 área computacional, ontologia é uma estrutura de dados que tem a finalidade de representar o conhecimento de um domínio específico. Para Uschold and Gruninger (1996), ontologia é um termo utilizado como referência para denominar o compartilhamento do conhecimento de alguma área de interesse, podendo ser aplicada no desenvolvimento de ferramentas computacionais para processamento de informações representadas estruturadamente. Em uma ontologia é incorporado algum tipo de visão de mundo relacionado com um determinado campo de conhecimento. Essa visão é caracterizada como um conjunto de conceitos (entidades, atributos, processos, entre outros) e relacionamentos entre os mesmos. Para Guarino (1997), ontologia é uma caracterização intuitiva de um vocabulário lógico, em que as sentenças expressam relacionamentos entre características específicas, sendo que muitas vezes é necessária uma inferência mais detalhada do conhecimento para excluir ou reduzir interpretações errôneas por Sistemas Computacionais (SC). Na definição de Fox, Barbuceanu, Gruninger and Lin (1998) e de Garcia and Sichman (2003), ontologia é uma representação formal de uma entidade, ou seja, é constituída de propriedades, de relações, de restrições e de comportamentos. Nesse sentido, uma entidade é definida como uma organização, que é composta por várias divisões e consiste em um grupo de agentes associados a um conjunto de papéis, que são funções desempenhadas pelos agentes da organização com a finalidade de cumprir metas estipuladas. Agente é um membro de uma divisão da organização que assume pelo menos um papel a ser desempenhado. Segundo Gruber (2009), uma ontologia tem o intuito de definir um conjunto de primitivas de representação, como classes, atributos e relacionamentos para modelar o domínio de conhecimento. Para a definição de primitivas, devem ser incluídas as informações sobre o seu significado e as restrições lógicas para sua aplicação. Por exemplo, em sistemas de bancos de dados, o nível de abstração de modelos de dados pode ser considerado uma ontologia. 2.3 Aplicações da Ontologia Na área computacional, o uso de ontologias é dividido em três categorias (Uschold and Gruninger, 1996): Comunicação: permitem o compartilhamento de conhecimento e o contato entre indivíduos com necessidades e ideias diferentes em distintos domínios específicos. Em SC, essas estruturas são utilizadas para padronizar modelos de dados, relacionamento de redes, integração de diferentes sistemas, entre outros; Interoperabilidade: possibilitam a integração de diferentes softwares sem a necessidade

35 9 de tradução de métodos de modelagem, de linguagens de programação, de ferramentas computacionais, e de arquiteturas; Engenharia de Sistemas: facilitam o processo de identificação de requisitos durante a modelagem e o desenvolvimento de projetos de SC, tal como possibilitam a automatização da verificação de consistência, aumentando a confiabilidade do sistema. Também, essas estruturas de dados podem ser reutilizadas para a construção de outros sistemas. Assim, ontologias podem ser utilizadas como apoio na especificação de requisitos, auxiliando na tarefa de identificação de necessidades que deverão ser atendidas por meio de uma solução computacional. Nesse contexto, as ontologias geralmente são utilizadas com o propósito de facilitar a realização de tarefas, como: organização de conhecimento; compartilhamento de informações entre as pessoas; processamento de dados; aplicação de processos de MD; e comunicação entre os componentes de software e/ou aplicações computacionais (Chute, 2005). Assim, ontologias podem ser aplicadas em projetos que envolvem multidisciplinaridade com o objetivo de facilitar o diálogo entre os especialistas de diferentes áreas, bem como apoio para reduzir a complexidade do desenvolvimento de sistemas. Na área da saúde, por exemplo, várias ontologias foram desenvolvidas com o intuito de representar vocabulários médicos em estruturas de dados para que possam ser utilizadas por ferramentas computacionais (Campbell, 1998), dos quais se destaca a Unified Medical Language System (UMLS) (Humpheys, Lindberg, Schoolman and Barnett, 1998). A UMLS é um repositório mantido pela organização norte-americana National Lybrary of Medicine (NLM) e é composto por vários vocabulários de termos utilizados nas ciências médicas. Sendo assim, esse repositório possui três bases de conhecimento, tais como a Metathesaurus, a Semantic Network e a Specialist Lexicon. A Metathesaurus é uma ampla base de dados multilíngua de vocabulários utilizada para o mapeamento de termos médicos com a finalidade de definir ou de identificar distintos termos que estão associados a um simples conceito. Essa base possui mais de um milhão de conceitos médicos e mais de cinco milhões de nomenclaturas de termos, compondo mais de 100 vocabulários diferentes, incluindo os vocabulários controlados Medical Subject Headings (MeSH) e Systematized Nomenclature of Medicine Clinical Terms (SNOMED-CT). A Semantic Network é um catálogo de tipos de semânticas (categorias) e de relacionamentos que definem a classificação dos conceitos presentes na base Metathesaurus por meio da atribuição. Essa base contém 133 tipos semânticos e 54 relacionamentos diferentes. A Specialist Lexicon é um dicionário em que são apresentadas as definições sintáticas para termos médicos no idioma inglês. Cada termo de entrada processado (dados de entrada) contém informações ortográficas, morfológicas (forma e estrutura) e sintaxe (como as palavras

36 10 são organizadas para gerar um significado). No Laboratório de Bioinformática (LABI) da Universidade Estadual do Oeste do Paraná (UNIOESTE) em parceria com o Serviço de Coloproctologia da Faculdade de Ciências Médicas (FCM) da Universidade Estadual de Campinas (UNICAMP) foi proposta uma versão do Processo de Mapeamento de Laudos Médicos (PMLM) que utiliza ontologias para a representação do conhecimento. Essa estrutura contém atributos e Regras de Mapeamento (RM), que são utilizados para transformação de laudos médicos textuais não estruturados para o formato estruturado, como a tabela atributo-valor (Lee, Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundes and Chung, 2011). 2.4 Tipos de Ontologias As ontologias podem ser categorizadas de acordo com o domínio do conhecimento envolvido, que é representado em uma estrutura de dados segundo os níveis de detalhes determinados (Bodenreider and Burgun, 2005). Nesse sentido, essas ontologias podem ser classificadas como: Ontologias de aplicação (application ontologies): representam os conceitos que são dependentes de um domínio específico e de suas atividades que atendem as especificações do problema a ser resolvido (Guarino, 1997); Ontologias centrais (core ontologies): descrevem as divisões do estudo de uma determinada área e/ou conceitos genéricos e abstratos (Guarino and Giaretta, 1995). Essas ontologias contém apenas definições necessárias para compreender outros conceitos; Ontologias de domínio (domain ontologies): especificam o conhecimento de um determinado domínio específico, ou seja, parte particular do mundo. Para a construção desse tipo de ontologia é necessário o uso de uma ontologia de nível mais genérico que descreva os termos mais gerais e que sejam independentes de domínio. As ontologias de nível mais genérico são denominadas de ontologias gerais (França, 2009); Ontologias gerais (foundation ontologies): representam o conhecimento em um nível intermediário de detalhes independentemente do seu uso em representações específicas (Bodenreider and Burgun, 2005). Assim, as ontologias gerais consistem em modelos de dados comumente aplicáveis a uma grande variedade de ontologias de domínio. Por exemplo, os termos relacionados ao veículo podem ser aplicados na conceituação de carro, de trem, de avião ou de navio. Desse modo, o veículo pode ser representado por uma ontologia geral e os tipos derivados de veículo podem ser representados por uma ontologia de domínio;

37 11 Ontologias de representação (representation ontologies): esboçam a classificação das primitivas que são utilizadas por intermédio de uma linguagem de representação de conhecimento (Guarino, 1997); Ontologias de tarefas (task ontologies): descrevem o vocabulário relacionado com as atividades necessárias para a resolução de problemas independentemente do domínio em que ocorrem (Guarino and Giaretta, 1995). 2.5 Construção de Ontologias Na literatura foram propostos vários métodos para o desenvolvimento de ontologias, dos quais se destaca o método geral de construção de ontologias (Uschold and Gruninger, 1996), que tem como objetivo generalizar o processo de construção dessas estruturas de dados. O método proposto por Uschold and Gruninger (1996) é aplicado em cinco fases: 1. Identificação do escopo e do objetivo; 2. Construção da ontologia; 3. Avaliação; 4. Documentação; 5. Estabelecimento de diretrizes para cada fase. Na Fase (1), são levantadas as especificações para o desenvolvimento de uma ou mais ontologias, bem como são respondidas questões à respeito das mesmas, como a motivação e o modo de uso. O escopo é definido mediante um conjunto de questões de competência, os quais são problemas diferentes de raciocínio que devem ser atendidos pela ontologia proposta. Assim, as definições e as restrições de uma ontologia são avaliadas e validadas por meio das questões de competência. Na Fase (2), após as definições da etapa anterior, é construída a ontologia considerando três aspectos: Captura: contempla atividades para a definição da ontologia, como a identificação dos conceitos principais e dos relacionamentos existentes no domínio de interesse, a produção de definições exatas de texto não ambíguos para os conceitos identificados e a definição dos termos referentes aos conceitos e aos relacionamentos;

38 12 Codificação: a partir dos conceitos identificados durante a captura da ontologia, a mesma é construída por meio de uma linguagem de representação em um ambiente de desenvolvimento; Integração com ontologias existentes: durante a codificação dessa estrutura, podem ser reaproveitadas outras ontologias que foram desenvolvidas anteriormente. Na Fase (3), verifica-se se foram atendidas todas as especificações levantadas para o desenvolvimento de uma ou mais ontologias. Assim, são avaliadas as suas características, tais como a sua expressividade e a sua consistência. Essa avaliação deve determinar se é necessária a extensão da ontologia ou se as questões de competência podem ser respondidas por meio de ontologias existentes. Na Fase (4), o processo de desenvolvimento da ontologia é documentado. Nessa documentação são incluídas as especificações levantadas durante as etapas anteriores e os conceitos utilizados para o desenvolvimento da estrutura. Na Etapa (5), são definidos os conjuntos de técnicas, métodos e princípios para a aplicação de cada uma das fases anteriores, bem como são estipulados os relacionamentos entre essas fases, tais como a ordem de execução, a intercalação e a entrada/saída de informações. É importante ressaltar que as duas últimas fases são complementos que provém suporte para o desenvolvimento das outras fases. 2.6 Linguagens de Representação de Ontologias Nessa seção são apresentadas as linguagens comumente utilizadas para a representação de esquemas de ontologias, das quais se destaca a linguagem Ontology Web Language (OWL) que foi utilizada para o processamento de laudos textuais médicos por meio do PMLM Knowledge Interchange Format A linguagem Knowledge Interchange Format (KIF) (Genesereth, Fikes, Brachman, Gruber, Hayes, Letsinger, Lifschitz, Macgregor, Mccarthy, Norvig and Patil, 1992) foi desenvolvida com o objetivo de facilitar a troca de informações entre softwares escritos em diferentes linguagens. A KIF, caracterizada por ser baseada no cálculo de predicados e por apresentar alto poder de expressividade, foi uma das primeiras linguagens elaboradas com o intuito de representar o conhecimento por meio de ontologias. O propósito dessa linguagem é similar ao da linguagem Postscript (Adobe Systems, 1990), que é comumente utilizada em programas de formatação de textos e de gráficos para a visibilização de informações.

39 13 Nesse sentido, essa linguagem possui algumas características que podem ser essenciais para a representação do conhecimento, tais como: Semântica declarativa: possibilita a compreensão das principais expressões dessa linguagem sem a necessidade dos recursos de um interpretador para manipular essas expressões; Logicamente compreensível: fornece expressões de sentenças arbitrárias para o cálculo de predicados; Representação de meta-conhecimento: provém suporte aos usuários em processo de tomadas de decisões no contexto de representação do conhecimento explícito. Na Figura 2.1 é apresentado um exemplo de expressão para definição de uma classe, no qual subclass é uma operação para a definição de subclasses, => é um operador para declaração de regras, instancia é a operação para a definição de instância,?pf é uma variável, attribute é uma característica de?pf. Figura 2.1: Exemplo de definição de classes KIF Ontolingua Proposta por Gruber (1992), a linguagem Ontolingua tem como objetivo auxiliar na manutenção de ontologias de maneira flexível e que seja compatível com várias linguagens de representação de conhecimento. Essa linguagem é implementada em um programa que utiliza uma sintaxe simples para traduzir definições, que são os dados de entrada para vários sistemas de representação. Nesse contexto, a sintaxe da Ontolingua é baseada nas notações padrões e cálculo de predicados presentes na linguagem KIF. Assim, a linguagem Ontolingua traduz ontologias desenvolvidas na linguagem KIF em sistemas de representação, os quais são limitados pela lógica de primeira ordem para a implementação do raciocínio. Desse modo, essa linguagem é projetada para capturar representações comuns do conhecimento. Também, a Ontolingua é baseada no Frame Ontology (FO) (Farquhar, Fikes and Rice, 1997), o qual foi construído como uma camada sobre o KIF e consiste em uma ontologia de representação do conhecimento que tem

40 14 a finalidade de permitir a construção de ontologias seguindo o paradigma de quadros (frames), propiciando termos como classes, instâncias, herança, entre outros. Comumente utilizado na área da Inteligência Artificial, frame é uma estrutura de dados utilizada para representar conhecimento de um determinado domínio (Minsk, 1985). Desse modo, de acordo com Corcho and Gómez-Pérez (2000), a linguagem Ontolingua permite construir ontologias por qualquer uma das três maneiras: utilizando exclusivamente o vocabulário FO; usando expressões KIF; ou aplicando ambas as linguagens simultaneamente. Na Figura 2.2 é apresentado um exemplo de definição de classes estruturadas na linguagem Ontolingua, no qual define-class é um construtor de classe,?nome e?cpf são variáveis, :def é um comando para a definição de atributos de classes, :axiom-def é um comando para a especificação de propriedades de classes e subclass-of é uma operação para a definição de subclasses. Figura 2.2: Exemplo de definição de classes Ontolingua Resource Description Framework A linguagem Resource Description Framework (RDF) (Klyne, Carroll and McBride, 2014) foi desenvolvida com o intuito de padronizar a comunicação de dados entre dispositivos por meio da Internet. Essa linguagem é focada na representação de dados de forma flexível e minimamente restritiva para facilitar a automatização do processamento de recursos da web. A sintaxe do RDF utiliza a linguagem de marcação denominada extensible Markup Language (XML) (Bray, Paoli, Sperberg-McQueen, Maler and Yergeau, 2006) para representar os dados e possibilitar a especificação da semântica para os dados baseados em XML de modo padronizado e interoperável. XML é uma linguagem simples e flexível que foi desenvolvida para a criação e a formatação de documentos de maneira hierárquica. Essa linguagem foi desenvolvida com a finalidade de enfrentar o desafio de gerenciar grandes quantidades de documentos eletrônicos publicados

41 15 na web. Assim, o XML oferece uma definição de sintaxe padrão para o desenvolvimento de documentos estruturados. Essa linguagem é apresentada no Capítulo 5. Nesse contexto, a linguagem RDF foi desenvolvida para atender a alguns requisitos de representação do conhecimento, tais como: prover suporte ao desenvolvimento de modelos de dados que sejam simples e fáceis de serem utilizados em aplicações de processamento e de manipulação de informações; possuir semântica formal e inferência de raciocínio provável; portar um vocabulário totalmente extensível e baseado em URI, que são referências utilizadas para nomear todos os tipos de objetos em RDF; utilizar XML para codificar o modelo de dados para a troca de informações entre aplicativos distribuídos; utilizar diferentes tipos de dados de esquema XML para representar valores com o objetivo de auxiliar no compartilhamento de informações entre aplicativos que utilizam as linguagens XML e RDF; e facilitar o uso em escala de recursos da Internet. No entanto, RDF não oferece mecanismos para descrição de propriedades, bem como não provê recursos para a descrição de relações entre estas propriedades e outros recursos. Para reduzir esses problemas, foi desenvolvido o RDF Schema (RDFS) (Brickley and Guha, 2004), também conhecido como esquema RDF, o qual consiste em uma extensão de RDF que tem a finalidade de definir as classes e as propriedades para serem utilizadas na descrição de outras propriedades. Na Figura 2.3 é apresentado um exemplo de definição de classes estruturadas na linguagem RDFS, no qual rdfs:class é um construtor que define classes, rdf:id é o identificador de um elemento declarado em um construtor, rdfs:property é o construtor de propriedades de classes, rdfs:subclassof é a operação de herança de características de classes, rdf:domain estabelece qual a classe que um elemento pertence neste exemplo e rdf:resource representa o nome da classe que um elemento está vinculado. Figura 2.3: Exemplo de definição de classes RDFS.

42 Ontology Inference Layer Ontology Inference Layer (OIL) (Horrocks, Fensel, Broekstra, Decker, Erdmann, Goble, van Harlemen, Klein, Staab, Studer, Motta and Horrocks, 2000) consiste em uma linguagem que tem o propósito de padronizar a tarefa de construção de ontologias por meio do uso de padrões web para a representação de dados, tais como as linguagens XML e RDFS. Para isso, essa linguagem possui uma camada de inferência para ontologias. A OIL combina o uso de primitivas de modelagem, que são amplamente utilizadas em linguagens baseadas em frames, com a aplicação da semântica formal e da lógica descritiva para a inferência do raciocínio. Para definição de ontologias em OIL é necessária a distinção de três camadas diferentes dessa linguagem, tais como: nível de objeto, na qual são descritas as instâncias concretas de uma ontologia; primeiro meta-nível, em que as definições ontológicas atuais são disponibilizadas; e segundo meta-nível, também conhecido como meta-meta nível, na qual são definidas as características que descrevem a ontologia do nível de objeto. Na Figura 2.4 é ilustrado um exemplo de definição de classes de uma ontologia OIL, no qual class-def define o nome de uma classe, slot-def determina um elemento de classe, domain estabelece qual a classe que um elemento pertence e subclas-of é a operação de herança de características de classes. Figura 2.4: Exemplo de definição de classes OIL (Modificado de van Harmelen and Horrocks (2000)) DAML + OIL Inicialmente, por meio de um programa financiado pela agência norte-americana US Defense Advanced Research Projects Agency (DARPA), do Departamento de Defesa dos Estados Unidos (United States Department of Defense), foi desenvolvida uma linguagem de marcação baseada em RDF e XML denominada DARPA Agent Markup Language (DAML) (Hendler and D. L. McGuinness, 2000). Essa linguagem foi elaborada com o objetivo de facilitar o desenvolvimento de estruturas de dados para a realização de buscas na web. Após o desenvolvimento da DAML, a mesma sofreu algumas alterações e foi evoluída para a DAML ONT, que consiste em uma linguagem simplificada para a representação de con-

43 17 ceitos em classes RDF de forma mais sofisticada que a representação permitida pela linguagem RDFS. Assim, com objetivo de aprimorar a representação do conhecimento, foram unidas as linguagens DAML ONT e OIL em uma nova linguagem chamada DAML+OIL (Horrocks, 2002). Essa tecnologia adota o paradigma orientado a objetos na descrição de estruturas para a representação do conhecimento por meio do uso de classes e propriedades. Essa linguagem também utiliza estruturas XML Schema para a representação de dados. Na Figura 2.5 é apresentado um exemplo de estrutura DAML+OIL para a representação de um conjunto de dados, no qual daml:oneof define a enumeração de elementos, parsetype representa o tipo de dados, daml:collection determina que essa estrutura é uma coleção não ordenada de dados, daml:thing é um elemento utilizado para a declaração de elementos de representação de dados e rdf:about é utilizado para nomear um elemento. Figura 2.5: Exemplo de representação de um conjunto de dados DAML+OIL Ontology Web Language Ontology Web Language (OWL) (Smith, Welty and McGuinness, 2004) é uma linguagem baseada nas linguagens OIL e DAM+OIL utilizada para a representação do conhecimento que tem o intuito de construir e de instanciar ontologias na web. Assim, a linguagem OWL foi desenvolvida para ser utilizada na web semântica (semantic web) (Berners-Lee, Hendler and Lassila, 2006). A web semântica consiste em uma visão do futuro da web, onde a informação terá um significado explícito, facilitando o processamento e a integração de informações disponíveis na web pelos computadores. Assim, o propósito é tornar os recursos da web mais acessíveis aos processos automatizados por meio da adição de informações sobre os recursos que descrevem ou fornecem conteúdo na web, facilitando o trabalho de cooperação entre o humano e a máquina (McGuinness and van Harmelen, 2004).

44 18 Desse modo, a ontologia OWL é construída utilizando estruturas XML e RDF. As informações desse tipo de ontologia são organizadas utilizando as tags RDF, RDFS e OWL, também conhecidos como construtores. Também, nessa linguagem as semânticas formais e específicas determinam como derivar consequências lógicas, tais como os fatos que não estejam presentes na ontologia, mas que foram vinculados com a semântica. Classes Uma classe consiste em um mecanismo de abstração para definir um grupo de indivíduos (também conhecidos como objetos na área computacional) pertencentes a um conjunto que compartilham as mesmas propriedades. Por exemplo, carro e avião são indivíduos pertencentes à classe Veiculo. Nesse sentido, cada classe OWL está associada a um conjunto de indivíduos, sendo essa associação denominada extensão de classe. Cada indivíduo nessa extensão é denominado uma instância de classe. As classes podem ser organizadas em uma hierarquia de especialização, também denominado herança, por exemplo, a classe PessoaJurídica pode ser uma especialização da classe Pessoa. Na linguagem OWL, o mecanismo de especialização pode ser aplicado utilizando o construtor rdfs:subclassof. Nessa linguagem existe uma classe embutida mais geral denominada Thing, que é uma superclasse para todas as classes OWL (Bechhofer, van Harmelen, Hendler, Horrocks, McGuinnes, Patel-Schneider and Stein, 2004; McGuinness and van Harmelen, 2004). Para definição de classes OWL, também podem ser utilizados os seguintes construtores: owl:complementof : permite a combinação de classes por meio da operação lógica de complemento. Por exemplo, a classe Cozinha é um complemento da classe Casa; owl:disjointwith: garante que um indivíduo de uma classe não pode ser associado simultaneamente com uma outra classe especificada, ou seja, as classes não podem possuir os mesmos indivíduos. Por exemplo, os indivíduos da classe Fruta não podem ser instanciados pela classe Carne. owl:equivalentclass: indica que duas classes possuem a mesma extensão de uma mesma classe, ou seja, duas ou mais classes podem conter os mesmos indivíduos. Por exemplo, as classes PessoaFísica e PessoaJurídica podem obter os mesmos indivíduos relacionados à classe Pessoa; owl:intersectionof : permite a combinação de classes por meio da operação lógica de intersecção. Assim, a classe que utiliza esse construtor, além de suas características específicas, permite o uso apenas das características que são semelhantes entre as classes

45 19 utilizadas. Por exemplo, a intersecção das classes Brasileiro e Argentino ocasiona nas características equivalentes aos da classe Pessoa; owl:oneof : define a enumeração de classes, permitindo que as mesmas sejam descritas pela enumeração exaustiva de suas instâncias. Assim, a classe definida por esse construtor contém apenas indivíduos enumerados. Por exemplo, a classe Fruta pode ser composta pelos indivíduos das classes Maçã, Banana, Pêssego, Abacate, entre outras; owl:unionof : permite a combinação de classes por meio da operação lógica de união. Esse construtor viabiliza a junção de características de várias classes em uma única classe. Por exemplo, a classe América pode ser elaborada com a união das classes Argentina, Brasil, Colômbia, entre outras. Na Figura 2.6 é apresentado um exemplo de definição de uma classe na linguagem OWL, no qual owl:class representa uma classe OWL, rdf:id é um atributo para nomeação de um componente OWL e owl:resource é utilizado para referenciar elementos nessa linguagem. Figura 2.6: Exemplo de representação de definição de classes OWL. Propriedades Na linguagem OWL, as propriedades tem como finalidade representar as regras de relacionamento entre os indivíduos (Bechhofer, van Harmelen, Hendler, Horrocks, McGuinnes, Patel-Schneider and Stein, 2004; Smith, Welty and McGuinness, 2004). Essa linguagem possui dois tipos diferentes de propriedades: datatype properties: estabelece relações entre as instâncias de classes, literais da linguagem RDF e XML Schema datatypes; object properties: define relações entre as instâncias de duas ou mais classes. Nesse sentido, podem ser utilizados os seguintes construtores para a definição de propriedades, para os quais são apresentadas as suas funcionalidades: owl:equivalentproperty: determina que duas ou mais propriedades são equivalentes, ou seja, têm a mesma propriedade de extensão;

46 20 owl:functionalproperty: especifica que uma propriedade P pode ter apenas um único valor para cada indivíduo; owl:inversefunctionalproperty: indica que um valor pode ser somente atribuído à propriedade P de um único indivíduo; owl:inverseof : define que uma propriedade é inversa em relação à outra propriedade. Por exemplo, se a propriedade Px é inversa da propriedade Py e se a classe X está relacionada com a classe Y pela Py, então Y está associada com X pela Px; owl:symmetricproperty: utilizado para indicar que uma propriedade é simétrica, ou seja, se o conjunto de indivíduos (x, y) é uma instância de P, então o conjunto (y, x) é uma instância de P; owl:transitiveproperty: determina que uma propriedade é transitiva, isto é, se os conjuntos (x, y) e (y, z) são instâncias de P, então o conjunto (x, z) é uma instância de P; rdfs:domain: caracterizado como domínio da propriedade, limita os indivíduos para possibilitar a aplicação da propriedade. Assim, se a propriedade possui uma classe como um de seus domínios e um indivíduo é relacionado a um outro indivíduo por meio dessa propriedade, então esses indivíduos pertencem a mesma classe. Por exemplo, a propriedade denominada temfilho pode ser indicada para ter o domínio de progenitores (mãe e/ou pai); rdfs:range: limita a instanciação de indivíduos por meio da definição de valores que são válidos para uma determinada propriedade. Por exemplo, a propriedade diasemana pode ser indicada para possuir um dos valores presentes no conjunto (domingo, segunda-feira,..., sábado); rdfs:subpropertyof : define que a propriedade é uma sub-propriedade de outra propriedade. Por exemplo, as propriedades tercarro, tercamionete e tercaminhão são subpropriedades de terveiculoterrestre. Sendo assim, cada propriedade é representada pela estrutura XML <owl:objectproperty rdf:about= nomeatributo >, na qual rdf:about é um atributo de nomeação ou referência de um atributo. Na Figura 2.7 é apresentado um exemplo de uso de propriedade na linguagem OWL, em que é definida a propriedade temcasa, que é sub-propriedade de temimovel e possui a propriedade temdomicilio como equivalente e a classe Imovel como limitação do valor a ser aceito nessa definição.

47 21 Figura 2.7: Exemplo de uso de propriedade da linguagem OWL. Restrições de Propriedades A linguagem OWL permite o uso de restrições sobre o modo como as propriedades são permitidas para serem aplicadas em instâncias de uma classe. Essa linguagem fornece dois tipos de restrições que podem ser utilizados em propriedades: restrição de valor (value constraints) e restrição de cardinalidade (cardinality constraints). A restrição de valor aplica limitações no alcance da propriedade quando são utilizadas na descrição de classes, ou seja, define os valores possíveis ou um intervalo de valores que uma propriedade é capaz de obter. A restrição de cardinalidade limita a quantidade de valores que uma propriedade pode assumir na descrição de classes (Bechhofer, van Harmelen, Hendler, Horrocks, McGuinnes, Patel-Schneider and Stein, 2004; McGuinness and van Harmelen, 2004). Em ontologias desenvolvidas com a linguagem OWL, as restrições de propriedades podem ser aplicadas por meio do uso das tags <owl:restriction> e <owl:onproperty rdfs:resource= propriedade >, das quais a tag <owl:onproperty> indica a propriedade restrita. A seguir são apresentados os construtores das restrições que limitam os valores que são utilizados em uma propriedade: owl:allvaluesfrom: descreve uma classe para todos os indivíduos de um determinado conjunto em que todos os valores da propriedade em questão são membros quaisquer da extensão de classe de descrição ou são valores de dados em um determinado intervalo, isto é, são especificados todos os relacionamentos entre os indivíduos de uma classe. Assim, a propriedade presente nesta classe tem uma restrição local para valores associados à mesma. Por exemplo, a classe Escola possui a propriedade temprofessor restringindo todos os seus valores como instâncias da classe Pessoa; owl:somevaluesfrom: determina uma classe para todos os indivíduos de um determinado conjunto que possuem pelo menos um valor da propriedade em questão e o mesmo é um exemplo da classe de descrição ou de valor em um intervalo especificado. Ao contrário do allvaluesfrom, o construtor somevaluesfrom não limita a propriedade para que todos os seus valores sejam instâncias da mesma classe. Também, nessa linguagem são incluídas limitações de cardinalidade, que são definidas

48 22 como restrições locais, as quais são apresentados a seguir: owl:maxcardinality: determina o número máximo de instâncias que uma propriedade possa possuir; owl:mincardinality: estabelece o número mínimo de instâncias que uma propriedade possa obter; owl:cardinality: define que uma propriedade possui o valor de maxcardinality igual ao valor do mincardinality, ou seja, uma propriedade deve possuir exatamente um número de instâncias. Por exemplo, a propriedade temcpf da classe PessoaJurídica deve ter o valor de cardinality exatamente igual a um. 2.7 Ferramentas para Representação de Ontologias Várias ferramentas foram desenvolvidas com o objetivo de facilitar o processo de construção de ontologias. A seguir são apresentadas as principais ferramentas utilizadas para o desenvolvimento dessas estruturas Chimaera Chimaera (McGuinness, Fikes, S. and Wilder, 2000) é uma ferramenta computacional que tem a finalidade de prover suporte aos usuários nas tarefas de criação e de manutenção de ontologias na web. Essa ferramenta tem duas funções principais: mesclar ontologias múltiplas em uma só e evoluí-las. Também, Chimaera suporta ontologias oriundas de bases de conhecimento de formatos diferentes por meio da reorganização de taxonomias, da resolução de conflitos de nome, da edição, entre outros. Nesse sentido, Chimaera possui um ambiente simples para a construção e a edição de ontologias, tal como possibilita que o usuário utilize o editor/navegador do ambiente Ontolingua para a edição mais extensa e complexa dessas estruturas de dados. Também, é importante destacar que essa ferramenta computacional pode utilizar ontologias representadas por meio das linguagens OWL e DAML OilED OilED (Horrocks, Goble and Stevens, 2001) é uma ferramenta para construção de ontologias nas linguagens OIL e DAML+OIL com o intuito de proporcionar um estilo simples e intuitivo para indução de raciocínio por intermédio de uma interface amigável ao usuário. Essa

49 23 ferramenta utiliza frames para lidar com a expressividade da linguagem OIL. A ferramenta OilED também usa mecanismos altamente sofisticados de indução de raciocínio por DL com o propósito de gerar conclusões para o raciocínio que está sendo processado, facilitando a elaboração de ontologias mais complexas e detalhadas. Na versão atual dessa ferramenta é necessária a inclusão de vários recursos para a construção de ontologias, pois o mesmo não suporta o desenvolvimento dessas estruturas em larga escala, bem como não provê suporte para versionamento Protégé Protégé (Gennari, Musen, Fergerson, Grosso, Crubzy, Eriksson, Noy and Tu, 2003) consiste em um ambiente de código aberto (open source) e de uso gratuito para construção de sistemas baseados em conhecimento. Inicialmente desenvolvido com objetivo de atender a área médica, esse ambiente foi aprimorado para um conjunto de ferramentas de uso geral. O Protégé é composto por duas partes: o modelo (model), que é um mecanismo interno para representação de ontologias e bases de conhecimento; e a visão (view), que oferece uma interface ao usuário para exibir e editar ontologias. Atualmente, Protégé pode construir e editar ontologias em várias linguagens, tais como OWL, RDF, XML, Unified Modeling Language (UML) e banco de dados relacionais. Para a construção de ontologias na linguagem OWL foi desenvolvido um plugin 1 de extensão denominado Protégé OWL Plugin (Knublauch, Fergerson, Noy and Musen, 2004). O uso desse plugin oferece alguns benefícios, dos quais se destacam: uma grande comunidade de usuários e desenvolvedores ativos que utilizam e desenvolvem esse plugin; uma biblioteca de componentes reutilizáveis; e uma arquitetura flexível Servidor Ontolingua Servidor Ontolingua (Farquhar, Fikes and Rice, 1997) é um conjunto de ferramentas que tem o propósito de apoiar o processo de construção de ontologias na linguagem Ontolingua de modo individual, bem como de forma compartilhada entre grupos. Essas ferramentas fazem o uso da web para permitir o acesso e oferecer recursos aos usuários para manipulação de ontologias, como publicação, navegação, criação, edição e compartilhamento em um servidor específico. Sendo assim, o Servidor Ontolingua oferece muitas facilidades para o desenvolvimento de ontologias, tais como: 1 Plugin é um componente de software que permite adicionar uma caraterística específica a uma aplicação de software já existente.

50 24 Linguagem de representação semi-formal que oferece suporte para a descrição de termos apresentados informalmente em linguagem natural e formalmente em linguagem de representação de conhecimento interpretável por computadores; Busca, reposição, construção, melhoria e extensão de ontologias em repositórios; Facilidade de interpretação de ontologias de repositórios em sistemas computacionais; Facilidade de acesso a ontologias por meio de aplicações remotas via web. 2.8 Considerações Finais Ontologia consiste em uma estrutura de dados promissora para representação de dados médicos, pois com essa estrutura é possível organizar o conhecimento de modo flexível e estruturado. Para representação de dados médicos, na literaturam foram desenvolvidas várias ontologias, como a UMLS, que é o maior vocabulário de termos de ciências biomédicas disponível para auxiliar sistemas computacionais no processamento e no gerenciamento de dados. No PMLM são utilizadas ontologias com o propósito de representar atributos e RM para mapear conjuntos de laudos médicos textuais para uma base de dados. As ontologias utilizadas nesse processo são representadas por intermédio da linguagem OWL devido a sua grande quantidade de recursos para flexibilizar o desenvolvimento de ontologias, permitindo a expansão do potencial de representação dessas estruturas de acordo com o domínio de conhecimento. Para o desenvolvimento de ontologias nessa linguagem, geralmente é utilizada a ferramenta Protége, pois é facilitada a construção dessas estruturas por meio de uma interface gráfica amigável e intuitiva ao usuário, bem como não é necessário o conhecimento da linguagem OWL por parte do usuário para o uso dessa ferramenta. Também, essa ferramenta possui código-fonte aberto e o seu uso é gratuito, possibilitando que desenvolvedores de software aprimorem essa ferramenta de acordo com as suas necessidades e/ou de outros usuários.

51 Capítulo 3 Processo de Mapeamento de Laudos Médicos utilizando Ontologias 3.1 Considerações Iniciais Neste capítulo é apresentado o processamento de textos utilizados no Processo de Mapeamento de Laudos Médicos (PMLM), que tem o objetivo de transformar conjuntos de laudos textuais não estruturados para uma representação estruturada, como a tabela atributo-valor (Lee, Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundes and Chung, 2011). Inicialmente, em Cherman, Lee, Honorato, Fagundes, Góes, Coy and Wu (2007) foi proposta a primeira versão desse processo, a qual utiliza o Dicionário do Conhecimento (DC) para a descrição de Regras de Mapeamento (RM). O DC consiste em uma estrutura de dados utilizada para a transformação de laudos por intermédio de casamento de padrões. Essa estrutura é representada por um arquivo estruturado descrito na linguagem de marcação XML (extensible Markup Language), que é amplamente aplicada para a construção de documentos com dados organizados hierarquicamente com o uso de marcadores (tags). Porém, estudos realizados anteriormente apontam que o DC apresenta pouca flexibilidade para a representação do conhecimento, dificultando a elaboração de RM mais complexas, sendo necessária a construção de novos esquemas de DC e a alteração do método de mapeamento para adaptá-lo à nova estrutura de DC (Honorato, Cherman, Lee, Monard and Wu, 2007; Costa, Ferrero, Lee, Coy, Fagundes and Chung, 2009; Costa, Ferrero, Lee, Coy, Fagundes and Chung, 2010; Lee, Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundes and Chung, 2011). Com o propósito de reduzir as limitações dessa abordagem, em Lee, Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundes and Chung (2011) foi proposta uma variação do método original com o intuito de substituir o DC por uma ontologia, que é uma estrutura de dados que apresenta maior flexibilidade para representação de dados. 25

52 26 Nesse contexto, na Seção 3.2 são apresentadas abordagens utilizadas para o mapeamento desses laudos médicos e alguns trabalhos nos quais foram aplicadas essas abordagens. Em seguida, são apresentadas as duas etapas do PMLM, as quais são abordadas nas Seções 3.3 e Mapeamento de Laudos Médicos Os laudos textuais são imprescindíveis para qualquer especialidade médica, pois permitem descrever achados em exames realizados e manter o histórico do paciente quanto a procedimentos, sintomas, enfermidades, entre outros. No entanto, para que as informações contidas nesses laudos possam ser utilizadas, por exemplo, para estatísticas ou pesquisas médicas, para o estudo de enfermidades, a identificação de padrões, o desenvolvimento de procedimentos médicos, entre outros, o mapeamento de laudos é geralmente realizado de forma manual para uma base dados, como planilhas eletrônicas, o que torna essa tarefa inviável para grandes quantidades de laudos textuais. Na Figura 3.1 é ilustrado um exemplo de transcrição manual de um fragmento de laudo artificial pré-processado da seção de esôfago para uma base de dados, onde as linhas representam laudos mapeados e as colunas representam características (atributos) consideradas essenciais mapeadas nesses laudos. Nesse sentido, no LABI da UNIOESTE/Foz do Iguaçu em parceria com o Serviço de Coloproctologia da Faculdade de Ciências Médicas (FCM) da UNICAMP foi desenvolvido o PMLM com a finalidade de automatizar e padronizar a transcrição de informações presentes em laudos médicos para uma base de dados (Honorato, Cherman, Lee, Monard and Wu, 2007; Cherman, Lee, Honorato, Fagundes, Góes, Coy and Wu, 2007; Lee, Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundes and Chung, 2011). Inicialmente, em Cherman, Lee, Honorato, Fagundes, Góes, Coy and Wu (2007) foi proposta a versão do PMLM que utiliza uma estrutura de dados denominada Dicionário de Conhecimento (DC) para o mapeamento de laudos. Essa estrutura contém RM que representam possíveis combinações de termos em frases de cada laudo para o preenchimento da base de dados. Essas RM são geralmente apresentadas na forma local-característica-subcaracterística e/ou local-característica, onde: Local: corresponde aos termos que descrevem uma porção anatômica do corpo humano; Característica: equivale às palavras que caracterizam possíveis anormalidades ou outras informações importantes à respeito de um determinado local; Subcaracterística: representa as informações complementares de uma determinada carac-

53 27 Figura 3.1: Exemplo de transcrição manual de um laudo textual artificial da seção de esôfago para uma base de dados. terística. No caso do DC, essas regras são representadas de modo sequencial, em que cada local descreve uma lista de característica e cada característica pode possuir uma lista de subcaracterísticas, como ilustrado na Figura 3.2, em que L i é uma lista de locais, L i C j é a lista de características de L i, A j é o atributo que é preenchido caso seja encontrada a sequência L i C j no laudo, V j é o valor do atributo A j, L i C j S k é subcaracterística de L i C j, As k é o atributo que é preenchido caso seja encontrado no laudo a sequência L i C j S k no laudo e V s k é o valor do atributo As k. Entretanto, o DC apresenta pouca flexibilidade para a representação do conhecimento e a descrição de RM, dificultando a elaboração de regras que apresentam maior complexidade e completitude 1, tornando indispensável a construção de novas estruturas de DC e especialmente, a realização de modificações no método para adaptá-lo ao novo esquema de DC para o mapeamento de laudos que não tenham sidos mapeados anteriormente. Com a finalidade de melhorar a representação do conhecimento presente em laudos tex- 1 Possibilidade de inclusão de maior quantidade de informações relevantes em uma única regra.

54 28 Figura 3.2: Estrutura do Dicionário de Conhecimento (Spolaôr, Lee, Cherman, Honorato, Fagundes, Góes, Coy and Chung, 2007). tuais, em Costa, Ferrero, Lee, Coy, Fagundes and Chung (2009) foi apresentada uma proposta inicial de uma variação do PMLM com o objetivo de substituir o DC por uma ontologia para aumentar a flexibilidade na representação do conhecimento e facilitar o reuso dessa estrutura para a construção de outras ontologias sem a necessidade de reconstruí-la e sem a necessidade da alteração do algoritmo de mapeamento para adaptá-lo a essas estruturas. Em Wu, Coy, Lee, Fagundes, Ferrero, Machado, Maletzke, Zalewski, Leal, Ayrizono and Costa (2010) e Lee, Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundes and Chung (2011), foi proposta a versão atual do PMLM. Entretanto, todas as técnicas aplicadas nesse processo devem ser executadas manualmente e separadamente por intermédio do uso de comandos computacionais, dificultando a aplicação do método por profissionais que não sejam da área computacional. Por exemplo, para a construção de Conjuntos de Frases Únicas (CFU) e o pré-processamento de laudos textuais, o usuário deve executar de forma manual os arquivos escritos na linguagem Perl utilizando instruções específicas por meio de interpretadores dessa linguagem. Outro exemplo é a realização do mapeamento desses laudos, para a qual é necessária a execução manual do método por meio de uma Máquina Virtual Java (MVJ), o qual é executado com o uso de instruções computacionais. Ainda, a construção das estruturas como a lista de stopwords (stoplist) e o Arquivo de Padronização (AP), que são apresentadas na Seção 3.3, é realizada manualmente com o uso de estruturas XML. A organização manual de stopwords e de Regras de Padronização (RP) em estruturas XML se apresenta como uma atividade altamente repetitiva e custosa, pois as suas informações devem ser organizadas de forma padronizada e hierárquica por intermédio de marcadores, podendo acarretar na representação errônea das mesmas e influenciar no desempenho do pré-processamento e do mapeamento de laudos médicos (Lee, Oliva, Maletzke, Machado, Voltolini, Coy, Fagundes and Wu, 2013).

55 29 Para a construção de ontologias, podem ser utilizadas ferramentas computacionais de uso gratuito para a representação das RM, como o Protégé (Gennari, Musen, Fergerson, Grosso, Crubzy, Eriksson, Noy and Tu, 2003). No entanto, o uso dessa ferramenta requer treinamento e o conhecimento da linguagem de representação de ontologias denominada OWL (Smith, Welty and McGuinness, 2004) por parte de seus usuários, tal como para a elaboração de RM e de atributos é exigido grande esforço. 3.3 Primeira Fase do PMLM Nessa etapa são aplicadas técnicas de processamento de textos em um conjunto de laudos textuais digitais com a finalidade de identificar padrões relevantes que são representados por meio de um Arquivo de Padronização (AP). Em seguida, os padrões identificados nos laudos são analisados em conjunto com profissionais da área médica e da área computacional para definir os atributos da tabela atributo-valor (base de dados estruturada) e as RM que irão compor a ontologia para a representação do conhecimento presente em laudos médicos (Cherman, Spolaôr, Lee, Costa, Fagundes, Coy and Wu, 2008; Lee, Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundes and Chung, 2011). Na Figura 3.3 é apresentada a primeira fase do método de mapeamento de laudos. Figura 3.3: Primeira fase do PMLM baseado em ontologia (Modificado de Lee, Oliva, Maletzke, Machado, Voltolini, Coy, Fagundes and Wu (2013)). Com base na Figura 3.3, nas seções seguintes são apresentadas as técnicas de processamento de textos utilizadas no PMLM, bem como são abordadas a construção do AP, da tabela

56 30 atributo-valor e da ontologia Construção do Conjunto de Frases Únicas A identificação de frases únicas consiste na extração de todas as sentenças distintas existentes em um conjunto de laudos médicos. Essa técnica é aplicada de forma sequencial em três passos (Cherman, Lee, Honorato, Fagundes, Góes, Coy and Wu, 2007): 1. Concatenação de todas as frases presentes no conjunto de laudos em um único arquivo; 2. Ordenação alfabética das frases; 3. Eliminação de frases redundantes, restando apenas um exemplo para cada frase. Após a aplicação dessa técnica, é gerado o Conjunto de Frases Únicas (CFU). Na Figura 3.4 é ilustrado graficamente o processo de identificação de frases únicas. Figura 3.4: Processo de identificação de frases únicas (Cherman, Lee, Honorato, Fagundes, Góes, Coy and Wu, 2007) Normalização do Conjunto de Frases Únicas O desempenho da aplicação de métodos de processamento de textos pode ser influenciado pela simples variação de um caracter em um determinado termo. Por exemplo, os termos Japão, japão, Japao e japao podem ser considerados distintos por métodos de processamento de textos

57 31 devido à variação de um ou mais caracteres, como a presença ou a ausência de acentuação e de caracteres maiúsculos ou minúsculos. Nesse sentido, para evitar problemas de variações de um mesmo caractere, cada termo presente no CFU é normalizado com o objetivo de substituir caracteres maiúsculos por caracteres minúsculos e caracteres com presença de acentuação por caracteres sem acentuação (Cherman, Lee, Honorato, Fagundes, Góes, Coy and Wu, 2007). Na Figura 3.5 é apresentado um exemplo de aplicação da normalização em um fragmento de CFU. Figura 3.5: Normalização de um exemplo de CFU Construção do Arquivo de Padronização Após a construção e a normalização do CFU, é possível identificar algumas informações que podem ser padronizadas, como termos semelhantes ou frases que apresentam as mesmas informações de maneiras distintas. Assim, em conjunto com especialistas do domínio é iniciada a construção do AP. Esse arquivo é uma estrutura de dados representada por meio da linguagem de marcação XML utilizada para uniformização de laudos textuais com o objetivo de reduzir a complexidade de cada frase presente nesses laudos, de modo que seja compatível com as RM presentes em uma ontologia. Essa uniformização é realizada por intermédio da substituição de termos que apresentam o mesmo significado ou em formato inadequado por um sinônimo ou

58 32 um conjunto de sinônimos definidos como sendo mais adequados que estão descritos no AP. Por exemplo, a frase "esôfago com presença erosões", que descreve uma possível anormalidade presente em um tecido biológico, pode ser substituída pelo sinônimo definido como "esôfago anormal". Também, podem ocorrer frases que apresentam mais de uma característica, como "calibre distensibilidade normais", na qual são descritas duas características: calibre e distensibilidade, que são classificadas como normais. Por meio da aplicação de padronização nessa frase, a mesma pode ser substituída por duas outras frases, como "calibre normal" e "distensibilidade normal". Na Figura 3.6 é apresentado um exemplo de estrutura do AP, onde <pattern> é o marcador que representa o cabeçalho do AP, number é o número de Regras de Padronização (RP) presentes no AP, <synonym> é o marcador que representa uma RP, n é o número de termos que irão substituir um determinado termo, <old> é o marcador que constitui um termo a ser padronizado e <new> é o marcador que representa um novo termo que substituirá o termo representado no marcador <old>, caso seja encontrado em um laudo textual durante a aplicação do AP. Figura 3.6: Exemplo de estrutura do Arquivo de Padronização. Para a construção de um AP, podem ser utilizadas Expressões Regulares (ER) 2 com a finalidade de identificar sequências de caracteres importantes para a padronização de termos, como espaços em branco excedentes entre palavras, sequência excedente de um determinado caractere, ou termos que ocorrem raramente em frases (Honorato, Cherman, Lee, Wu and Monard, 2007). Por exemplo, no padrão "ponto[s]*\s*esbranquicado[s]*" (Figura 3.6), a expressão regular "[s]*" aponta a possibilidade de haver zero ou mais vezes a presença do caractere "s" em uma determinada parte de uma palavra e a expressão regular "\s*" aponta a possibilidade 2 Expressão regular é uma sequência de caracteres que formam um padrão a ser identificado em uma frase ou uma palavra, por exemplo na forma de operações "busca e substituição".

59 33 de haver zero ou mais vezes a presença de espaços em branco. Nesse contexto, a aplicação de outras técnicas de processamento de textos, como as apresentadas nas próximas seções, pode gerar termos ou frases diferentes, aumentando as possibilidades para desenvolvimento de RP. Desse modo, a construção do AP é continuada no decorrer da aplicação da primeira fase do PMLM, à medida que são identificadas informações que podem ser uniformizadas Remoção de Stopwords Esse método tem a finalidade de reduzir o tamanho de frases por meio da eliminação de stoptwords (Makrehchi and Kamel, 2008), que são termos considerados irrelevantes, ou seja, não são necessários para a compreensão de frases. É importante notar que as stopwords são dependentes de contexto. Os exemplos mais comuns incluem tais como pronomes, preposições, artigos, entre outros. Nesse método, os stopwords compõem uma lista denominada stoplist, que é utilizada no processamento do CFU e de laudos durante a remoção desses termos. A stoplist é construída em conjunto com especialistas do domínio e assim como AP, é representada por intermédio da linguagem de marcação XML. Na Figura 3.7 é apresentado um exemplo de stoplist, onde <stopwords> é o marcador que representa a lista de termos considerados irrelevantes, number é o número de stopwords presentes na stoplist e <stopword> é o marcador que representa um stopword. Figura 3.7: Exemplo de stoplist.

60 Aplicação de Stemming O método de aplicação de stemming tem o objetivo de reduzir cada termo para o seu radical, eliminando diferentes inflexões da mesma palavra (Hull, 1996). Radical ou morfema é a parte invariante de uma palavra que explicita o significado da mesma, isto é, o sentido de um termo é mantido mesmo sem prefixo e/ou sufixo (Michaelis, 2009). Assim, stemming é aplicado com o intuito de identificar e eliminar frases redundantes, pois muitas sentenças podem ser consideradas distintas por causa da variação de uma palavra, por exemplo, mucosa terço distal erosão e mucosa terço distal erosões representam uma mesma observação, mas estão escritas de formas diferentes. Ao aplicar stemming nessas frases, obtém-se muc terç dist eros para ambos os casos. Nesse sentido, na literatura foram propostos diversos métodos para a aplicação de stemming, dos quais se destaca o Stemmer de Porter (Porter, 1997), que é um algoritmo de remoção de sufixos de palavras em inglês. Nesse algoritmo, a remoção de sufixos é exclusivamente baseada em regras, sem o uso de outras estruturas para realização de operações de busca, tais como listas de exceções e/ou dicionários de dados. Essas regras são escritas na forma S 1 S 2, em que o sufixo S 1 é substituído por S 2. Por exemplo, a regra ico elimina os sufixos de palavras terminadas com "ico", como a palavra médico, que é transformada em méd. Com base no Stemmer de Porter, foram desenvolvidos métodos de aplicação de stemming para a remoção de sufixos de palavras escritas em outros idiomas. Em (Orengo and Huyck, 2001), foi proposto um método de aplicação de stemming em termos escritos em português, o qual foi implementado pelo grupo de pesquisa do LABI para ser utilizado no PMLM. Esse método é aplicado em oito passos, que são apresentados a seguir: 1. Transformação de termos plurais para singular; 2. Conversão de substantivo feminino para masculino; 3. Redução de advérbio para verbo infinitivo ou adjetivo masculino singular; 4. Transformação de substantivo diminutivo/aumentativo para singular; 5. Remoção de pronomes; 6. Eliminação de sufixos de verbos; 7. Exclusão da última vogal; 8. Remoção de acentuação.

61 35 No PMLM, os passos 3 e 8 não são necessários para o processamento de termos, pois já são aplicados anteriormente nos métodos apresentados nas Seções e 3.3.4, respectivamente. Na Figura 3.8 é ilustrado graficamente um exemplo de aplicação de stemming em um conjunto de frases normalizadas e sem a presença de stopwords. Figura 3.8: Exemplo de aplicação de stemming. No entanto, a aplicação de stemming pode acarretar, em alguns casos, na perda da legibilidade de termos, dificultando a compreensão de algumas palavras. Também, a redução dos termos para o seu radical pode conduzir eventualmente a uma interpretação semântica incorreta devido à existência de termos com significados diferentes, mas com radicais iguais (Fuller and Zobel, 1998). Um exemplo disso são as palavras média e médico que tem o mesmo radical méd, mas os significados são distintos. Desse modo, com a finalidade de amenizar esses problemas de representação do conhecimento, neste trabalho também é proposta a substituição do método de stemming pela técnica de aplicação de lematização, que é apresentada na próxima seção Aplicação de Lematização Laudos textuais médicos contém um vasto vocabulário de termos, apresentados na literatura médica, para descrição de procedimentos médicos, diagnóstico de enfermidades e outras informações. Entretanto, há termos que se diferenciam apenas morfologicamente, mas possuem

62 36 o mesmo significado (Ananiadou and Mcnaught, 2005). Essa variedade morfológica aumenta a complexidade das informações presentes em laudos médicos, dificultando a aplicação de métodos e de ferramentas computacionais para a análise desses dados. Para amenizar a complexidade dessas informações, podem ser aplicadas técnicas de lematização (lemmatization) com a finalidade de reduzir a variabilidade de termos (Abacha and Zweigenbaum, 2011; Liu, Christiansen, Jr. and Verspoor, 2012). A lematização tem como objetivo transformar morfologicamente cada termo para a sua forma canônica, denominada lema, que é a forma simplificada de um termo, como o singular de um substantivo plural, a forma infinitiva de um verbo conjugado, o masculino do substantivo feminino, entre outros. Assim, a lematização consiste em um processo de redução de termos onde diferentes variações morfológicas de uma palavra são transformadas para um lema base comum, reduzindo o número total de termos distintos (Chrupala, 2006; Jongejan and Dalianis, 2009). Esse processo pode ser realizado por meio da busca em um Dicionário de Lemas (DL) e/ou do uso de Regras de Lematização (RL). O DL consiste em uma estrutura de dados em que são registradas palavras não canônicas e os seus respectivos lemas (Branco and Silva, 2007). As RL tem como objetivo substituir afixos de termos não canônicos por afixos que os tornam canônicos (Nunes, 2007). Os verbos na língua portuguesa em forma canônica, por exemplo, geralmente possuem sufixos "ar" (chamar, trabalhar, conversar), "er" (poder, torcer, crescer), "ir" (pedir, surgir, sorrir), "or" (repor, transpor) ou "ôr" (pôr). Neste caso, o método de lematização substitui os sufixos dos verbos conjugados, como os sufixos de verbos "ou" (agonizou), "rá" (terminará), "ei" (estudei) ou "ado" (recortado) são substituídos pelo su?xo "ar" (agonizar, terminar, estudar, recortar), por um dos cinco sufixos apresentados anteriormente usando RL. Na Figura 3.9 é apresentado um modelo de conjunto de RL para processamento de verbos e um exemplo de aplicação para cada RL exibida. Figura 3.9: Exemplo de conjunto de regras para lematização de verbos. A RL de número dois apresentada na Figura 3.9, por exemplo, tem como finalidade substituir sufixos de verbos conjugados para o tempo passado que terminam com ado pelo sufixo ar, transformando esse verbo para a sua forma infinitiva. Assim, uma regra pode englobar um grande número de lemas, não sendo necessário listá-los explicitamente em um lista, como ocorre em caso de lematizadores que utilizam DL (Branco and Silva, 2007). No entanto, para cada RL pode haver exceções que devem ser tratadas de modo que evite as transformações errôneas de termos, como na regra "ado" "ar", a qual é aplicada em verbos, pois, existem

63 37 palavras terminadas com o sufixo ado que não são verbos, tais como: reinado, gado, lado, entre outros. Para a transformação de termos na sua forma canônica em uma determinada linguagem, existem dois processos principais que podem ser utilizados para isso: o derivativo e o inflexional (Kanis and Skorkovská, 2010). No processo derivativo, os termos são normalizados de acordo com a sua classe morfológica, por exemplo, as palavras diagnosticou e diagnosticará são derivadas do verbo diagnosticar. No processo inflexional, os termos são normalizados conforme outras classes morfológicas, como o termo diagnosticadamente. Nesse contexto, sistemas computacionais avançados de processamento textos que aplicam a técnica de lematização para transformação de dados utilizam RL construídas manualmente (lematizador manual) ou automaticamente (lematizador automático). O lematizador manual utiliza DL e/ou RL construídos manualmente para processamento de termos. O lematizador automático constrói RL e/ou DL automaticamente durante o treinamento do lematizador a partir de conjuntos de dados, que são representados em pares (palavra não simplificada lema). Nessa abordagem, a construção de RL é baseada na busca de maiores sub-palavras comuns em termos não canônicos e lemas (Jongejan and Dalianis, 2009). Assim como stemming, na literatura também foram propostas várias abordagens para a lematização de palavras escritas em diversos idiomas. Por exemplo, em Juršič, Mozetič and Lavrač (2007) é apresentado um sistema denominado LemmaGen para a construção automática de lematizadores, que foi aplicado em conjuntos de termos escritos em idiomas como alemão, búlgaro, esloveno, estoniano, espanhol, francês, húngaro, inglês, italiano, romeno, sérvio e tcheco. Para a geração de lematizadores, esse sistema utiliza o algoritmo de aprendizado denominado Ripple Down Rule (RDR) (Plisson, Lavrac, Mladenic and Erjavec, 2008), que tem a finalidade de construir RL automaticamente a partir do processamento de textos. Após a elaboração do conjunto de RL, novas regras podem ser adicionados ao sistema na medida em que novos exemplos de termos são avaliados. Em outro trabalho, foi proposto um algoritmo de lematização baseado em regras para processamento de termos nominais escritos no idioma português utilizando listas com quantidade mínima de palavras (Branco and Silva, 2007). Esse algoritmo é baseado no método proposto por Porter (1997), sendo que ao invés de remover os sufixos presentes nos termos, os mesmos são substituídos por outros sufixos definidos nas RL. Também, nesse algoritmo é utilizado um conjunto de regras para desfazer mudanças nas palavras em casos de exceções para a aplicação de determinadas regras. Desse modo, a lematização proporciona os mesmos benefícios da aplicação de stemming, mas tem as vantagens de facilitar a compreensão dos resultados do processamento e de possibilitar a manutenção da semântica dos termos processados (Korenius, Laurikkala, Järvelin and Juhola, 2004).

64 Definição dos Atributos da Tabela Atributo-Valor e da Ontologia Após a aplicação do pré-processamento, os CFU resultantes são analisados em conjunto com especialistas do domínio e utilizados para especificar os atributos e seus possíveis valores que irão compor a base de dados (tabela atributo-valor) e serão aplicados para a representação de padrões relevantes que se encontram em laudos textuais, bem como são elaboradas as RM que serão aplicadas com a finalidade de mapear esses padrões para uma base de dados. Os atributos e as RM são representados por intermédio de uma ontologia, que é uma estrutura de dados utilizada para representar o conhecimento de um determinado domínio (Gruber, 2009), conforme apresentado no Capítulo 3. Nesse sentido, o uso de ontologias possibilita a definição de esquemas flexíveis para a descrição e a classificação de termos presentes em laudos textuais médicos, bem como a representação dos atributos da tabela atributo-valor e das RM. Essas regras definem as combinações de termos para o preenchimento de cada atributo com valores definidos como possíveis para o preenchimento de cada atributo. Conforme mencionado, as RM geralmente são estruturadas para interpretar sentenças com os termos apresentados sequencialmente na forma: Local: corresponde aos termos que descrevem uma porção anatômica do corpo humano; Característica: equivale às palavras que caracterizam possíveis anormalidades ou outras informações importantes à respeito de um determinado local; Subcaracterística: representa as informações complementares de uma determinada característica. Em laudos médicos, cada frase pode ser organizada na sequência local-característica ou local-característica-subcaracterística. Por exemplo, na frase esôfago com úlcera de 8 mm, o esôfago é uma porção anatômica (local), a úlcera é uma anormalidade observada no esôfago (característica) e o termo 8 mm é a extensão da úlcera (subcaracterística). Na Figura 3.10 é ilustrado um exemplo de esquema de ontologia para a representação de atributos e de RM: Thing: é a classe principal da maioria das ontologias e corresponde a todos os indivíduos representados por essas estruturas; Atributo: é a classe responsável por agrupar todos os atributos de uma tabela atributovalor e é dividida em duas subclasses: Nome_atributo: é a classe que representa o nome do atributo;

65 39 Tipo_atributo: indica os valores possíveis para o atributo. Termo: constitui os termos que podem ser encontrados em laudos textuais e é composta por duas classes: Região: que descreve as porções anatômicas do corpo humano; Observações: determina as informações sobre uma região do corpo humano. Essa classe é divida em duas classes: Característica: equivale às descrições sobre uma região; Subcaracterística: representa as informações complementares sobre uma característica. Figura 3.10: Exemplo de esquema de ontologia para mapeamento de laudos médicos. Geralmente, os atributos representados por uma ontologia são nomeados de modo que seja facilitada a identificação dos mesmos, adotando padrões de nomenclatura local_característica, local_característica_subcaracterística ou outros formatos que sejam compatíveis com a RM. Nesse sentido, a relação local-característica pode gerar no máximo um atributo e a relação

66 40 local-característica-subcaracterística pode gerar no mínimo dois atributos. Por exemplo, na frase esôfago com úlcera de 8 mm, podem ser definidos dois atributos para compor a tabela atributo-valor: "esofago_ulcera", que consta presença ou ausência de úlcera no esôfago, ou seja, os valores desse atributos são booleanos (verdadeiro ou falso); e "esofago_ulcera_extensoa", que representa a extensão da úlcera no esôfago, isto é, os valores devem ser numéricos. 3.4 Segunda Fase Na Figura 3.11 é ilustrada a segunda fase do processo de mapeamento, que é aplicada sequencialmente na seguinte forma: primeiramente é selecionado o conjunto de laudos a ser processado, podendo opcionalmente ser escolhido o conjunto utilizado na primeira fase. Em seguida, as técnicas selecionadas para o processamento de textos como normalização, remoção de stopwords, stemming e/ou padronização são aplicadas nesses laudos com a finalidade de uniformizá-los, reduzindo a complexidade de suas sentenças. Após, em cada laudo é aplicado o algoritmo de mapeamento com o auxílio de uma ontologia, preenchendo a tabela atributo-valor. Figura 3.11: Segunda fase do PMLM baseado em ontologia (Modificado de Lee, Oliva, Maletzke, Machado, Voltolini, Coy, Fagundes and Wu (2013)). Essa etapa tem como propósito preencher a tabela atributo-valor, definida anteriormente com os dados contidos no conjunto de laudos textuais digitais. Nessa etapa, o processamento é realizado automaticamente, pois não há interação com o usuário, sendo necessária apenas a escolha do conjunto de laudos a serem processados e o uso das estruturas definidas na etapa anterior, como a stoplist e o AP para a uniformização dos laudos e a ontologia para a realização

67 41 do mapeamento com base nas RM definidas (Lee, Oliva, Maletzke, Machado, Voltolini, Coy, Fagundes and Wu, 2013). Essa transcrição é realizada por meio de um algoritmo especializado, que processa cada frase dos laudos mediante o casamento de padrões, utilizando RM representadas em uma ontologia. Assim, para cada laudo é gerado um registro com valores de cada atributo presente na ontologia. Esses registros compõem a tabela atributo-valor, representando o conjunto de laudos estruturadamente (Costa, Ferrero, Lee, Coy, Fagundes and Chung, 2010). O método de mapeamento de laudos por meio de ontologias é aplicado em três etapas (Costa, Ferrero, Lee, Coy, Fagundes and Chung, 2009), as quais são apresentadas a seguir: 1. Divisão de laudos em sentenças: cada laudo textual selecionado para a aplicação do método de mapeamento é dividido em um conjunto de sentenças; 2. Processamento das sentenças: cada termo presente nas sentenças é processado e vinculado a uma propriedade de acordo com a sua classificação na ontologia. Caso um termo não seja identificado na ontologia, o mesmo é incluído em uma lista de termos não processados. Após, as palavras identificadas são associadas com as RM, definindo quais são os atributos a serem preenchidos e os seus respectivos valores; 3. Preenchimento de atributos não-mapeados: após o processamento de cada sentença, os atributos que não foram mapeados são preenchidos com o caractere traço ( -"). 3.5 Considerações Finais O PMLM apresenta grande importância para a padronização e a representação de laudos textuais no contexto de aplicação da Mineração de Dados (MD) para a extração de padrões relevantes. Isso pode contribuir com a geração de novos conhecimentos, tais como a descoberta de fatores que aumentam o risco de enfermidades, a criação de novas técnicas para o diagnóstico de doenças, o desenvolvimento de novos medicamentos, a construção de modelos preditivos para auxiliar especialistas da área médica em tomadas de decisão, entre outros. Esse processo foi avaliado em trabalhos anteriores e apresentaram resultados considerados satisfatórios, tanto para a abordagem baseada em DC (Cherman, Lee, Honorato, Fagundes, Góes, Coy and Wu, 2007; Honorato, Cherman, Lee, Monard and Wu, 2007; Cherman, Spolaôr, Lee, Costa, Fagundes, Coy and Wu, 2008; Honorato, Cherman, Lee, Monard and Chung, 2008), quanto a baseada em ontologia (Costa, Ferrero, Lee, Coy, Fagundes and Chung, 2009; Costa, Ferrero, Lee, Coy, Fagundes and Chung, 2010). A ontologia se apresenta como uma estrutura de dados mais flexível e representativa para a aplicação do método de mapeamento de laudos médicos em relação ao DC. É possível observar essa característica na Figura 3.10, na qual no DC a relação local-característica e/ou

68 42 local-característica-subcaracterística, bem como os atributos e seus respectivos valores são representados em uma única classe, o que se caracteriza como uma estrutura de dados com pouca flexibilidade para representação do conhecimento. Nesse sentido, caso seja necessária a descrição de RM mais complexa e/ou em outros formatos, pode ser necessária a alteração de toda a estrutura do DC ou a geração de um novo esquema. Com a substituição do DC por uma ontologia, o problema de representação do conhecimento é amenizado, pois cada tipo de termo é descrito por uma classe específica, facilitando o reaproveitamento dessa estrutura para a elaboração de RM em diversos formatos. No entanto, como apresentado anteriormente, todas as técnicas utilizadas no PMLM devem ser executadas manualmente e separadamente em todas as suas etapas, dificultando, principalmente, o seu uso por profissionais que não são da área computacional ou que não conheçam detalhadamente o processo. O desenvolvimento de um sistema computacional para automatizar e facilitar o uso do processo é portanto de grande valia. Para a construção de um sistema confiável e com qualidade, é necessária a aplicação de abordagens sistemáticas e disciplinadas de engenharia de software. Sendo assim, no Capítulo 4 são apresentados métodos de engenharia de software que visam orientar na construção de sistemas computacionais.

69 Capítulo 4 Desenvolvimento de Sistemas Computacionais 4.1 Considerações Iniciais Atualmente, os Sistemas Computacionais (SC) 1 apresentam grande importância no cenário mundial, sendo indispensável para os negócios, a ciência, a engenharia e a criação de novas tecnologias. O SC está embutido em diferentes domínios, como médico, militar, transporte, comunicação, industrial, entretenimento, entre outros. Esses sistemas são produtos resultantes da aplicação de processos de engenharia de software para a execução de um conjunto de instruções, que são realizados sequencialmente para a manipulação de informações (Pressman, 2011). A engenharia de software consiste em uma área da computação relacionada com a produção de software, focada na sua especificação, desenvolvimento e manutenção, definição e aplicação de tecnologias e métodos adequados, gerenciamento de projetos e outras atividades com a finalidade de garantir a organização, a produtividade e a qualidade na construção do software (Sommerville, 2009). O processo de desenvolvimento de software pode ser realizado por meio de vários modelos de processos que são aplicados de acordo com o tamanho da equipe de desenvolvimento, a complexidade dos requisitos, o nível de risco do projeto e o domínio do problema a ser resolvido (Pfleeger, 2004). Sendo assim, na Seção 4.2 são apresentados alguns conceitos e um exemplo de processo de software. Após, são apresentadas as principais tarefas dos processos de software, como a atividade de levantamento de requisitos (Seção 4.3). Na Seção 4.4 é apresentada a atividade de projeto de SC. Na Seção 4.5 é abordada a atividade de codificação dos requisitos de software e na Seção 4.6 são descritas algumas técnicas de testes de SC. 1 Neste trabalho, sistema, software e programa são considerados sinônimos. 43

70 Processo de Software O processo de software, também denominado ciclo de vida de software, consiste em um conjunto de atividades necessárias para a construção de um SC. Esse conjunto de atividades é executados de forma sequencial, gerando como produto final um SC. Atividade é uma fase do processo de software caracterizada como um grupo de tarefas imprescindíveis para atingir um objetivo amplo, como o planejamento da construção do programa. A tarefa é concentrada em um objetivo pequeno e bem definido, por exemplo, a escolha de tecnologias para o desenvolvimento da solução computacional (Pfleeger, 2004; Sommerville, 2009). Basicamente, um processo de software é constituído por cinco atividades (Pressman, 2011): Comunicação: são realizadas reuniões em conjunto com os interessados no projeto para identificar e compreender as necessidades dos futuros usuários por meio do levantamento de requisitos para a definição das características que deverão ser atendidas pelo sistema; Planejamento: são descritas as tarefas técnicas a serem desempenhadas, os riscos possíveis, os recursos necessários, o cronograma de trabalho e os resultados esperados; Modelagem: são criados os modelos computacionais e/ou gráficos para facilitar a compreensão das necessidades do usuário e como as mesmas deverão ser atendidas; Construção: é gerado o código-fonte do SC com base nas especificações do planejamento e nos modelos construídos, bem como são elaborados testes com o objetivo de identificar os erros na codificação; Emprego: o SC é entregue aos usuários finais, que o avaliam e fornecem um feedback. Nesse sentido, o processo de software é aplicado de modo iterativo e interativo, no qual cada iteração do processo resulta em um incremento do SC. Sendo assim, é importante ressaltar que todos processos de software tem como entrada a definição das necessidades do usuário e como saída uma versão do programa. O ciclo de desenvolvimento de software é comumente repetido várias vezes, na medida em que o requisitos são incrementados, atualizados ou removidos (Pfleeger, 2004). Para oferecer suporte às atividades do processo de software no decorrer da execução do projeto, podem ser realizadas algumas atividades de apoio (Pressman, 2011), como: Controle e acompanhamento do projeto, no qual é avaliada a evolução do desenvolvimento do projeto, tomando medidas necessárias para o cumprimento do cronograma de execução;

71 45 Administração de riscos, em que são avaliados possíveis problemas que possam afetar no resultado e/ou na qualidade do sistema; Garantia de qualidade, que conduz tarefas para garantir o desenvolvimento de software que atenda satisfatoriamente as especificações levantadas; Revisões técnicas, na qual são avaliados todos os documentos da engenharia de software, também denominados artefatos, com o objetivo de identificar os possíveis erros para evitar problemas na aplicação das atividades seguintes; Medição, que determina critérios para medir a qualidade e o progresso do SC, podendo ser utilizadas nas demais atividades do processo de software; Gerenciamento de configuração, que tem o propósito de controlar os efeitos das mudanças ao longo da aplicação do processo; Gerenciamento da reusabilidade, em que são definidos os critérios para o reuso dos artefatos e estabelecidos mecanismos para o uso dos componentes reutilizáveis; Produção de artefatos, que define as tarefas necessárias para elaborar artefatos, como modelos, documentos textuais, diagramas, formulários, código-fonte, entre outros. No entanto, um único modelo de processo de software não é adequado para a aplicação em todos projetos de sistemas. Nesse sentido, os processos de software podem ser aprimorados mediante padronizações dos mesmos, que são denominados modelos de processo, os quais são representações abstratas do processo de software, representando-o em uma determinada perspectiva (Sommerville, 2009). O objetivo de um modelo processo de software é guiar, de modo sistemático, a aplicação das tarefas fundamentais para garantir a construção de um sistema que atenda aos objetivos do projeto e as necessidades dos usuários por intermédio da definição de um conjunto de tarefas a serem executadas, a entrada, a saída, as condições, a sequência e o fluxo de cada tarefa (Tsui and Karam, 2013). Assim, na literatura foram propostos vários modelos de processo de software, os quais são utilizados de acordo com o tipo e a complexidade dos requisitos, como o modelo ágil de desenvolvimento por prototipagem, que é apresentado seguir. Modelo de Desenvolvimento de Sistemas por Prototipagem Prototipagem é uma abordagem da engenharia de software para construção de soluções computacionais de modo ágil. Esse modelo se apresenta adequado quando os requisitos são considerados complexos e há a necessidade de maior participação dos usuários no processo de desenvolvimento do sistema (Pressman, 2011). Na Figura 4.1 é ilustrado o ciclo do modelo de desenvolvimento por prototipagem, que é constituído de cinco etapas:

72 46 1. Comunicação: é realizado o levantamento de requisitos por meio de reuniões em conjunto com os interessados no projeto para definir as funcionalidades que deverão ser exercidas pelo novo SC; 2. Plano rápido: os requisitos levantados na etapa anterior são analisados e estudados com a finalidade de verificar a viabilidade do desenvolvimento de um software. Em seguida, é realizado um planejamento rápido para a construção de uma solução computacional. Assim, são estruturadas as necessidades dos usuários por intermédio da interpretação dos requisitos e são estudados os métodos e tecnologias existentes que podem prover apoio no desenvolvimento do software; 3. Modelagem: a partir das especificações levantadas nas etapas anteriores, são criados modelos com a finalidade de facilitar a compreensão dos requisitos; 4. Construção do protótipo: o software é implementado por meio de uma linguagem de programação apoiado por um ambiente de desenvolvimento e de outras ferramentas computacionais. Durante e após a codificação, são realizados testes no sistema com a finalidade de identificar e corrigir erros que podem afetar o desempenho do processamento, a integridade e a segurança dos dados; 5. Avaliação e feedback: o SC é entregue aos usuários finais, os quais verificarão se foram atendidos satisfatoriamente os requisitos levantados. Após a avaliação, os usuários fornecem feedback com sugestões definindo os requisitos que devem ser incluídos, removidos e/ou alterados. Figura 4.1: Modelo de desenvolvimento por prototipagem (Modificado de Pressman (2011)). Na Figura 4.1, é possível observar que a construção do sistema é iniciada com um conjunto simples de requisitos. No decorrer da execução do ciclo de desenvolvimento, os requisitos são ajustados e detalhados. O planejamento para a construção da solução computacional é aprimorado por meio do desenvolvimento de modelos. Ao final, o SC é implementado utilizando uma linguagem de programação e após a realização de testes, o mesmo é entregue aos usuários para avaliação e validação. Assim, cada atividade do ciclo pode ser repetida inúmeras vezes na medida em que novos requisitos são levantados e erros são encontrados (Pfleeger, 2004).

73 Levantamento de Requisitos O levantamento de requisitos é realizado por meio de reuniões em conjunto com usuários e/ou outros interessados no projeto com o objetivo de estabelecer as necessidades que devem ser atendidas em um SC (Pfleeger, 2004). Essa fase de construção de software ocorre no início do ciclo de desenvolvimento, podendo ser repetidas mais de uma vez, até atender satisfatoriamente as especificações levantadas, dependendo do modelo de construção de sistema abordado. Na engenharia de software, requisitos são descrições das funcionalidades que o programa deve oferecer, as quais são documentadas e revisadas no decorrer do desenvolvimento do projeto do SC (Sommerville, 2009). Essas descrições podem ser do tipo explícito, normativo ou implícito (Filho, 2009). Os requisitos explícitos são descritos, em linguagem natural, em documentos textuais. Os requisitos normativos descrevem as aplicações que devem seguir normas impostas por leis, padrões, regras, entre outros. Os requisitos implícitos são as funções esperadas por clientes que não são documentadas, como tratamento de segurança de dados, desempenho, entre outros. Dessa maneira, os requisitos são geralmente classificados em dois tipos: funcionais e não-funcionais (Pressman, 2011; Sommerville, 2009). Os requisitos funcionais são relacionados diretamente com as funcionalidades do sistema, isto é, definem a entrada de dados, o comportamento do SC e a saída de dados. Esses requisitos incluem o processamento de dados, a realização de cálculos, entre outras aplicabilidades que o programa deverá atender. Os requisitos não-funcionais descrevem as restrições de uso do software, tais como segurança, desempenho, tecnologias auxiliares, entre outros. Nesse contexto, o final dessa fase resulta em um conjunto de requisitos. Entretanto, no decorrer da construção do software podem haver mudanças e alternativas na medida em que ocorrem diálogos com os usuários durante todas as etapas de cada ciclo de desenvolvimento. Com isso, é importante ressaltar que, para a produção bem sucedida de uma solução computacional é imprescindível a compreensão detalhada dos requisitos, sendo que um levantamento deficiente pode influenciar negativamente nas fases seguintes da elaboração do sistema (Pfleeger, 2004). 4.4 Projeto de Software Antes da elaboração do projeto de software, os requisitos levantados inicialmente são analisados e estudados detalhadamente com a finalidade de verificar a viabilidade tecnológica e econômica para o desenvolvimento de uma solução computacional que atenda as especificações desses requisitos (Pressman, 2011). Caso seja viável a construção, é iniciada a elaboração do projeto do SC, bem como são definidas as tecnologias necessárias para esse fim.

74 48 O projeto de software tem o objetivo de traduzir os requisitos para documentos em formatos textuais e/ou gráficos, definindo como o sistema deve ser desenvolvido. Assim, são definidas as tarefas que serão desempenhadas pelo programa, os riscos possíveis do desenvolvimento do projeto, a arquitetura do SC, os elementos da interface, os recursos necessários para a implementação da solução computacional, o cronograma de execução do trabalho, entre outras (Braude, 2005). Para melhor descrição dos requisitos do programa, cinco modelos de projeto podem ser aplicados simultaneamente (Pressman, 2011): Projeto de dados/classes: definição de modelos de dados, também denominado estrutura de dados, que serão manipulados pelo sistema; Projeto arquitetural: definição dos tipos de relacionamentos entre modelos de dados, a arquitetura do SC e os padrões de projeto que podem ser aplicados para atender as especificações levantadas anteriormente; Projeto de interface: tem a finalidade de determinar o modo de interação da solução computacional com outros softwares e com os usuários que o utilizarão; Projeto em nível de componente: descreve o comportamento de cada elemento do SC, isto é, os algoritmos para o processamento de dados que ocorre em um elemento e/ou em uma interface que executa todas as operações desses componentes; Projeto em nível de implantação: determina os recursos tecnológicos necessários para a implantação do sistema, como o ambiente computacional físico e os subsistemas que irão interagir com o novo software. Nesse contexto, o gerenciamento de projetos consiste em uma tarefa essencial para a construção de software e tem o propósito de assegurar que essa tarefa seja realizada corretamente. Para o gerenciamento de projetos de sistemas, são comumente executadas as seguintes atividades: preparação da proposta; planejamento do desenvolvimento; elaboração do cronograma; estimativa de custos e de riscos; monitoração e revisões de projeto; seleção e avaliação de integrantes; preparação de relatórios; e apresentações dos resultados (Sommerville, 2009). O gerenciamento de projetos pode ser aplicado em quatro fases (Tsui and Karam, 2013), que são apresentadas na Figura 4.2. Na fase de planejamento, são determinados os resultados esperados do projeto, o cronograma de execução, os recursos necessários, as metas a serem alcançadas, as medidas de qualidade e os riscos do projeto. Na fase de organização, são definidos os mecanismos para o monitoramento das tarefas e do cronograma, os recursos imprescindíveis para o desenvolvimento do projeto, os meios para mensurar e monitorar os objetivos e as medidas para listar, acompanhar e minimizar os riscos. Na fase de monitoramento é acompanhada a execução do projeto para verificar se a construção do mesmo está progredindo como planejado. Essa fase

75 49 Figura 4.2: Processo de gerenciamento de projetos (Modificado de Tsui and Karam (2013)). é realizada por meio da coleta de informações do projeto, da análise dos dados coletados e da apresentação das informações por intermédio de reuniões com os envolvidos. Na fase de ajuste, são realizadas as alterações no projeto para adequá-lo com os novos requisitos, os problemas encontrados durante a elaboração do software, entre outros. Também, outras técnicas e ferramentas podem ser utilizadas para o desenvolvimento de projetos de software, como a Unified Modeling Language (UML) 2, que é uma linguagem padrão de modelagem, de especificação e de documentação de SC, comumente utilizada para esse fim. Nessa linguagem, são desenvolvidos diversos diagramas, dos quais cada tipo de diagrama é utilizado para representar diferentes partes e detalhes do SC com a finalidade de eliminar ou minimizar possíveis erros de projeto (Miles and Hamilton, 2006). 4.5 Implementação A maioria dos projetos de engenharia de software tem o intuito de construir um SC funcional (Tsui and Karam, 2013). Nesse sentido, na etapa de implementação, os requisitos e os modelos computacionais são codificados por meio de uma linguagem de programação com suporte de um ambiente de desenvolvimento (Pressman, 2011). Para essa tarefa, existem várias linguagens de programação que são utilizadas para construção de programas de acordo com as necessidades dos usuários, como Java 3, Ruby 4, Python 5, entre outras. A implementação de sistemas pode ser facilitada com o uso de ambientes de desenvolvimento e de outras ferramentas computacionais, auxiliando e automatizando a tarefa de geração de código-fonte

76 50 Durante a etapa de construção do programa, os desenvolvedores devem escrever o códigofonte de forma simples e compreensível, adotando padrões de programação das linguagens utilizadas para reduzir custos e facilitar as atividades de manutenção, de revisão e de reuso. Assim, para a codificação de softwares, alguns aspectos gerais de programação devem ser considerados, tais como: conjuntos de algoritmos que devem ser utilizados para atender os requisitos do usuário; entrada e saída de dados para o uso dos algoritmos; estruturas de controle para coordenar o fluxo de dados do sistema; estrutura de dados para organizar os algoritmos e simplificar a construção do SC; revisões do código-fonte com a finalidade de aprimorá-lo; e reutilização de códigos-fonte desenvolvidos em outros projetos para facilitar a elaboração da solução computacional. Também, o código-fonte dever ser documentado para facilitar a compreensão da lógica interna do software, auxiliando nas manutenções futuras do mesmo (Pfleeger, 2004). De acordo com Tsui and Karam (2013), para uma boa codificação de sistemas, os desenvolvedores devem considerar as seguintes características: Legibilidade: o código-fonte deve ser escrito de forma que facilite a sua leitura e compreensão por outros desenvolvedores; Manutenibilidade: o código-fonte deve ser facilmente alterado e mantido; Desempenho: os algoritmos devem ser produzidos de modo que a sua execução seja realizada o mais rápido possível; Rastreabilidade: o código do sistema deve corresponder a um elemento de design, ou seja, garantir que o software seja desenvolvido corretamente; Exatidão: o código-fonte deve ser escrito para fazer exatamente as tarefas para o qual foi construído; Integralidade: todos os requisitos devem ser atendidos satisfatoriamente. Entretanto, uma codificação mal realizada e mal documentada pode implicar na geração de um software deficiente, mesmo funcionando corretamente, dificultando a realização de alterações, o reuso dos componentes de software em outros projetos e a compreensão da lógica interna por outros integrantes do projeto (Tsui and Karam, 2013). 4.6 Testes de Software O teste de software é um conjunto de tarefas projetadas antecipadamente para desempenhar as funcionalidades do sistema com o propósito de identificar erros que influenciam no funcionamento correto dos algoritmos, tal como na integridade e na segurança dos dados processados pelo programa (Pressman, 2011).

77 51 A realização de testes em SC consiste em uma tarefa complexa e altamente custosa, representando cerca de 50% a 80% do custo total do desenvolvimento do projeto. Os testes de software são utilizados de forma controlada para verificar a concordância de suas funcionalidades em relação às especificações levantadas e expôr as suas falhas de forma antecipada à sua entrega ao usuário final (Sommerville, 2009). Nesse contexto, foram propostas várias abordagens para a avaliação de sistemas, as quais são divididas em testes dos tipos caixa-branca, caixa-preta e e caixa-cinza. O teste caixa-branca, também denominado teste estrutural ou orientado à lógica, tem o objetivo de avaliar a lógica interna dos componentes de um determinado SC. O teste caixa-preta, igualmente denominado teste funcional, orientado a dados ou a entrada/saída, tem a finalidade de avaliar o comportamento do programa em relação à entrada de dados e são conduzidas por meio de uma interface gráfica. O teste caixa-cinza consiste na combinação das técnicas caixa-branca e caixa-preta para a avaliação do SC (Myers, Badgett, Sandler and Thomas, 2004; Sommerville, 2009; Tsui and Karam, 2013; Lewis, 2008). Geralmente, as avaliações de software são realizadas em várias etapas: teste de unidade, teste de integração, teste de sistema e teste de aceitação. Essas etapas são ilustradas na Figura 4.3 e apresentadas em seguida. Figura 4.3: Etapas do teste de software (Jung, 2012). O teste de unidade tem o intuito de avaliar isoladamente cada membro do SC. Essa abor-

78 52 dagem é focada na lógica interna do processamento e nas estruturas de dados que envolvem um componente e pode ser aplicado em paralelo com outros testes de unidade (teste de integração). O planejamento do teste unitário pode ser realizado antes, durante e depois da codificação do sistema (Pressman, 2011). O teste de integração é uma técnica utilizada para identificar falhas de agregação dos membros de SC testados anteriormente, isto é, os componentes são combinados e avaliados em grupo. Esse teste tem o propósito de avaliar os requisitos funcionais, o desempenho e a modelagem da solução computacional para descobrir erros relacionados com a interface. Para isso, foram propostas várias abordagens, das quais se destacam as técnicas bottom-up e topdown (Pfleeger, 2004). O teste bottom-up é uma abordagem incremental que avalia os elementos do programa hierarquicamente, começando com pequenos grupos de componentes combinados, nos quais são incrementados alguns elementos (unidades de componentes e/ou outros grupos) no decorrer da evolução dos testes, até que todos os componentes estejam integrados a um único grupo. O teste top-down é o inverso de bottom-up, ou seja, a avaliação é iniciada com todos os componentes integrados em um único grupo, o qual é fragmentado em pequenos grupos até que todas as falhas identificadas serem isoladas. O teste de sistema é aplicado para avaliar o SC como um todo por meio da execução de todas as suas funcionalidades, sob o ponto de vista do usuário final. Esse tipo de teste engloba diversos tipos de avaliações que são vantajosas para a construção de SC (Pressman, 2011), tais como: teste de recuperação, que é executado para forçar o programa de várias maneiras para falhar e verificar se a recuperação de falhas é realizada corretamente; teste de segurança, que é utilizado para examinar os métodos de proteção usados na solução computacional com o propósito de garantir que os dados dos usuários estejam protegidos de acessos indevidos; teste por estresse, que avalia o SC em situações anormais, como a demanda de recursos em termos de quantidade, frequência e/ou intensidades consideradas anormais; teste de desempenho, o qual é usado com o objetivo de assegurar que o sistema pode operar o volume necessário de dados, que é aumentado até o comportamento do SC ser considerado inaceitável e é realizado em todas as etapas de testes; e teste de disponibilização, que examina a operação do software em diferentes tipos de plataformas. O teste de aceitação é focado nas atividades que serão desempenhadas pelo usuário. Para isso, são definidos os critérios a serem considerados na validação por intermédio de um plano de avaliação que define os tipos de testes que serão conduzidos com o intuito de garantir que todos os requisitos sejam atendidos satisfatoriamente, todas as características comportamentais anormais sejam identificadas e que todos os dados originados pelo sistema sejam confiáveis e apresentados adequadamente. Nesse sentido, os testes de aceitação são realizados inicialmente por desenvolvedores em ambiente controlado e são caracterizados como testes alpha. Após a realização dos testes e correção dos erros identificados pelos desenvolvedores, o SC é entregue aos usuários finais para avaliarem as suas funcionalidades com a finalidade de identificar erros

79 53 que não foram identificados pelos desenvolvedores. Essa avaliação é também conhecida como teste beta (Sommerville, 2009). Desse modo, os testes são realizados enquanto os erros forem encontrados e solucionados. Assim, quando as avaliações forem bem-sucedidas, o sistema é entregue aos usuários. Entretanto, podem ser necessárias algumas adaptações para o melhor aproveitamento e funcionamento da solução computacional, como o treinamento dos usuários e a aquisição de hardware e software (Laudon and Laudon, 2007). 4.7 Considerações Finais Para a construção de SC, o processo de software apresenta-se como uma abordagem de grande importância para o sucesso do projeto, o qual é uma ferramenta relevante para o desenvolvimento de uma solução computacional de qualidade, pois possibilita a organização das atividades a serem ministradas, o estudo e a análise dos riscos, o gerenciamento de equipes, a estipulação de custos, entre outros. Para o êxito e a entrega do sistema dentro do prazo estipulado, é necessário que cada atividade do processo seja realizada cuidadosamente, desde a iniciação até o final do projeto, de modo que garanta a entrega de um produto de qualidade satisfatória e que facilite a realização de manutenções futuras. Outro recurso importante para a construção de programas é o uso da UML, que facilita a compreensão e o registro exato dos requisitos por meio da elaboração de modelos e de diagramas. Neste trabalho foi utilizado o modelo ágil de desenvolvimento de sistemas por prototipagem devido à complexidade dos requisitos e a necessidade do envolvimento de especialistas do domínio para acompanhar a construção de um Sistema Computacional Colaborativo (SCC) com a finalidade de automatizar o Processo de Mapeamento de Laudos Médicos (PMLM). No Capítulo 5 são apresentadas as tecnologias que foram utilizadas para o desenvolvimento do SCC para a automatização do PMLM apresentado neste trabalho.

80 54

81 Capítulo 5 Ferramentas e Tecnologias 5.1 Considerações Iniciais Uma área tecnológica em crescente evolução é o de desenvolvimento de sistemas web devido à facilidade e a agilidade no seu uso, pois não são necessários computadores sofisticados, bem como é dispensável a instalação de softwares específicos e a configuração da máquina para utilizar um sistema web. Outra vantagem é a não ocupação de espaço no disco ou em outro dispositivo de armazenamento do usuário. Com essas características, o usuário pode acessar o sistema por meio de computadores, sendo necessário apenas que um navegador web como o Mozila Firefox 1, o Opera 2, o Internet Explorer c, ou o Google Chrome 3 esteja instalado na máquina do usuário e que haja acesso à Internet. Para a construção de sistemas web é necessário o uso combinado de diversos tipos de tecnologias, tais como: linguagens de programação, de marcação e de estilo; ambientes de desenvolvimento; frameworks; e infraestrutura física, como servidores, redes de computadores, entre outros. Para o uso dessas tecnologias, é imprescindível o conhecimento técnico por parte dos desenvolvedores para possibilitar a construção de sistemas web eficientes e que atendam às especificações de seus usuários, bem como deve ser considerado o uso de diferentes tipos de navegadores web, pois cada navegador possui características específicas que podem influenciar no funcionamento correto desses sistemas (Jung, 2012). Desse modo, neste capítulo são apresentadas as principais ferramentas e as tecnologias utilizadas pelo Processo de Mapeamento de Laudos Médicos (PMLM) e as que são necessárias para o desenvolvimento do Sistema Computacional Colaborativo (SCC) para automatizar a utilização do método. Nas Seções 5.2 e 5.3 são apresentadas algumas características das linguagens de progra

82 56 mação Java e Ruby, respectivamente. Na Seção 5.4 é apresentado o principal framework da linguagem Ruby que é aplicado na construção de sistemas web. Na Seção 5.5 é descrito um dos ambientes de desenvolvimento de softwares mais utilizados na atualidade por desenvolvedores de software. Na Seção 5.6 é apresentada a linguagem de programação comumente aplicada na elaboração de métodos de processamento de textos denominada Perl. Nas Seções 5.7 e 5.3 são descritas as linguagens de marcação HTML e XML. Na Seção 5.9 é apresentada a linguagem de estilo denominada CSS, que é comumente utilizada para a modelagem de layout de documentos HTML e XML. Na Seção 5.10 é explanada a linguagem de programação Javascript, que é frequentemente usada no tratamento de eventos relacionados com a interação de páginas web com usuários. 5.2 Linguagem de Programação Java Java é uma das linguagens de programação mais utilizadas para o desenvolvimento de Sistemas Computacionais (SC), devido à ampla variedade de recursos disponíveis (Deitel and Deitel, 2010). Essa linguagem, foi construída na década de 90 por desenvolvedores liderados por James Gosling, na empresa Sun Microsystems 4. Diferentemente de outras linguagens, o código-fonte escrito em Java é traduzido para um formato intermediário de código, denominado bytecode, que é interpretado por uma Máquina Virtual Java (MVJ), a qual tem como finalidade converter os bytecodes para um código executável por máquinas, bem como gerenciar aplicações desenvolvidas na linguagem Java. Com a MVJ, os softwares escritos em Java podem ser executados em qualquer sistema operacional que contém uma MVJ instalada (Lindholm, Yellin, Bracha and Buckley, 2013). Assim, nessa linguagem podem ser destacadas algumas características: paradigma de programação orientado a objetos; independência de plataforma, isto é, o software desenvolvido nessa linguagem pode ser executado em qualquer sistema operacional; extensa biblioteca de ferramentas para auxiliar na construção de sistemas, recurso necessário para projetos que apresentam requisitos complexos para o seu desenvolvimento; simplicidade e eficiência para a construção de softwares, sem a necessidade do gerenciamento de memória por código, reduzindo possibilidades de erros de programação; desalocação automática de memória por meio do processo denominado coleta de lixo (garbage collector) (Deitel and Deitel, 2010). Para facilitar a construção de SC por intermédio da linguagem Java, foram desenvolvidas várias ferramentas e bibliotecas. Na Sun Microsytems, foi criado o pacote de ferramentas denominado Java Development Kit (JDK), que contém bibliotecas e outros recursos necessários para a escrita de código-fonte de softwares. Também, foi desenvolvido o Java Runtime Environment 4

83 57 (JRE), o qual é uma biblioteca que inclui a MVJ e outros recursos para a execução de sistemas Java (Gosling, Joy, Steele and Bracha, 2005). Foram construídos também diversos ambientes de desenvolvimento, denominados Integrated Development Environment (IDE), que têm o propósito de reunir os principais recursos para a construção de softwares em Java, tais como JDK, JRE, entre outras ferramentas e bibliotecas (Boudreau, Glick and Spurlin, 2002). Um dos IDE mais populares entre os desenvolvedores para a implementação de SC em Java é o NetBeans 5, que é apresentado na Seção Linguagem de Programação Ruby Ruby é uma linguagem dinâmica de código aberto focada na simplicidade e na produtividade para a elaboração de sistemas que foi criada em 1995 por Yukihiro "Matz" Matsumoto, o qual tinha como objetivo desenvolver uma linguagem de script mais poderosa do que Perl e mais orientada a objetos do que a linguagem Python 6, combinando a programação funcional com a programação imperativa. Assim, a linguagem Ruby consiste na combinação das linguagens Perl, Smalltalk, Eiffel, Ada e Lisp. Atualmente, essa linguagem se encontra na versão 2.0 e é disponível para diversas plataformas, como Windows c, GNU/Linux, Mac OS, Solaris, entre outros (Metz, 2012). A linguagem Ruby apresenta as seguintes características: todos os elementos utilizados são considerados objetos, incluindo números e outros tipos de dados primitivos; o gerenciamento de memória é realizado de modo automático; a linguagem é dinâmica e forte, permitindo o uso de variáveis sem a necessidade de declará-las ou pré-determiná-las; possui sintaxe intuitiva, o que facilita a compreensão do código-fonte; utiliza caracteres especiais para determinar a condição de uma determinada variável, como "$" e "@", os quais indicam que as variáveis são globais e de instância, respectivamente; e a possibilidade de desenvolvimento de ferramentas e de disponibilizá-las em formato padrão de pacote de código, também denominado gem (Carlson and Richardson, 2006). Também, para a linguagem Ruby existem várias implementações alternativas, como o JRuby 7, que foi escrito na linguagem de programação Java para funcionar em MVJ e possibilitar o uso dos recursos dessa linguagem sem a necessidade da instalação de gems e configuração do computador para viabilizar o uso de ferramentas e/ou outros recursos desenvolvidos nessa linguagem por sistemas construídos em Ruby. JRuby foi desenvolvido em 2001 por Jan Arne Petersen e atualmente se encontra na versão 1.7.4, o qual oferece suporte para Ruby 2.0. O JRuby possibilita o reconhecimento de código escrito em Java e a utilização de classes da pla

84 58 taforma Java no interpretador Ruby (Nutter, Enebo, Sieger, Bini and Dees, 2011). É importante ressaltar que a linguagem Ruby obteve maior aceitação no mercado devido, principalmente, ao desenvolvimento do framework denominado Ruby on Rails 8, o qual também é compatível com o JRuby. Esse framework é apresentado na próxima seção. 5.4 Framework Ruby on Rails Ruby on Rails (RoR) consiste em um framework de código aberto e de uso gratuito que tem o intuito de agilizar a construção de sistemas web por meio de estruturas pré-definidas, baseada no modelo de desenvolvimento ágil de sistemas. Esse framework foi lançado no ano de 2004 por David Heinemeier Hansson, mas os direitos para o compartilhamento do projeto foram disponibilizados apenas em 2005 (Ruby, Thomas, Hansson, Breedt, Clark, Davidson, Gehtland and Schwarz, 2011). Atualmente, o RoR se encontra na versão A arquitetura do RoR segue os preceitos do padrão Model-View-Controller (MVC), o qual tem o objetivo de organizar o código-fonte do sistema web em três camadas: model, que determina e gerencia as informações processadas pelo SC; view, que apresenta as informações do model de forma que seja útil ao usuário por intermédio de uma interface; e controller, que tem a finalidade de receber a entrada de dados, processá-la e apresentar os resultados ao usuário (Saint-Laurent, Dumbill and Gruber, 2012). Na Figura 5.1 é ilustrado o padrão MVC, em que as setas contínuas representam o relacionamento direto entre os componentes MVC e a seta tracejada representa o relacionamento indireto entre model e view. Figura 5.1: Padrão MVC (Modificado de Ruby, Thomas, Hansson, Breedt, Clark, Davidson, Gehtland and Schwarz (2011)). Assim, o framework RoR segue os seguintes princípios (Holzner, 2006; Húngaro, 2013): 8

85 59 Não se repita (Don t Repeat Yourself - DRY): determina mecanismos para evitar a necessidade de repetição do código em diversas partes do sistema; Convenção sobre configuração (convention over configuration): define padrões para a construção de sistemas com a finalidade de reduzir a necessidade de elaborar configurações para o funcionamento do mesmo, possibilitando que o desenvolvedor se preocupe apenas com a solução do problema; Controladores magros e modelos gordos (tiny controllers, fat models): estimula o hábito de limitar as tarefas de um determinado domínio de um problema aos modelos e as tarefas de controle do fluxo de dados aos controladores; Mantenha simples, estúpido! (Keep It Simple, Stupid - KISS): baseado em um princípio de origem militar, determina que a simplicidade deve ser o foco do projeto e toda a complexidade deve ser desconsiderada ou reduzida; Você não vai precisar disso (you ain t gonna need it): define que nenhuma funcionalidade dispensável deve ser adicionada ao sistema; Desenvolvimento iterativo e incremental (iterative and incremental development): é a base dos métodos ágeis de construção de sistemas em que o ciclo de desenvolvimento pode ser repetido várias vezes e para cada repetição de ciclo é adicionado pelo menos uma funcionalidade; Desenvolva menos (build less): resultado de todos os princípios e práticas apresentados anteriormente, possibilita a redução do processo de construção de sistemas. Nesse sentido, RoR oferece diversos mecanismos para facilitar a construção de SC por meio da automatização de várias tarefas, como o comando generate, que é aplicado para gerar componentes do sistema. Neste comando, podem ser incluídas outras instruções para a geração de componentes no Padrão MVC, como o scaffold, que tem o intuito de gerar uma parte do sistema no padrão MVC com toda a estrutura CRUD (Create, Read, Update, Delete), que são as operações básicas para manipulação de dados de um sistema, como criar, ler ou visibilizar, atualizar e excluir (Griffiths, 2009). Também,o RoR oferece suporte para o uso de diversos bancos de dados, como PostgreSQL, MySQL, Oracle, entre outros (Ruby, Thomas, Hansson, Breedt, Clark, Davidson, Gehtland and Schwarz, 2011). 5.5 Ambiente de Desenvolvimento NetBeans Inicialmente sob o nome Xelfi 9, o projeto do NetBeans foi iniciado em 1996 e tinha a finalidade de agregar funcionalidades semelhantes aos disponíveis nos IDE populares da lingua- 9

86 60 gem Delphi 10, os quais eram atrativos por serem fáceis de utilizar e também por apresentarem recursos gráficos para facilitar o desenvolvimento de softwares. Em 1997, foi desenvolvida a primeira versão comercial do IDE NetBeans, que foi comprada pela Sun Microsystems em 1999, tornando-o em um IDE gratuito e de código aberto (NetBeans, 2013). Atualmente na versão 7.4, o NetBeans foi construído com o propósito de simplificar e aumentar a produtividade do processo de construção de sistemas. Essa IDE pode ser utilizada em qualquer sistema operacional, pois foi desenvolvida em Java. Também, essa IDE suporta qualquer linguagem de programação como o próprio Java, Python, Ruby, Perl, entre outras (Boudreau, Glick and Spurlin, 2002; Kutler and Leonard, 2008). Assim, é possível a construção de sistemas utilizando várias linguagens simultaneamente, isto é, dependendo da complexidade dos requisitos, pode ser usada mais de uma linguagem em um único projeto de software. Essa IDE possui vários recursos, das quais se destacam: editor de código-fonte com vasta gama de mecanismos para a construção de sistemas web e aplicações visuais para a elaboração de interfaces gráficas; gerador automático de código; ferramentas para a criação de diagramas UML; controle de versão, o qual tem como finalidade manter antigas versões dos arquivos em uma base dados para facilitar a recuperação dos mesmos quando necessário; gerenciamento de bases de dados; integração e/ou reuso de componentes; disponibilidade de servidores de sistemas para web; ferramentas de modelagem de interfaces gráficas; e suporte para a construção de aplicações para dispositivos móveis (Silva, 2005). 5.6 Linguagem de Programação Perl Perl (Practical Extraction and Report Language) 11 é uma linguagem de programação multiplataforma que tem o intuito de facilitar o desenvolvimento de métodos e ferramentas para o processamento de textos, de relatórios e de formulários textuais. Essa linguagem foi desenvolvida por Larry Wall em 1987 com o objetivo de reunir as principais vantagens de tecnologias comumente utilizadas no sistema operacional Unix, como o editor Stream EDitor ( sed ) 12 e as linguagens AWK 13, C 14 e Shell Script 15. Em 1992, na sua quarta versão, Perl tornou-se uma linguagem padrão para o sistema operacional Unix (Schwartz, Phoenix and D Foy, 20011). Recentemente, o Perl se encontra na versão A linguagem Perl segue o preceito "Existe mais de uma maneira para fazer isso" (There s

87 61 More Than One Way To Do It - TMTOWTDI), isto é, para cada tarefa ou problema existem várias formas para solucioná-las, facilitando o desenvolvimento de soluções computacionais e o aprendizado do uso da linguagem por programadores (Wall, Christiansen and Schwartz, 2012). A sintaxe do Perl é semelhante ao do C e possui uma ampla variedade de recursos para realização de tarefas comuns, como a manipulação de arquivos. No código-fonte Perl, todas as variáveis escalares, ou seja, que assumem um valor individual, são precedidas pelo caractere "$". As variáveis vetoriais que representam os conjuntos de valores (arrays) são precedidas pelo caractere "@" e as variáveis associativas, as quais apresentam valores de arrays associativas (tabelas hash), são precedidas pelo caractere "%". Também, todas as versões dessa linguagem gerenciam a memória automaticamente e possuem tipagem dinâmica, uma característica que não exige a declaração de variáveis devido à capacidade de definição do tipo de dado dinamicamente para cada variável (Wainwright, Cozens, Calpini, Corliss and Merelo-Guervos, 2001). Outras vantagens da linguagem Perl são: possibilidade de elaboração de código-fonte rapidamente; disponibilidade de comandos poderosos para processamento de textos; suporte à programação estruturada e à orientada a objetos; disponibilidade para vários sistemas operacionais; facilidade de compreensão da documentação da linguagem; e viabilidade do uso de Expressões Regulares (ER) (Schwartz, Phoenix and D Foy, 20011). Uma das características responsáveis pela popularização da linguagem Perl é a possibilidade do uso de ER, que tem a finalidade de identificar cadeias de caracteres com características de interesse, tais como letras particulares, palavras ou padrões de caracteres (Wall, Christiansen and Schwartz, 2012; Friedl, 2006). Essas expressões são escritas formalmente em uma linguagem que pode ser interpretada por determinados processadores de textos, os quais processam ER por meio de casamento de padrões, que geralmente é realizado com suporte de caracteres especiais, denominados de metacaracteres (Friedl, 2006). Na Tabela 5.1, são apresentados alguns exemplos de metacaracteres e os seus significados. Por exemplo, na ER "ˆ \s*", são identificados todos os espaços em branco no início de uma frase. Em Perl, uma ER é designada entre barras (/) e o casamento de padrões é realizado por meio do operador lógico "= ". Na expressão "$algo = /ˆ \s+ /", por exemplo, o resultado será verdadeiro (true) se a sentença analisada contém no mínimo um espaço em branco no início de uma frase e o resultado será falso (false), caso contrário. Também, podem ser aplicadas operações em ER, como substituição, que é dada por "$algo = s / ER / P /", na qual "s" (substitute) é o caractere que representa a operação de substituição e "P" é a sequência de caracteres que substituirá o padrão encontrado por "ER", como na expressão "$frase = s / ˆ \s* //", a qual elimina os espaços em branco no início de uma frase. No entanto, a expressão "$algo = s / ER / P" elimina apenas uma ocorrência de "ER", sendo que pode haver a necessidade de remover todas as ocorrências. Para isso, na expressão deve ser adicionada ao

88 62 Tabela 5.1: Tabela de exemplos de metacaracteres utilizados em ER (Adaptado de Schwartz, Phoenix and D Foy (20011) e de Intentor (2010)). Metacaractere Significado. Coincidir qualquer caractere * Presença de zero ou mais vezes de um determinado caractere ou conjunto + Presença de um único caractere ou de conjunto no mínimo uma vez {n} Presença de um determinado caractere ou de um conjunto exatamente n vezes {n,m} Presença de um determinado caractere ou um conjunto no mínimo n e máxima de m vezes \ Quando um determinado caractere especial está presente em uma cadeia de caracteres, é utilizado "\" precedido do mesmo [] Agrupamento de expressões () Agrupamento de caracteres ˆ Início de uma linha de texto $ Fim de uma linha de texto \n Nova linha \t Caractere de tabulação \d ou \D Reconhecem apenas dígitos \s ou \S Reconhecem apenas espaços em branco \w ou \W Reconhecem qualquer caractere alfanumérico e o caractere underline ("_") final mais uma barra e um caractere que represente a operação de remoção de todas as ocorrências, acarretando na expressão "$algo = s / ER / P / g", na qual "g" (global) é o caractere que representa todas as ocorrências de "ER", por exemplo, a expressão "$algo = s / - / \s / g" substitui cada caractere -" por um espaço em branco. Neste caso, também pode ser utilizado no final da expressão o caractere "gi" (global ignore), que tem a mesma funcionalidade de "g", mas neste caso, os caracteres maiúsculos não são diferenciados dos minúsculos (Wainwright, Cozens, Calpini, Corliss and Merelo-Guervos, 2001; Schwartz, Phoenix and D Foy, 20011). 5.7 Linguagem de Marcação HTML HyperText Markup Language (HTML) 16 é uma linguagem de marcação utilizada para construção de páginas web que foi criada pelo físico Britânico Tim Berners-Lee com a finalidade de resolver um problema de comunicação e de disseminação de pesquisas entre ele e seu grupo de pesquisadores. Nas primeiras versões dessa linguagem foram definidas regras sintáticas para auxiliar na publicação de documentos na Internet (Castro and Hyslop, 2013). Essa linguagem foi especificada na década de 1990 baseada nas propostas de Tim Berners- Lee para a elaboração de uma linguagem inspirada em Standard Generalized Markup Language (SGML) 17 para a web. A primeira versão do HTML foi publicada em 1993 como uma aplicação do SGML. Após a publicação da versão 3.5 do HTML em 1997, foi iniciado pela Wide

89 63 World Web Consortium (W3C) 18 o desenvolvimento do XHTML 19, que combina as funcionalidades das linguagens HTML e XML (extensible Markup Language) 20 com o propósito de ser o sucessor da linguagem HTML. Em 2008, foi lançado a quinta versão do HTML, também conhecido como HTML5, que é amplamente utilizado atualmente (Pilgrim, 2011; Lubbers, Albers and Dalim, 2013). Para a elaboração de documentos utilizando qualquer versão da linguagem HTML, são utilizadas estruturas de marcação pré-definidas com instruções denominadas etiquetas, marcadores ou tags, que são representadas na forma <nome_do_marcador>. Uma tag contém o seu respectivo nome e opcionalmente possui atributos, os quais são aplicados para alterar os resultados padrões de uma tag por intermédio de valores que definem essas mudanças. Um elemento HTML geralmente contém uma tag de abertura, uma tag de encerramento e conteúdo. Uma tag e abertura é representada na forma <Nome_Tag atributo=valor> e na mesma pode conter inúmeros atributos. Uma tag de fechamento é representada na forma </Nome_Tag> e não comporta atributos. O conteúdo é apresentado entre as duas tags e geralmente são textos, imagens, vídeos ou outros tipos elementos representados pela tag. Assim, um elemento HTML pode ser representado na forma <Nome_Tag att1=valor1 attn=valorn> Conteúdo </Nome_Tag> houver a representação de alguma informação, ou na forma <Nome_Tag atr=valor> </Nome_Tag> ou <Nome_Tag att1=valor1 attn=valorn />, caso contrário (Lawson and Sharp, 2011). A estrutura básica de um documento HTML é definida pelas seguintes tags (Castro and Hyslop, 2013): <html>: é a tag que define o início de um documento HTML; <head>: define o cabeçalho da página e as informações sobre o documento para o navegador web; <body>: determina o conteúdo principal da página web. Nessa tag, são comportados outros marcadores que contém textos, imagens, vídeos, ou outros tipos de dados; <title>: representa o título do documento. Outro componente que faz parte da estrutura básica de um documento HTML é denominado <!DOCTYPE html>, que é geralmente localizada na primeira linha de código do documento, antes das tags básicas. O Doctype tem o intuito de informar ao navegador web ou outros sistemas e ferramentas qual especificação de código deve ser utilizada para a exibição do documento. É importante ressaltar que o Doctype não é uma tag HTML, mas sim uma instrução

90 64 interpretada pelo navegador web para informar sobre a versão do HTML em que o código foi escrito (Lubbers, Albers and Dalim, 2013). Nesse contexto, existem várias tags para a representação e a formatação de dados em páginas web (Pilgrim, 2011). Para formatação de textos, podem ser citados os seguintes exemplos de tag: <p>: determina um novo parágrafo; <b>: formata o texto para negrito; <i>: formata o texto para itálico; <u>: formata o texto para sublinhado; <sub>: formata o texto para subscrito; <sup>: formata o texto para sobrescrito; <h1>, <h2>, <h3>, <h4>, <h5> e <h6>: determina o tamanho dos caracteres, sendo <h1> o maior e <h6> o menor. Na Figura 5.2, é apresentado um exemplo de documento HTML (à esquerda) e a página web equivalente (à direita). Figura 5.2: Exemplo de documento HTML e página web equivalente. Outras tags comumente utilizadas para a representação de dados são: <img>, que tem a finalidade de exibir uma imagem; <a>, que representa um link para uma outra página web; <ul>, <ol> e <dl> para a exibição de listas; <form> para a elaboração de formulários e é composta pelos marcadores <input> (campo de texto para entrada de dados), <button> (botão), <select> (lista de opções para seleção), entre outros; <table> para a apresentação de tabelas e os seus elementos são definidos pelas tags <tr> (coluna), <th> (célula destacada) e <td> (célula comum); entre outras (Castro and Hyslop, 2013; Lawson and Sharp, 2011; Lubbers, Albers and Dalim, 2013).

91 65 No entanto, para a construção de um sistema web, a linguagem HTML é utilizada apenas para a exibição do conteúdo. Para melhorar a visibilização de dados e a organização do conteúdo, bem como tornar a página interativa com os usuários, é necessário o uso de outras tecnologias para aprimorar o documento HTML, como uma linguagem de estilo para definir como as informações devem apresentadas e uma linguagem de programação para tornar a página interativa. 5.8 Linguagem de Marcação XML extensible Markup Language (XML) é uma linguagem de marcação utilizada para representar tipos de dados e organizá-los hierarquicamente. O principal objetivo do XML é facilitar, simplificar e generalizar o compartilhamento de informações por meio da Internet. Essa linguagem é o resultado de um projeto da W3C desenvolvido na década de 1990 que tinha o propósito de desenvolver uma linguagem de marcação que combinasse a flexibilidade da SGML com a simplicidade da HTML e que pudesse facilitar a comunicação entre sistemas construídos em linguagens de programação diferentes (Bray, Paoli, Sperberg-McQueen and Maler, 1996). Assim como o HTML, a linguagem XML utiliza tags para representar dados, no entanto, o XML possibilita a criação de marcadores para a representação de informações, ao contrário de HTML, que tem um repertório limitado de tags. Também, essas linguagens foram desenvolvidas para atender as especificações de diferentes alvos, sendo que o XML é focado no transporte e no armazenamento de dados e o HTML na exibição de dados. Outra diferença entre essas linguagens é que a declaração de um documento HTML é dada por <!DOCTYPE html> e a de um documento XML é <?xml version="1.0" encoding="utf-8"?>, no qual o atributo version define a versão da linguagem e o encoding determina o modo de codificação de caracteres (Harold, 1998; Deitel, 2012; Lubbers, Albers and Dalim, 2013). Na Figura 5.3 é apresentado um exemplo de estrutura de documento XML para a representação de informações bibliográficas de trabalhos científicos. Desse modo, o uso da linguagem XML apresenta os seguintes benefícios: operações de buscas mais eficientes; construção de aplicações flexíveis para a web; integração de dados em formatos diferentes; facilidade na manipulação de dados; várias maneiras de visibilizar os dados; fácil distribuição na Internet; facilidade na compreensão do conteúdo de documentos representados nessa linguagem; baseado em textos simples; suporta o padrão representação de caracteres Unicode 21, possibilitando a elaboração de documentos com o conteúdo representado em linguagens latinas; entre outros (Deitel, 2012). 21

92 66 Figura 5.3: Exemplo de estrutura de documento XML para a representação de documentos científicos. 5.9 Linguagem CSS Cascading Style Sheets (CSS) 22 é uma linguagem de estilo utilizada para definir a formatação (design) da apresentação de documentos escritos mediante ao uso de linguagens de marcação, como XML e HTML. O objetivo da linguagem CSS consiste em separar o layout do conteúdo de documentos web. Hoje em dia, grande parte desses documentos utilizam CSS para organizar, formatar e expor informações de modo personalizado (Sklar, 2001; Larsen, 2013). A linguagem CSS foi criada em 1994 por Håkon Wium Lie e Bert Bos, os quais apresentaram o projeto dessa linguagem para a W3C, que lançaram a recomendação oficial do CSS Level 1 (CSS1) em 1996 e CSS2 no ano de Atualmente, a linguagem CSS está em sua terceira versão (CSS3) e ainda se encontra em desenvolvimento (Meyer, 2009). Essa linguagem possui uma sintaxe simples e utiliza palavras em inglês para especificar os nomes de regras e de suas propriedades. Uma regra CSS é dividida em três partes, como o identificador da regra (seletor), a propriedade do seletor e o valor de cada propriedade. Assim, 22

93 67 uma regra é definida na forma nome_seletor{ propriedade1:valor1; propriedaden:valorn; } e é classificada em três tipos distintos (Lie and Bos, 2005; Sklar, 2001; Meyer, 2009): Seletores XHTML: definem o modo de exibição de uma tag HTML. Esse tipo de seletor não pode ser nomeado dinamicamente, isto é, podem apenas conter nomes de tags HTML. Por exemplo, a regra p{color:red; background-color:green;} determina que as informações representadas pela tag <p> terão todos os seus caracteres apresentados na cor vermelha e o parágrafo terá a cor de fundo verde; Classes: os seletores podem ser nomeados dinamicamente e aplicados em distintos elementos. O nome do seletor para esse tipo de regra é precedido pelo caractere ponto ("."). Ao contrário dos seletores XHTML, o seletor do tipo classe deve ser declarado na tag que utilizará as suas propriedades por meio do atributo class e o seu valor com nome da classe sem o caractere ponto. Assim, esse tipo de regra pode ser utilizada em qualquer tag HTML. Por exemplo, a regra.minha_classe{ background-color:blue; } determina que a cor de fundo de cada tag que a utiliza terá cor azul, como <p class="minha_classe >... <p/> e <body class="minha_classe >... </body>; Identificadores (ID): também nomeável dinamicamente, porém, cada ID pode ser aplicada apenas uma única vez em qualquer tag HTML. O nome do seletor para esse tipo de regra é precedido pelo caractere cerquilha ("#") e sua declaração em uma tag HTML é definida pelo atributo id. Por exemplo, a regra #meu_id{color:white;} determina que a cor dos caracteres será branco, como <b id="meu_id >... </b>. Em um documento HTML, o CSS pode ser usado em três modos distintos: adição do atributo style diretamente na tag com a respectiva declaração de propriedades, por exemplo, <h2 style="color:black >... </h2>; inclusão da tag <style type="text/css >, que permite a criação de regras CSS dentro do próprio documento HTML; ou inserção de arquivo CSS externo por meio da tag <link>, utilizando o atributo rel para determinar o tipo de documento aplicado e o atributo href para definir o local e o nome do arquivo CSS (Lie and Bos, 2005). Desse modo, com o uso do CSS é possível construir páginas web com design aprimorado sem a necessidade da formatação de informações em arquivos HTML, ou seja, o layout da página é separado da estrutura do arquivo HTML, tornando a página mais leve e viabilizando o reuso do design em outras páginas web, ou seja, um arquivo CSS pode ser utilizado em toda coleção de páginas. Também, o CSS possibilita a redução de tempo para o carregamento de páginas web, pois com todas as regras de formatação em arquivos CSS, é reduzida a quantidade de código dessas páginas, diminuindo o fluxo de dados a serem transmitidos e analisados pelos navegadores web (Meyer, 2009).

94 Linguagem de Programação Javascript Javascript 23 é uma linguagem de programação interpretada de característica orientada a objetos e inspirada nas linguagens C, C++ e Java. Originalmente desenvolvida por Brendan Eich da Netscape 24, sob o nome de Mocha, foi mudado para LiveScript que foi lançado em sua primeira versão em setembro de A mudança do nome LiveScript para Javascript ocorreu no mesmo período em que a Netscape iniciou a utilização da tecnologia Java em seu navegador web, em dezembro de Em 1996, Javascript foi submetida para o ECMA (European Computer Manufacturers Association) Internacional com a finalidade de torná-lo uma linguagem padrão industrial, resultando na versão padronizada denominada ECMAScript (Crockford, 2008). Atualmente, Javascript é a linguagem mais utilizada para construção de componentes de interfaces de sistemas web, sites, portais, entres outras ferramentas web. Essa linguagem é geralmente aplicada no desenvolvimento de funcionalidades para a interação do sistema com os usuários, tais como tratamento de eventos (clique com botões do mouse, pressionamento de teclas, entre outras), validação de formulários, efeitos visuais, transferência de informações, entre outras (Goodman and Morrison, 2007). Essa linguagem possui sintaxe de programação estruturada semelhante ao da linguagem C e tipagem dinâmica, ou seja, não é necessária a declaração do tipo de dados. Também, Javascript é quase inteiramente baseada em objetos (orientação a objetos), possui programação dirigida por eventos e é independente de plataforma (Crockford, 2008). Os códigos escritos na linguagem Javascript são incluídos em arquivos HTML (páginas web), os quais são exibidos para os usuários por meio de um navegador web. Assim, é importante ressaltar que a variabilidade de tipos de navegadores para o acesso às páginas web pode influenciar no comportamento de funcionalidades escritas em Javascript, isto é, uma funcionalidade pode gerar resultados diferentes para cada tipo de navegador (Flanagan, 2006). Esse tipo de problema pode ser solucionado ou amenizado com o uso simultâneo de métodos compatíveis com os principais navegadores para a realização de uma determinada tarefa. Por exemplo, o comando document.selection.createrange().text é utilizado para a captura do texto selecionado pelo usuário e funciona corretamente nos navegadores web Netscape e Internet Explorer, ao contrário dos navegadores Opera, Firefox e Chrome, na quais devem ser usado o comando window.getselection().tostring(). Nesse sentido, esses dois comandos podem ser utilizados em um único SC, sendo necessário apenas a realização de um tratamento para que cada comando seja executado no navegador correto. Para facilitar a construção de aplicações em Javascript, podem ser utilizadas outras tec

95 69 nologias, como Javascript Object Notation (JSON) 25 e Document Object Model (DOM) 26. O JSON é uma estrutura padrão de dados manipulável pela linguagem Javascript. Essa estrutura, proposta por Douglas Crockford, é uma alternativa à linguagem XML para manipulação de informações de páginas web (Ferguson and Heilmann, 2013). O DOM é uma linguagem multiplataforma independente para representar interação entre objetos em documentos HTML, XHTML e XML (van Kesteren, Gregor, Russel and Berjor, 2014). Também, para construção de ferramentas utilizando Javascript, podem ser utilizados bibliotecas de código-fonte, como o JQuery 27, que oferece várias funcionalidades para manipulação de informações (Crockford, 2008) Considerações Finais A escolha de ferramentas e tecnologias para auxiliar na construção de uma solução computacional se apresenta como uma abordagem essencial para o sucesso de um projeto de software. Essas escolhas são baseadas nas características e na complexidade dos requisitos estabelecidos. Assim, são definidas as linguagens de programação, os frameworks e outros recursos que deverão ser utilizados na elaboração do SC para atender às especificações de seus usuários. Neste capítulo, foram apresentadas as tecnologias mais empregadas na construção de sistemas computacionais, bem como no SC para a automatização do PMLM. Para o método de mapeamento, foi utilizada a linguagem de programação Perl para a implementação das técnicas de processamento de texto devida a sua variabilidade de métodos que facilitam essa tarefa. A linguagem de marcação XML é usada para representar a lista de stopwords e do Arquivo de Padronização (AP). A linguagem de programação Java foi aplicada sob apoio do ambiente de desenvolvimento NetBeans e outras ferramentas para a implementação do algoritmo de mapeamento de laudos médicos por ontologias. Para automatizar e consolidar o PMLM e facilitar o seu uso por especialistas da área médica, neste trabalho foi desenvolvido um sistema web de modo que seja acessível em qualquer lugar sem a necessidade de instalação de softwares e de configuração da máquina para o seu uso, sendo apenas indispensável um navegador web instalado no computador do usuário e acesso à Internet. Com esse sistema é eliminada a necessidade do conhecimento técnico de seus usuários para a aplicação de cada método de processamento de textos e a criação de estruturas como a stoplist, o AP e a ontologia. Para a construção desse SC, foi utilizada a linguagem JRuby com o suporte do framework RoR e de métodos e ferramentas desenvolvidas em Java e em Perl. Para a elaboração de uma interface amigável, intuitiva e interativa ao usuário, foram utilizadas as

96 70 linguagens HTML, CSS e Javascript. Desse modo, no Capítulo 6 é descrita detalhadamente a aplicação da abordagem de engenharia de software denominada método de desenvolvimento por prototipagem e o uso de ferramentas e tecnologias discutidas neste capítulo para a construção do SCC para a automatização e a consolidação do PMLM.

97 Capítulo 6 Processo de Desenvolvimento do Sistema Computacional Colaborativo 6.1 Considerações Iniciais Neste trabalho, foi desenvolvido o Sistema Computacional Colaborativo (SCC) seguindo os preceitos de Engenharia de Software conhecido como método de desenvolvimento de sistemas computacionais por prototipagem. Essa escolha foi realizada devido à complexidade das especificações, bem como pela importância e indispensabilidade da participação de especialistas do domínio. Esse método é aplicado em cinco etapas (Lee, Oliva, Maletzke, Machado, Voltolini, Coy, Fagundes and Wu, 2013), as quais são apresentadas a seguir. Sendo assim, na Seção 6.2 são apresentadas as atividades realizadas na etapa de Comunicação. Na Seção 6.3 são descritas as tarefas desempenhadas na etapa de Plano Rápido. Na Seção 6.4 é apresentada a modelagem do SCC. Na Seção 6.5 é descrita a construção do sistema. Na Seção 6.6 são ilustradas as telas do SCC e as suas funcionalidades. Na Seção 6.7 é apresentada a avaliação do sistema realizada por especialistas do domínio. 6.2 Etapa de Comunicação Nessa etapa, primeiramente foram estudados conceitos relacionados ao PMLM e às técnicas de processamento de textos utilizadas nesse processo para a compreensão do funcionamento do método de mapeamento. Nesse estudo, foi observado que todas as técnicas utilizadas no PMLM devem ser executadas separadamente por meio do uso de instruções computacionais, dificultando a sua aplicação por profissionais que não sejam da área computacional ou que não conheçam detalhadamente o processo. Também, foi constatado que uma das técnicas utilizadas no pré-processamento, denominada stemming, pode dificultar o entendimento de alguns termos e os resultados de sua aplicação podem ser interpretados pelos especialistas erroneamente, 71

98 72 como discutido no Capítulo 3. Após o estudo direcionado ao PMLM, foram realizadas reuniões com especialistas do domínio para o levantamento de requisitos para a construção do SCC com o propósito de reduzir os problemas apresentados anteriormente e maximizar a criação de um Sistema Computacional (SC) funcional, amigável e interativo. Assim, os principais requisitos definidos foram: Automatização do PMLM por ontologias mediante a integração de técnicas de processamento de laudos textuais; Substituição da técnica de pré-processamento stemming pelo método de lematização, no qual os resultados podem ser mais facilmente compreendidos pelos seus usuários; Desenvolvimento de uma interface web amigável e intuitiva ao usuário para facilitar o uso do sistema, de modo que não seja necessária a instalação de programas adicionais e a configuração específica do computador para a execução do SCC; Possibilidade do uso do sistema por qualquer computador com configuração mediana atualmente (por exemplo, computadores com processador Intel c Core i3) que tenha acesso à internet. 6.3 Etapa de Plano Rápido Na etapa de Plano Rápido, os requisitos foram analisados com a finalidade de compreender o problema a ser resolvido para verificar se era viável o desenvolvimento de uma solução computacional. Neste projeto, inicialmente foram realizadas análises conceituais e práticas sobre os métodos desenvolvidos na linguagem Perl com o intuito de esclarecer o funcionamento do pré-processamento de laudos textuais. Assim, primeiramente foram estudados os aspectos teóricos que abrangem essas técnicas, caracterizado como estudo conceitual. O estudo prático foi conduzido de dois modos: simulado, no qual não foram executados os códigos dos métodos por meio de um interpretador computacional, mas de forma manual para simular a execução dos mesmos; e real, em que os códigos dos métodos são executados em um interpretador de código Perl. Também, foram estudados a técnica de pré-processamento aplicada na segunda fase do PMLM e o método de mapeamento de laudos por ontologias, os quais foram codificados nas linguagens Perl e Java, respectivamente. O pré-processamento consiste na seleção e na aplicação das técnicas de transformação de textos utilizadas na construção de Conjuntos de Frases Únicas (CFU) para a uniformização dos laudos que serão mapeados para a tabela atributo-valor por intermédio do método de mapeamento. Esses estudos foram conduzidos da mesma forma que foi aplicada nos métodos de pré-processamento. Sendo assim, com esses estudos foi possí-

99 73 vel compreender as dificuldades que abrangem o uso do PMLM por profissionais que não sejam da área de computacional ou que não conheçam detalhadamente o processo. Após, foi iniciado o planejamento da solução computacional, bem como foram definidas e analisadas as tecnologias que podem ser utilizadas para apoiar na construção de um SCC com a finalidade de facilitar o uso do método e atender aos requisitos levantados anteriormente. 6.4 Etapa de Modelagem Na etapa de Modelagem do SCC, foram estruturados dois cenários, um para cada fase do PMLM, com o intuito facilitar a compreensão das especificações para o seu desenvolvimento (Lee, Oliva, Maletzke, Machado, Voltolini, Coy, Fagundes and Wu, 2013). No cenário da primeira fase do PMLM, foram definidas as seguintes funcionalidades: Gerenciamento do Conjunto de Laudos Médicos: tem a finalidade de gerenciar os conjuntos de laudos textuais que serão utilizados para a geração do CFU. Essa funcionalidade deve possibilitar a seleção, a abertura e a exclusão de laudos em uma lista de arquivos, bem como a visibilização do conteúdo dos mesmos; Construção e Gerenciamento do Conjunto de Frases Únicas: tem o objetivo de aplicar as técnicas de processamento de textos do PMLM no conjunto de laudos médicos selecionados para a geração de CFU (Conjunto de Frases Únicas). Nessa funcionalidade deve ser possível visibilizar, comparar e gravar os resultados do processamento; Definição e Gerenciamento da Lista de Stopwords: tem o intuito de auxiliar na definição da stoplist. Nessa tarefa deve ser possível construir uma lista de stopwords, a qual é exibida em um painel de exibição de stoplist. Também, deve ser viável o carregamento e o download da stoplist e a aplicação do método de remoção de stopwords; Construção e Gerenciamento do Arquivo de Padronização: tem o propósito de auxiliar na construção do AP (Arquivo de Padronização) para a uniformização de laudos. Assim, essa funcionalidade deve permitir a definição de uma lista de padrões, os quais são representados por dois conjuntos, sendo um de termos a serem substituídos e outro de termos substitutos. Do mesmo modo, deve ser possível carregar e gravar AP, tal como aplicá-lo para a uniformização do CFU por meio do método de padronização; Definição e Gerenciamento do Conjunto de Atributos: tem a finalidade de apoiar na definição de elementos que serão representados por uma ontologia, como os atributos e seus respectivos valores que constituirão a base de dados e as RM que serão utilizadas para mapear o conhecimento presente em laudos textuais para essa base. Esses atributos devem ser apresentados em uma lista e as suas respectivas RM devem ser exibidas no

100 74 caso de seleção de um elemento dessa lista. Do mesmo modo, nessa funcionalidade é possível carregar e gravar ontologias. Para a segunda fase do PMLM, foram definidas as seguintes funcionalidades: Aplicação de Pré-Processamento: tem o objetivo de aplicar as técnicas de processamento de textos em um conjunto de laudos, que pode ser o que foi utilizado na primeira fase e/ou outro conjunto novo de laudos disponibilizados em uma única lista de arquivos. Essa funcionalidade deve permitir a seleção de técnicas de pré-processamento a serem aplicadas ao conjunto de laudos, a aplicação dessas técnicas a esses laudos e o download do conjunto pré-processado; Realização de Mapeamento: tem o intuito de aplicar o método de mapeamento por meio de uma ontologia para a transcrição do conjunto de laudos pré-processados e o preenchimento de uma base de dados. Nessa funcionalidade deve ser possível a visibilização dos resultados por meio de uma tabela atributo-valor e de uma lista de termos não-processados, bem como deve ser permitido gravá-los no computador do usuário. Na Figura 6.1 são apresentadas as funcionalidades de ambos cenários utilizando a linguagem UML (Unified Modeling Language) por meio de um diagrama de casos de uso, no qual é ilustrado a interação entre o usuário e o SCC. Também, a partir da análise dos requisitos e de sua respectiva modelagem, foi elaborado um modelo arquitetural com o intuito de ilustrar a integração das técnicas aplicadas no PMLM com o SCC e a sua respectiva interação com o usuários. Esse modelo é apresentado na Figura 6.2 e é constituído pelos seguintes elementos: Cliente: é o componente do SCC utilizado pelos usuários para a aplicação do PMLM automatizado por intermédio da Internet; Internet: rede de comunicação de dados; Servidor de Aplicações (SA): é o componente do sistema que tem o propósito de gerenciar os recursos computacionais disponíveis para a aplicação do PMLM automatizado por meio da interação do Cliente com o sistema. Esse servidor é composto por: Interface Web (IW) para a disponibilização das funcionalidades do sistema por meio de telas intuitivas e amigáveis ao usuário; Controlador de Recursos do Sistema (CRS) para gerenciar o acesso às funcionalidades do sistema, que são compostas por scripts Perl e métodos escritos em Java; Scripts Perl (SP) para a aplicação das técnicas de processamento de textos, escritas na linguagem Perl, em laudos textuais selecionados pelo usuário;

101 75 Figura 6.1: Diagrama de casos de uso do SCC. Métodos Java (MJ) para controlar a execução de SP no sistema e a aplicação do método de mapeamento. Também, esse componente é utilizado para gerenciar as estruturas utilizadas pelo PMLM, como a stoplist, o AP, a ontologia e a base de dados; Banco de Dados (BD) para armazenar dados de cadastro e de login de usuários; Base de Dados do Usuário (BDU) para armazenar os laudos e os outros arquivos necessários para a aplicação do PMLM, tal como gravar os seus respectivos resultados. Sendo assim, é importante ressaltar que os dados produzidos pelo PMLM, como o CFU, o AP, a ontologia, os laudos transformados, os termos não processados e a tabela atributo-valor podem ser armazenados no computador do usuário, caso assim seja definido. Desse modo, estruturas como AP e ontologias podem ser reaproveitadas para o mapeamento de outros conjuntos de laudos e a construção de novas bases de dados.

102 Etapa de Construção Figura 6.2: Modelo de arquitetura do SCC. Após o planejamento e a modelagem da solução computacional, nessa etapa foi construído o SCC utilizando as ferramentas e as tecnologias apresentadas no Capítulo 5. Nesse sentido, a principal linguagem de programação utilizada foi uma implementação

103 77 da linguagem Ruby denominada JRuby com o suporte do framework para o desenvolvimento de sistemas web Ruby on Rails (RoR) na versão Para o controle do acesso ao SCC, foi utilizada a gem Devise 1 na versão 3.0.2, que é aplicada ao controle do acesso ao sistema por intermédio de login e senha, assim como para o gerenciamento do cadastro de conta de usuários do sistema. Para prover suporte no armazenamento de dados dos cadastros de usuário, foi utilizado o sistema de gerenciamento de base de dados RoR denominado SQLite 2 na versão Para facilitar a integração e a consolidação do PMLM com o SCC, foram desenvolvidos métodos utilizando a linguagem de programação Java apoiada pelo ambiente de desenvolvimento NetBeans 7.3 para a construção e o carregamento de estruturas utilizadas pelo PMLM e a execução de técnicas de processamento de textos escritas na linguagem Perl por meio de um interpretador JRuby. Esses métodos são apresentados a seguir: Gerenciador de CFU: controla a aplicação de técnicas de processamento de textos do PMLM escritos em Perl para a geração de CFU; Gerenciador de stopwords: é aplicado para a construção da stoplist por meio da lista de termos considerados irrelevantes definida no SCC. Também é utilizado para a exibição dos stopwords no SCC; Gerenciador de Regras de Padronização (RP): constrói e carrega o AP por intermédio de RP definidas pelos usuários no SCC; Configurador de parâmetros: determina as técnicas que deverão ser aplicadas para o pré-processamento de laudos, isto é, os métodos escolhidos pelo usuário; Pré-processador de laudos: utiliza as técnicas determinadas no configurador de parâmetros para a execução do pré-processamento em laudos textuais. Também, os métodos escritos em Perl sofreram alterações em nível de código-fonte com a finalidade aprimorá-las e reduzir a complexidade de sua execução por meio da linguagem Java. Assim, na técnica de normalização foi incluída a remoção dos caracteres iniciais -", que é utilizado na descrição de observações em laudos textuais por especialistas. Na técnica de remoção de stopwords foi incluída a possibilidade de processamento de caracteres especiais caso sejam definidas como stopwords, tais como parênteses ("()"), ponto de interrogação ("?") e ponto de exclamação ("!"), os quais são comumente encontrados em laudos textuais. Na técnica de aplicação de padronização eram anteriormente utilizados dois AP, sendo um com o intuito de representar RP para a substituição de uma palavra ou parte de uma frase

104 78 antiga por apenas um novo termo ou uma nova frase (RP do tipo um para um) e outro AP com o objetivo de desempenhar RP para a substituição de uma palavra ou de uma frase antiga por dois ou mais novos termos e/ou frases (RP do tipo um para vários). Na Figura 6.3 são apresentados dois exemplos de AP, em que (a) é a estrutura que representa as RP que contém apenas uma sentença para substituir uma observação presente no laudo não-padronizado e (b) é o AP que contém RP com duas sentenças novas para a substituição de uma única observação. Nessa figura, pattern é o marcador da estrutura do AP que contém apenas RP do tipo um para um, patterntwo é a tag da estrutura do AP que contém apenas RP do tipo um para vários, number é um atributo que descreve o número de RP contidas em uma AP, synonym é o marcador de uma RP de pattern, synonymtwo é a tag de uma RP de patterntwo, n é um atributo que determina o número de termos e/ou de sentenças substitutas contidas em synonymtwo, old é o marcador que define uma palavra ou uma frase a ser substituída e new é a tag que se refere a uma palavra ou uma frase substituta. Figura 6.3: Exemplos de AP antigos. Nesse sentido, o método de padronização foi reestruturado para utilizar apenas um AP que represente todas RP, mantendo as técnicas originais para tratar diferentes tipos de RP. Na Figura 6.4 é a demonstrado um exemplo para a nova estrutura de AP utilizando os exemplos apresentados na Figura 6.3. Figura 6.4: Exemplo de nova estrutura otimizada de AP. Também, no SCC desenvolvido neste trabalho, a técnica de processamento de textos denominada stemming foi substituída pelo método de lematização com o objetivo de reduzir as

105 79 limitações relacionadas ao stemming, conforme apresentado no Capítulo 3. O método de lematização foi implementado por intermédio da linguagem de programação Perl com base no método proposto por Branco and Silva (2007) e na técnica de stemming implementada por Honorato, Cherman, Lee, Wu and Monard (2007). O método de lematização foi adaptado ao PMLM para processar apenas substantivos femininos e/ou plurais, os quais são mais comuns nos laudos textuais. Como essa técnica de lematização é baseada no algoritmo de Porter (1997), foi possível reutilizar o código-fonte do método de stemming do PMLM, realizando algumas adaptações, como a substituição das regras de remoção de sufixos por regras de lematização. Com a retirada do método de stemming e a inclusão da técnica de lematização no processo de mapeamento, foi necessária a realização de modificações adaptativas no código-fonte do método aplicado na segunda fase do PMLM para o pré-processamento de laudos. Também, por meio da linguagem Perl foi desenvolvido um método para facilitar e automatizar a geração de CFU a partir de um conjunto de laudos médicos selecionados por usuários. Esse método tem a finalidade de construir sequencialmente os seguintes tipos de CFU: Não-processado; Normalizado; Sem stopwords; Lematizado; Padronizado. O CFU não-processado consiste em um conjunto de frases e/ou palavras distintas extraídas de laudos médicos, no qual não foram aplicadas técnicas de processamento de textos do PMLM e os outros CFU são conjuntos de frases pré-processadas. Para a elaboração da técnica de geração de CFU, foram utilizados os métodos do PMLM escritos e aprimorados em Perl. Nesse contexto, é importante ressaltar que no método de criação dos CFU, cada tipo de conjunto de frases é gerado a partir do último CFU criado. Além disso, o método de mapeamento de laudos médicos por ontologias, desenvolvido em Java (Costa, Ferrero, Lee, Coy, Fagundes and Chung, 2009; Lee, Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundes and Chung, 2011), foi integrado ao SCC. As ontologias utilizadas nesse método, eram construídas na linguagem OWL (Ontology Web Language) utilizando a ferramenta Protégé, as quais foram apresentadas no Capítulo 2. Com o intuito de facilitar e de aprimorar a integração desse método com o SCC foram desenvolvidas as novas funcionalidades, como: Possibilidade de seleção de ontologias por usuários;

106 80 Construção de um gerenciador de atributos para a geração de ontologias por intermédio da definição de RM e de características por usuários no SCC. Esse gerenciador é também utilizado para a exibição de atributos e suas RM no sistema. Para a construção de ontologias, essa ferramenta gera os seguintes componentes, que são apresentado na Seção 7.6: Propriedades de dados: descrevem os elementos de ontologias; Propriedades de objeto: desempenham o relacionamento entre os elementos da ontologia, formando as RM e os atributos; Classes: rotulam e organizam o conhecimento de forma hierárquica; Elementos: determinam os indivíduos que devem estar presentes em todas as ontologias utilizadas pelo SCC, como regiões anatômicas, características, subcaracterísticas, tipo de dados, atributos e RM. Requisito de que todas as RM devem conter uma região anatômica e no mínimo uma característica para descrevê-la; Geração de resultados no formato de texto e organizados de forma que simplifiquem a representação de seus resultados na interface do SCC; Carregamento e gravação da tabela atributo-valor e da lista de termos não-processados no sistema. Para a construção de uma interface web amigável e interativa com o usuário, foram utilizadas as linguagens: HTML para a construção de páginas web; CSS para a modelagem visual dessas páginas; Javascript para a interatividade da página com o usuário. Nesse sentido, foi desenvolvida uma página web para cada funcionalidade de ambos os cenários do sistema e adicionalmente, foram construídas outras páginas para auxiliarem no uso dessas funcionalidades, tais como para carregamento de laudos, de lista de stopwords, de AP e de ontologias, bem como para a criação e a edição de RP e de mapeamento. Para o gerenciamento do carregamento de arquivos, no SCC foi utilizada a gem Paperclip Assim, para elaboração da interface do SCC foi utilizado o modelo de estruturas CSS desenvolvidas em Jung (2012) com o propósito de padronizar o SCC de acordo com os projetos em andamento no LABI. 3

107 6.6 Apresentação do Sistema Computacional Colaborativo Desenvolvido 81 Como mencionado, o SCC foi estruturado em dois cenários, um para cada uma das fases 1 e 2, e as tarefas foram organizadas em menus de seleção que proveem acesso direcionado às funcionalidades do PMLM. Na Figura 6.5 é apresentada a primeira tela do SCC em que é solicitada a autenticação do usuário para possibilitar o uso desse sistema. Somente após a autenticação do usuário, é possível que o mesmo tenha acesso a todas as funcionalidades do sistema relacionadas aos laudos textuais. A partir dessa tela, também é viável a criação de novos cadastros de usuário por meio do link "Criar uma conta" e redefinir senha do usuário por intermédio do link "Esqueceu a sua senha?", a partir do qual é enviado para a conta do usuário a sua senha de acesso. Figura 6.5: Tela de acesso ao sistema. Após a autenticação do usuário, caso essa conexão seja a primeira ao SCC, no diretório do computador servidor onde esse sistema encontra-se hospedado é gerada uma pasta cujo o nome é o número de identificação da conta do usuário e as seguintes subpastas são criadas: CFU: contendo todos os CFU construídos durante a aplicação da primeira fase do PMLM; laudos: contendo laudos textuais que foram selecionados para a criação de CFU; laudos_padronizados: contendo laudos utilizados para o mapeamento, os quais são préprocessados mediante técnicas de processamento de textos do PMLM; tabela_atributo_valor: contendo resultados do mapeamento dos laudos contidos na pasta laudos_padronizados. Os resultados armazenados são a tabela atributo-valor e a lista de termos não processados.

108 82 Na pasta do usuário, também são criadas e armazenadas as estruturas que são utilizadas pelo PMLM, tais como o AP, a stoplist e a ontologia, as quais são geradas e/ou carregadas pelo usuário. Outro arquivo que se encontra nessa pasta, é o de configuração de parâmetros denominado parameters, que tem a finalidade de controlar a aplicação do pré-processamento na segunda fase do método no SCC. Esse arquivo é estruturado na linguagem de marcação XML e é composto pelos seguintes marcadores: applynormalize: determina se a técnica de normalização deve ser aplicada; applystopwords: define se o método de remoção de stopwords deve ser usado; applylemmatization: indica se o procedimento de aplicação de lematização deve ser executado; applypattern: determina se a técnica de padronização deve ser aplicada; dirstopword: define a localização do diretório do usuário em que se encontra a stoplist; dirdocuments: indica onde está situada a pasta do usuário na qual estão os laudos utilizados para a construção de CFU. Esse marcador também é utilizado para o reuso dos laudos da pasta referenciada pela mesma para a aplicação do pré-processamento e/ou do mapeamento; dirpatterns: determina o local do diretório do usuário onde está localizado o AP; diroutput: indica a localização da pasta do usuário em que se encontram os laudos para serem ou que foram padronizados; Nesse arquivo, os marcadores que determinam a aplicação de técnicas de processamento de textos podem representar apenas os seguintes valores: "sim", o qual é atribuído a um marcador caso o usuário escolheu uma determinada técnica para a aplicação de pré-processamento de laudos; ou "não", que é atribuído aos marcadores das técnicas de processamento de textos que não foram escolhidos pelo usuário. Os marcadores que representam a localização de arquivos e de diretórios do usuário apresentam valores na forma /localização do SCC/tmp/sessions/número de identificação do usuário ou no formato /localização do SCC/tmp/sessions/número de identificação do usuário/subpasta. Na Figura 6.6 é apresentado um exemplo de estrutura de arquivo de parâmetros, que é criado na pasta de um usuário. O arquivo de parâmetros ilustrado na Figura 6.6 determina que as técnicas de processamento de textos como a de normalização, de remoção de stopwords, de lematização e de padronização foram selecionadas pelo usuário para serem aplicadas ao conjunto de laudos localizado no diretório laudos_padronizados, para o qual a sua localização é representada pelo marcador diroutput, em que "1" é o nome da pasta de um usuário.

109 83 Figura 6.6: Exemplo de estrutura do arquivo de parâmetros do SCC. Sendo assim, a seguir são apresentadas as funcionalidades de cada cenário do SCC, nas quais os componentes são descritos na forma C.F.I, onde C é o número do cenário, F é o número da funcionalidade de C e I é o item destacado da funcionalidade F. Na Figura 6.7 é apresentada a tela do SCC equivalente à funcionalidade denominada "Gerenciamento do Conjunto de Laudos Médicos", na qual foram destacados: Menu de seleção das funcionalidades (1.a); Link para a mudança de cenário (1.b); Painel da lista de laudos (1.1.1); Área de texto em que é exibido o conteúdo do laudo selecionado na lista (1.1.2); Botão "Excluir", que tem a finalidade de descartar os laudos selecionados como sendo de não interesse nesse momento. Essa operação pode ser aplicada pelo pressionamento da tecla Delete no computador do usuário, sendo necessária a seleção de no mínimo, um laudo em (1.1.1); Botão "Carregar", é usado para carregar conjuntos de laudos. Esse botão ao ser clicado, é aberta uma janela popup com uma página web de gerenciamento do carregamento de laudos textuais. Na Figura 6.8 são apresentadas as telas de gerenciamento de carregamento de laudos textuais. Nessa figura, (a) representa a tela abertura de arquivos e (b) é a tela para a qual se é direcionado após o usuário clicar no botão "Enviar" na tela (a). É importante destacar que nessa tela é viável carregar vários laudos simultaneamente a partir do computador do usuário. Na Figura 6.9 é exibida a tela da funcionalidade "Conjunto de Frases Únicas (CFU)", na qual têm-se: Campos do tipo texto para a exibição de um determinado CFU (1.2.1);

110 84 Figura 6.7: Funcionalidade "Gerenciamento do Conjunto de Laudos Médicos" da primeira fase. Figura 6.8: Telas de gerenciamento de carregamento de laudos textuais. Campos de seleção do tipo de CFU a ser apresentado no campo de exibição (1.2.2); Botão "Reconstruir CFU", que tem o objetivo de gerar o conjunto de CFU a partir dos laudos carregados na tela da Figura 6.7 e o botão "Download CFU" que permite gravar os resultados no computador do usuário. O texto do botão "Reconstruir CFU" é exibido em duas maneiras, sendo que o texto "Reconstruir CFU" é apresentado neste botão caso pelo menos um CFU seja existente na base de dados ou "Construir CFU", caso contrário. Nessa funcionalidade, também é possível a visibilização de dois CFU distintos simultaneamente. Nesse contexto, é importante ressaltar que os CFU são construídos por meio do método de geração automática de CFU desenvolvido neste trabalho, sendo apresentadas na seguinte ordem: Conjunto de Frases Únicas CFU; CFU Normalizado; CFU Normalizado e sem Stopwords (caso exista stoplist na base de dados);

111 85 Figura 6.9: Funcionalidade "Construção e Gerenciamento do Conjunto de Frases Únicas" da primeira fase. CFU Lematizado (caso não exista uma stoplist cadastrada no SCC) ou CFU Lematizado e sem Stopwords (caso exista uma stoplist cadastrada); CFU Padronizado (caso exista uma AP na base de dados). Essa funcionalidade apresenta as seguintes restrições: para a construção de CFU, é necessária a existência de laudos textuais para esse fim na base de dados do SCC, os quais devem ser carregados por meio da funcionalidade "Gerenciamento do Conjunto de Laudos Médicos", apresentado na Figura 6.7; e para a construção dos CFU sem stopwords e do CFU padronizado é imprescindível a presença de uma stoplist e de um AP na base de dados local do usuário no SCC, respectivamente. Na Figura 6.10 é ilustrada a tela da funcionalidade "Definição e Gerenciamento da Lista de Stopwords", em que é possível a visibilização de todos CFU gerados até o momento, facilitando a definição e a identificação de palavras consideradas irrelevantes para aquele contexto, também denominadas stopwords. A seguir são apresentados os principais componentes dessa funcionalidade: Campo de texto para a determinação de uma nova palavra irrelevante, a qual é incluída na stoplist (1.3.1); Stoplist (1.3.2); Botão "Incluir", que é utilizado para incluir a stopword de (1.3.1) na stoplist; Botão "Excluir", que tem o propósito de excluir a stopword selecionada em (1.3.2);

112 86 Botão "Carregar Stoplist", que é usado para carregar uma stoplist por intermédio do computador do usuário; Botão "Download Stoplist", que tem o intuito de gravar a stoplist no computador do usuário; Botão "Aplicar Stoplist", que tem a finalidade de aplicar o método de remoção de stopwords no último CFU construído. Figura 6.10: Funcionalidade "Definição e Gerenciamento da Lista de Stopwords" da primeira fase. As restrições da funcionalidade apresentada na Figura 6.10 são: a exigência do preenchimento do campo (1.3.1) para a inclusão de uma stopword; a necessidade da existência de uma stoplist para a aplicação do método de remoção de stopwords; e a impossibilidade de cadastrar termos irrelevantes repetidos. No sistema desenvolvido neste trabalho, a existência de uma stoplist é dada pela presença de no mínimo uma stopword em (1.3.2) da Figura Nesse sentido, ao executar a técnica de remoção de palavras consideradas irrelevantes mediante o botão "Aplicar Stoplist", os métodos de remoção de stopwords e de lematização são aplicados no último CFU construído, gerando o CFU normalizado e sem stopwords e o CFU lematizado e sem stopwords, respectivamente. Na Figura 6.11 é mostrada a tela da funcionalidade "Construção e Gerenciamento do Arquivo de Padronização", na qual destacam-se: Painel da lista de termos antigos a serem substituídos (1.4.1); Painel da lista de termos substitutos do termo antigo selecionado (1.4.2); Botão "Novo", que ao ser clicado, é aberta uma janela popup para definição de uma nova RP. Também é possível definir uma nova RP por meio da seleção de palavras na área de

113 87 texto de exibição de CFU, na qual, ao selecionar um termo ou sequência de termos, é aberta a tela de definição de novas regras; Botão "Editar", que ao ser clicado, é aberta uma janela popup, como na Figura 6.12, para a edição da RP selecionada em (1.4.1). A edição de uma RP também pode ser realizada por intermédio da tecla "Enter"; Botão "Excluir", que ao ser clicado, é aplicado a remoção de uma RP selecionada em (1.4.1). A exclusão de uma RP também pode ser realizada por meio da tecla "Delete"; Botão "Carregar Arquivo", que é aplicado para carregar AP do computador do usuário; Botão "Download Arquivo", que é usado para gravar o AP no computador do usuário; Botão "Padronizar CFU", que é utilizado para a aplicação da técnica de padronização no último CFU construído. Figura 6.11: Funcionalidade "Construção e Gerenciamento do Arquivo de Padronização" da primeira fase. Para a aplicação da técnica de padronização de CFU, é necessária a existência de um AP na base de dados do SCC, isto é, a lista de termos a serem substituídos como apresentado na Figura 6.11 deve conter no mínimo um termo presente nessa lista. A janela popup para definição de uma nova RP descrita anteriormente é apresentada na Figura 6.12, onde (a) é o campo de texto referente ao termo a ser substituído, (b) é o campo de termo substituto a ser cadastrado e (c) é a lista de termos substitutos. Nessa tela, é possível a definição, a edição e a exclusão de termos substitutos. Assim, o texto do botão de inclusão de termos substitutos é "Incluir +", caso exista no mínimo um termo substituto cadastrado na lista de termos novos ou "Incluir" caso contrário.

114 88 Figura 6.12: Tela para definição de uma nova RP. Para a edição de RP, o SCC disponibiliza uma tela semelhante ao apresentado na Figura 6.12, na qual a única diferença é o título de ambas, sendo "Editar Padrão" para a atualização de RP. Para definir ou editar uma RP, é necessário que (a) seja preenchido e (c) contenha pelo menos um elemento. Também, para cada RP em ambos os casos não pode haver repetição de termos novos, bem como não é permitido que duas ou mais RP possuam o mesmo termo antigo, o qual é substituído pela lista de termos substitutos. Neste caso, um termo pode ser considerado uma palavra ou uma frase. Na Figura 6.13 é exibida a tela da funcionalidade "Definição e Gerenciamento do Conjunto de Atributos", a qual apresenta: Lista de nome de atributos (1.5.1); Valor padrão do atributo selecionado (1.5.2); Valores possíveis do atributo selecionado (1.5.3); Região da RM (1.5.4); Característica da RM (1.5.5); Lista de observações do atributo selecionado (1.5.6); Valor da observação selecionada (1.5.7); Botão "Novo", que é usado para a definição de uma nova RM a partir de uma janela popup, que é apresentada na Figura 6.14; Botão "Editar", é utilizado para a edição de uma RM selecionada em (1.5.1) por intermédio de uma tela popup similar à apresentada A edição de uma RM também pode ser realizada por meio da tecla "Enter"; Botão "Excluir", que é aplicado para a remoção de uma RM selecionada em (1.5.1). Essa operação pode ser realizada por meio da tecla "Delete";

115 89 Botão "Carregar Ontologia", que é utilizado para carregar ontologia do computador do usuário; Botão "Download Arquivo", que usado para armazenar localmente a ontologia no computador do usuário. Figura 6.13: Funcionalidade "Definição e Gerenciamento do Conjunto de Atributos" da primeira fase. Com essa funcionalidade, a necessidade do uso de ferramentas externas ao SCC para a construção de ontologias na linguagem OWL, como o Protégé, se torna dispensável para representação de atributos e de RM, facilitando e simplificando a elaboração de estruturas de dados para a representação do conhecimento presente em laudos textuais. Outra característica dessa funcionalidade é a impossibilidade de cadastrar atributos com nomes repetidos. Para a definição de novos atributos e suas RM, é utilizada uma tela popup semelhante ao de elaboração de RP. A tela para definição de atributos e de RM é apresentada na Figura 6.14, em que (a) é o campo para nomeação do atributo, (b) é o campo de seleção de valores possíveis para o atributo, (c) é o valor padrão do atributo, (d) é a região para ser identificada com a RM, (e) é a característica para ser identificada pela RM, (f) é o campo de cadastramento de observações (subcaracterísticas) que serão mapeadas na RM, (g) é valor da observação a ser cadastrada, (h) é a lista de observações cadastradas e (i) é o campo de texto com o valor da observação selecionada em (h). Na Figura 6.14 é ilustrada a definição do atributo "esofagite_edematosa_inferior" com RM no formato local-característica-subcaracterística, no qual "terço distal" é o local, "presenca_edema" é a característica e "normal" e "anormal" são as subcaracterísticas, contabilizando duas RM. No SCC, uma observação é implicitamente considerada subcaracterística

116 90 Figura 6.14: Tela para definição de nova RM. quando a RM representa sentenças no formato local-característica-subcaracterística ou é determinada como característica quando a RM representa sentenças no formato local-característica, que ocorre quando o campo "Característica" se encontra vazio no momento em que o atributo é registrado por intermédio do botão "Salvar". Para a definição de atributos e de suas respectivas RM, o sistema apresenta as seguintes restrições: para cadastrar um novo atributo, no mínimo o usuário deve preencher o campo de nomeação do atributo, selecionar uma região e cadastrar no mínimo uma observação; e não é permitido o registro de observações com nomes repetidos. Nesse sistema, cada observação é composta por duas informações: o nome e o seu respectivo valor. O nome da observação é uma informação que deve ser mapeada por meio de uma RM e o valor da observação é uma informação utilizada para o preenchimento de um atributo na base de dados caso o nome de sua respectiva observação seja mapeada. Também, no SCC é permitida a criação de observações com nomes iguais aos seus valores, por exemplo, se uma observação tem o nome "normal", o mesmo pode conter o valor "normal". Na Figura 6.15 é apresentada a tela da funcionalidade "Aplicação de Pré-Processamento", na qual são destacados: Menu de seleção das funcionalidades do segundo cenário (2.a); Link para mudança de cenário (2.b);

117 91 Lista de laudos escolhidos para pré-processamento e mapeamento (2.1.1); Área de texto utilizada para exibição de laudos (2.1.2); Botão "Laudos Fase 1", que tem a finalidade de reutilizar os laudos do primeiro cenário; Botão "Outros Laudos", que é utilizado para carregar outros laudos no computador do usuário; Botão "Outra Stoplist", que é aplicado para o carregamento de uma stoplist; Botão "Outro Arquivo", que é usado para o carregamento de um AP; Botão "Pré-Processamento", tem o objetivo de pré-processar os laudos selecionados para o mapeamento; Botão "Download Laudos", tem o propósito de gravar os laudos pré-processados no computador do usuário. Figura 6.15: Funcionalidade "Aplicação de Pré-Processamento" da segunda fase. Para o pré-processamento, é permitida a seleção de técnicas como a de normalização, de remoção de stopwords, de lematização e/ou de padronização, de acordo com os critérios do usuário. Sendo assim, nessa funcionalidade, os laudos selecionados podem ser visibilizados apenas em seu estado atual em (2.1.2), ou seja, se não foi aplicada nenhuma técnica de pré-processamento são exibidos os laudos em suas versões originais, caso contrário, são apresentados os laudos processados. Também, o processamento de textos é realizado por meio do botão "Pré-Processamento", que ao ser clicado, o SCC primeiramente verifica as técnicas de processamento de textos selecionados pelo usuário para configurar o arquivo de parâmetros, como apresentado na Figura 6.6. Em seguida, esse arquivo é interpretado pelo sistema com a finalidade de indicar quais técnicas devem ser aplicadas para a transformação dos laudos selecionados para o mapeamento, tal

118 92 como determinar a localização de alguns elementos importantes nessa tarefa, como a pasta que contém os laudos para serem transformados e as estruturas indispensáveis para a aplicação das técnicas de remoção de stopwords e de padronização. Na Figura 6.16 é ilustrada a tela da funcionalidade "Realização de Mapeamento", na qual destacam-se: Tabela em que são apresentados os resultados do mapeamento dos laudos pré-processados (2.2.1); Área de texto em que são apresentados os termos não processados de cada laudo, os quais são utilizados para identificar falhas no mapeamento e definir novas RP e/ou RM (2.2.2); Botão "Mapear Laudos", que é usado para a realização do mapeamento de laudos textuais; Botão "Download Tabela", que é utilizado para gravar a tabela atributo-valor dos laudos mapeados; Botão "Download Termos", que é aplicado para armazenar localmente o arquivo de termos não processados. Figura 6.16: Funcionalidade "Realização de Mapeamento" da segunda fase. Nessa funcionalidade, para o mapeamento dos laudos transformados na função "Aplicação de Pré-Processamento", apresentado na Figura 6.15, o método utiliza a ontologia desenvolvida ou carregada na funcionalidade "Definição e Gerenciamento do Conjunto de Atributos" do primeiro cenário do SCC, conforme apresentado na Figura 6.13.

119 Etapa de Avaliação e Feedback Durante a construção do SCC, o mesmo foi constantemente avaliado em conjunto com os envolvidos na elaboração do projeto com o intuito de verificar o andamento do projeto e se as especificações levantadas foram atendidas satisfatoriamente. Assim, foram realizadas reuniões quinzenais entre os envolvidos no desenvolvimento do sistema para discutir as atividades que foram desempenhadas desde a última reunião, bem como apresentadas as dificuldades encontradas e as possíveis soluções. Também, nessas reuniões foram definidos quais requisitos deveriam ser acrescentados, alterados e/ou removidos. Após a construção da versão final do SCC, o mesmo foi avaliado em conjunto com especialistas do domínio, os quais constataram que esse sistema cumpre os requisitos definidos e se apresenta como promissor para a definição, a extração e o estudo de padrões que podem ser encontrados em laudos textuais (Lee, Oliva, Maletzke, Machado, Voltolini, Coy, Fagundes and Wu, 2013). Ainda, o SCC foi avaliado quanto ao desempenho na aplicação do PMLM automatizado a um conjunto de 100 laudos médicos textuais artificiais que simulam exames de Endoscopia Digestiva Alta (EDA). Os critérios e os resultados dessas avaliações são apresentados no Capítulo Considerações Finais Neste capítulo foi apresentada a aplicação do processo de desenvolvimento de sistemas por prototipagem para a construção do SCC com o intuito de automatizar o PMLM por ontologias. Inicialmente, foram estudados os aspectos teóricos e práticos que abrangem a aplicação de todas as técnicas de processamento de textos utilizadas nas duas fases do PMLM. A análise desse processo permitiu constatar que o uso de todas as técnicas é complexo para qualquer pessoa que não conheça detalhadamente o método e principalmente por profissionais que não sejam da área computacional. Isso se deve ao fato de que essas técnicas são executadas separadamente mediante às instruções computacionais, bem como as estruturas utilizadas pelo PMLM devem ser construídas manualmente por meio de uma linguagem de marcação. Após o estudo do PMLM, foram realizadas reuniões com especialistas do domínio com o intuito de identificar os requisitos para desenvolver um SCC para automatizar e facilitar o uso do método. Em seguida, os requisitos foram estudados e analisados com a finalidade de verificar a viabilidade para o desenvolvimento de uma solução computacional e planejar a construção do mesmo. Depois, o SCC foi modelado em dois cenários, sendo um para cada fase do PMLM.

120 94 Após, o sistema foi implementado utilizando a linguagem programação Ruby com o auxílio da ferramenta RoR. Para o uso das técnicas de construção de CFU, de pré-processamento e de mapeamento de laudos médicos foi utilizada a linguagem de programação Java por intermédio do ambiente de desenvolvimento NetBeans. Para facilitar e agilizar o uso do SCC, foi construída uma interface gráfica web amigável, intuitiva e interativa ao usuário. Oferece suporte completo a todas a tarefas e fases do PMLM sem a necessidade do usuário conhecer detalhadamente as especificações técnicas, como linguagens de programação e de marcação, bem como comandos para a execução dos métodos do PMLM, possibilitando a construção de bases de dados para a realização estudos futuros de forma ágil e eficiente. Também, para o uso do SCC não é necessária a sua instalação e a configuração do computador do usuário, bastando apenas um navegador web instalado na máquina e acesso à internet. Depois da construção do sistema, o mesmo foi avaliado e validado em conjunto com especialistas do domínio, os quais constataram que a solução computacional atendeu aos requisitos estabelecidos e se apresenta como promissora para a extração e o estudo de padrões em laudos textuais médicos. Em seguida, o SCC foi aplicado a um conjunto de 100 laudos médicos textuais artificiais simulando exames de EDA com a finalidade de avaliar o desempenho do PMLM automatizado. Essa avaliação é apresentada detalhadamente Capítulo 7.

121 Capítulo 7 Estudo de Caso 7.1 Considerações Iniciais Como apresentado anteriormente, este trabalho tem o objetivo de automatizar e de consolidar o Processo de Mapeamento de Laudos Médicos (PMLM) por ontologias por meio da integração de todas as suas técnicas de processamento de textos, bem como a inclusão de outros métodos e funcionalidades em um sistema computacional. Para isso, foi realizado um estudo de caso interdisciplinar envolvendo as áreas computacional e médica. Para alcançar os objetivos deste trabalho, foi construído um Sistema Computacional Colaborativo (SCC) no Laboratório de Bioinformática (LABI) da Universidade Estadual do Paraná (UNIOESTE/Foz do Iguaçu) em parceria com o Serviço de Coloproctologia da Faculdade de Ciências Médicas da Universidade Estadual de Campinas (UNICAMP). Esse sistema foi desenvolvido para automatizar e facilitar o uso do PMLM por profissionais que não sejam da área computacional, por exemplo, da área de saúde e que não possuam conhecimento detalhado do método, possibilitando a construção de grandes bases dados, as quais poderão ser utilizadas para a aplicação de processos como o de Mineração de Dados (MD). Após a construção do SCC e a avaliação por especialistas do domínio, foi realizado um estudo de caso com a finalidade de avaliar o desempenho do sistema durante o processamento de um conjunto de laudos médicos textuais artificiais. Na Seção 7.2 é descrita a avaliação experimental realizada neste estudo de caso. Nas Seções 7.3 e 7.4 são apresentadas a definição do Arquivo de Padronização (AP) e da stoplist, respectivamente. Na Seção 7.5 são descritos os atributos da base de dados e a forma de estruturação de Regras de Mapeamento (RM). Na Seção 7.7 é demonstrada a aplicação do método de mapeamento por ontologias. Na Seção 7.6 são apresentadas as principais características da ontologia utilizada pelo SCC para este estudo de caso, a qual foi proposta em (Lee, Monard, Honorato, Lorena, Ferrero, Maletzke, Zalewski, Coy, Fagundes and Chung, 2011). 95

122 Avaliação Experimental do SCC Neste trabalho, a avaliação experimental do sistema computacional desenvolvido foi realizada em um conjunto de 100 laudos médicos artificiais que simulam relatórios de exames de Endoscopia Digestiva Alta (EDA). Esses exames são usados por especialistas em processos de diagnóstico de enfermidades que acometem o esôfago, o estômago e/ou o duodeno (Cordeiro, 1994; Cotran, Kumar and Collins, 1996). Os documentos utilizados nessa avaliação experimental contêm um total de 400 frases e palavras. Os laudos artificiais apresentam a seguinte estrutura: Cabeçalho: indica a porção anatômica analisada e geralmente está presente na primeira linha do texto e escrito em caixa-alta; Observações: são sentenças que descrevem anormalidades e/ou outras características observadas em uma determinada região e são precedidas pelo caractere traço (-). Na Figura 7.1 é apresentado um exemplo de laudo textual artificial de exame de EDA da seção de esôfago, no qual a parte destacada na cor vermelha é o cabeçalho e na cor verde são as observações. Figura 7.1: Exemplo de laudo textual de exame EDA da região do esôfago. De acordo com as informações apresentadas na Figura 7.1 é possível notar que não foram identificadas anormalidades na região do esôfago por intermédio do exame de EDA. Nessas observações, o calibre se refere ao diâmetro interno do esôfago, a distensibilidade é a capacidade de ampliação (elasticidade) de um tecido, a motilidade está relacionada à capacidade de um órgão de executar movimentos autônomos e a TEG é o limite entre o esôfago e o estômago. Conforme mencionado, o PMLM é realizado em duas fases. É importante lembrar que ao se realizar o processo pela primeira vez para um conjunto de laudos de um determinado domí-

123 97 nio, é necessária a realização de todas as tarefas associadas ao processo, incluindo a construção do Arquivo de Padronização (AP), da stoplist e da ontologia. Na primeira fase, as frases de todos os documentos selecionados foram concatenados e ordenados alfabeticamente em um único arquivo. Em seguida, todas as frases repetidas foram eliminadas, originando o Conjunto de Frases Únicas (CFU), o qual contém uma entrada para cada frase distinta. Depois, foi executada a técnica de normalização para a redução da variação de caracteres por meio da substituição de todas as letras maiúsculas e/ou acentuadas por caracteres minúsculos e sem acentuação, resultando no CFU Normalizado. Após, foi definida uma lista de termos considerados irrelevantes, conforme apresentada na Seção 7.4. Essa stoplist foi aplicada no CFU Normalizado por meio da técnica de remoção de stopwords, gerando o CFU Normalizado e sem Stopwords. Em seguida, esse grupo de sentenças foi submetido à transformação por intermédio do método de lematização, concebendo o CFU Lematizado e sem Stopwords. Posteriormente, foram definidas Regras de Padronização (RP) a partir da análise dos CFU gerados anteriormente, construindo o AP, conforme apresentado na Seção 7.3. Essas regras foram determinadas para transformar as sentenças de modo que sejam representadas no formato local-característica-subcaracteristica ou local-característica com o propósito de facilitar a definição de RM, como apresentada na Seção 7.5. A aplicação do AP no último conjunto de frases gerados concebeu o CFU Padronizado. Depois da construção de todos os CFU, as frases foram analisadas com o intuito de definir as variáveis e os valores da tabela atributo-valor (base de dados), bem como a estrutura da ontologia, como apresentadas nas Seções 7.5 e 7.6, respectivamente, para a representação do conhecimento presente nos laudos médicos utilizados neste trabalho por intermédio dessas estruturas. Na segunda fase, o conjunto de laudos médicos utilizado na construção de CFU foi submetido à aplicação de técnicas de processamento de textos com o propósito de transformá-los para uma representação adequada para a execução do método de mapeamento. Para isso, foram usadas as estruturas como a stoplist e o AP definidas anteriormente. Sendo assim, nesses documentos foram efetuadas sequencialmente as seguintes técnicas: normalização, remoção de stopwords, lematização e padronização. Posteriormente, as informações presentes nos laudos padronizados foram mapeadas para a base de dados. Esse mapeamento foi conduzido de duas formas: manual, que é realizado manualmente para uma planilha do Microsoft Excel c ; e automático, o qual é aplicado por intermédio do SCC. Após a realização do mapeamento, manual e automática, no conjunto de laudos médicos, para a avaliação dos resultados da aplicação do PMLM por ontologias foram calculados:

124 98 Medidas estatísticas para os termos e as frases dos CFU gerados durante a aplicação de técnicas de processamento na primeira fase do PMLM, como média, desvio-padrão, mínimo e máximo; Custo computacional da aplicação de cada técnica utilizada para a construção de CFU; Custo computacional da aplicação da primeira fase do PMLM; Porcentagem de atributos mapeados para a base de dados; Porcentagem de laudos que apresentaram termos não-processados; Incidência de termos não-processados; Custo de tempo para o mapeamento manual; Custo computacional para o mapeamento automático; Custo computacional da aplicação do PMLM por meio do SCC. 7.3 Construção do Arquivo de Padronização Para trabalhar com um vocabulário controlado e possibilitar que as informações estejam em formato adequado para a construção de Regras de Mapeamento (RM) que irão compor uma ontologia, como a apresentada na Seção 7.6, deve ser definido o AP por intermédio da elaboração de RP. Nesse sentido, neste trabalho foram definidas, em conjunto com especialistas, 81 RP com a finalidade de uniformizar as frases para o formato local-característica-subcaracterística ou local-característica. Dessas regras, 66 são do tipo um para um (um termo antigo é substituído por um termo novo) e 15 são do tipo um para vários (um único termo antigo é substituído por vários termos novos simultaneamente). Para a elaboração de RP, também foram utilizadas Expressões Regulares (ER) com o intuito de identificar características em palavras ou frases, como espaço em branco excedentes, para padronizá-las adequadamente. Essas RP são apresentadas no Apêndice A.2. Na Figura 7.2 é ilustrado um fragmento do AP elaborado neste trabalho. No fragmento de AP apresentado na Figura fig:apec são apresentados três exemplos de RP para a aplicação da padronização de laudos textuais. A primeira RP é aplicada para a substituição da palavra "enantemo" pela sequência "presenca_edema sim", transformando a frase para o formato local-característica-subcaracterística, sendo que esse termo antigo geralmente é precedido por uma palavra que determina uma porção anatômica, por exemplo, "esofago inferior enantemo". A frase antiga da segunda RP determina que todas as porções do esôfago apresentam pelo menos uma enfermidade, as quais não são descritas explicitamente. Nesse caso, a regra é

125 99 Figura 7.2: Fragmento do AP desenvolvido no Estudo de Caso. aplicada para a substituição da sentença antiga por outras três no formato local-característica, determinando que existem anormalidades nas três porções do esôfago. A terceira RP apresentada na Figura 7.2 é uma das regras que tem o propósito de transformar a descrição da extensão da TEG (transição esôfago-gástrico) medida em centímetros para grau de anormalidade. Assim, essa porção é considerada normal quando se encontra no mesmo nível ou até 0,50 cm acima do pinçamento diafragmático do esôfago, grau 1 ("gi") quando é localizada entre 1,00 cm e 2,99 cm acima, grau 2 ("gii") para valores de 3,00 cm até 4,49 cm, grau 3 ("giii") para valores de 4,50 cm até 6,00 cm e grau 4 ("giv") para valores a partir de 6,01 cm. Essa RP contém ER para identificação de padrões em sentenças de laudos textuais, na qual ".*" determina que pode existir nenhum, um ou mais caracteres de qualquer tipo ("."). Ainda, a expressão "[,.]" determina que pode existir ou não os caracteres "," ou ".", "s*" estabelece que pode haver zero ou mais espaços em branco e "[acima]" descreve que pode existir ou não o termo "acima". Nesse contexto, as RP foram desenvolvidas para serem aplicadas em laudos textuais lematizados e sem stopwords devido a menor variabilidade de frases, facilitando a construção dessas regras. 7.4 Elaboração da Stoplist Neste estudo de caso foi definida, em conjunto com especialistas, uma stoplist contendo 59 termos considerados irrelevantes nesse contexto, na qual são incluídas pronomes, preposições, advérbios, entre outros. Essa transcrição foi realizada por meio da análise do CFU Normalizado. Na Figura 7.3 é ilustrada a definição da lista de stopwords a partir de um fragmento

126 100 de CFU Normalizado, na qual, o usuário identifica o termo considerado irrelevante e o sistema armazena-o na stoplist. Figura 7.3: Exemplo de transcrição de stopwords. Sendo assim, a stoplist definida neste trabalho é apresentada com as suas stopwords organizadas em ordem alfabética crescente no Apêndice A.1, no qual essa lista é exibida utilizando estruturas determinadas na linguagem de marcação XML. 7.5 Definição de Atributos da Base de Dados e de Regras de Mapeamento Após a construção dos CFU, as informações geradas são analisadas com o intuito de definir a estrutura da base de dados, ou seja, a tabela atributo-valor do SCC. Para isso, foram definidos, em conjunto com especialistas, dezesseis atributos representativos com a finalidade de descrever informações relevantes presentes em laudos textuais médicos de EDA. Essas propriedades foram divididas em três grupos de acordo com os seus respectivos tipo de valores, que são apresentados na Seção 7.6. Desse modo, foram definidos nove atributos para a representação dos valores "sim" e "nao" (Grupo 1). Essas características tem a finalidade de representar a presença ou a ausência de enfermidades inflamatórias nas porções de esôfago inferior, médio e superior, as quais são apresentadas a seguir: esofagite_edematosa_inferior: edemas na região do esôfago inferior; esofagite_edematosa_medio: edemas no esôfago médio; esofagite_edematosa_superior: edemas no esôfago superior; esofagite_erosiva_inferior: erosões no esôfago inferior; esofagite_erosiva_medio: erosões no esôfago médio; esofagite_erosiva_superior: erosões no esôfago superior;

127 101 esofagite_ulcerada_inferior: úlceras no esôfago inferior; esofagite_ulcerada_medio: úlceras no esôfago médio; esofagite_ulcerada_superior: úlceras no esôfago superior. Os atributos que contém os valores "normal" ou "anormal" (Grupo 2) tem o propósito de determinar se as porções do esôfago (inferior, médio e superior) e as características como calibre, distensibilidade e motilidade apresentam anormalidade, correspondendo no total de seis atributos, que são apresentados a seguir: calibre_esofago: diâmetro interno do esôfago; distensibilidade_esofago: elasticidade do tecido do esôfago; motilidade_esofago: capacidade do esôfago de realizar movimentos autônomos; mucosa_esofago_inferior: condição do esôfago inferior; mucosa_esofago_medio: situação do esôfago médio; mucosa_esofago_superior: estado do esôfago superior. Para o grupo de valores "normal", "gi", "gii", "giii" e "giv" (Grupo 3) foi definido apenas um atributo, que é denominado teg_extensao e tem o propósito de determinar se a largura da teg é normal ou caso contrário, apresentar o grau da gravidade de enfermidade. Paralelamente à atividade de definição de atributos, foram definidas as suas respectivas RM, que são foram elaboradas para mapear frases no formato local-característica e localcaracterística-subcaracterística. Para os atributos do Grupo 1, as RM foram definidas para mapear frases que apresentam: Uma porção do esôfago (inferior, médio, superior), como região; Presença ou ausência de enfermidade do tipo edema, erosão ou úlcera, na forma "presenca_anormalidade", como característica; Subcaracterística: "sim" ou "não". Para os atributos do Grupo 2, as RM foram apresentadas na forma local-característicasubcaracterística para a descrição de características do esôfago inteiro, como o calibre, a distensibilidade e motilidade e para a apresentação da situação de uma porção do esôfago e da propriedade do Grupo 3, a RM apresenta o formato local-característica. A seguir são apresentados exemplos de RM para alguns atributos descritos anteriormente: esofagite_edematosa_inferior:

128 102 "esofago_inferior presenca_edema nao"; "esofago_inferior presenca_edema sim". calibre_esofago: "esofago calibre normal"; "esofago calibre anormal". mucosa_esofago_medio: "esofago_medio normal"; "esofago_medio anormal". teg_extensao: "teg normal"; "teg gi"; "teg gii"; "teg giii"; "teg giv". É importante destacar que os atributos e as RM são representadas por meio de uma ontologia, como a apresentada na Seção 7.6. Também, a base de dados é preenchida apenas após o mapeamento dos laudos textuais, com base nas características determinadas para a tabela atributo-valor. 7.6 Ontologia Construída no Estudo de Caso Para a representação de atributos e de seus respectivos RM em uma ontologia, foi utilizada a linguagem OWL devido ao grande poder de expressividade, à inclusão de todos os recursos da linguagem OWL e a garantia de completude computacional e de operação de expressões por computadores em tempo finito. Sendo assim, nesse sistema é utilizado o esquema de ontologia proposto por Costa, Ferrero, Lee, Coy, Fagundes and Chung (2009), que é organizado pelas seguintes classes (Figura 7.4): Thing: é a principal classe de todas as ontologias estruturadas na linguagem OWL; Valor_de_Atributo: determina os valores dos atributos que deverão ser utilizados para o preenchimento da base de dados;

129 103 Grupo_va_1: é uma subclasse de Valor_de_Atributo que apresenta os valores "nao" e "sim"; Grupo_va_2: é uma subclasse de Valor_de_Atributo que descreve os valores "normal" e "anormal"; Grupo_va_3: é uma subclasse de Valor_de_Atributo que determina os valores "normal", "gi" (grau 1), "gii" (grau 2), "giii" (grau iii) e "giv" (grau 4); Atributo_Base_de_Dados: representa os atributos da base de dados; Atributo_Tipo_va_1: é uma subclasse de Atributo_Base_de_Dados que descreve os atributos que são preenchidos pelos valores de Grupo_va_1; Atributo_Tipo_va_2: é uma subclasse de Atributo_Base_de_Dados que determina os atributos que são preenchidos pelos valores de Grupo_va_2; Atributo_Tipo_va_3: é uma subclasse de Atributo_Base_de_Dados que estabelece os atributos que são preenchidos pelos valores de Grupo_va_3; Termo: é destinada para a representação de termos presentes nos laudos pré-processados; Regiao: é uma subclasse de Termo que descreve as regiões do corpo humano; Observacao: é uma subclasse de Termo que relata as características e as subcaracterísticas que foram observadas nas regiões representadas pela classe Regiao; Caracteristica: é uma subclasse de Observacao que representa as informações relevantes que podem ser mapeadas em laudos textuais; Situacao: é uma subclasse de Observacao que descreve as subcaracterísticas, também denominadas informações complementares; Anormalidade: é uma subclasse de Situacao que determina as anormalidades descritas em laudos médicos; Outra_Situacao: é uma subclasse de Situacao que apresenta outras informações complementares. Na ontologia apresentada na Figurafig:ontologiaOWL, as classes são representadas de forma hierárquica e os indivíduos como atributos, possíveis valores, regiões anatômicas e observações são instanciados nas subclasses de níveis mais baixos da hierarquia da estrutura, como Anormalidade, Outra_Situacao, Caracteristica, Regiao e as subclasses relacionadas aos atributos. Para auxiliar na organização do conhecimento presente em laudos médicos por ontologia foram definidas propriedades para desempenhar relacionamentos entre os indivíduos dessa estrutura (Figura 7.6). Assim, uma dessas propriedades de dados é a denominada nomeinstancia, que tem o propósito de descrever um termo para cada elemento, como palavras de laudos

130 104 Figura 7.4: Hierarquia de classes da ontologia proposta por Costa, Ferrero, Lee, Coy, Fagundes and Chung (2009). textuais pré-processados, atributos da base de dados e possíveis valores para cada tipo de atributo. Essa característica se encontra presente em todas as instâncias de classes. Também, foram definidas as seguintes propriedades de objeto: observacao: contém os indivíduos que descrevem características e subcaracterísticas em RM; regiao: representa as instâncias que determinam as porções anatômicas em RM; valor_da_observacao: apresenta o valor a ser preenchido na tabela atributo-valor caso seja mapeada uma determinada RM. Essa propriedade é associada aos elementos pertencentes às classes Anormalidade e Outra_Situacao; valor_padrao: determina um valor a ser preenchido em um atributo da tabela atributovalor caso o mesmo não seja mapeado. Essa propriedade, assim como a observacao e a regiao são aplicadas nas instâncias pertencentes às classes Grupo_va_1, Grupo_va_2 e Grupo_va_3. Também, cada instância é referenciada pela propriedade rdf:about, a qual é utilizada por métodos e ferramentas que processam ontologias OWL para identificar cada componente dessa

131 105 estrutura, como indivíduos, classes e propriedades. Essas referências são atribuídas automaticamente pelo SCC de forma que seja facilmente legível em nível de código por desenvolvedores de ontologias que utilizam a linguagem OWL, permitindo desse modo a intercomunicação, quando necessário, entre ontologias criadas em ferramentas como o Protege e o SCC desenvolvido neste trabalho. Na Figura 7.5 é apresentado o exemplo de ontologia ilustrado na Figura 7.4 com uma instância para cada classe do nível mais baixo dessa hierarquia. Nessa Figura, os retângulos com presença de um círculo de cor alaranjada são classes e os com presença de um prisma de cor roxa são indivíduos instanciados em suas respectivas classes. Figura 7.5: Esquema detalhado de ontologia proposta por Costa, Ferrero, Lee, Coy, Fagundes and Chung (2009) com um exemplo de instância para cada classe utilizada para representação de conhecimento. Assim, as referências de elementos instanciados pelas classes Regiao, Caracteristica, Anormalidade e Outra_Situacao são traduzidas no formato classeindividuo_numeroindividuo, no qual classeindividuo corresponde à classe em que o item se encontra instanciado e numeroindividuo determina a i-ésima instância cadastrada em uma classe da ontologia. Por exemplo: regiao_01, caracteristica_01, anormalidade_01 e outra_situacao_01. As instâncias das classes Grupo_va_1, Grupo_va_2 e Grupo_va_3 são atribuídas no formato valor_de_atributo_x_numeroindividuo, em que x é uma referência ao grupo de valores em que o atributo encontra-se instanciado e pode conter apenas os valores "1", "2" ou "3", por exemplo, valor_de_atributo_1_01, que representa o valor de atributo "nao".

132 106 Os indivíduos das classes Atributo_Tipo_va_1, Atributo_Tipo_va_2 e Atributo_Tipo_va_3 são iguais aos respectivos valores atribuídos pela propriedade nomeinstancia, pois representam os atributos da tabela atributo-valor e as suas respectivas RM. Essas instâncias são definidas de acordo com os grupo de valores que foram escolhidos para o preenchimento de seus atributos na base de dados, por exemplo, se um atributo for do tipo Grupo_va_1, o indivíduo que o representa será instanciado na classe Atributo_Tipo_va_1. Desse modo, as propriedades de objetos são aplicadas nas instâncias que contêm os atributos com a finalidade de representar as RM. Abaixo é apresentado um exemplo de atributo com as suas propriedades: nomeinstancia: "calibre_esofago"; regiao: "esofago" (regiao_01); valor_padrao: "normal" (valor_de_atributo_2_02); observacao: "calibre" (caracteristica_01); observacao: "anormal" (anormalidade_01); observacao: "normal" (outra_situacao_01); Na Figura 7.6 é apresentado o atributo "calibre_esofago" representado na linguagem OWL, no qual owl:thing é um construtor para a definição de indivíduos, rdf:type é uma propriedade aplicada para estabelecer as classes relacionadas com o indivíduo, NamedIndividual é a classe de todas as instâncias que são definidas pelo construtor owl:thing, rdf:resource é uma propriedade semelhante à rdf:about que é utilizada para determinar o nome de uma classe ou de uma outra instância. Figura 7.6: Exemplo de atributo representado na linguagem OWL. Nesse contexto, o SCC determina implicitamente os indivíduos para as classes Regiao, Grupo_va_1, Grupo_va_2 e Grupo_va_3, nas quais não é permitido que os usuários definam novos elementos. Os nomes das instâncias de Regiao são:

133 107 "esofago" (regiao_01); "esofago_inferior" (regiao_02); "esofago_medio" (regiao_03); "esofago_superior" (regiao_04); "teg" (regiao_05); "terco_distal" (regiao_06); "terco_medio" (regiao_07); "terco_proximal" (regiao_08). Os itens de Grupo_va_1 são nomeados com valores como: "nao" (valor_de_atributo_1_01); "sim" (valor_de_atributo_1_02). Os elementos de Grupo_va_2 são identificados como: "normal" (valor_de_atributo_2_01); "anormal" (valor_de_atributo_2_02). As instâncias de Grupo_va_3 possuem nomes como: "normal" (valor_de_atributo_3_01); "gi" (valor_de_atributo_3_02); "gii" (valor_de_atributo_3_03); "giii" (valor_de_atributo_3_04); "giv" (valor_de_atributo_3_05). Na Figura 7.7 é apresentado um exemplo de esquema de ontologia expandida na classe Regiao. Para as classes Caracteristica, Anormalidade, Outra_Situacao e as subclasses de Atributo_Base_de_Dados, os indivíduos são criados após a definição de um novo atributo por meio de uma tela acessível pela funcionalidade "Conjunto de Atributos" do SCC apresentada na Figura Antes da gravação de novos elementos, na ontologia é verificada a existência de um indivíduo nas subclasses de Atributo_Base_de_Dados com o nome igual ao do atributo em

134 108 Figura 7.7: Exemplo de esquema de ontologia criada automaticamente pelo SCC com a classe Regiao expandida. definição. Caso seja inexistente, é criada uma nova instância para representar o novo atributo. Também, os termos que representam características e subcaracterísticas na RM são analisados com a finalidade de verificar se foram cadastrados na ontologia. Assim, são criadas instâncias da classe Caracteristica para os termos que descrevem características, da classe Anormalidade para as observações que apresentam o valor "sim", "anormal", "gi", "gii", "giii" ou "giv" e da classe Outra_Situacao para as observações que contém o valor "nao" ou "normal". 7.7 Aplicação do Método Mapeamento por Ontologias em Laudos Médicos Artificiais Com base na estrutura apresentada na Figura 7.4, o PMLM é aplicado em cada cadeia de caracteres presente em um conjunto de laudos médicos. Nesse sentido, ao processar uma frase, o método primeiramente compara cada termo presente na sentença com a informação contida na propriedade nomeinstancia de cada indivíduo das subclasses de Termo com o propósito de verificar se a palavra analisada foi cadastrada na ontologia por meio de RM. Caso o vocábulo não seja encontrado na estrutura, o mesmo é adicionado à lista de termos não-processados, o qual pode ser utilizado posteriormente para a definição de novas RP e RM. Após, nas subclasses de Atributo_Base_de_Dados são analisadas as respectivas instâncias para localizar os atributos que contém RM compatíveis com as palavras da frase que foram localizadas na ontologia e preencher a tabela atributo-valor com o valor dos elementos presentes nas subclasses de Valor_de_Atributo. Por exemplo, na frase "esofago calibre normal", para cada termo, primeiramente o algo-