Você está na página 1de 114

UNIVERSIDADE DE PERNAMBUCO ESCOLA POLITÉCNICA DE PERNAMBUCO PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO

Legilmo Marcelo Fontes de Oliveira

Uma abordagem orientada a modelos no desenvolvimento de sistemas clínicos baseado em arquétipos

Dissertação de Mestrado

Recife, 2012.

UNIVERSIDADE DE PERNAMBUCO ESCOLA POLITÉCNICA DE PERNAMBUCO PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO

Legilmo Marcelo Fontes de Oliveira

Uma abordagem orientada a modelos no desenvolvimento de sistemas clínicos baseado em arquétipos

Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Engenharia da Computação da Universidade de Pernambuco, como requisito parcial para obtenção do Título de Mestre em Engenharia da Computação.

Orientador: Prof. Dr. Vinicius Cardoso Garcia

Recife, 2012.

Dedico este trabalho as pessoas que sempre estiveram ao meu lado, meus filhos (Mariela, Fernanda e Daniel) e esposa Daniela. Pelo amor incondicional, pelo apoio nas minhas decisões, pela força transmitida que me encoraja a enfrentar os momentos difíceis.

AGRADECIMENTOS
Os meus sinceros agradecimentos são destinados:  Aos meus pais, Lélia Oliveira e João Gilberto, que em toda minha vida me incentivaram a crescer com conhecimento. Em especial, a minha mãe pelos conselhos, incentivos e cuidados contínuos;  Aos meus irmãos: João Gilberto, Wellington Andre e Gíllia Valeria pelo companheirismo. Agradeço principalmente à minha irmã Gíllia, pelo seu exemplo de luta, pelo apoio, incentivo e união de sempre;  À minha esposa, Daniela Eugenia, que me ajudou desde a inscrição do mestrado, e que esteve presente em todas as etapas, até o final. Para cada “vai conseguir!” dita, por me tranquilizar nos meus momentos de estresse, por me alegrar, por me fazer feliz e muitas vezes e efetuar o meu papel de pai dos nossos filhos, suprindo a minha ausência por causa da minha dedicação ao mestrado;  Aos meus filhos Mariela, Fernanda e Daniel. A presença de vocês na minha vida é um estímulo de energia. Foi em vocês que ganhei forças para ultrapassar cada dificuldade encontrada durante o mestrado;  À minha família em geral, tios e primos. Em especial a minha tia Ivone, que é uma referência de conhecimento e experiência, fornecendo informações essenciais nas minhas escolhas;  Aos amigos, Jose Damaricio, Marcos Pereira, Felipe Leão, Christian Lins, Rafael Oliveira, Guilherme Camacho e Priscila Alcantara pelas experiências compartilhadas durante esses anos. Em especial, a Jose Damaricio pelas orientações, sugestões técnicas, companheirismo e contínua colaboração;     Aos casais da igreja, que vêm nos apoiando nas nossas ausências dos encontros e eventos religiosos e sociais; A minha sogra e ao meu sogro: Lucineide e Antonio, pelo apoio dado e o preenchimento do vazio que deixo em casa por causa da minha ausência pelo envolvimento no mestrado; A todos os entrevistados que influenciaram diretamente o resultado deste trabalho; Aos amigos da UPE, Eric Souza, Ariane Nunes, Maurício Manoel, Anthony Lins e Fernando Wanderley pelas experiências compartilhadas durante as disciplinas. Em

iv

especial, a Fernando Wanderley pelas orientações, paciência, companheirismo e contínua colaboração;     Ao meu orientador, Vinicius, que me acolheu, acreditou em mim e orientou durante estes anos; Aos membros da banca examinadora, Daniel Lucrédio, Maria Lencastre com seus valiosos comentários durante a defesa ajudaram a enriquecer muito este trabalho; A todos os professores do programa de pós-graduação em Engenharia da Computação da Universidade de Pernambuco por todos os ensinamentos recebidos; Aos membros da equipe do CESAR que faço parte, Walter Jardim, Felipe Evangelista, Marcelo Goncalves, Wilton Oliveira, Paloma Nunes, Liane Bandeira, Amaro Elton, Carlos Gomes e Allan Araujo pela compreensão e apoio no andamento do mestrado;  Às instituições que fizeram com que esta trajetória fosse possível. Estas incluem a UPE, por ter sido a minha casa durante estes anos, à CAPES que em diversos momentos me ajudou financeiramente, espero ter correspondido e continuar correspondendo à altura este investimento em mim realizado.  Agradeço a Deus por me iluminar, guiar meus passos, por me dar forças dia a dia para concluir mais uma caminhada. Obrigado a todos !

v

Nada poderá me abalar, nada poderá me derrotar, pois minha força e vitória têm um nome e é Jesus... Sandro Andrade

vi

RESUMO
A área da saúde vem recebendo investimentos em todo mundo para o desenvolvimento de sistemas de informação que proporcionam apoio às suas atividades. No entanto, existem ainda alguns desafios a serem enfrentados para que o processo de desenvolvimento destes sistemas tenha maior produtividade e qualidade. O desenvolvimento de ambientes para a implementação de sistemas de informações de saúde apresenta alguns desafios, dentre os quais a complexidade dos processos de cuidado à saúde se destaca. Neste contexto, a tentativa de minimizar a complexidade no aprendizado do domínio clínico e a necessidade de aumentar a produtividade e a qualidade na construção dos sistemas de informação de saúde (Healthcare Information System – HIS) surge como requisitos essenciais. Para diminuir a complexidade dos Processos de Cuidado a Saúde e aumentar a produtividade e qualidade na construção dos HIS, a adoção de arquétipos integrada a uma abordagem de desenvolvimento orientada a modelos aparecem como uma alternativa potencial para resolver esses problemas. Conforme definido, arquétipos são fatias de conhecimento que apontam como representar conceitos ou informações de um determinado domínio. Adicionalmente, as abordagens orientadas a modelos apresentam um potencial relevante para lidar de forma adequada com esses desafios pelo fato de oferecerem um nível mais alto de abstração no desenvolvimento de software. Tal característica proporciona, entre outros benefícios: reusabilidade, portabilidade e

interoperabilidade, aumentando a produtividade do processo e a qualidade das aplicações. Neste contexto, este trabalho de mestrado apresenta uma abordagem, referente ao desenvolvimento dirigido a modelos (Model-Driven Development – MDD) na confecção de aplicações para o Cuidado de Saúde do paciente baseada em arquétipos clínicos. Com a adoção de MDD, a abordagem proposta é composta por um conjunto de atividades que visam ajudar e aumentar a produtividade das equipes no desenvolvimento de sistemas clínicos.

Palavras-chave: MDE, MDD, MDA, Arquétipo clínico, MOFScript

vii

ABSTRACT
The health sector has received investments worldwide for the development of information systems that provides support for its activities. However, there are still some challenges to be faced in these systems development process to have higher productivity and quality. The environments developments for the health information systems implementation present some challenges, among which the complexity of health care process stands out. In this context, the attempt to minimize the learning complexity in the clinical domain and the need to improve productivity and quality in the construction of information systems in healthcare (Healthcare Information System - HIS) emerges as essential requirements. To decrease the complexity of health care processes to increase productivity and quality in the construction of HIS, adoption of archetypes integrated approach to development-oriented models appear as a potential alternative to solve these problems. As defined, archetypes are knowledge parts that suggest how to represent concepts or information from a specific domain. Models driven approaches are potentially relevant to deal adequately with these problems because they offer a higher level of abstraction in software development. This feature provides some benefits: reusability, portability and interoperability, improving process productivity and applications quality. In this perspective, this master degree work presents an approach, referring to the model-driven development (Model-Driven Development - MDD) for the Patient Health Care applications development based on clinical archetypes. With MDD adoption, the approach proposal consisting on a set of activities that aim to help and increase the productivity of teams in the clinical systems development.

Keywords: MDE, MDD, MDA, Clinical Archetype, MOFScript

viii

LISTA DE FIGURAS
Figura 1. Projeto de Especificação openEHR (OPENEHR, 2011) ....................................................................... 22 Figura 2. Informação x Arquétipos ....................................................................................................................... 24 Figura 3. Estrutura de pacotes (OPENEHR, 2011) ............................................................................................... 25 Figura 4. Pacote Core RM (OPENEHR, 2011) ..................................................................................................... 25 Figura 5. Visão dos pacotes do patterns (OPENEHR, 2011) ................................................................................ 27 Figura 6. Pacotes pertencentes ao domain (OPENEHR, 2011) ............................................................................. 28 Figura 7. Modelo de informação EHR (OPENEHR, 2011) .................................................................................. 28 Figura 8. Relacionamento das informações para o Processo de Investigação (OPENEHR, 2011) ....................... 30 Figura 9. Modelo Dados Demográficos (OPENEHR, 2011) ................................................................................ 31 Figura 10. Estrutura do Pacote AM (OPENEHR, 2011) ....................................................................................... 32 Figura 11. Estrutura ADL (OPENEHR, 2011)...................................................................................................... 33 Figura 12. ADL Dados do Paciente (OPENEHR CKM, 2011)............................................................................. 34 Figura 13. Mapa Mental de Temperatura Corporal (OPENEHR CKM, 2011) ..................................................... 36 Figura 14. Processo de Criação de Software (LUCRÉDIO, 2009) ....................................................................... 38 Figura 15. Representação das iniciativas de Moden-Driven (AMELLER, 2009) ................................................. 42 Figura 16. Níveis de abstrações de MDA ............................................................................................................. 42 Figura 17. Fluxo de Transformação Geral ............................................................................................................ 43 Figura 18. Quatro Camadas da Arquitetura do Metamodelo (LIDDLE, 2010)..................................................... 45 Figura 19. Exemplo de preenchimento de tagged value no modelo ...................................................................... 48 Figura 20. Interface da ferramenta UML Papyrus ................................................................................................ 51 Figura 21. Exemplo de HTML com Jquery Mobile .............................................................................................. 54 Figura 22. Linha do tempo HTML ........................................................................................................................ 55 Figura 23. Exemplo de Código HTML5 ............................................................................................................... 56 Figura 24. Definição e Exemplo de CSS............................................................................................................... 57 Figura 25. Linha do Tempo CSS (W3C)............................................................................................................... 57 Figura 26. Modelo e Exemplo de JSON ............................................................................................................... 59 Figura 27. Plataformas suportadas com FPG (PHONEGAP FRAMEWORK, 2012)........................................... 60 Figura 28. Características suportadas pelo FPG x Sistemas Operacionais dos dispositivos móveis (PHONEGAP FRAMEWORK, 2012) ................................................................................................................................. 61 Figura 29. Histórico anual do FPG ....................................................................................................................... 62 Figura 30. Visão geral do Build PhoneGap (Build PhoneGap, 2012) ................................................................... 63 Figura 31. Protocolo Definido para a Pesquisa ..................................................................................................... 66 Figura 32. Fluxo do Processo da Pesquisa ............................................................................................................ 68 Figura 33. Ordem e Resultados da Aplicação dos Critérios .................................................................................. 69 Figura 34. Visão da Abordagem Proposta ............................................................................................................ 73 Figura 35. Etapas da abordagem ........................................................................................................................... 75

ix

Figura 36. Diagrama do Macroprocesso - Engenharia de Domínio ...................................................................... 76 Figura 37. Diagrama do Macroprocesso - Engenharia de Aplicação .................................................................... 77 Figura 38. Processo Proposto para Engenharia de Domínio ................................................................................. 78 Figura 39. Exemplo de Modelo Conceitual Refinado ........................................................................................... 80 Figura 40. Projeção do Modelo Conceitual para Modelo de Domínio .................................................................. 81 Figura 41. Diagrama de Classe do perfil UML ..................................................................................................... 82 Figura 42. Tela inicial ........................................................................................................................................... 83 Figura 43. Modelo Domínio x trecho código MOFScript x HTML gerado .......................................................... 84 Figura 44. Diagrama de Processo EA ................................................................................................................... 87 Figura 45. Mapas mentais do SOT (OPENEHR CKM, 2011) .............................................................................. 87 Figura 46. Diagrama de Casos de Uso do SOT ..................................................................................................... 88 Figura 47. Diagrama de Sequência para registrar Temperatura Corporal ............................................................. 89 Figura 48. Trecho de Código Gerado da Tela em HTML5 ................................................................................... 90 Figura 49. Trecho de código da Tela inicial do aplicativo SOT............................................................................ 91 Figura 50. SOT em execução ................................................................................................................................ 92 Figura 51. Visão Funcional do aplicativo SASVM ............................................................................................... 93 Figura 52. Alguns Mapas Mentais do SASVM..................................................................................................... 94 Figura 53. Diagrama de Casos de Uso do SASVM .............................................................................................. 96 Figura 54. Diagrama de sequência do caso de uso Consultar Histórico do Sinal Vital......................................... 97 Figura 55. Mapeamento de Modelo conceitual para Modelo de Domínio ............................................................ 98 Figura 56. Trecho de código HTML5 e JavaScript Gerados................................................................................. 99 Figura 57. Testes do registro de Sinais Vitais e Medidas do SASVM ................................................................ 100 Figura 58. Testes da Consulta do Histórico Sinal Vital – Lado Observador do SASVM ................................... 101 Figura 59. Gráfico LOC Automática x Manual dos CCs .................................................................................... 102

x

LISTA DE TABELAS
Tabela 1. Categoria (tipos) de dados do openEHR ............................................................................................... 26 Tabela 2. Estruturas Genéricas do openEHR ........................................................................................................ 27 Tabela 3. Strings de Busca .................................................................................................................................... 67 Tabela 4. Fontes de Pesquisa ................................................................................................................................ 67 Tabela 5. Critérios de Inclusão e Exclusão de Trabalhos Relacionados ............................................................... 68 Tabela 6. Descrição das classes das facetas por conteúdo .................................................................................... 69 Tabela 7. Classificação das obras de acordo com os tipos .................................................................................... 70 Tabela 8. Regras de Transformação ...................................................................................................................... 85 Tabela 9. Matriz do Resultado dos Formulários Preenchidos ............................................................................. 103

xi

LISTA DE ACRÔNIMOS
AD – Análise de Domínio ADL – Archetype Definition Language AM – Archetype Model AOM – Metamodelos de arquétipos AP – Archetype Profile CBIS– Congresso Brasileiro de Informática de Saúde CCs – Conceitos Clínicos CIM – Modelo Independente da Computação CKM– Clinical Knowledge Manager EA – Engenharia de Aplicação ED – Engenharia de Domínio EHRs – Registros Eletrônicos de Saúde ER – Entidade-Relacionamento FPG – Framework PhoneGap HIS – Health Information Systems JSON– JavaScript Object Notation LOC – Lines of Code M2C – Model to Code M2M – Model to Model M2T – Model to Text MD – Modelar Domínio MDA – Model-Driven Architecture MDD – Model-Driven Development MDE – Model-Driven Engineering MM – Mapas Mentais MOF – MetaObject Facility OCL – Object Constraint Language OWL – Ontology Web Language PEP – Prontuário Eletrônico do Paciente PIM – Modelo Independente de Plataforma PSM – Modelo plataforma específica RES – Registro Eletrônico de Saúde

xii

RM – Reference Model RMOP – Registro Médico Orientado a Problemas SASVM – Sistema de Acompanhamento dos Múltiplos Sinais Vitais e Medidas do Paciente SUS – Sistema Único de Saúde SE – Engenharia de Software SEI – Software Engineering Institute TAM – Technology Acceptance Model TOM – Template Object Model UI – Interface do Usuário UML – Unified Modeling Language XMI – XML Metadata Interchange

xiii

SUMÁRIO
1. Introdução
1.1 1.2 1.3 1.4 1.5 Caracterização do Problema Motivação Objetivos Escopo Negativo Organização do Trabalho 16 17 17 18 20

16

2

Arquétipos
2.1 Fundação openEHR 2.2 Modelo Dual 2.2.1 Modelo de Referência - RM 2.2.2 Modelo Arquétipo - AM 2.3 Archetype Definition Language - ADL 2.4 Mapa Mental 2.5 Síntese do Capítulo 23 23 24 32 33 35 36

21

3

Desenvolvimento Dirigido a Modelos
3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 Definição Histórico Iniciativas Metodologia Unified Modeling Language - UML Metamodelagem Mecanismos de Extensão da UML Perfis UML Transformações de Modelos Síntese do Capítulo 37 40 40 43 44 45 46 48 49 51

37

4

Tecnologias Web
4.1 4.2 4.3 4.4 4.5 4.6 JQUERY Mobile Hypertext Markup Language – HTML Cascading Style Sheets - CSS JavaScript Object Notation - JSON Framework PhoneGap Síntese do Capítulo 52 54 56 58 59 63

52

5. Trabalhos Relacionados
5.1 Introdução 5.2 Método e Protocolo de Busca 5.2.1 Definição das Questões 5.2.2 Realização da Pesquisa 5.2.3 Definição das Fontes de Pesquisas 5.2.4 Seleção dos Estudos 5.2.5 Classificação dos Estudos 5.2.6 Conclusões da Pesquisa 65 66 66 67 67 68 69 70

65

6. Abordagem Proposta
6.1 Objetivos da abordagem 6.2 Visão Geral 6.3 Etapas da Abordagem 6.3.1 Engenharia de Domínio - ED 6.3.2 Engenharia de Aplicação - EA 73 74 77 77 86

72

xiv

7. Estudo de Caso - Sistema
7.1 Engenharia de Aplicação - EA 7.1.1 Análise 7.1.2 Projeto 7.1.3 Implementação 7.1.4 Testes 7.2 Resultados 7.2.1 Lines of Code - LOC 7.2.2 Avaliação 94 94 97 98 100 101 101 102

93

8. Conclusões e Trabalhos Futuros
8.1 8.2 8.3 8.4 8.5 Sumário das Conclusões Contribuições Dificuldades encontradas Limitações Trabalhos Futuros

104
104 105 105 105 106

Referências

107

xv

1. INTRODUÇÃO
Este capítulo motiva e caracteriza o problema a ser resolvido nesta dissertação, apresenta o objetivo a ser atingido, além da definição do escopo negativo. Por fim, descreve a estrutura na qual estão organizados os demais capítulos deste documento.

1.1

C ARACTERIZAÇÃO DO P ROBLEMA
O crescente aumento das exigências por sistemas de qualidade refletem uma maior

exatidão os seus processos organizacionais. Diante desse cenário, a indústria de desenvolvimento de software tem trabalhado com o objetivo de criar novas tecnologias que atendam a tais necessidades (SOUZA; OLIVERA, 2012). Segundo Bergmann (2010), em todo mundo têm sido feitos grandes investimentos para o desenvolvimento de Sistemas de Informação em Saúde (Health Information Systems – HIS), com o objetivo de prover um ganho de produtividade na área da saúde, através da captação dos benefícios proporcionados pelas novas tecnologias utilizadas no

desenvolvimento de software. Portanto, tem sido dada uma considerável atenção ao potencial das abordagens orientadas a modelos no suporte ao desenvolvimento de HIS. Bergmann (2010) menciona também que a tendência global em cuidados de saúde está voltada para modelos de atenção mais centrados no paciente, baseada na manutenção do bemestar, ao invés dos modelos tradicionais centrados no médico que são focados nas doenças. Neste sentido, abordagens orientadas a modelos, tais como: Desenvolvimento Orientado a Modelos (Model-Driven Development – MDD) apresentam um potencial importante para colaborar na melhoria da produtividade do processo e da qualidade do produto de software. MDD é um paradigma de desenvolvimento de sistemas dirigido a modelos que visa aprimorar a forma com que o software é desenvolvido, via a representação das principais características de um sistema em modelos, os quais são construídos e refinados conforme o sistema é desenvolvido (VOELTER; GROHER, 2007). Além disso, MDD possibilita a especificação do sistema de maneira a tornar possível a geração dos artefatos da aplicação de forma automática através de operações de transformações de modelo para texto.

16

Por outro lado, as soluções adotadas no desenvolvimento dos HIS são complexas e mudam constantemente, isto eleva a dificuldade de implementação e manutenção dos HIS (DENNIS, 2009). Neste contexto, o conjunto de especificações proposto pela Fundação openEHR (BEALE,2002) conhecida como Arquétipos, a qual tem o intuito do desenvolvimento de padrões abertos para a construção de HIS, fornece meios para uma separação entre a modelagem da informação e a modelagem de dados clínicos, chamado de modelo Dual, diminuindo assim a complexidade no entendimento dos Conceitos Clínicos. A proposta da Fundação openEHR é, através da confecção do padrão que representa formalmente arquétipo, possibilitar que as especificações dos conceitos clínicos sejam compartilhados e ajudem na confecção dos HIS baseados em conceitos sólidos. Um exemplo da representação de um conceito clínico através de arquétipo é o “Peso Corporal”, que é formada por uma quantidade (valor e unidade) e a data da ocorrência da aferição (NARDON et al, 2011).

1.2

M OTIVAÇÃO
A tentativa de melhorar a produtividade e a qualidade no desenvolvimento dos HIS é

desafiadora por si só. Adicionalmente a isso, desenvolver HIS reduzindo a complexidade é ainda mais estimulante. Com a adoção do desenvolvimento orientado a modelos – MDD espera-se uma melhoria da produtividade dos esforços de desenvolvimento, através da utilização de conceitos que são menos associados à tecnologia de desenvolvimento, e mais próximos do domínio do problema, possibilitando assim a confecção dos HIS realizadas por especialista de domínio e não necessariamente por um especialista em computação.

1.3

O BJETIVOS
O presente trabalho tem o objetivo de confeccionar um ambiente que permita o

aumento da produtividade e a diminuição da complexidade na construção de HIS baseados em conceitos clínicos (arquétipos) através da abordagem de desenvolvimento orientado a modelos.

17

Para alcançar o objetivo desse trabalho, faz-se necessário estabelecer objetivos específicos:  Definir um perfil UML que possibilite a modelagem das informações dos Conceitos Clínicos utilizados nesta pesquisa. A definição de um perfil UML neste trabalho foi estimulada através da criação da openEHR uma iniciativa de modelagem de informações clínicas com arquétipos e perfil UML (Clinical Information Modelling Initiative – CIMI). Esse grupo funciona através de uma colaboração internacional e se dedica a fornecer um formato comum para especificações detalhadas visando a representação do conteúdo de informação de saúde (CIMI, 2011);   Modelar os Conceitos Clínicos de Cuidado à Saúde pertencente ao domínio dos metamodelos clínicos - Arquétipos baseado no perfil UML; Construir programas geradores utilizando uma abordagem Model Driven Development MDD para transformar o modelo de domínio das informações clínicas em artefatos conforme tecnologias adotadas;  Descrever uma abordagem de desenvolvimento baseada nas etapas Engenharia de Domínio - ED com MDD e Engenharia de Aplicação - EA. Durante a etapa ED serão confeccionados artefatos que serão uteis na EA. Um estudo de caso utilizará essa abordagem especificada para construir um protótipo;  Avaliar o ambiente através da realização de um estudo de caso que confecciona um protótipo. Esse protótipo tem a utilização avaliada por analistas de sistemas e estudantes.

1.4

E SCOPO N EGATIVO
Algumas atividades não serão contempladas pelo corrente trabalho, entre elas:

 

Atividades relativas à evolução e/ou manutenção dos artefatos, tais como: gerenciamento de projetos, gerenciamento de configuração ou merge de modelos; Implementação de ferramentas para o desenvolvimento orientado a modelos, com funcionalidades para: o Transformação de modelo para modelo; o Transformação reversa, isto é, transformação de texto para modelo; o Validação dos modelos e validação das transformações; o Desenvolvimento de ferramenta case – UML;

18

   

Transformação dos subconjuntos do metamodelo clínico - arquétipos; Transformação das regras de restrições dos demais subconjuntos do metamodelo clínico arquétipos; Geração de código responsável pela comunicação e segurança entre HIS; Desenvolvimento de artefatos para a disciplina de implantação.

19

1.5

O RGANIZAÇÃO DO T RABALHO
Neste capítulo descreveu-se a caracterização do problema onde foram apresentados os

problemas alvo e metas desta dissertação. Além disso, foi apresentada a motivação da realização da pesquisa, os principais objetivos / metas e a definição de escopo desse trabalho. Na sequência, ilustramos a organização desse documento:

Capítulo 2 - Arquétipos
• São apresentados os principais conceitos e os relevantes modelos;

Capítulo 3 - Desenvolvimento Orientado a Modelos
• São apresentados os conceitos sobre desenvolvimento orientado a modelos, as principais técnicas e abordagem.

Capítulo 4 - Tecnologias WEB
• São apresentados os conceitos sobre as tecnologias WEB utilizadas nessa pesquisa.

Capítulo 5 - Trabalhos Relacionados
• São apresentados os trabalhos relacionados a essa pesquisa, através de uma revisão bibliográfica.

Capítulo 6 - Abordagem Proposta
• É apresentada uma abordagem proposta que será utilizada nessa pesquisa;

Capítulo 7 - Estudo de Caso
• É apresentada de forma detalhada um estudo de caso que utilizada o MDD no desenvolvimento de HIS baseado em arquétipos e apresenta os resultados obtidos na avaliação;

Capítulo 8 - Conclusão
• São descritas de forma conclusiva as contribuições, dificuldades, limitações, trabalhos futuros e considerações finais;

20

2 ARQUÉTIPOS
Neste capítulo são apresentados os principais conceitos e técnicas sobre arquétipos, seus modelos, formas de apresentações em: ADL e Mapa Mental. Em um ponto de vista mais genérico, considerando a definição do termo arquétipo no Dicionário online Merriam-Webster que é: "o padrão original ou modelo do qual todas as coisas do mesmo tipo são representados ou um perfeito exemplo". Conforme definição de Beale (2007), arquétipos são pedaços de conhecimento que indicam como representar conceitos ou informação. Um arquétipo que representa o conceito “temperatura corporal”, por exemplo, pode definir que este conceito é formado por uma quantidade (um número e uma unidade) e por uma data que indica o momento em que a temperatura foi aferida. Arquétipo é a definição formal de combinações prescritas das classes definidas no Modelo de Referência para domínios ou organizações clínicas específicas. Ou seja, arquétipo é uma expressão formal de um conceito distinto em nível de domínio, expresso na forma de restrições sobre os dados cujas instâncias estejam em conformidade com o modelo de referência. Desta forma, a utilização de arquétipos permite compartilhar conceitos e conhecimento clínico, formando sistemas a partir de um conjunto de integração. Esta é a proposta da Fundação openEHR (BEALE, 2007): criar um padrão que permita representar formalmente arquétipos, possibilitando assim que as especificações de conceitos clínicos criadas com este formalismo sejam compartilhadas e resultem na construção de sistemas de informação em saúde fundamentados em conceitos sólidos. Arquétipos são descritos como um modelo formal e reutilizável de um conceito do domínio. Assim, se um conceito é representado por um arquétipo, este conceito pode ser reutilizado nos vários cenários em que ele se aplica. O que torna o uso de arquétipos uma boa alternativa para representação do conhecimento é a concentração de todo o conceito numa única estrutura. Sempre desenvolvido sob a orientação e auxílio de profissionais especialistas da área, o conceito descrito por um arquétipo pode ser visto como o refinamento da ontologia daquele domínio, trazendo benefícios para a comunicação humana, interoperabilidade ao nível conceitual, enriquecimento do domínio e desenvolvimento de sistemas padronizados (BEALE, 2001).

21

Figura 1. Projeto de Especificação openEHR (OPENEHR, 2011) A Figura 1 ilustra o projeto de especificação openEHR. Este projeto é responsável por desenvolver as especificações em que o plataforma computacional openEHR se baseia. As relações entre as partes da plataforma da computação e as especificações são indicadas no diagrama. Os resultados do projeto incluem requisitos, especificações abstratas, especificações de implementação de tecnologia, expressões computáveis e critérios de conformidade. As especificações abstratas consistem no: Reference Model (RM), o Service Model (SM) e Archetype Model (AM). Os RM e AM correspondem aos pontos de vista de informações e computacional, respectivamente. O SM formaliza a ponte entre modelos de informação e recursos de conhecimento. As especificações resumo publicado pela openEHR são definidos usando a notação UML e especificações formais da classe textuais. Estes modelos constituem as referências primárias para toda a semântica openEHR. O estilo de apresentação destas especificações abstratas está deliberadamente à intenção de ser clara e semanticamente próxima das idéias que estão sendo comunicadas. Assim, as especificações não seguem modismos ou limitações de linguagens de programação, linguagens específicas de esquema ou outros formalismos.

22

2.1

F UNDAÇÃO OPEN EHR
A Fundação openEHR (OPENEHR, 2011b) é uma fundação internacional sem fins

lucrativos fundada em 2003 pela equipe da University College London e a companhia australiana Ocean Informatics. A Fundação openEHR é dedicada ao desenvolvimento para área de saúde, tornando essa área aberta. A openEHR tem como foco a pesquisa das necessidades clínicas, criação de especificações e implementações. As especificações assumem a forma de modelos de informação modulares, modelos de serviço e modelos de informação clínica (BEALE, 2001); A Fundação openEHR é dedicada à pesquisa e ao desenvolvimento dos Registros Eletrônicos de Saúde – EHRs, que empregam arquétipos na especificação de uma arquitetura livre baseada numa abordagem de duas camadas (BEALE, 2001), a qual separa o modelo de dados (ou modelo de persistência) do modelo de representação do domínio. Aqui no Brasil, os registros eletrônicos de saúde que possuem as informações dos cuidados a saúde do paciente são conhecidos como Prontuário Eletrônico do Paciente – PEP. Os principais objetivos, destacamos os objetivos do Projeto Arquétipo criado pela openEHR de tornar a tecnologia dos PEPs adaptável e à prova de futuro. Assim, os PEPs devem ser bases confiáveis para possibilitar as suas evoluções por mais de cem anos (BEALE, 2001).

2.2

M ODELO D UAL
O modelo de dados (primeira camada) é simbolizado por um Modelo de Referência

(Reference Model – RM) composto por classes, que representam estruturas genéricas do Registro Eletrônico de Saúde - RES ou de dados demográficos (FREIRE et al., 2008). O modelo de representação do domínio (segunda camada) é composto por regras que restringem o RM e especificam como os conceitos clínicos são usados no RES. Essas regras são definidas pelos arquétipos e essa camada é representada pelo Modelo de Arquétipo (Archetype Model - AM). Sendo o RM mais estável e menos sujeito a alterações que o AM, essa separação habilita o desenvolvimento de “sistemas à prova de futuro” (BEALE, 2001), permitindo os mecanismos de persistência serem pouco alterados e o AM ser afetado pelas alterações de estrutura e de regras de negócio (FREIRE et al., 2008). Neste modelo dual empregado pela openEHR, apenas a primeira camada é implementada em software. Dessa

23

forma, os sistemas tornam-se consideravelmente menores, mais sustentáveis e inerentemente auto-adaptativos, já que são construídos para consumir arquétipos, os quais poderão ser desenvolvidos em qualquer estágio de uso dos mesmos.

Figura 2. Informação x Arquétipos A Figura 2 ilustra que o uso dos arquétipos gera novos relacionamentos entre informações e modelos. Um sistema planejado de maneira clássica, com toda a semântica do domínio codificada no software ou banco de dados, estaria limitado do lado esquerdo da figura e seus dados conforme apenas a um modelo de dados. Com o uso do modelo dual, todos os dados em tempo de execução estão relacionados semanticamente aos arquétipos, expressos em Archetype Definitions Language (ADL), bem como concretamente relacionados ao modelo de referência (BEALE; HEARD, 2007b).

2.2.1 MODELO DE REFERÊNCIA - RM
O Modelo de Referência representa as características globais dos componentes do registro em saúde, como eles são agregados, e a informação contextual necessária para atender aos requisitos éticos, legais e de proveniência. Este modelo define o conjunto de classes que formam os blocos genéricos para construir o Registro Eletrônico de Saúde – RES.

24

Figura 3.Estrutura de pacotes (OPENEHR, 2011) Conforme ilustrado na Figura 3 e descrito em (BEALE; HEARD, 2007b) e também mencionado por MENEZES et al (2011), o RM pode ser dividido em core, patterns e domain, cada um com seus respectivos pacotes e subdivisões.

Figura 4. Pacote Core RM (OPENEHR, 2011)

25

A Figura 4 apresenta o diagrama de pacotes que pertencem ao core. O core é a parte do RM que é subdivido nos seguintes modelos de informações (BEALE et al., 2008d):  Support Information Model corresponde aos conceitos mais básicos requeridos por todos os demais pacotes, sendo formado pelos pacotes: definitions, identification, terminology e measurement. A semântica definida nestes pacotes permite que todos os outros modelos usem os identificadores e tenham acesso aos serviços de conhecimento, tais como terminologia e outros dados. Além disso, o pacote support compreende os tipos usados pelos modelos da openEHR, inclusive os tipos primitivos definidos por outras entidades. Este pacote é um guia para a integração de modelos openEHR adequadas para os sistemas.  Data Types Information Model define um conjunto de tipos de dados subjacentes a todos os demais modelos, provendo tanto os tipos de dados genéricos quanto os específicos requeridos pelas formas de infomação em Saúde. A Tabela 1 (BEALE et al., 2008b) lista as categorias de tipos de dados definidas pelo data types information model. Tabela 1. Categoria (tipos) de dados do openEHR Categoria Basic Types Text Quantities Descrição boolean, integer, real, etc. texto simples, texto codificado, parágrafos qualquer tipo ordenado, incluindo valores ordinais, medições com valores e unidades, etc. Data/Time data Encapsulated data  hora, tipos de data e hora, e tipos de data e hora parciais multimídia, conteúdo processável

Data Structures Information Model é composto pelas estruturas genéricas, listadas na Tabela 2, que são usadas para expressar o conteúdo da estrutura particular definida pelos arquétipos. Essas estruturas pertencem ao pacote item_structure exibido na Figura 4 (BEALE et al., 2008a). Além desse pacote, data_structures também contém o pacote history, o qual descreve uma noção genérica de história linear, permitindo o registro de informações ao longo do tempo.

26

Tabela 2. Estruturas Genéricas do openEHR Estrutura Single Descrição itens simples, utilizado para conter qualquer valor , exemplo: peso ou altura List Table lista linear de itens nominais, tais como alguns testes patológicos dado tabular, incluindo tabelas de tamanhos limitados e ilimitados, com colunas nominadas e ordenadas Tree dados em forma de árvore que podem ser conceitualmente uma lista de listas, ou outra estrutura de profundidade

Figura 5.Visão dos pacotes do patterns (OPENEHR, 2011) A Figura 5 apresenta o diagrama de pacotes que pertencem ao patterns. O patterns é a parte do RM que é subdivida nos dois modelos de informações (BEALE et al, 2010):  Common Information Model é um conjunto de vários pacotes contendo conceitos abstratos e padrões de projetos, que são usados em modelos de mais alto nível do openEHR. O archetyped habilita o emprego do modelo dual da openEHR, fazendo a ligação entre os modelos de informação e de arquétipos; o pacote generic contém classes que formam “padrões de análise”, os quais são genéricos por todo o domínio e comumente relacionados a referências realizadas a entidades demográficas por outros dados; o pacote directory provê uma abstração simples e reutilizável de uma estrutura de pasta com controle de versão; o pacote change_control define uma semântica generalizada das alterações de um repositório lógico ao longo do tempo, sendo que cada item no repositório tem sua versão controlada para permitir que o repositório como um todo tenha seu controle de versão garantido; o pacote resource define a semântica de um recurso de autoria (documentos), fornecendo suporte as traduções em vários idiomas, metadados descritivos e históricos de revisão.

27

Security Information Model define a semântica de controle de acesso e as configurações de privacidade para a informação no RES.

Figura 6. Pacotes pertencentes ao domain (OPENEHR, 2011) A Figura 6 apresenta o diagrama de pacotes e seus subpacotes que pertencem à parte do RM chamada de domain. Um detalhamento maior dos pacotes composition e ehr são apresentados na Figura 7.

Figura 7.Modelo de informação EHR (OPENEHR, 2011)

28

A Figura 7 apresenta uma visão detalhada do modelo de informação EHR. O modelo de informação EHR contém a estrutura de mais alto nível, que consiste de um objeto HER_ACCESS, um objeto EHR_STATUS, recipientes de controle de versão de dados na forma de VERSIONED_COMPOSITION, opcionalmente indexado por uma hierarquia de diretórios de FOLDER. Uma coleção de CONTRIBUTION, que documenta as mudanças do RES ao longo do tempo, também é incluída: o pacote composition é o recipiente de dados de mais alto nível num RES, sendo descrito pela classe COMPOSITION; o pacote content contém os pacotes navigation e entry, sendo que suas classes descrevem a estrutura e a semântica do conteúdo das composições num RES. Uma questão importante a ser destacada no modelo do padrão openEHR é a capacidade, por exemplo, de oferecer um melhor suporte ao Registro Médico Orientado a Problemas-RMOP, proposto por Lawrence Weed (1968), e registrado através do método SOAP, que significa a sequencia da evolução de: Subjetivo, Objetivo, Avaliação e Plano. Este método é destacado como um dos relevantes princípios da clínica médica, principalmente na atenção básica de saúde, por aumentar a organização do RES e direcionar o olhar para o cuidado do paciente, não apenas para a sua patologia (STAFIELD, 2002). Um problema é resolvido fazendo observações, formando opiniões (hipóteses), e prescrevendo ações (instruções) para os próximos passos, que podem ser investigação adicional, ou podem ser intervenções concebidas para resolver o problema, e, finalmente, a execução das instruções (ações). A Figura 8 demonstra o relacionamento das informações para o Processo de Investigação usando o método SOAP.

29

Figura 8.Relacionamento das informações para o Processo de Investigação (OPENEHR, 2011) O diagrama de classe adicionado à sequencia de passos ilustrados na Figura 8 apresenta o núcleo clínico do modelo de informação do Registro Eletrônico de Cuidado a Saúde. O EHR Information Model possui a classe de entrada (ENTRY) que é definida em dois grupos principais de informação no modelo de entrada: 1) Informações de Cuidado (CARE ENTRY); 2) Informações Administrativas (ADMIN ENTRY) (BEALE, 2007). Conforme mencionado por Gaete et al (2012), as Informações do Cuidado a Saúde estão relacionadas ao registro clínico de fato, enquanto as Informações Administrativas dizem respeito a todo o resto que não faz parte do processo de cuidado/assistência de Saúde. Existem quatro classes genéricas de registro de Informações do Cuidado (BEALE et al., 2007): 1) OBSERVATION, para registrar tudo o que puder ser observado, medido ou respondido pelo paciente; 2) EVALUATION, para registrar avaliações, diagnósticos e planos de cuidado; 3) INSTRUCTION, afirmações que podem ser executadas, como prescrições / receitas de

30

medicamentos, orientações, exames, encaminhamento, entre outros; 4) ACTION, informações que se registram como resultado da execução das instruções. 

Integration Information Model define classes que permitem representar dados externos ou legados numa árvore de dados. Este tipo de entrada de dados possui seu próprio tipo de arquétipos, denominados arquétipos de integração, os quais podem ser usados em conjunto com os arquétipos clínicos em sistemas de integração de dados.

Demographic Information Model determina os conceitos genéricos de PARTY, ROLE e os detalhes relacionados aos endereços de contato. O modelo de arquétipos define a semântica das restrições nas PARTY, permitindo que arquétipos para qualquer tipo de pessoa, organização, papel e relacionamento de papéis possam ser descritos. A Figura 9 apresenta uma visão detalhada do modelo das informações demográficas.

Figura 9.Modelo Dados Demográficos (OPENEHR, 2011)

31

2.2.2 MODELO ARQUÉTIPO - AM
O pacote AM contém os modelos necessários para descrever a semântica dos arquétipos e templates, bem como o seu uso na openEHR.

Figura 10.Estrutura do Pacote AM (OPENEHR, 2011) Como pode ser observado na Figura 10, o Archetype Model - AM inclui a ADL, os pacotes archetype e template, que definem a semântica orientada a objetos desses arquétipos e templates, e o pacote openehr_profile, que define um perfil genérico do modelo de arquétipo para o uso na openEHR (BEALE; HEARD, 2007b). Archetype Object Model - AOM define em Unified Modeling Language - UML o modelo de objetos equivalente aos arquétipos. Sendo um modelo genérico, o AOM pode ser usado para definir arquétipos para qualquer modelo de referência numa forma padronizada. O openEHR Archetype Profile - oAP define classes de arquétipos personalizadas, e suas sintaxes personalizadas equivalentes, que podem ser usadas no refinamento de certas classes do RM. O Template Object Model - TOM define o modelo de objetos para os templates, os quais são usados para combinar arquétipos em estruturas de informações específicas e assim suprir as necessidades de variações locais, usualmente correspondendo aos formulários de tela (BEALE, 2008). A Archetype Definition Language – ADL tem o objetivo de prover uma sintaxe abstrata capaz de representar textualmente arquétipos e templates.

32

2.3

A RCHETYPE D EFINITION L ANGUAGE - ADL
Archetype Definition Language (ADL) é uma linguagem formal desenvolvida pela

OpenEHR visando expressar arquétipos a fim de torná-los processáveis. Para descrever as restrições nos dados, que são instâncias de algum modelo de informação, a ADL emprega três sintaxes: dADL para expressar dados; cADL para expressar restrições; e uma versão de lógica de predicados de primeira ordem. Via o uso da ADL, arquétipos podem ser escritos para qualquer domínio onde existam modelos formais que descrevem instâncias de dados (BEALE; HEARD, 2008). Arquétipos expressos em ADL lembram códigos de linguagens de programação e possuem uma sintaxe definida. A cADL é usada para expressar a seção de definição de arquétipos, enquanto que a dADL é usada para expressar os dados que aparecem nas seções de idioma, descrição, ontologia e histórico de revisão (BEALE; HEARD, 2008). Uma visão geral da estrutura de uma ADL é apresentada na Figura 11.

Figura 11.Estrutura ADL (OPENEHR, 2011)

33

Usando uma sintaxe interpretável, a ADL possui um relacionamento formal com modelos estruturais, tais como os representados pela UML. Enquanto a sintaxe da ADL permanece como o principal formalismo para expressar arquétipos, o AOM estabelece a sua semântica, definindo principalmente os relacionamentos que precisam ser garantidos entre suas partes, para que esse arquétipo seja considerado válido como um todo. A Figura 12 apresenta um trecho da ADL do arquétipo para o registro dos dados do paciente.

Figura 12.ADL Dados do Paciente (OPENEHR CKM, 2011)

34

2.4

M APA M ENTAL
O Mapa Mental é um diagrama utilizado para conectar palavras, ideias e conceitos a

uma ideia ou conceito central, utilizado para visualizar, classificar, estruturar conceitos e gerar novas ideias (BUZAN, 2003). É similar a uma rede semântica, ou um mapa cognitivo, porém sem restrições nos tipos de conexões usadas. Nele os elementos são ordenados de forma intuitiva, de acordo com a importância dos conceitos relacionados a um domínio, que então são organizados em agrupamentos, ramificações ou áreas. Em outras palavras, um mapa mental é um diagrama radial que através de vocabulários (palavras-chave), distribuídas em certa ordem e correlacionadas possam representar e modelar cognitivamente um conceito ou um domínio específico. Segundo Buzan (2003), os principais benefícios em utilizar mapas mentais são: organização, utilização de palavras-chave, associação, agrupamento de ideias, memória visual, criatividade e inovação com simplicidade. Nesta pesquisa, o mapa mental é utilizado com o propósito de representar um mapa cognitivo, tendo como objetivo extrair, estruturar e organizar o conhecimento ou domínio de saúde, advindo dos arquétipos, de forma espacial, abstraindo as complexidades dos

arquétipos centrando o domínio em dados persistentes (DATA) para um sistema de informação de saúde. Alguns trabalhos (DOWNS, 1973) e (KITCHIN, 1994) destacam que esse tipo de representação facilita a mente humana em processar melhor as informações, reduzindo a carga cognitiva para a absorção do conhecimento ou domínio. Neste contexto, o mapa mental foi adotado com o intuito de facilitar a comunicação e simplificar a modelagem de domínio pelo Especialista de Domínio, tornando este processo mais ágil e eficaz. A Fundação openEHR utiliza-se de mapas mentais como um dos diagramas de representação de conhecimento para os registros de prontuários eletrônicos A Figura 13 apresenta um exemplo de mapa mental do conceito clínico Temperatura Corporal definida pela openEHR.

35

Figura 13.Mapa Mental de Temperatura Corporal (OPENEHR CKM, 2011)

2.5

S ÍNTESE DO C APÍTULO
De maneira geral, este capítulo apresentou definições referentes aos Arquétipos. A seção

2.1 explicitou detalhes sobre a Fundação openEHR, seus principais objetivos e focos de atuação. Na seção 2.2, foi detalhado o Modelo Dual, apresentando conceitos e descrevendo o Modelo de Referência - RM e Modelo Arquétipo – AM. Os submodelos foram apresentados, seus pacotes e classes ilustradas. Além disso, o processo de investigação clínica também foi demonstrado. Na seção 2.3, os conceitos e exemplos de Archetype Definition Language - ADL foram ilustrados. Por fim, a seção 2.4, os conceitos e exemplos sobre os mapas mentais foram apresentados. Também é justificada nesta seção a adoção de mapas mentais no corrente trabalho.

36

3 DESENVOLVIMENTO DIRIGIDO A MODELOS
Este capítulo fornece uma visão detalhada sobre o paradigma de desenvolvimento orientado a modelos, apresentando desde a sua definição, linha do tempo, utilização e abordagens mais frequentes. Antes de iniciar esta seção, faz-se necessário a apresentação de algumas definições do termo modelo. O termo modelo é um dos mais utilizados, mas seu significado pode visivelmente ser alterado entre contextos (amplamente explicado por (SEIDEWITZ, 2003; KÜHNE, 2005). Por exemplo, em Engenharia Software o termo modelo tradicionalmente refere-se a um artefato formulado em alguma linguagem de modelagem. Esta definição é estreito para MDE, onde o código de um programa pode ser interpretado como um modelo em alguns casos. No livro "MDA Explained" (KLEPPE; WARMER; BAST, 2003) o termo modelo é definido como: peça "Uma descrição (de) um sistema de escrita em uma linguagem bem definida". Em um ponto de vista mais genérico, considerando a definição do termo modelo no Dicionário online Merriam-Webster que é: "uma exata representação de algo de tamanho muito reduzido" ou a definição do dicionário Cambridge que é: "uma representação de algo, como um objeto físico que é geralmente menor que o objeto real, ou como uma simples descrição do objeto que possa ser utilizado nos cálculos".

3.1

D EFINIÇÃO
Muitos dos artefatos de alto nível (por exemplo, modelos UML) são utilizados com o

objetivo de facilitar a análise de um problema, sendo úteis apenas num primeiro instante. Com a evolução das atividades do desenvolvimento, esses artefatos vão se tornando obsoletos e deixam de representar fielmente a realidade da aplicação. Isto ocorre porque normalmente as mudanças e manutenções são confeccionadas diretamente no código, fazendo com que os esforços despendidos na construção desses artefatos não sejam aproveitados diretamente na produção de aplicações (BITTAR, 2009; LUCREDIO, 2009). Neste sentido, o Desenvolvimento Dirigido a Modelos (Model-Driven Development MDD) visa aprimorar a forma com que o software é desenvolvido, via a representação das relevantes características de um sistema em modelos, os quais são construídos e refinados

37

conforme o sistema é desenvolvido (VOELTER; GROHER, 2007). Em contraste com o desenvolvimento de software não dirigido a modelos, no MDD os modelos não constituem apenas a documentação, sendo processados por ferramentas que permitem suas transformações em diferentes níveis de abstração (VOELTER; GROHER, 2007).

Figura 14. Processo de Criação de Software (LUCRÉDIO, 2009)

Conforme ilustra a Figura 14 (LUCREDIO, 2009), o MDD pode desobrigar o Engenheiro de Sistemas da interação direta com o código fonte, abstraindo o seu trabalho das complexidades inerentes à implementação em diferentes plataformas (FRANCE; RUMPE, 2007; LUCREDIO, 2009). Mecanismos automáticos são responsáveis por efetuar transformações e gerar os códigos a partir dos modelos, fazendo com que estes deixem de ser apenas guias para o processo de desenvolvimento e também façam parte do software (LUCREDIO, 2009). De acordo com (DEURSEN; KLINT, 1998; KLEPPE et al., 2003; LUCREDIO, 2009; MERNIK et al, 2005), as principais vantagens do MDD relacionam-se à: 1) produtividade, porque as tarefas repetitivas podem ser implementadas nas transformações, poupando tempo e esforço, e o tempo de desenvolvimento é melhor aproveitado, já que é empregado na produção de modelos de mais alto nível; 2) portabilidade, porque um mesmo modelo pode

38

gerar código para diferentes plataformas; grau de integração, porque diferentes partes do modelo podem ser transformados em códigos para diferentes plataformas, resultando num software que corresponde à heterogeneidade do ambiente sem perder sua funcionalidade global; manutenção e documentação, porque as alterações são realizadas diretamente nos modelos, mantendo-os em conformidade com o código, e a documentação permanece sempre atualizada, facilitando assim a manutenção; 3) comunicação, porque os especialistas de

domínio podem usar os modelos para identificar os conceitos de negócio, não dependendo diretamente de conhecimento técnico relativo à plataforma; 4) reutilização, porque o reuso de artefatos de alto nível traz maiores benefícios que o reuso de código-fonte; 5) verificação e otimização, porque os modelos facilitam o emprego de verificadores semânticos e otimizações automáticas, o que pode reduzir a ocorrência de erros semânticos e fornecer implementações mais eficientes; e 6) corretude, porque as ferramentas usadas nas

transformações não geram erros acidentais (e.g., erros de digitação) e erros conceituais podem ser identificados em níveis superiores de abstração. Essas vantagens do MDD relacionam-se à minimização de tarefas repetitivas para a transformação de modelos em código fonte, as quais passam a ser realizadas com o auxílio de ferramentas, permitindo a sua automação e a manutenção da consistência dos modelos, isso mesmo mediante a realização de atividades de urgência, tais como a correção de erros (LUCREDIO, 2009). Entre as desvantagens causadas pelo MDD, alguns autores, como Ambler (2003), Thomas (2004), entre outros, citam: 1) Rigidez: o MDD causa maior rigidez no software produzido, uma vez que grande parte do código é gerado e fica além do alcance do desenvolvedor; 2) Curva de aprendizado: o desenvolvimento dos artefatos específicos do MDD exigem profissionais com habilidades na construção de linguagens, ferramentas de modelagem, transformações e geradores de código. O aprendizado destas técnicas, apesar de não ser extremamente difícil, requer um treinamento dedicado; 3) Alto investimento inicial: assim como a reutilização de software, o MDD depende de maior investimento inicial, uma vez que a construção de uma infraestrutura de reutilização orientada a modelos requer mais tempo e esforço. Porém, os ganhos posteriores são significativos, fazendo com que este investimento tenha retorno em poucas interações.

39

3.2

H ISTÓRICO
No início o uso de modelos no desenvolvimento de sistemas não considerava as ideias

de desenvolvimento automático ou semiautomático, conforme descrito por Ameller (2009). Uma das mais transcendentes linguagens baseadas em modelos foi a linguagem de Entidade-Relacionamento - ER proposta por Chen (1976). A declaração a seguir, também realizada pelo mesmo autor, resume a importância da contribuição ER: "Entidades e relacionamentos são uma maneira natural de organizar as coisas físicas bem como as informações... O conceito de ER é o princípio básico fundamental para modelagem conceitual. Ele tem estado conosco desde há milhares de anos e estará conosco por muitos anos vindouros.”. A modelagem conceitual era um tópico de investigação ativo durante a década de 1980, algumas abordagens foram publicadas para estender ER. As bases de Unified Modeling Language - UML surgiram com as contribuições de Booch, Rumbaugh e Jacobson (1992). Vinte e um anos depois de ER, em 1997, a primeira versão do UML foi apresentada. Hoje em dia, UML é usado como o idioma baseada em modelo padrão para desenvolvimento de software. ER e UML são as raízes do MDE. MDE nasceu nos primeiros anos da década de 2000 com o lançamento do Model-Driven Architecture (MDA, 2001), e uma unificação progressiva das iniciativas que levam modelos como um elemento principal no desenvolvimento de software.

3.3

I NICIATIVAS
De acordo com o relato de Ameller (2009), as iniciativas do desenvolvimento

orientado a Modelos são nomeadas por siglas, são as seguintes as mais representativas e apresentadas cronologicamente decrescente: Model-Driven Engineering (MDE): Em 2006, um artigo publicado no IEEE definiu MDE como: "As tecnologias da Model-driven engineering oferecem uma abordagem promissora para tratar a incapacidade das linguagens de terceira geração para aliviar a complexidade de plataformas e conceitos de domínio expressas de forma eficaz.". Por esta definição podemos entender MDE como a evolução das ferramentas CASE. A iniciativa propõe definições de MDE mais amplas em relação aos processos (não se limitando ao

40

desenvolvimento como MDD), e suporte para análise do modelo para tomar decisões ou simplesmente para o raciocínio (SCHMIDT, 2006). Model-Driven Development (MDD): Em 2003 um artigo com o mesmo nome como a iniciativa (MELLOR et al, 2003) é publicado em IEEE Software. O artigo define: "ModelDriven Development é simplesmente a noção de que podemos construir um modelo de um sistema que pode então se transformar em coisa real.". Uma diferença entre MDD e MDA é que MDD não é aderente algumas das normas da OMG. Foi dito por Fowler (2009), que a principal contribuição do MDD é a flexibilidade oferecida para definir processos de desenvolvimento. Model-Driven Architecture (MDA): O primeiro artigo do OMG referindo-se ao MDA foi publicado em 2000. Mais tarde, em 2003, a atual versão do guia MDA (MDA GUIDE, 2003) foi publicado. Todas as iniciativas model-driven seguem o princípio de que "tudo é um modelo", declarou em (BÉZIVIN, 2005). Em uma sessão plenária celebrada em Montreal entre os dias 23 e 26 de Agosto de 2004, a seguinte definição de MDA foi concedida: “A MDA é uma iniciativa OMG que se propõe a definir um conjunto de padrões proprietários que especificam tecnologias interoperáveis para realizar Model-Driven Development com transformações automatizadas”. Nem todas essas tecnologias se referem diretamente as transformações envolvidas na MDA. MDA não necessariamente depende da UML, mas, como um tipo especial de ModelDriven Development - MDD, MDA necessariamente envolve o uso de modelo (s) em desenvolvimento, o que implica que a modelagem, pelo menos, uma linguagem deve ser usado. Qualquer linguagem de modelagem utilizada na MDA deve ser descrita em termos da linguagem MOF, para permitir que os metadados possam ser entendidos de uma forma padrão, que é uma condição prévia para qualquer capacidade para realizar transformações automatizadas. A Figura 15 representa a evolução temporal dessas três iniciativas. Note-se que as iniciativas MDD e MDE surgirem mais cedo do que o ano mencionado. Os anos mostrados na figura representam os anos respectivos anos onde ocorreu a primeira publicação em revista.

41

Figura 15.Representação das iniciativas de Moden-Driven (AMELLER, 2009) Na MDA são descritos três tipos de abstrações e ilustrados através da Figura 16 que apresenta o sentido dos três níveis de abstração.

Figura 16.Níveis de abstrações de MDA

Estes três tipos de modelos referem-se aos estágios de desenvolvimento de software (AMELLER, 2009):  Compute Independent Model - CIM: A CIM é uma visão do sistema do ponto de vista independente da computação. CIM é muitas vezes chamado de modelo de negócio. Um exemplo de CIM poderia ser o modelo que representa o processo para entregar um pacote (simplificado): 1. Um funcionário leva o pacote a partir de casa do cliente e o leva para o escritório mais próximo. 2. O pacote é transportado para o escritório mais próximo do destinatário. 3. Um funcionário leva o pacote para o destinatário.

42

Platform Independent Model - PIM: Um modelo que não contém detalhes que têm significado apenas dentro de uma plataforma específica. Este tipo de modelo não tem relação com qualquer tecnologia de implementação. Na sequência do exemplo anterior, o modelo de PIM irá conter apenas as partes que são suposto ser feito pelo computador (simplificado): 1. O sistema atribui um identificador para o pacote. 2. O sistema calcula a rota mais econômica para entregar o pacote.

Platform Specific Model - PSM: Um modelo que contém detalhes que têm significado apenas dentro de uma plataforma específica. Este tipo de modelo tem normalmente uma relação com algumas tecnologias de implementação. Em comparação com o exemplo anterior, neste caso, o modelo de PSM irá conter as mesmas peças do processo, mas especificando concretamente uma tecnologia (simplificado): 1. O sistema usa um gatilho de banco de dados Oracle para gerar um identificador para cada pacote. 2. O sistema calcula a rota mais econômica para entregar o pacote utilizar os serviços web das companhias aéreas contratadas.

3.4

M ETODOLOGIA
A metodologia usual para Model-Driven Development - MDD é um processo de

transformação como afirmado por (HUMM, 2005). É mostrado na caixa cortada (pontilhada) da Figura 17:

Figura 17.Fluxo de Transformação Geral As caixas (M2M e M2T) são transformações. As caixas marcadas com a sigla M2M refere-se à transformação de Modelo para Modelo. Já a caixa com a sigla M2T, também conhecida com M2C, refere-se à transformação Modelo para Texto.

43

As transformações entre os modelos (M2M) são definidos como a transformação de idiomas. As transformações de um modelo para um arquivo de texto - M2T são normalmente feitas por algumas linguagens de script ou baseadas em modelo, alguns exemplos dessas linguagens: Velocity (Apache Velocity), MOFScript (MOFScript), JET (POPMA, 2004). Faz parte do escopo desse trabalho utilizar o processo de transformação M2T, com o objetivo de gerar artefatos textuais a partir de modelos de domínios projetados. Neste documento, daqui por diante será utilizado o termo M2C para identificar o processo de transformação modelo para texto.

3.5

U NIFIED M ODELING L ANGUAGE - UML
Segundo (WATSON, 2007), a história da modelagem gráfica de software pode ser

dividida em dois períodos: antes da UML e depois da UML. Antes da criação dessa linguagem, o cenário da modelagem de software era repleto de notações incompatíveis, o que levava ao enfraquecimento do mercado de ferramentas, deixando os modelos fora do processo de desenvolvimento de software. No entanto, após a especificação da UML e sua grande adoção no processo de produção de sistema, as incompatibilidades de notação até então existentes foram praticamente eliminadas. A UML, criada em 1996, hoje na sua versão 2.x (OMG, 2007) é composta por 13 diagramas que definem a notação e semântica para os seguintes domínios:    A interação do usuário ou modelo de casos de uso descreve os limites e interações entre o sistema e seus usuários, correspondendo a um modelo de requisitos, em alguns aspectos; O modelo de interação ou comunicação descreve como objetos do sistema interagem entre si; O modelo dinâmico ou de estados descreve os estados ou condições que as classes possuem ao longo do tempo. Gráficos de atividades descrevem o fluxo de trabalho que o sistema irá seguir;    O modelo lógico ou de classes descreve as classes e objetos que fazem parte do sistema; O modelo físico de componentes descreve o software (e algumas vezes componentes de hardware) que fazem parte do sistema; O modelo físico de implantação descreve a arquitetura física e a implantação de elementos na arquitetura de hardware.

44

3.6

M ETAMODELAGEM
A UML foi desenvolvida seguindo uma abordagem de metamodelagem que adapta

técnicas de especificação formal. Além disso, a UML segue um padrão arquitetural de quatro camadas (ver Figura 18) onde a camada M3 corresponde ao metamodelo1 MetaObject Facility - MOF (OMG, 2007), a camada M2 é a própria UML, a camada M1 são os modelos utilizados no processo de produção de software e a camada M0 são os objetos em si.

Figura 18. Quatro Camadas da Arquitetura do Metamodelo (LIDDLE, 2010) A Figura 18 descreve as camadas:  M3: A camada que contém meta-meta-metadata (meta-metamodelo) que descrevem as propriedades que meta-metadados podem exibir. Se houvesse uma camada M4 seria da mesma forma como M3, porque M3 é auto-descritivo. Meta Object Facility (MOF) é um padrão do OMG. MOF é uma linguagem para descrever metamodelos. Para se ter uma idéia aproximada do que é MOF, nós poderiamos pensar em UML limitado a diagramas de classe. O MOF foi utilizado também na própria definição do metamodelo da UML.  M2: A camada que contém os meta-metadados (metamodelo) que descrevem as propriedades que os metadados podem apresentar (por exemplo, tais elementos UML como classe, a Operação atributo). Aqui encontramos metamodelos, uma descrição ou definição de uma linguagem bem definida na forma de um modelo.

1

Um metamodelo é um modelo que tem o objetivo de definir os relacionamentos entre vários elementos de um modelo.

45

M1: A camada que contém os metadados do aplicativo (por exemplo, de acordo com a Figura 18 define que a classe Book é caracterizada pelo atributo title). M0: A camada que contém os dados de aplicação (por exemplo, o casos que preenchem um sistema orientado a objetos em tempo de execução ou linhas de tabelas relacionais de banco de dados. Na Figura 18 essa instância é representada pelo livro intitulado: Executable UML: A Fundation for Model-Driven Architectures). 3.7

M ECANISMOS DE E XTENSÃO DA UML
Os mecanismos de extensão da UML existem desde suas versões iniciais, porém

somente a partir da sua segunda versão é que a noção de perfil foi definida para proporcionar a extensão da linguagem de forma mais estruturada e precisa (OBJECT MANAGEMENT GROUP, 2007). Em Sampaio (2009) foi utilizado o mecanismo de perfis UML para gerar uma linguagem específica de domínio, em que o domínio pretendido foi o de aplicações geográficas. Nas subseções seguintes são explicados os mecanismos de extensão da UML (estereótipos, tagged values e constraints), assim como perfis UML.

Estereótipos
Estereótipo é um mecanismo de extensão da UML que define como uma metaclasse existente pode ser estendida e habilita o uso de uma terminologia específica para um domínio ou plataforma específicos em lugar da, ou em adição à, terminologia usada para a metaclasse estendida (OBJECT MANAGEMENT GROUP, 2007). Eriksson et al. (2004), assim como OBJECT MANAGEMENT GROUP (2007), caracterizam estereótipos como um dos principais veículos para a customização da UML. Um estereótipo pode estender uma metaclasse ou outro estereótipo, permitindo assim, que sejam criados novos elementos de modelagem. Não há limite no número de vezes que uma metaclasse pode ser estendida por um estereótipo, nem há regras que limitem o número de classes que podem aplicar um estereótipo. Um estereótipo é definido por um nome e pelo conjunto de elementos do metamodelo com os quais ele pode ser conectado. Graficamente, eles são definidos em caixas estereotipadas como: <<stereotype>> (FUENTES; VALLECILLO, 2004). Os elementos do

46

metamodelo são indicados por classes estereotipadas como <<metaclass>>. Eles podem também mudar a aparência visual dos elementos do modelo estendidos usando ícones gráficos (OBJECT MANAGEMENT GROUP, 2007).

Tagged Values
Um tagged value é um meta-atributo adicional que é vinculado a uma metaclasse do metamodelo estendido por um perfil. Eles adicionam informações aos elementos do modelo, as quais podem ser utilizadas por seres humanos e por máquinas, podendo assim ser expressos por alguma linguagem natural ou computacional. Seres humanos podem usar esses metaatributos para adicionar informações administrativas sobre o modelo como, por exemplo, o autor do modelo e a data e hora da última modificação. Máquinas podem usá-los, por exemplo, para a geração de código (ERIKSSON et al., 2004). Tagged values têm um nome e um tipo, e são associados a um estereótipo específico (OBJECT MANAGEMENT GROUP, 2007).

Constraints
Constraints são restrições em forma de regras ou definição de condições que são aplicadas a elementos do modelo. A todo elemento da UML está associada alguma semântica. Isso quer dizer que cada elemento gráfico dessa linguagem possui um significado bem definido que, uma vez entendido, fica implícito na utilização do elemento em algum diagrama. As restrições permitem estender ou alterar a semântica natural de um elemento gráfico (BEZERRA, 2002). As restrições podem ser associadas aos estereótipos, impondo, assim, restrições aos elementos do metamodelo correspondente. As regras definidas para um estereótipo se aplicam a cada elemento do modelo para os quais o estereótipo é aplicado e cada elemento do modelo para os quais o estereótipo precisa aderir às regras (ALHIR, 2003). Constraints podem ser expressas usando uma linguagem natural, ou a Object Constraint Language (OCL), que é adotada pelo OMG para expressar restrições e propriedades de elementos do modelo (FUENTES; VALLECILLO, 2004). Algumas restrições foram escritas, em OCL, nos metamodelos Arquétipos – AM pela Fundação openEHR, mas não será objeto de estudo desse trabalho.

47

3.8

P ERFIS UML
A UML permite uma personalização e extensão da sua sintaxe e semântica, além de

provê mecanismos de adaptação a domínios específicos chamados de perfis UML. Então, um perfil UML é um conjunto dos mecanismos de extensão da UML (estereótipos, tagged values e constraints), agrupados em um pacote UML estereotipado como <<profile>>. Como mencionado anteriormente, esses mecanismos permitem a extensão da sintaxe e semântica dos elementos da UML, porém sem violar a semântica original desses elementos. A intenção é fornecer um mecanismo direto para adaptar um metamodelo existente com construtores que são específicos para um domínio, plataforma ou método em particular. Tais adaptações são agrupadas em um perfil (OMG, 2007). O pacote de perfis contém mecanismos que permitem metaclasses de metamodelos existentes serem estendidas para adaptá-las a diferentes propósitos. Isso inclui a habilidade para customizar a UML a diferentes plataformas ou domínios específicos como, por exemplo, aplicações em tempo-real ou modelagem de processos de negócios. O mecanismo de perfis é consistente com o MOF (OMG, 2007). A Figura 19 apresenta a tela de preenchimento em um modelo da tagged value definida em um perfil UML. Esse exemplo demonstra o preenchimento da tagged value required com o valor true referente ao atributo value.

Figura 19.Exemplo de preenchimento de tagged value no modelo

48

Com o objetivo de manter uma sincronia com o desenvolvimento e evolução dos metamodelos arquétipos produzidos pela comunidade que participa da Fundação openEHR, esse trabalho adotou o uso de perfis UML para possibilitar a extensão da sintaxe e semântica da UML e prover mecanismos adaptativos a domínios específicos (Cuidado a Saúde), possibilitando assim o desenvolvimento baseado em modelos, através da realização das transformações de modelo para texto. 3.9

T RANSFORMAÇÕES DE M ODELOS
Transformação de modelos é o processo de converter um modelo em outro modelo do

mesmo sistema (OMG, 2003). A transformação utiliza os mapeamentos, mas também contém outras informações como, por exemplo, a condição no modelo fonte para disparar a transformação, a linguagem do modelo-alvo, a linguagem-fonte, etc. (KLEPPE; WARMER; BAST, 2003). Um mapeamento é especificado usando alguma linguagem para descrever uma transformação de um modelo em outro. A descrição pode ser em linguagem natural ou em uma linguagem de transformação de modelos. Uma qualidade desejável de uma linguagem de transformação é a portabilidade. Isso habilita o uso de um mapeamento com diferentes ferramentas (OMG, 2003).

Linguagem de Transformação
Sendall e Kozaczynski (2003) descrevem algumas características que são desejáveis para essas linguagens de transformação de modelos. A linguagem deve ser implementável de maneira eficiente, ser executável e deve oferecer editores gráficos, os quais proveem uma maneira mais intuitiva quando comparados com os textuais. Em geral, essas linguagens de transformação de modelos podem ser imperativas, declarativas ou híbridas. As linguagens imperativas são aquelas que descrevem como atingir determinado objetivo através de uma sequência de ações que devem ser executadas pelo computador. Exemplos são: Cobol, Fortran, C, Pascal, Java, etc.. As linguagens declarativas são aquelas que descrevem o objetivo que deve ser atingido pelo computador, deixando para o computador escolher a melhor maneira de realizá-lo. Exemplos desse tipo de linguagem são:

49

Lisp, Haskell, SQL, etc.. Já as linguagens híbridas são aquelas combinam características das duas anteriores. Em 2004, a OMG lançou uma requisição de propostas (Object Management Group, 2004) com o objetivo de padronizar a transformação de modelos para representação textual, onde foi solicitada a criação de uma nova linguagem ou a extensão de uma linguagem já existente para transformação de modelos em texto. Estava entre os principais requisitos dessa linguagem de transformação a compatibilidade com o metamodelo MOF 2.0, funções de manipulação de strings e o suporte aos mecanismos de extensão da UML. A linguagem MOFScript atende a todos os requisitos básicos da OMG e adiciona outros requisitos avaliados como importantes para uma linguagem desse tipo, tais como suporte a mecanismos de controle de fluxo, interação com serviços do sistema operacional (e.g. consultar a data e hora do sistema), e um equilíbrio entre facilidade de uso e poder de expressividade dos domínios. Também é fornecido um editor de transformações na forma de um plug-in para a IDE Eclipse, chamado MOFScript tool (OLDEVIK, 2006), que tem um editor léxico com coloração de sintaxe e assistente de digitação de código, visualizador estrutural de regras, gerenciador de configurações e visualizador de problemas. MOFScript já provou ser adequada para a tarefa de transformação de modelos em UML para texto (M2T) em outras situações como no trabalho de Porres et al. (2007) onde sistemas de apoio à decisão foram gerados a partir de diagramas de Máquina de Estados. Um conjunto completo de instruções de uso da ferramenta e da linguagem pode ser encontrado em seu manual do usuário (OLDEVIK, 2009). Além disso, a adoção da linguagem MOFScript neste trabalho foi baseada na utilização de (CATALINA et al, 2008) conforme resultado da revisão sistemática apresentado no capitulo 5.

Papyrus UML2 Modeler
A ferramenta CASE Papyrus UML2 Modeler (PAPYRUS UML, 2011) mostrou-se uma opção interessante por ser uma ferramenta de código aberto (opensource). Ela se basea no ambiente Eclipse e está sob a licença EPL (Eclipse Public License). A Figura 20 ilustra a interface principal da ferramenta.

50

Figura 20.Interface da ferramenta UML Papyrus Entre outros recursos interessantes para modelagem de sistemas utilizando o padrão UML2, a ferramenta dá suporte à criação de perfis UML, que é um dos objetivos de estudo desse trabalho. O perfil é criado selecionando-se os estereótipos a serem utilizados e as metaclasses que serão estendidas por esses estereótipos. Além disso, as programas transformadores M2C escritos em MOFScript podem ser editados e executados no Papyrus, tornando assim, uma ferramenta única para realização da modelagem de domínio, criação do perfil UML, confecção dos programas transformadores e execução das transformações.

3.10 S ÍNTESE DO C APÍTULO
De maneira geral, este capítulo apresentou as definições referentes ao paradigma de desenvolvimento orientado a modelos. Inicialmente foram apresentados conceitos sobre o próprio modelo. A seção 3.1 fundamentou conceitualmente e apresentou as principais características de MDD. Adicionalmente foram apresentadas as principais vantagens e/ou desvantagens da adoção de MDD e os pontos de vistas sobre sua adoção.

51

Nas seções 3.2 e 3.3, foram apresentadas a linha do tempo sobre o paradigma de desenvolvimento orientado a modelos e suas principais iniciativas apresentando as relevantes características. Nas seções 3.4, 3.5 e 3.6, as metodologias, definição sobre UML e a conceituação sobre metamodelagem são apresentadas. Na seção 3.4 foi apresentada a metodologia usada com MDD, detalhando os processos de transformações, tais como: M2M ou M2C. Na seção 3.5 foi realizada uma fundamentação teórica sobre UML, com o objetivo de facilitar ainda mais o entendimento das próximas seções. Na seção 3.6 foi conceituada a metamodelagem, suas principais características e suas camadas de abstrações. Nas seções 3.7 e 3.8, os conceitos e exemplos sobre os mecanismos de extensão e perfil UML são apresentados. Por fim, a seção 3.9 que apresentou a definição sobre as transformações de modelos, as características das linguagens de transformação e a ferramenta Papyrus que possibilita a criação de perfil UML, programas transformadores e a própria execução da geração de artefatos automáticos.

4 TECNOLOGIAS WEB
Este capítulo apresenta as tecnologias WEB utilizadas no desenvolvimento desse trabalho, detalhando as definições e históricos sobre Jquery Mobile, HTML, CSS, JSON e o Framework PhoneGap.

4.1

JQUERY M OBILE
Conforme definido no livro de Silva (2012) o JQuery Mobile é um framework

utilizado para o desenvolvimento WEB e é otimizado para interação por toque (Touch). Esse framework é um fácil caminho para a confecção de aplicações web que são acessíveis em todos os dispositivos móveis populares como: smartphones e tablets. A confecção desse framework tem o objetivo de fornecer mecanismos que possibilitam a criação de sistemas unificados de interface do usuário (UI), baseados em Jquery , JQuery UI, HTML5 e CSS3. Esses sistemas não apenas adicionam funcionalidades

52

para criação do layout (listas, painéis, layers etc.), mas também fornecem um rico conjunto de controles e widgets (entre outros: sliders, toggles, abas) (SILVA, 2012). O framework efetua o princípio “fazer mais escrevendo menos”, que dita o desenvolvimento da biblioteca jQuery, com a finalidade de criar aplicações únicas para todos os dispositivos móveis e sistemas operacionais. Em relação a interoperabilidade entre navegadores e plataformas móveis, esse framework foi desenvolvido baseado em um diretriz que estabelece que se trata de uma ferramenta capaz de implementar aplicações que sejam suportadas pela grande maioria dos modernos navegadores desktop e das plataformas para smartphones, e tablets.

Histórico
Em 16 de outubro de 2010, John Resig (criador do Jquery) anunciou o lançamento da primeira versão alfa do framework, o jQuery Mobile 1.0 alfa 1, com as seguintes funcionalidades: 1) tema e layout; 2) topo e rodapé (fixos e prsistentes); 3) controles de formulário; 4) caixas de diálogo; 5) listagens; 6) eventos e transições. Em 2011, foram lançadas várias versões candidatas a lançamento do framework, contendo as seguintes novas características: 1) suportes para Blackbarry 5, Mini Opera e séries 60 do smartphone Nokia; 2) Refinamentos, otimizações e melhoria de desempenho; 3) correções de bugs; Para utilizar o Framework JQuery Mobile no ambiente de desenvolvimento não é requerido a execução de instalações prévias. É necessário apenas criar, na marcação HTML5 do documento, os seguintes links: 1) um link para a biblioteca JQuery; 2) um outro link para a biblioteca desse framework; 3) Um link para a folha de estilo (CSS3) padrão do framework. Essas criações permitem a maximização do uso das funcionalidades e principalmente da simplicidade de implementar para quase todos os dispositivos móveis existentes no mercado, independentes de marcas, modelos e plataformas ou sistemas operacionais. A Figura 21 apresenta um modelo mínimo para desenvolver uma página para dispositivo móvel.

53

Figura 21.Exemplo de HTML com Jquery Mobile

4.2

H YPERTEXT M ARKUP L ANGUAGE – HTML
É uma linguagem de marcação (linguagem de marcação de hipertexto) global para

estruturação e apresentação de conteúdo para WEB criada e mantida pelo consórcio W3C. A HTML foi concebida essencialmente como uma linguagem para descrever semanticamente documentos científicos, embora a sua concepção geral e adaptações ao longo dos anos permitiu-lhe ser usada para descrever uma série de outros tipos de documentos (HISTORY HTML, 2012). O W3C descreve que HTML é baseado no conceito de Hipertexto. Os Hipertextos são conjuntos de elementos ligados por conexões. Estes elementos podem ser, entre outros: palavras, imagens, vídeos, áudio, documentos. Estes elementos ligados criam uma grande rede de informação. A conexão feita em um hipertexto é algo imprevisto que permite a comunicação de dados, organizando conhecimentos e guardando informações relacionadas. Um relevante propósito do HTML é ser uma linguagem universalmente entendida por diversos meios de acesso, isto é, possibilitar distribuição da informação de maneira global.

Histórico
A linha do tempo do HTML é apresentada nesta seção. A Figura 22 apresenta a linha do tempo do HTML. Neste trabalho utilizamos o HTML5

54

Figura 22.Linha do tempo HTML Na década de 1990, o HTML ganhou popularidade quando o navegador Mosaic ganhou força. Com isso, fabricantes de navegadores e desenvolvedores usaram o HTML como base para a implementação de suas aplicações. Em 1996, o W3C publicou a versão HTML 2 que corrigia alguns erros e No ano de 1997, O W3C recomendou a versão 3.2 do HTML, essa versão continha as seguintes novas características, entre outras: 1) Fontes, tag: <font>; 2) Tabelas, tag: <table>; 3) applets; 4) superscripts e subscripts. Em 1998, o W3C recomendou a versão HTML 4.0, onde a sua mais nova importante característica foi à adoção de folhas de estilo (CSS). No ano de 2000, o W3C lançou o XHTML 1.0 como uma reformulação do HTML 4.0.1 no formato XML. Em paralelo às evoluções do XHTML, a partir de 2004, um grupo chamado Web HyperText Application Tecnology Working Group (WHATWG) foi fundado por desenvolvedores de empresas como Mozilla, Apple e Opera que trabalhavam em uma versão do HTML que trazia mais leveza e flexibilidade para a produção de aplicações WEB. Em 2006, foi anunciada uma parceria entre o grupo WHATWG e a equipe de desenvolvimento do XHTML visando o desenvolvimento do HTML versão 5 (HTML5). Contudo o XHTML continuou sendo desenvolvido até o ano de 2009, onde teve o desenvolvimento parado. Em 2008, o W3C anunciou a primeira especificação do HTML5, que contem as seguintes características: 1) Funções para embutir som, vídeos e gráficos; 2) armazenamento de dados no lado cliente; 3)documentos interativos. Com essas novas característica poderá ser eliminada a dependência de plug-ins para manipulação de multimídia em navegadores, por

55

exemplo: flash player da empresa adobe. A Figura 23 apresenta um exemplo do trecho código na linguagem HTML5.

Figura 23.Exemplo de Código HTML5

4.3

C ASCADING S TYLE S HEETS - CSS
Conforme definição do consórcio W3C, Cascading Style Sheet, ou em português:

Folhas de Estilo em Cascata são: “Um mecanismo simples para adicionar estilos (por exemplo: fontes, cores, espaçamentos) aos documentos WEB”. Conforme definido em Silva (2007), o CSS formata a informação entregue pelo HTML ou XML. Essa informação pode ser, entre outras: imagem, texto, vídeo, áudio ou qualquer outro elemento criado. Essa formatação na maioria das vezes é visual, mas não obrigatoriamente. As CSS têm por finalidade devolver à marcação HTML/XML o propósito inicial da linguagem. Isto significa que a HTML foi criada para ser uma linguagem exclusivamente de marcação e estruturação de conteúdos. A responsabilidade do HTML é fornecer informações a qualquer dispositivo (por exemplo: navegadores e dispositivos móveis) que sejam capazes de interpretar um documento escrito em uma linguagem de marcação. É competência, responsabilidade, do CSS as funcionalidades de apresentação dos elementos de um documento HTML/XML. O CSS têm a finalidade de possibilitar a estilização dos elementos,

56

configurando, por exemplo: 1) definição de cores de fontes; 2) definição de tamanho de fontes. A Figura 24 demonstra a definição padrão e um exemplo básico do CSS

Figura 24. Definição e Exemplo de CSS O seletor representa uma estrutura que é usada como uma condição para determinar quais elementos de um grupo de elementos será formatada. A propriedade é a característica que se deseja modificar no elemento (exemplos: color, width) ou conjunto de elementos. O valor representa o valor referente a esta característica. Se modificar a cor do texto, o valor é um Hexadecimal, RGBA ou até mesmo o nome da cor por extenso (exemplo: color:red). O exemplo ilustrado no lado direito da Figura 24 representa o código CSS que define para o seletor corpo: 1) fonte padrão Arial, caso não exista substitui por Verdana; 2) define o valor da propriedade cor de fundo do corpo da página para vermelha; 3) define os valores para a propriedade margem. Nesta pesquisa utilizamos o CSS3 na solução proposta com o objetivo de estilizar elementos dos formulários gerados.

Histórico
A linha do tempo do CSS é apresentada nesta seção. A Figura 25 apresenta a linha do tempo referente à evolução do CSS.

Figura 25.Linha do Tempo CSS (W3C)

57

Em 1996, o consórcio W3C lançou a primeira edição do CSS, contemplando as seguintes características: 1) Introdução da 'id' única para cada propriedade e introdução de classes para as propriedades que devem ter os mesmos atributos estilos eram as coisas mais importantes existiam; 2) Margem, borda, espaçamento e posicionamento também alimentado por folhas de estilo, embora pudesse ser feito usando os elementos HTM; 3)Espaçamento entre linhas e linhas de tabelas também são facilmente definidos usando as folhas de estilo. Em 1998, o consórcio W3C lançou a edição (nível) 2.0 do CSS, contendo, entre outras, as seguintes características: 1) Controlar o posicionamento visual do conteúdo da página através de identação de texto, margens, floats, e posicionamentos absoluto e relativo; 2) Prover efeitos visuais, como sombras; 3)Eliminar imagens e espaços em branco usados para o posicionamento. Em 2012, a edição 3.0 do CSS que se encontra em desenvolvimento, busca implementar, entre outras, as seguintes funcionalidades: 1) Manipulação de opacidade; 2) Texto de estouro de consultas; 3) Meios de comunicação; 4) Gradiente em textos e elementos; 5) bordas arredondadas; 6) sombras em texto e elementos; 7) controle de rotação.

4.4

J AVA S CRIPT O BJECT N OTATION - JSON
JavaScript Object Notation – É um formato de troca de dados simples e leve. Esse

formato é fácil para: 1) os seres humanos lerem e escreverem; 2) máquinas para analisarem e gerarem. Esse formato, baseia-se em um subconjunto da linguagem de programação JavaScript, Standard ECMA-262 3 ª Edição - Dezembro de 1999. JSON é um formato de texto que é completamente independente de linguagem, mas usa convenções que são familiares aos desenvolvedores da família C de linguagens, incluindo: C, C + +, C #, Java, JavaScript, Python, e muitos outros. JSON é construído baseado nas estruturas de dados universais: 1. Uma coleção de pares: nome / valor. Em várias linguagens, Esta coleção é percebida como um objeto de: registro, dicionário, struct, tabela hash, a lista com chave e etc. 2. Uma lista ordenada de valores. Na maioria das linguagens, isto é percebido como uma matriz, vetor e etc. A Figura 26 apresenta do lado esquerdo o modelo de um objeto JSON e no lado direito um exemplo de objeto preenchido no formato JSON:

58

Figura 26.Modelo e Exemplo de JSON Um objeto é um conjunto sem ordenação dos pares: nome / valor. Um objeto começa com {(chave esquerda) e termina com} (chave direita). Cada nome (exemplo:string) é seguido por: (dois pontos) e os pares nome / valor são separados por, (vírgula). O lado direito da Figura 26 apresenta um exemplo do objeto preenchimento no formato JSON.

4.5

F RAMEWORK P HONE G AP
O PhoneGap é um framework para o desenvolvimento de sistemas para dispositivos

móveis que permite confeccionar aplicativos híbridos (web e móvel), onde o desenvolvimento é feito em JavaScript, HTML5 e CSS3, e através da sua API, é possível ter acesso aos recursos nativos do dispositivo além de possibilitar facilmente as criações de plugins (PHONEGAP FRAMEWORK, 2012). A adoção do framework PhoneGap (FPG) elimina a necessidade de aprendizado das diversas linguagens utilizadas no desenvolvimento de aplicativos para plataformas móveis. Com esse framework um sistema é desenvolvido utilizando JavaScript, HTML, CSS3 e JQuery Mobile; e compilado para o sistema operacional da plataforma móvel destino como se fosse um sistema nativo. Com o FPG a construção das aplicações móveis é baseada em padrões WEB, baseada em tecnologia WEB como o HTML5 e javascript. Inclusive, o FPG permite ao desenvolvedor utilizar características nativas dos dispositivos móveis e possibilita implantar um mesmo sistema em múltiplas plataformas móveis. A Figura 28 apresenta a lista das principais características dos dispositivos móveis suportadas pelo FPG versus os respectivos sistemas operacionais das plataformas móveis homologadas.

59

O FPG é uma implementação open source de padrões aberto. Ela será sempre livre e de código aberto sob a Licença Apache, Versão 2.0. Isso significa que os desenvolvedores, instituições educacionais e/ou empresas podem usar PhoneGap para aplicações móveis que estão livres, código aberto, comercial, ou qualquer combinação destes. Além disso, o FPG possui uma crescente e ativa comunidade que vem evoluindo as documentações, criando e publicando aplicativos e plugins novos, utilizando blogs e faqs para troca de informações sobre essa API e principalmente evoluindo as características desse framework. A Figura 27 apresenta as plataformas móveis homologadas, suportadas, para rodar aplicações construídas com o FPG. Essa grande diversidade de plataformas suportadas foi um fator decisivo na escolha desse framework na realização desse trabalho.

Figura 27.Plataformas suportadas com FPG (PHONEGAP FRAMEWORK, 2012).

60

Figura 28.Características suportadas pelo FPG x Sistemas Operacionais dos dispositivos móveis (PHONEGAP FRAMEWORK, 2012)

Histórico
A Figura 29 apresenta anualmente a evolução histórica do framework PhoneGap, destacando ano a ano as relevantes ocorrências no histórico do componente, partindo do ano de 2008, ano de surgimento do framework e finalizando no fim do primeiro semestre de 2012. Em 2008 o FPG foi criado inicialmente pela empresa Nitobi Software para participar do evento iPhoneDevCamp em São Francisco nos EUA em agosto desse ano; No último trimestre do ano de 2008 foi adicionado ao FPG o suporte as plataformas móveis Android e BlackBerry.

61

Em 2009: Em abril de 2009 o FPG foi vencedor do Web 2.0 Expo LaunchPad e ainda no primeiro semestre foram lançadas duas novas versões dessa API, as versões: 0.6.0 e a 0.7.2 para Android e IPhone. No início do segundo semestre foram adicionados o suporte as plataformas:Windows Mobile e Nokia WRT. No último trimestre do ano a versão 0.8 foi aceita pela Apply para AppStore, a infoWorld elegeu o FPG como “top emerging enterprise technology” na categoria "cross-platform mobile app development" e no final desse ano foi adicionado o suporte para Palm. Em 2010: A plataforma Symbian adicionou o FPG. Em 2011: Ocorreu a publicação da versão candidata 1.0 do FPG. Em outubro desse ano a empresa Adobe anunciou a aquisição da empresa Nitobi Software fabricante da FPG. O código do FPG foi contribuído para a Apache Software Foundation visando iniciar um novo projeto chamado Apache Cordova. Neste trabalho, iremos utilizar a sigla FPG para representar o Apache Cordova ou framework PhoneGap com o objetivo de uniformizar o nome do framework e facilitar as suas citações nas próximas seções desse documento (APACHE CORDOVA, 2012). Em 2012: Em janeiro de 2012 foi publicada a versão 1.4 contendo várias correções e novidades para as diversas plataformas móveis. A última versão baixada e utilizada no desenvolvimento deste trabalho foi a versão 1.9.

Inicio do FPG

Integração Symbian

Lançamento das versões 1.4 até a 1.9

2008

2010

2012

2009
O FPG foi premiado

2011
- A adobe Adquiriu o FPG - Mudou nome para Apache Cordova

Figura 29.Histórico anual do FPG

62

O Construtor PhoneGap é um serviço que possibilita ao desenvolvedor compilar na internet (cloud) um aplicativo (integrado ao PhoneGap Framework), gerando assim compatibilidade desse aplicativo com várias plataformas móveis, entre outras: Android, Bada, Apple iOS e Windows Phone 7. O Processo ocorre conforme os seguintes passos: 1) Fazer upload da aplicação integrada ao FPG e escrita em javascript, HTML5 e CSS3 para o Buid PhoneGap; 2) submeter ao serviço Buid PhoneGap; 3) Receber o aplicativo compatível com a plataforma desejada. A Figura 30 apresenta uma visão geral do funcionamento do Build PhoneGap (Build PhoneGap, 2012).

Figura 30.Visão geral do Build PhoneGap (Build PhoneGap, 2012)

4.6

S ÍNTESE DO C APÍTULO
De maneira geral, este capítulo apresentou as definições referentes às tecnologias WEB

adotadas no corrente trabalho. Além disso, foram apresentadas justificativas sobre adoção dessas tecnologias. A seção 4.1 apresentou as principais características sobr JQuery Mobile e sua respectiva linha do tempo. As seções 4.2 e 4.3, foram apresentadas as definições, exemplos e linha do tempo sobre, respectivamente, HTML e CSS. A seção 4.4 apresentou o conceito e as principais características sobre JSON. Além disso, foi apresentada a linha do tempo sobre JSON e ilustrado exemplo do modelo JSON.

63

Por fim, a seção 4.5 apresentou as principais características sobre o framework PhoneGap e sua respectiva linha do tempo. As tecnologias apresentadas nas seções 4.1, 4.2, 4.3 e 4.4 são utilizadas diretamente pela arquitetura do framework PhoneGap. Além disso essa seção justificou a adoção do framework PhoneGap no trabalho corrente.

64

5. TRABALHOS RELACIONADOS
Este capítulo descreve uma revisão bibliográfica - RB para o levantamento e mapeamento do estado da arte na abordagem de desenvolvimento orientado a modelos utilizando modelos clínicos - arquétipos. Neste trabalho, foi realizada uma sistematizada revisão bibliográfica baseada em algumas das principais atividades de uma revisão sistemática, visando obter evidências de trabalhos relacionados a essa pesquisa que utilizaram uma abordagem de desenvolvimento orientada a modelos integrados aos arquétipos. Assim, a seção 5.1 introduz o conceito de revisão sistemática, aqui abreviado como RS. A seção 5.2 descreve o método da RS usado neste trabalho e o motivo do seu uso; nas subseções é apresentado como foi planejada e executada a pesquisa, como foi feita a seleção dos dados analisados, e como foi feito a análise em si.

5.1

I NTRODUÇÃO
A revisão sistemática da literatura é um método de estudo secundário que tem obtido

muita atenção ultimamente em Engenharia de Software - SE (KITCHENHAM, 2007) e é inspirado em pesquisas médicas. Resumidamente, uma revisão sistemática (RS) passa por relatórios primários existentes, revê-los em profundidade e descreve a sua metodologia e resultados. Comparado com revisões de literatura comuns em qualquer projeto de pesquisa, um RS tem várias vantagens: a metodologia bem definida reduz viés, uma ampla gama de situações e contextos pode permitir que mais conclusões gerais e uso de meta-análise estatística pode detectar mais estudos individuais isoladamente (KITCHENHAM, 2007). No entanto, RSs também têm várias desvantagens, a principal é o considerável esforço necessário. As RSs em engenharia de software concentraram-se em estudos quantitativos e empírico, mas um grande conjunto de métodos para a síntese de resultados de pesquisas qualitativas existe conforme colocado em (DIXON-WOODS et al., 2005). Um planejamento antecipado e claro de quais atividades serão executadas e quais endereçamentos serão levados em consideração no momento de tomada de decisões, pode ser bastante benéfico na execução de uma RB. Apesar da não obrigatoriedade da criação do protocolo (nome dado a esse planejamento), os autores que o fizeram incentivam o seu uso

65

alegando ser um artefato importante para avaliar e calibrar o processo de estudo do mapeamento.

5.2

M ÉTODO E P ROTOCOLO DE B USCA
Este trabalho apresenta um estudo de revisão sistemática realizada a fim de verificar o

estado da arte sobre o desenvolvimento orientado a modelos integrado aos arquétipos clínicos através de análise de evidências, como também identificação de aglutinação e ausências de pesquisas relacionadas com temas da área. O objetivo foi evidenciar, através de informações confiáveis, como a academia vem abordando o assunto. O protocolo criado para esta pesquisa pode ser visualizado através da Figura 31. Ele inclui a definição das questões a serem respondidas pela pesquisa, a estratégia de busca, a definição das fontes de pesquisa, a seleção dos estudos, a classificação dos estudos, além das conclusões da pesquisa. Cada uma das etapas do protocolo será explicada nas sessões seguintes, que detalham a condução do mesmo.

Definição das Questões

Realização da Pesquisa

Definição das Fontes de Dados

Seleção dos Estudos

Classificações dos Estudos

Publicação das Conclusões

Figura 31.Protocolo Definido para a Pesquisa

5.2.1 DEFINIÇÃO DAS QUESTÕES
A questão principal que orienta este estudo de mapeamento e reflete o nosso objetivo é: RQ1. Qual a evidência sobre a adoção do desenvolvimento orientado a modelos integrado aos arquétipos clínicos?

66

5.2.2 REALIZAÇÃO DA PESQUISA
Os termos de pesquisa adotados neste estudo foram definidos utilizando a abordagem descrita por (KITCHENHAM, 2007), que descreve cinco etapas: 1) termos devem derivar das perguntas; 2) identificação de grafias alternativas e sinônimas, 3) a constatação de palavrachave, 4) utilização de OR; 5) e definição de operadores de fundir as seqüências de pesquisa. As strings de busca da pesquisa estão disponíveis na Tabela 3. Tabela 3. Strings de Busca "Model-driven" AND ("clinical archetype" or "openehr archetype")

5.2.3 DEFINIÇÃO DAS FONTES DE PESQUISAS
Foram definidos quais engenhos de busca deveriam ser utilizados nas pesquisas. Os engenhos de busca escolhidos foram os considerados como as principais bases de armazenamento de publicações na área de engenharia de software e informática médica. Outro critério de escolha dos engenhos de busca foi a possibilidade de utilização de seus recursos via internet, e a capacidade de leitura dos trabalhos de forma gratuita para alunos da Universidade de Pernambuco através do portal da CAPES. As três fontes de pesquisas escolhidas podem ser visualizadas na Tabela 4. Adicionalmente, foi realizada uma pesquisa manual, relacionada ao objetivo do estudo, no Congresso Brasileiro de Informática de Saúde – CBIS. Os dois níveis de pesquisa (manual e automático) foram processados juntos. A Figura 32 ilustra o fluxo do processo de pesquisa executado. Tabela 4. Fontes de Pesquisa Engenho de Busca Busca Manual (CBIS) IEEE Xplore ScienceDirect PubMed Scholar Google TOTAL: Nº de Obras Encontradas
0 0 1 2 36

39

67

Figura 32.Fluxo do Processo da Pesquisa

5.2.4 SELEÇÃO DOS ESTUDOS
Como pode ser visualizado na Tabela 4, ao se executar as buscas utilizando as strings predefinidas nos engenhos de busca, gerou-se como resultado um baixo número de trabalhos a serem avaliados (39). Apesar do número baixo dos trabalhos encontrados, foi aplicado um filtro para evitar esforço desnecessário. A tabela 5 apresenta Critérios de Inclusão e Exclusão de Trabalhos Relacionados. Tabela 5. Critérios de Inclusão e Exclusão de Trabalhos Relacionados Tipo Exclusão Critério Descrição Objetivo Remover re-trabalho, ou seja, leitura de um mesmo artigo repetidamente ou por especialistas diferentes.

Duplicidade Algumas vezes a mesma obra foi retornada por diferentes engenhos de busca ou através de diferentes strings. Neste caso, apenas uma obra foi selecionada e as demais descartadas. Títulos, resumo e conclusão

Exclusão

Foram analisados os títulos, resumos e Eliminar artigos conclusões dos artigos e verificado se avaliando o título, os mesmos condiziam com o foco da resumo e conclusão. pesquisa.

A ordem na qual os critérios de inclusão e exclusão foram aplicados e a quantidade de trabalhos obtidos como resultados podem ser observados na Figura 33.

68

Critério Inicial

39 trabalhos
Critério por Duplicidade

32 trabalhos
Critério por Título, Resumo e Conclusão

2 trabalhos
Figura 33.Ordem e Resultados da Aplicação dos Critérios

5.2.5 CLASSIFICAÇÃO DOS ESTUDOS
Após a seleção das obras observou-se a necessidade de classificá-las de acordo com seu conteúdo. As classificações dos estudos foram realizadas seguindo a mesma idéia de categorização que utiliza duas facetas, por se tratar de uma maneira estruturada de fazer tal tarefa (KITCHENHAM, 2007). A primeira faceta é baseada nas questões criadas para guiar a pesquisa (seção 3.2.2), e a outra faceta de acordo com o tipo de pesquisa. A execução da classificação foi apenas realizada no conjunto final dos estudos, ou seja, após os processos de filtragem. As classes que formam a faceta de tipos de pesquisa estão descritas na Tabela 6. Tabela 6. Descrição das classes das facetas por conteúdo Classes Pesquisa de Validação Pesquisa de Avaliação Descrição
Técnicas novas que ainda não foram implementadas na prática. Trata-se de experimentos feitos em laboratórios. Técnicas aplicadas na prática e com avaliação conduzida, ou seja, é mostrado como a técnica foi implementada na prática e quais seus pontos positivos e de melhorias. Esta classe também leva em consideração a identificação de problemas na indústria. Uma solução para um determinado problema é proposto podem ser totalmente nova ou extensão de uma técnica existente. Os potenciais benefícios e aplicabilidade da solução são indicados por um pequeno exemplo ou uma satisfatória linha de argumentação. Estes artigos apresentam uma nova maneira de visualizar as coisas existentes pela estruturação através de taxonomia ou modelos

Proposta de Solução

Artigos Filosofia

69

conceituais.

Artigos que descrevem opiniões

Estes trabalhos expressão a opinião de alguém sobre determinada técnica. Eles não dependem de trabalhos relacionados e metodologia de pesquisa.

Artigos que Experiências

descrevem Estes trabalhos descrevem experiências práticas do autor.

5.2.6 CONCLUSÕES DA PESQUISA
O objetivo desta revisão bibliográfica foi verificar o estado da arte sobre o desenvolvimento orientado a modelos integrado a arquétipos e não explicitar de forma detalhada como os artigos adotam arquétipos e MDD. A lista de todas as obras e suas respectivas classificações pode ser visualizada na Tabela 7. A classificação baseada nos tipos das pesquisas nos ajudou na conclusão que os trabalhos tratam de Proposta de Solução e que utilizam uma abordagem de desenvolvimento orientado a modelos integradas a Arquétipos. Tabela 7. Classificação das obras de acordo com os tipos # 01 Classificação Artigo Proposta de A model-driven approach for representing clinical archetypes for Solução Semantic Web environments (Catalina et al, 2008). Proposta de Solução Clinical data interoperability based on archetype transformation (Catalina et al, 2011).

02

Os resultados das classificações baseada na questão RQ1 é detalhado a seguir.

RQ1. Qual as evidências sobre a adoção do desenvolvimento orientado a modelos integrado aos arquétipos clínicos? 01) Foi encontrada evidência da utilização do desenvolvimento orientado a modelos com arquétipos clínicos no artigo de (CATALINA et al, 2008). Esse artigo trata de uma proposta de solução que combina tecnologias de Web Semântica e MDE para transformar Archetype Definition Language - ADL em Ontology Web Language - OWL usando a linguagem de transformação MOFScript. Esse artigo evidenciou a integração de arquétipos com MDE através de uma solução proposta que transformou ADL para OWL. Foi sentida falta de informações que avaliassem ou quantificassem os ganhos utilizando MOFScript na transformação dos conceitos clínicos

70

representados em ADL para OWL. De qualquer forma, concluiu-se que a integração de MDE com arquétipos foi evidenciada e a linguagem MOFScript foi utilizada para efetuar as transformações. 02) Foi encontrada evidência da adoção de técnicas de desenvolvimento orientado a modelos integrado com arquétipo no artigo (CATALINA et al, 2011). Esse artigo foca na interoperabilidade semântica dos registros eletrônicos de saúde. Esse artigo utilizou e estendeu as regras de transformações definidas no artigo 01. Esse artigo não efetuou nenhuma proposta nova em relação as técnicas de MDE utilizadas em relação ao artigo 01.

71

6. ABORDAGEM PROPOSTA
Este capítulo propõe uma abordagem para adotar o desenvolvimento orientado a modelos na confecção de um sistema de cuidado à saúde conforme os arquétipos clínicos. Visando fornecer suporte ao desenvolvimento do HIS, foi definida uma abordagem de desenvolvimento com o intuito de determinar atividades e artefatos que auxiliam a modelagem dos conceitos clínicos – Arquétipos. Na especificação desta abordagem, utilizamos técnicas de MDD para geração semi-automática de alguns dos artefatos. Assim, esta abordagem de desenvolvimento utiliza o paradigma de desenvolvimento dirigido a modelos - MDD para a implementação de aplicações de domínio clínico baseadas respectivamente em metamodelos clínicos. A entrada da abordagem ocorre com o fornecimento de Conceitos Clínicos – CCs que são obtidos no repositório CKM da OpenEHR e representados através de mapa mental. Conforme explanado no capítulo 2, os arquétipos indicam como representar conceitos ou informações de um domínio via expressões computáveis, sendo que essas expressões baseiam-se num modelo de Referência - RM e são definidas na forma de restrições estruturais. A estrutura do RM é restringida pelo arquétipo empregado, disponibilizando uma estrutura resultante que possui as características do conceito clínico definido pelo arquétipo. A Fundação openEHR fornece algumas formas de representar os conceitos clínicos – Arquétipos. Entre essas representações destacamos os mapas mentais que são diagramas que através de palavras-chave podem representar e modelar cognitivamente um conceito ou um domínio específico. Alguns trabalhos (DOWNS, 1973) e (KITCHIN, 1994) ressaltam que esse tipo de representação facilita a mente humana em processar melhor as informações, reduzindo a carga cognitiva para a absorção do conhecimento ou domínio. Neste contexto, o mapa mental foi empregado nesta abordagem com o intuito de facilitar a comunicação e simplificar a modelagem de domínio pelo Especialista de Domínio, tornando esta abordagem mais ágil e eficaz e consequentemente reduzindo a complexidade dos conceitos clínicos arquétipos. Conforme pode ser visto na Figura 34, esses mapas mentais que representam os conceitos clínicos (arquétipos) são transformados automaticamente em modelos conceituais, visando diminuir o gap entre o especialista do negócio e o engenheiro de sistema, através da abordagem proposta por (WANDERLEY et al, 2012). Em seguida, esses modelos conceituais

72

são refinados e projetados manualmente pelos especialistas de domínio e, finalmente, são transformados automaticamente em artefatos executáveis com conformidade com o framework PhoneGap. A Figura 34 apresenta a visão da abordagem proposta.

Figura 34.Visão da Abordagem Proposta Na sequência deste capítulo são apresentados os objetivos da abordagem, visão geral da mesma e a descrição das etapas, contendo os detalhes dos seus conjuntos de atividades.

6.1

O BJETIVOS DA ABORDAGEM
O principal objetivo deste trabalho foi propor uma abordagem que possibilite uma

melhoria na produtividade e qualidade na construção de um sistema clínico, utilizando o paradigma de desenvolvimento orientado a modelos – MDD.

73

Outra motivação foi a tentativa de diminuir a complexidade do desenvolvimento de soluções de cuidado da saúde. Mesmo arquétipos sendo uma proposta de padronização, melhoria de qualidade semântica para os sistemas da área de saúde, foram encontrados problemas na sua adoção conforme ressaltados por HAJAR (2011), que relatou a existência de alguns desafios enfrentados na adoção de arquétipos, entre eles: 1) Ser enorme e complicado: Arquétipos é, naturalmente, grande e complexo e esta complexidade não é inesperada já que os arquétipos definidos pela openEHR são considerados como uma solução para um problema complicado em um domínio complexo (ou seja, o domínio clínico é naturalmente complicado). Por exemplo, o enorme modelo arquétipo permite expressar conceitos complexos clínicos, portanto, um desenvolvedor inexperiente para prover soluções baseadas em arquétipos deve esperar passar algum tempo para aprender os conceitos openEHR. 2) Falhas em aspectos educacionais: A compreensão de um conceito é o primeiro passo para ser capaz de adotá-lo, e esta é ainda mais válida para conceitos tão complexos como os dos arquétipos clínicos definidos pela openEHR. Infelizmente encontramos: pouca documentação formal, guias para iniciantes, raras sessões de formações (treinamentos) e poucas pessoas formadoras ao redor do mundo. Visando minimizar a complexidade na utilização de arquétipos, ou na tentativa de diminuir a curva de aprendizado dos conceitos clínicos (arquétipos), foram utilizados Mapas Mentais – MM para facilitar o entendimento do domínio do Cuidado a Saúde. Além disso, a adoção da infraestrutura de (WANDERLEY et al, 2012) nesta proposta tem o objetivo de aumentar a produtividade na construção dos modelos conceituais clínicos, através da geração automática do modelo conceitual baseado em mapa mental. Adicionalmente, o emprego dos conceitos de desenvolvimento orientado a modelos - MDD no processo proposto permite que os refinamentos inerentes à abordagem proposta de desenvolvimento sejam apoiados por modelos e que os artefatos gerados sejam reutilizáveis. Consequentemente teremos um ganho de produtividade, já que uma parte dos artefatos não será refeitos, isto é, esses artefatos serão reusáveis.

6.2

V ISÃO G ERAL
Essa abordagem consiste em duas etapas: Engenharia de Domínio – ED e Engenharia

de Aplicação - EA. O desenvolvimento das partes gerais, desenvolvimento com foco em

74

reutilização, é chamado de Engenharia de Domínio e o desenvolvimento de um produto (desenvolvimento com reutilização), de Engenharia de Aplicação (LUCRÉDIO, 2009). Para essa abordagem, utilizamos a engenharia de domínio com foco na análise de domínio clínico, usando como referência os Modelos de Arquétipos - AMs, selecionando os requisitos semelhantes que pertencem ao subdomínio OBSERVATION. Conforme detalhado na seção 2.2, a classe genérica OBSERVATION é uma das quatro classes que especializam a classe CARE_ENTRY e é utilizada para registro de informações de Cuidado á Saúde. As informações de Cuidado a Saúde registradas são: os registros de tudo que puder ser observado, medido ou respondido pelo paciente. Esses requisitos são independentes de especialidade médica, por exemplo: Temperatura Corporal. Além disso, de acordo com a abordagem de Lucrédio (2009) foi adicionada o uso de MDD na Engenharia de Domínio com o objetivo da modelagem fazer parte desta abordagem, para aumentar o nível de abstração do desenvolvimento das soluções de cuidado a saúde. A Figura 35 apresenta as duas etapas da abordagem.

Engenharia de Domínio + MDD

Engenharia de Aplicação

Figura 35.Etapas da abordagem Na ED os mapas mentais do subdomínio clínico dos arquétipos são selecionados e recuperados do repositório Clinical Knowledge Manager - CKM (OPENEHR, 2012). O modelo conceitual é refinado e projetado utilizando a ferramenta MagicDraw que é uma ferramenta para modelagem baseada na UML e utilizada pela OpenEHR na definição dos seus metamodelos de arquétipos - AOM (OpenEHR, 2011); são implementadas: o componente de apoio e as transformações M2C para a geração de artefatos reusáveis; Todos os artefatos da ED são usados como apoio a Engenharia de aplicação – EA, onde os sistemas de cuidado de saúde são desenvolvidos baseados no refinamento dos metamodelos da ED. Alguns dos artefatos são utilizados no refinamento e nas transformações.

75

As transformações M2C são reutilizadas para geração de diversos artefatos descritos na abordagem proposta. A Figura 36 apresenta um diagrama do macroprocesso demonstrando os principais atores envolvidos na ED e as respectivas fases da ED proposta, como: Análise de Domínio, Projeção e Implementação.

Figura 36.Diagrama do Macroprocesso - Engenharia de Domínio A ED tem início na fase Análise de Domínio (AD). A AD começa com a coleta dos requisitos do domínio do problema, a definição do escopo, refinamento do modelo conceitual e tem como alvo a modelagem do domínio. Durante a realização dessa atividade o engenheiro de domínio é guiado pelo Modelo de Arquétipo (AM), representados por Mapas Mentais – MM que são obtidos no repositório de arquétipos CKM (OPENEHR, 2011). Na fase de Projeção, o engenheiro de sistemas realiza algumas atividades referentes ao mapeamento do modelo conceitual para o modelo de domínio. As principais atividades realizadas na fase projeção são: 1) Refinamento visando definir submódulos, criando interfaces, abstrações, definindo fronteiras; 2) Refinamento do modelo conforme, tecnologias e padrões adotados; Para a implementação, as atividades começam com o desenvolvimento preliminar que precede o refinamento e a transformação M2C, seguida de algumas outras atividades, entre elas: 1) Desenvolver Perfil UML; 2) Montar ambiente; 3) Desenvolver manualmente o complemento funcional e não funcional; 4) Confeccionar transformação. A Figura 37 apresenta o diagrama do macroprocesso referente as atividades da EA que envolvem algumas das disciplinas tradicionais de engenharia de software, tais como: Análise, Projeto, Implementação e Testes. Durante a realização dessas fases, o Engenheiro de Aplicação é guiado pela UML e pelos diagramas de classes dos metamodelos RM e AM, utilizando as ferramentas MagicDraw e o Papyrus.

76

Figura 37.Diagrama do Macroprocesso - Engenharia de Aplicação

6.3

E TAPAS DA A BORDAGEM
Nesta seção, descrevemos as etapas da abordagem, visando facilitar o

desenvolvimento de sistemas clínicos utilizando o paradigma de desenvolvimento orientado a modelos.

6.3.1 ENGENHARIA DE DOMÍNIO - ED
Conforme apresentado por Leite e Girard (2009) a ED é uma etapa voltada para a confecção de artefatos reusáveis pertencentes a um domínio específico. Outra característica relevante da ED é a determinação das características comuns quanto também das variações das aplicações de um domínio particular (LUCRÉDIO, 2009). Na abordagem proposta, utilizaremos a ED para identificar as características semelhantes do domínio clínico, especificamente dos subdomínios gerais da área de conhecimento OBSERVATION definida pela openEHR e ilustrada na Figura 8. A Figura 38 demonstra através de um diagrama de processo quais as fases e suas atividades, sequencias e como essas atividades da ED são relacionadas.

77

Figura 38.Processo Proposto para Engenharia de Domínio

Análise de Domínio - AD
Conforme exposto por Lucrédio (2009), a fase de Análise de Domínio - AD é o começo da ED que contempla a identificação dos principais conceitos e elementos de um domínio e a determinação de seu escopo. Essa fase inicial é responsável por coletar informações do domínio para as fases subsequentes da abordagem proposta. Essa fase inicia com a seleção de um conjunto preliminar de conceitos clínicos (CCs) baseados em arquétipos, representados por Mapas Mentais (MM), que são adotados em distintas especialidades médicas do domínio do Cuidado de Saúde. A finalização da AD ocorre com a realização da atividade Modelar Domínio - MD, que é iniciada com a execução da atividade Executar a infraestrutura de (WANDERLEY et al, 2012) com o objetivo de obter o modelo conceitual para a realização do refinamento deste modelo conceitual. As atividades da fase Análise de Domínio - AD adotadas neste trabalho são: A Seleção de Arquétipos em Mapa Mentais, nesta atividade o engenheiro de domínio com o auxílio do especialista de domínio, pesquisa, estuda e seleciona (coleta) no repositório CKM os arquétipos (openEHR, 2011), ilustrados através dos mapas mentais representando os conceitos clínicos pertencentes ao subdomínio desejado (define escopo).

78

Como fluxo excepcional, caso o conceito clínico geral desejado pelo especialista do domínio não esteja no repositório CKM de arquétipos – openEHR, esse especialista cria o novo conceito clínico usando a ferramenta linkEHR com o auxílio de um engenheiro de sistemas. Esse novo conceito clínico criado é enviado para a ativa comunidade openEHR, onde a openEHR realiza uma avaliação desse novo conceito, visando evitar repetição, inconsistência. Em seguida, caso tenha resultado positivo da avaliação, é efetuada uma publicação desse novo conceito clínico, colocando-o no repositório de CKM e que passa a ser gerenciado pela openEHR. A exportação do mapa mental (no formato XML), nesta subatividade o especialista de domínio realiza a exportação dos mapas mentais no formato XML para serem insumos, entradas, para a execução da abordagem de Wanderley; A Figura 13 ilustra um exemplo de MM; A execução da abordagem Wanderley, nesta subatividade o especialista de domínio fornece um XML que representa o mapa mental e executa a abordagem de Wanderley (Wanderley et AL, 2012), que após transformação M2C, gera um arquivo no formato XML Metadata Interchange - XMI representando respectivamente o modelo conceitual do conceito clínico fornecido como mapa mental. Na atividade Refinar Modelo de Domínio, o engenheiro de domínio é apoiado quando necessário pelo especialista do domínio que realiza o refinamento no modelo conceitual baseado no uso da ferramenta Case Papyrus adicionado com os AMs e RMs, perfis UML da OpenEHR e um novo perfil UML confeccionado previamente para possibilitar a extensão das características dos elementos dos modelos. Entre outras atividades de refinamento, é possível modificar o modelo conceitual para: 1) a identificação e descrição dos CCs; 2) definir associações entre as entidades; 3) Determinar ordem de apresentação (mesma ordem dos atributos nas classes); 4) Identificar os tipos de dados dos atributos; 5) em alguns casos, identificação de informações sobre restrições de valores possíveis dos atributos. Essa atividade é comumente baseada nos MM e em casos que necessitam de um detalhamento maior (por exemplo: restrição de valores de um determinado atributo) os engenheiros de domínio obtêm um detalhamento dos conceitos clínicos através de consultas manuais aos CCs que estão descritos em ADLs. A saída desta atividade é o modelo de domínio especificado; A Figura 39 ilustra um exemplo do Modelo Conceitual Refinado. Do lado esquerdo da Figura

79

39 é apresentado um modelo conceitual oriundo da abordagem de (Wanderley et al, 2012) e do lado direito é apresentado o modelo conceitual correspondente com o refinamento do tipo e do nome do atributo.

Figura 39.Exemplo de Modelo Conceitual Refinado

Projeção de Domínio - PD
A projeção de domínio é uma fase essencial da engenharia de domínio (BOSCH, 2000). Um dos seus objetivos é definir um conjunto de artefatos reutilizáveis que podem ser combinados para desenvolver aplicativos mais rapidamente e com maior qualidade. Conforme descrito por LUCRÉDIO (2009), a projeção de domínio é um processo iterativo de refinamento. Inicia-se com o domínio todo, e a cada iteração é feito um refinamento que identifica novos módulos, que serão refinados na próxima iteração, e assim por diante, até que o projeto esteja concluído, em função de um entendimento satisfatório sobre o que deverá ser implementado. Nesta fase, ocorre a atividade Projetar Modelo de Domínio, a qual é responsável pela realização do mapeamento do modelo conceitual já refinado para o modelo de domínio. Essa atividade inicia com características de modelo conceitual oriundo da AD, e esse modelo é refinado e projetado manualmente conforme padrões, componentes, plataformas e tecnologias que viabilizarão a fase de implementação. A Figura 40 apresenta o resultado da atividade Projetar Modelo de Domínio.

80

Figura 40.Projeção do Modelo Conceitual para Modelo de Domínio

Implementação de Domínio
Nesta fase é realizada a implementação manual com base nas especificações contidas no modelo de domínio resultante da fase de projeção. Na atividade Desenvolver Perfil UML é confeccionado um perfil UML que possibilita ao Engenheiro de Domínio incluir informações no modelo referentes à apresentação, negócio e persistência das entidades modeladas além de: 1) possibilitar ao Engenheiro de Domínio realizar refinamentos; 2) possibilitar ao engenheiro de sistemas realizar a projeção (mapeamento) do modelo conceitual para o modelo de domínio. Além disso, esse perfil UML criado pode ser utilizado em conjunto com os perfis UML dos modelos da openEHR nas fases AD e Projeção de Domínio. A Figura 41 ilustra o diagrama de classe do perfil UML criado.

81

Figura 41.Diagrama de Classe do perfil UML A atividade Implementar Complemento, visa complementar as soluções de domínio clínico dos requisitos funcionais e não funcionais, essa atividade contempla, entre outras, a implementação manual das classes utilitárias, extensões de padrões de projetos e demais características dos requisitos funcionais, por exemplo: associar a classe Paciente a um Componente ou biblioteca de Controle de Acesso, isto para os sistemas onde o paciente será o responsável pelo registro autenticado das suas observações. Além dos requisitos funcionais, ocorrerá desenvolvimento manual visando atender também aos requisitos de qualidade (não funcionais), tais como: desempenho, facilidade de uso (usabilidade). A Figura 42 apresenta um trecho de código da tela inicial.

82

Figura 42.Tela inicial A atividade Desenvolver Transformações M2C é responsável pela construção dos programas transformadores que são editados através da ferramenta Papyrus (PAPYRUS UML, 2011). Esses programas transformadores M2C são escritos na linguagem MOFScript e tem o objetivo de transformar modelos em texto (M2C). O uso dos modelos na construção de transformações tem se destacado dentre as demais técnicas existentes conforme mencionado por Lucrédio (2009). Isto significa que nesta atividade são criadas as transformações M2C, que são aplicadas aos modelos construídos na Engenharia de Aplicação. Essas transformações têm o objetivo de diminuir os esforços de implementação dos CCs e possibilitar o reuso dos modelos de domínio.

83

Figura 43. Modelo Domínio x trecho código MOFScript x HTML gerado A Figura 43 apresenta um exemplo de M2C, o item 1) apresenta o modelo de domínio identificado com os respectivos estereótipos (persistence, view) das classes e as tagged values dos atributos. As regras de transformações adotadas são descritas na Tabela 8; 2) É um trecho do programa transformador escrito em MOFScript, que recebe como entrada o modelo de domínio resultante do item 1 e transforma-o no artefato de saída (item 3); 3) É o layout da tela de cadastro da temperatura corporal que foi gerada automaticamente pelo programa apresentado no item 2. Além disso, a Figura 43 ilustra: a seta identificada por A que destaca o estereotipo view na classe BodyTemperature no modelo de domínio e o uso desse mesmo estereótipo no programa de transformação escrito em MOFScript; seta B apresenta a linha de

84

código que escreve a palavra <html> no arquivo de saída, o layout HTML da tela de cadastro da temperatura corporal; A seta C descreve a linha de código que obtém a tagged value label da classe BodyTemperature que está sendo lida pelo programa transformador gerando assim o título da tela de cadastro da temperatura corporal. A Tabela 8 apresenta as regras de transformação utilizadas com os mecanismos de extensão criados no perfil UML. Tabela 8. Regras de Transformação Mecanismos de Extensão Este estereótipo é aplicado para classes, onde as entidades identificadas com esse estereótipo são processadas pelo programa gerador que as transformam em layouts de tela em HTML5,conforme FPG. Nesta tagged Value o Engenheiro de Sistema informa a descrição Label do label que aparecerá no título e cabeçalho das telas nos layouts HTML5. Este estereótipo é aplicado para classes, onde as entidades <<persistence>> identificadas com esse estereótipo são processadas pelo programa gerador que as transformam em programas javascript responsáveis pela manipulação (persistência) dos respectivos dados. Nesta tagged Value o Engenheiro de Sistema informa o nome da nameTable tabela que representa essa entidade no banco Sql Lite. Caso não seja informado nenhum valor para essa tagged value, o programa gerador utiliza o nome da classe para transformar no nome da tabela no banco de dados SQL Lite. Nesta tagged Value o Engenheiro de Sistema informa a descrição commentTable do comentário da tabela da entidade do banco de dados. <<propertyAdditional>> Este estereótipo é aplicado para os atributos das classes. Nesta tagged Value o Engenheiro de Sistema informa a descrição Label do label que será transformado pelo gerador em um label da tela HTML5. Esse label da tela aparecerá do lado esquerdo do campo. Nesta tagged Value o Engenheiro de Sistema informa true or Required false para identificar se o atributo será obrigatório. Com isso, o gerador transforma em código javascript que obriga o preenchimento do atributo. Nesta tagged Value o Engenheiro de Sistema informa o valor defaultValue padrão inicial para o atributo. Nesta tagged Value o Engenheiro de Sistema informa true or unique false para identificar se o atributo será o indentificador único da entidade. Com isso, o gerador transforma em código SQL que << View>> Regras de Transformação

85

typePresentation

orderBy

sortDirection

valueInitialAllow

valueFinishAllow

nameColumn

initialValueNormal

finishValueNormal

identifica o campo como Chave Primária - PK. Nesta tagged Value o Engenheiro de Sistema informa o tipo de apresentação (Exemplo: String, password) do atributo. Com isso, o gerador transforma em código correspondente na linguagem HTML5. Nesta tagged Value o Engenheiro de Sistema informa true or false para identificar se o atributo será usado na ordenação da entidade. Com isso, o gerador transforma em código SQL correspondente. Nesta tagged Value o Engenheiro de Sistema informa asc ou desc para identificar o sentido da ordenação do atributo. Com isso, o gerador transforma em código SQL correspondente. Nesta tagged Value o Engenheiro de Sistema informa o menor valor permitido para o atributo. Com isso, o gerador transforma em código javascript correspondente. Nesta tagged Value o Engenheiro de Sistema informa o maior valor permitido para o atributo. Com isso, o gerador transforma em código javascript correspondente. Nesta tagged Value o Engenheiro de Sistema informa o nome da coluna que representa o atributo no banco Sql Lite. Caso não seja informado nenhum valor para essa tagged value, o programa gerador utiliza o nome do atributo para transformar no nome da coluna no banco de dados SQL Lite. Nesta tagged Value o Engenheiro de Sistema informa o limite inferior da normalidade do valor para o atributo. Com isso, o gerador transforma em código javascript correspondente. Nesta tagged Value o Engenheiro de Sistema informa o limite superior da normalidade do valor para o atributo. Com isso, o gerador transforma em código javascript correspondente.

6.3.2 ENGENHARIA DE APLICAÇÃO - EA
A EA é uma etapa da abordagem proposta que tem o objetivo de confeccionar aplicações específicas de um dado domínio (LEITE; GIRARDI, 2009). A EA reusa os artefatos oriundos da ED e suas atividades são baseadas em quatro disciplinas da engenharia de software: Análise, Projeto, Implementação e Testes. A Figura 44 ilustra o diagrama de processo da etapa EA.

86

Figura 44.Diagrama de Processo EA Na abordagem proposta, a etapa EA é responsável pela confecção de aplicações de CCs dos subdomínios semelhantes da classe OBSERVATION que compõe o MA. Visando demonstrar o objetivo relevante da construção de aplicações específicas da EA, foram escolhidos os CCs do subdomínio OBSERVATION: Paciente e Temperatura Corporal com o intuito de construir o aplicativo móvel para registrar a coleta da temperatura corporal do paciente - SOT. O Sistema para Registrar a Temperatura do Paciente - SOT é um aplicativo Web e Móvel que possibilita os pacientes ou profissionais de saúde que realizam assistência domiciliar efetuar registro das aferições das temperaturas corporais do paciente. O principal objetivo do SOT é permitir o registro da temperatura do paciente. Conforme abordado por Carvalho et al (2011), os sistemas móveis adotados na construção de sistemas de cuidado à saúde durante a assistência domiciliar visam coletar observações sobre sinais vitais do paciente.

Figura 45.Mapas mentais do SOT (OPENEHR CKM, 2011)

87

A Figura 45 apresenta os mapas mentais utilizados para a construção do SOT: Paciente e Body Temperature.

Análise
A etapa Análise é responsável pela especificação dos requisitos funcionais referentes aos CCs pertencentes ao subdomínio OBSERVATION para o aplicativo SOT. O Engenheiro de aplicação ou Analista de Sistemas utiliza a ferramenta MagicDraw para produzir artefatos, tais como: Diagrama de Casos de Uso, Diagrama de Colaboração, Diagramas de Estado. Além disso, o engenheiro de aplicação utiliza a ferramenta Papyrus para produzir diagrama de classe. Com o objetivo de descrever a relação dos usuários com a aplicação SOT, alguns artefatos são confeccionados durante a atividade especificar requisitos, entre eles: O Diagrama de Caso de Uso que é responsável por identificar e descrever os atores e as suas respectivas ações exercidas no aplicativo SOT. Por exemplo, a Figura 46 apresenta o diagrama de casos de uso do sistema SOT, descrevendo: os principais requisitos funcionais do sistema SOT relativos ao registro da temperatura corporal do paciente, e a consulta do histórico das aferições das temperaturas corporais do paciente.

Figura 46.Diagrama de Casos de Uso do SOT Outro artefato produzido na atividade especificar requisitos é o diagrama de sequência, também conhecido como diagrama de colaboração. O diagrama de sequência é criado com o objetivo de descrever como o usuário vai interagir com o sistema de acordo com cada caso de uso. A Figura 47, apresenta um diagrama de sequência que descreve a interação do usuário com o sistema para registrar temperatura corporal do paciente.

88

Figura 47.Diagrama de Sequência para registrar Temperatura Corporal

Projeto
Nesta fase os artefatos resultantes da fase da Análise são refinados conforme as tecnologias de hardware e software envolvidos, tais como o framework PhoneGap que é baseado em HTML5, CSS3 e JQuery Mobile (JavaScript). Na atividade de Refinar/Projetar Modelo de Domínio o Engenheiro de Domínio ou engenheiro de sistemas é responsável por mapear o modelo conceitual para o modelo de domínio utilizando como entrada o Modelo Conceitual oriundo da fase de Análise. O modelo de domínio resultante da fase Projeto representa as informações da aplicação referente ao Registro da Temperatura Corporal do Paciente. Como especificado no diagrama de casos de uso ilustrado na Figura 46, o usuário registra a temperatura corporal aferida em seu dispositivo móvel.

Implementação
Nesta fase ocorre a codificação da aplicação e a geração dos artefatos oriundos do modelo de domínio. Com o auxílio da ferramenta Papyrus, o Engenheiro de Aplicação realiza a atividade Geração Automática de Artefatos executando as transformações M2C, que são aplicadas aos modelos de domínio para gerar os seguintes artefatos da aplicação SOT: 1) as telas da

89

aplicação (view); 2) funções responsáveis por restringir o conteúdo dos atributos das entidades; 3) funções responsáveis pela manipulação dos dados (persistência); 4) estrutura de criação dos objetos do banco de dados SQL Lite. A Figura 48 apresenta um trecho do código da tela gerada em HTML5 da aplicação SOT.

Figura 48.Trecho de Código Gerado da Tela em HTML5

90

A atividade Implementação Complementar é realizada pelo engenheiro de sistema ou engenheiro de aplicação com o intuito de confeccionar manualmente algumas características funcionais e ou requisitos de qualidade do sistema SOT. Por exemplo, a tela inicial do aplicativo SOT, foi desenvolvida manualmente com o objetivo de facilitar a navegação no sistema e atender ao requisito de qualidade: facilidade de uso. A Figura 49 apresenta um trecho de código da tela inicial do sistema SOT.

Figura 49.Trecho de código da Tela inicial do aplicativo SOT Além disso, a Figura 49 apresenta trecho do código em HTML5 e JavaScript em conformidade com o framework PhoneGap, podendo assim, ser compilado e executado em várias plataformas móveis distintas conforme descrito na seção 4.5.

91

Testes
Na fase de Testes são realizados os testes de sistema, o SOT é executado com o objetivo de verificar se os aspectos gerais do sistema estão sendo atendidos. Os requisitos funcionais e não funcionais do sistema são testados através da execução do SOT pelo engenheiro de aplicação (analista de sistemas). A Figura 50 ilustra a interface da aplicação SOT em execução.

Figura 50.SOT em execução

92

7. ESTUDO DE CASO - SISTEMA
Este capítulo apresenta a realização de um estudo de caso referente à criação de um protótipo com o objetivo de avaliar a abordagem proposta no capítulo 6. Adicionalmente, foram apresentadas métricas na seção 7.2 como resultado da avaliação do protótipo. No corrente capítulo são apresentadas as etapas da abordagem sendo executadas na implementação de um sistema, protótipo, que permite ao Paciente, registrar as suas medidas dos diversos sinais vitais e que consequentemente possibilita ao profissional de saúde, responsável pelo acompanhamento do paciente, receber essas observações das aferições. O Sistema de Registro e Acompanhamento dos Múltiplos Sinais Vitais e Medidas do Paciente – SASVM é formado por duas partes: 1) O lado cliente ou lado observado, a parte da aplicação que possibilita aos pacientes efetuarem o registro dos seus múltiplos sinais vitais em vários dispositivos de plataformas móveis diferentes (exemplo: Android e IOS). Esses registros são persistidos inicialmente em um banco de dados local, dentro do dispositivo móvel. Além disso, essas observações clínicas são enviadas e persistidas em uma aplicação WEB que está sendo executado em um servidor WEB; 2) O lado Observador, é um módulo web que disponibiliza uma tela (interface) que permite ao profissional de saúde acompanhar a evolução dos sinais vitais dos seus pacientes. A Figura 51 apresenta uma visão geral do funcionamento da aplicação – SASVM.

Figura 51.Visão Funcional do aplicativo SASVM

93

7.1

E NGENHARIA DE A PLICAÇÃO - EA
Este estudo de caso permitiu avaliar a etapa EA da abordagem proposta com a

reutilização dos artefatos confeccionados na Engenharia de Domínio - ED. Serviu ainda para refinar a ED na especificação e projeto do modelo de domínio, na construção das transformações M2C e na realização dos testes de sistema.

7.1.1 ANÁLISE
Esta fase inicia a EA com a especificação da aplicação, onde o engenheiro da aplicação ou analista de sistemas realiza o levantamento de requisitos e define o escopo do sistema. Os Conceitos Clínicos – CCs semelhantes, pertencentes à classe OBSERVATION do Metamodelo de Arquétipos – AM, contemplados pelo SASV, são: 1) Pressão Sanguínea; 2) Peso Corporal; 3) Altura/Comprimento; 4) Consultar o Índice de Massa Corpórea - IMC; 5) Frequência Cardíaca; 6) Frequência Respiratória; 7) Temperatura Corporal. Como muitos desses CCs não tinham sido contemplados na Engenharia de Domínio - ED, foi realizado uma volta as fases da ED para efetuar uma atualização no metamodelo. Neste retorno foram analisados alguns mapas mentais apresentados na Figura 52.

Figura 52.Alguns Mapas Mentais do SASVM

94

Na fase de Análise, o Engenheiro de Aplicação ou Analista de Sistemas na atividade de especificar requisitos confeccionam os artefatos: 1) Diagrama de Casos de Uso - é responsável por identificar e descrever os atores e as suas respectivas ações; 2) Diagrama de Sequência - descreve como o usuário vai interagir com o sistema de acordo com cada caso de uso. O diagrama de casos de uso foi construído pelo Engenheiro da Aplicação, ajudado pela ferramenta MagicDraw, com o objetivo de especificar os requisitos do SASVM

referentes as seguintes funcionalidades: 1) Registrar Os Múltiplos Sinais Vitais; 2) Consultar o Histórico dos Múltiplos Sinais Vitais. Outra funcionalidade, disparada automaticamente pelo relógio (ator clock), é o envio do registro dos sinais vitais e medidas que não foram enviados. A Figura 53 ilustra o diagrama de casos de uso do SASVM.

95

Figura 53.Diagrama de Casos de Uso do SASVM Depois de iniciar o levantamento de requisitos, através do desenvolvimento do diagrama de casos de uso, o Engenheiro de Aplicação descreve manualmente o diagrama de sequência com o objetivo de refinar o caso de uso. A Figura 54 ilustra o diagrama de sequência do caso de uso Consultar Histórico do Sinal Vital (lado Observador).

96

Figura 54.Diagrama de sequência do caso de uso Consultar Histórico do Sinal Vital

7.1.2 PROJETO
Nesta fase da EA, o modelo de domínio referente aos CCs do SASVM é desenvolvido de acordo com as tecnologias envolvidas para a implementação do Lado Cliente e do Lado Observador. O módulo do lado cliente é baseado no Framework phoneGap, com tecnologias baseada em HTML5, javascript (JQuery Mobile) e o banco de dados Sql Lite. Já para o Lado observador, a aplicação servidora terá a ccamada de apresentação com HTML5 e para processar as requisições foi adotado Servlet na linguagem Java. Além disso, para possibilitar persistência no banco de dados foi usado Spring com Hibernate e banco de dados MySql. Para confeccionar o modelo de domínio, o Engenheiro de Aplicação utiliza a ferramenta Papyrus conforme a fase de análise fazendo o refinamento, mapeamento, do modelo conceitual para o modelo de domínio, modelando e utilizando elementos definidos no perfil UML construído na ED. A Figura 55 apresenta um diagrama de classe que mostra uma parte do mapeamento entre os modelos.

97

Figura 55.Mapeamento de Modelo conceitual para Modelo de Domínio

7.1.3 IMPLEMENTAÇÃO
Nesta fase da EA, é realizada a implementação da aplicação, em conformidade com as tecnologias adotadas na atividade de projeto, modelo de domínio e com base no reuso dos artefatos gerados na ED.

98

Com o auxílio da ferramenta Papyrus, é realizada a atividade de Geração automática de Artefatos, através da execução do programa gerador (escrito em MOFScript) que é responsável pela transformação M2C. Os seguintes artefatos foram gerados: 1) Layout de Tela (HTML5); 2) funções de validações e restrições de conteúdo em javascript; 3) funções de manipulação de dados (persistência) e estrutura dos objetos do banco de dados Sql Lite. A Figura 56 apresenta um trecho do código HTML5 e JavaScript gerados que representa o layout da tela no formato HTML5 referente a funcionalidade de adicionar o peso corporal do paciente.

Figura 56.Trecho de código HTML5 e JavaScript Gerados

99

A atividade Implementação Complementar é executada nesta fase com o objetivo de desenvolver manualmente alguns requisitos, entre eles destacamos: a implementação do caso de uso responsável por enviar os registros dos sinais vitais e medidas pendentes de envio da aplicação do lado cliente para o modulo lado observador.

7.1.4 TESTES
Nesta Fase da EA, os testes de sistemas são executados com o objetivo de verificar o funcionamento geral do aplicativo SASVM. O módulo da aplicação SASVM do lado cliente foi submetido para o phoneGap Build gerá-lo para a plataforma Android. O funcionamento do phoneGap Build foi explanado na seção 4.5 dessa trabalho. A Figura 57 apresenta algumas das interfaces executadas referentes à funcionalidade de registrar sinais vitais, mais especificamente: Peso e Temperatura. A Figura 57 apresenta a interface gráfica das telas referentes ao registro de sinais e medidas do SASVM.

Figura 57.Testes do registro de Sinais Vitais e Medidas do SASVM

100

O módulo do lado Observador foi instalado em um servidor Web, possibilitando ao profissional de saúde efetuar a consulta do histórico dos sinais vitais e medidas dos seus pacientes observados (acompanhados), conforme interface da tela apresentada na Figura 58.

Figura 58.Testes da Consulta do Histórico Sinal Vital – Lado Observador do SASVM

7.2

R ESULTADOS
Nesta seção são apresentadas as discussões referentes às observações realizadas

durante o emprego da abordagem e das avaliações realizadas no protótipo desenvolvido.

7.2.1 LINES OF CODE - LOC
Com o resultado produzido na adoção da EA neste capítulo, observamos que as atividades executadas e os artefatos gerados, contribuíram para o aumento da produtividade na construção do SASVM. Uma demonstração desse aumento da produtividade ocorre na geração dos CCs em artefatos executáveis, apoiados pelas transformações M2C.

101

Cerca de 76% das linhas de código (HTML e javascript) dos artefatos executáveis foram gerados. A Figura 59 apresenta um gráfico que ilustra para alguns CCs os respectivos quantitativos das linhas de códigos - LOC geradas automaticamente e desenvolvidas manualmente. As implementações manuais realizadas pelo engenheiro de aplicação são decorrentes do desenvolvimento de funcionalidades adicionais, como: atributo com valor calculado, como acontece com Blood Pressure.

Figura 59.Gráfico LOC Automática x Manual dos CCs

7.2.2 AVALIAÇÃO
Para realizar a avaliação do protótipo SASVM, foi efetuada uma apresentação / treinamento para 10 pessoas, cinco engenheiros de sistemas experientes (com mais de 3 anos de experiência) em desenvolvimento de HIS e cinco estudantes do curso de pós-graduação em Engenharia da Computação da Universidade de Pernambuco. A estratégia de avaliação adotada foi o modelo: Technology Acceptance Model – TAM. O TAM possibilita avaliar a facilidade de utilização e a própria utilidade da tecnologia que é percebida pelos usuários (DAVIS, 1989). Depois da utilização e navegação no SASVM, foram aplicados os formulários de avaliação, baseados no TAM, aos respectivos usuários. Neste formulário continham cinco afirmativas, e as respostas dessas afirmações eram especificações do nível de concordância sobre uma determinada afirmativa, de acordo com a escala de Likert (1932).

102

Além disso, foram realizados convites para três profissionais de saúde (enfermeiros e médico) para participarem da avaliação do protótipo SASVM. Porém, até a data da confecção desta dissertação, os profissionais de saúde estavam com indisponibilidade de tempo para executarem esta avaliação. A Tabela 9 apresenta uma matriz contendo os resultados dos formulários preenchidos pelos avaliadores. Cada linha dessa matriz representa uma afirmativa conforme TAM, que cruzam com os quantitativos das respectivas respostas baseadas na escala de Likert.

Tabela 9. Matriz do Resultado dos Formulários Preenchidos
Concorda plenamente
1.Foi fácil utilizar a tecnologia apresentada.

Concorda parcialmente 1 (20%) ---1 (20%) 1(20%) -----

Nem concorda nem discorda ----1 (20%) ------

Discorda parcialmente ---1 (20%) --1 (20%) --1 (20%)

Discorda totalmente --5 (100%) 4(80%) --4 (80%) 5 (100%) 5 (100%) 4 (80%)

4 (80%) 5 (100%)

2.Adoção dessa tecnologia dificulta a relação médico-paciente. 3. É essencial o uso dessa tecnologia no seu dia-adia. 4. É difícil registrar informações nesta tecnologia. 5.Não foi possível recuperar dados com essa tecnologia.

--3 (60%) 4 (80%) -----

103

8. CONCLUSÕES E TRABALHOS FUTUROS
Este capítulo objetiva apresentar as conclusões deste trabalho, descrever as contribuições, dificuldades encontradas e limitações, assim como apresentar as

recomendações para trabalhos futuros.

8.1

S UMÁRIO DAS C ONCLUSÕES
Apesar do recebimento de investimentos em todo o mundo para o desenvolvimento

dos sistemas de informação, a área da saúde vem enfrentando alguns desafios referentes ao aumento da produtividade e a qualidade no processo de desenvolvimento do HIS. A complexidade no entendimento dos processos de Cuidado a Saúde é outra relevante dificuldade encontrada no desenvolvimento dos HIS. Motivado por estes desafios, e visando minimizar as dificuldades, este trabalho propôs uma abordagem para o desenvolvimento de HIS baseado em arquétipos e utilizando o paradigma de desenvolvimento dirigido a modelos. proposta ajudou a:  Combater os desafios referentes às necessidades de melhorar a produtividade e qualidade do processo de desenvolvimento de HIS. A capacidade de automação e a geração de código resultaram em um ganho da produtividade. Além disso, a mudança do foco das atividades para a modelagem ofereceu um nível mais alto de abstração, o que proporcionou uma melhor qualidade do produto;  Minimizar as dificuldades referentes à complexidade do processo de desenvolvimento, tornando-o mais simples através da geração automática de artefatos que possibilitou uma diminuição na quantidade de artefatos confeccionados manualmente. A adoção de Arquétipos na abordagem proposta auxiliou a:  Diminuir a curva de aprendizado dos Conceitos Clínicos, representados através dos Mapas Mentais;  Aumentar da produtividade na construção dos modelos conceituais, através da adoção da abordagem Wanderley, que gerou o modelo conceitual a partir de um XML que representava um Mapa Mental de determinado Conceito Clínico. A adoção de MDD na abordagem

104

8.2

C ONTRIBUIÇÕES

Como principais contribuições associadas a este trabalho pode-se assinalar:  O próprio desenvolvimento da pesquisa que reúne um rico e variado referencial teórico, com ênfase em Desenvolvimento Orientado a Modelos e Arquétipos;  Adoção de uma abordagem de desenvolvimento de HIS baseando em Engenharia de Domínio e Engenharia de Aplicação;  O desenvolvimento de um perfil UML, que adicionado aos programas

transformadores escritos na linguagem MOFScript possibilitaram a geração automática de vários artefatos executáveis;  O SASVM é um protótipo resultante do estudo de caso executado neste trabalho.

8.3

D IFICULDADES ENCONTRADAS
Algumas dificuldades foram encontradas durante a realização deste trabalho, entre as

mais relevantes pode-se citar:   Dificuldade de obtenção de informação sobre arquétipos, ausência de treinamentos; Alta curva requerida de aprendizado referente ao entendimento dos Metamodelos Arquétipos, tanto o modelo de referência quanto o modelo de Arquétipos. Esses modelos são complexos, possuindo diagramas de classes enormes, com muitos níveis de herança, dificultando o entendimento dos comportamentos e responsabilidades das classes.

8.4

L IMITAÇÕES
Apesar do resultado apresentado na seção 7.2 desse trabalho algumas limitações foram

encontradas, entre as mais relevantes pode-se citar:  Não foram desenvolvidos programas transformadores que contemplassem as regras de negócio referentes às informações resultantes de cálculos e ou fórmulas clínicas, como por exemplo: O Índice de Massa Corporal – IMC que é resultado da divisão do peso corporal sobre o quadrado da altura do paciente;

105

O SASVM não foi integrado a um sistema desenvolvido por terceiros visando validar a interoperabilidade semântica;

Não foi implementada integrações on-line com dispositivos que medem sinais vitais do paciente, como por exemplo: termômetro digital.

8.5

T RABALHOS F UTUROS
Uma série de trabalhos futuros pode ser vislumbrada com a continuação do que foi

produzido nesta dissertação. Entre esses trabalhos, destacam-se:  A confecção de programas transformadores que tem o objetivo de transformar automaticamente os Conceitos Clínicos escritos em ADL para Modelo Conceitual em UML, aumentando assim a produtividade dos especialistas de domínio no

desenvolvimento de HIS;  Desenvolvimento de programas transformadores com o intuito de fazer transformação do tipo Model to Model - M2M, isto é, converter os modelos conceituais para modelos de domínio e vice e versa, aumentando assim a produtividade referente às atividades de refinamento e projeto;  Geração de artefatos relacionados às disciplinas de requisitos e de testes, aumentando a produtividade e melhorando a qualidade do HIS. Exemplo de artefato a ser produzido: os testes unitários;  Criação de programas escritos em OCL com o objetivo de validar e garantir a consistência dos modelos conceituais e modelos de domínio especificados durante a produção do HIS;  Desenvolvimento da integração com equipamentos e/ou dispositivos que aferem sinais vitais, por exemplo, termômetro, e com isso efetuar o registro dos sinais vitais medidos on-line na aplicação que roda no dispositivo móvel. Assim, seria eliminada a necessidade de registro manual pelo paciente. Outra pesquisa a ser explorada consiste em estender a proposta neste trabalho para tratar as variabilidades dos Conceitos Clínicos e aplicar técnicas de Linhas de Produtos de Software na construção dos Conceitos clínicos pertencentes ao domínio OBSERVATION.

106

REFERÊNCIAS
ALHIR, S. Learning UML. Sebastopol: O’Reilly&Associates, Inc. 252p, 2003. AMELLER, Considering Non-Functional Requirements in Model- Driven Engineering, 2009. APACHE CORDOVA. Acesso em 07/05/2012. Disponível em: http://incubator.apache.org/cordova/#about APACHE VELOCITY, acesso em: 02/02/2012. Disponível em: http://velocity.apache.org/ BEALE, T. Archetype Object Model. Novembro 2008. Acesso em: 22/01/2011. Disponível em: http://www.openehr.org BEALE, T. Archetype constraint-based domain models for future-proof information systems. p. 69, 2001. Disponível em: http://www.deepthought.com.au BEALE, T. et al. Data Types Information Model. Novembro 2008. Acesso em: 22/03/2011. Disponível em: http://www.openehr.org BEALE, T. The openEHR Archetype Model: openEHR Templates. Fevereiro 2010. Acesso em: 22/03/2011. Disponível em: http://www.openehr.org BEALE, T; FRANKEL, H. The openEHR Information Model: Extract Information Model. Maio 2010. Acesso em 22/03/2011. Disponível em: http://www.openehr.org BEALE, T.; HEARD, S. Archetype Definition and Principles. 2007. Acesso em: 11/01/2011. Disponível em: http://www.openehr.org BEALE, T.; HEARD, S. openEHR Architecture Overview. Abril 2007. Acesso em:

22/03/2011. Disponível em: http://www.openehr.org BEALE, T.; HEARD, S. Archetype Definition Language. Dezembro 2008. Acesso em: 23/03/2011. Disponível em: http://www.openehr.org

107

BEALE, T. et al. Data Structures Information Model. Novembro 2008. Acesso em: 23/03/2011. Disponível em: http://www.openehr.org BEALE, T. et al. Data Types Information Model. Novembro 2008. Acesso em: 22/03/2011. Disponível em: http://www.openehr.org BEALE, T. et al. EHR Information Model. Agosto 2008. Acesso em: 22/03/2011. Disponível em: http://www.openehr.org BEALE, T. et al. Support Information Model. 2008. Acesso em: 22/03/2011. Disponível em: http://www.openehr.org BEALE, T. et al. Commom Information Model. Abril 2010. Acesso em: 22/03/2011. Disponível em: http://www.openehr.org BERGMANN, N. Better Design Methods for eHealth Software, International Journal of Engineering and Industries, v. 1, n. 1, p. 1-9, 2010. BEZERRA, E. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro: Elsevier, 320p, 2002. BÉZIVIN, On the Unification Power of Models, Software and Systems Modeling, vol. 4, pp. 171-188, 2005. BITTAR, T. J. et al. Web communication and interaction modeling using model-driven development. In: Proceedings of the 27th ACM international conference on Design of communication. New York, NY, USA: ACM, 2009. (SIGDOC ’09), p. 193–198. ISBN 9781-60558-559-8. Disponível em: http://doi.acm.org/10.1145/1621995.1622033 BUILD PHONEGAP. Acesso em 07/05/2012. Disponível em: https://build.phonegap.com/ BUZAN, T. The Mind Map Book, BBC Active, 2003. CAMBRIDGE DICTIONARY - Cambridge University Press. Acesso em: 23/01/2012. Disponível em: http://www.dictionary.cambridge.org

108

CARVALHO, S, COPETTI, A. E FILHO, O. Sistema de computação ubíqua na assistência domiciliar à saúde, 2011. CHEN, P. The Entity-Relationship Model: Toward a Unified View of Data, ACM Trans. on Database Systems, vol. 1, pp. 9-36, 1976. CIMI - Clinical Information Modelling Initiative. Acesso em 07/08/2011. Disponível em: http://www.openehr.org/326-OE DAVIS, F. D. Perceived Usufulness, Perceived Ease of Use, and User Acceptance of Information Technology. MIS Quarterly, v. 13, n. 3, p. 318–341, 1989. DENNIS et al. Archetype-based electronic health records: a literature review and evaluation of their applicability to health data interoperability and access. Acesso em 03/05/2011. Disponível em: http://www.himaa.org.au/members/journal/himj_38_2_2009/wollersheim_archetypebased_elec_health_rec.pdf DEURSEN, A. V.; KLINT, P. Little languages: little maintenance? Journal of Software Maintenance, v. 10, n. 2, p. 75–92, 1998. DICTIONARY AND THESAURUS - Merriam-Webster Online. Acesso em: 23/01/2012. Disponível em: http://www.merriam-webster.com DOWNS, R. G. and Stea D. Image & Environment: Cognitive Mapping and Spatial Behavior, 1973. ERIKSSON, H. et al. UML 2 Toolkit. Indianapolis: Wiley Publishing, 2004. 552p. FOWLER, M. home page, Language Workbenches and Model Driven Architecture. Acesso em: 10/11/2010. Disponível em: http://martinfowler.com/articles/mdaLanguageWorkbench.html FRANCE, R.; RUMPE, B. Model-driven development of complex software: A research roadmap. In: 2007 Future of Software Engineering. Washington, DC, USA: IEEE Computer

109

Society, 2007. (FOSE ’07), p. 37–54. http://dx.doi.org/10.1109/FOSE.2007.14

ISBN 0-7695-2829-5. Disponível em:

FRANKEL, Model Driven Architecture: Applying MDA to Enterprise Computing: Wiley Publishing, 2003. FREIRE, S. M. et al. Utilizando o modelo dual para a representação e persistência de contexto em aplicações ubíquas de telemonitoramento. VIII Workshop de Informática Médica, p. 252– 255, 2008. FUENTES-FERNÁNDEZ, L.; VALLECILLO-MORENO, A. An introduction to UML profiles. European Journal for the Informatics Professional, [s.l.]: Novática, v. 5, n. 2, p. 615, 2004. GAETE, R. A. C. ; RALHA, Célia Ghedini, Proposta Metodologica de Desenvolvimento de Arquétipos Aplicado a Vigilância Alimentar e Nutricional Em: XII Workshop de Informática Médica (WIM 2012), 2012, Curitiba. Anais do XII WIM. Porto Alegre : SBC, v. 1, p. 1-10, 2012. HAJAR, The Intersection of Clinical Decision Support and Electronic Health Record: A Literature Review. Acesso em: 01/12/2011. Disponível em: http://fedcsis.eucip.pl/proceedings/pliks/13.pdf HISTORY HTML – W3C. Acesso em: 03/03/2012. Disponível em: http://dev.w3.org/html5/spec/introduction.html#history-1 HUMM, U. SCHREIER, and J. SIEDERSLEBEN, Model-Driven Development: Hot Spots in Business Information Systems, European Conf. on Model Driven Architecture Foundations and Applications (ECMDA-FA). Nuremberg, Germany, 2005. INTRODUCING JSON. Acesso em: 05/03/2012. Disponível em: http://www.json.org/ KITCHENHAM, B. and CHARTERS, S. Guidelines for performing Systematic Literature Reviews in Software Engineering. Technical Report EBSE 2007-001, Keele University and Durham University Joint Report, 2007.

110

KITCHIN, R. M., Maps Cognitive: O que são eles e porque o estudo deles? Environment Psychology Journal, 14: 1-19, 1994. KLEPPE, A.; WARMER, J.; BAST, W., MDA Explained - The Model Driven Architecture Practice and Promise. [S.l.]: Addison-Wesley, 2003. (Object Technology Series) KÜHNE T. What is a Model? in Dagstuhl Seminar Proceedings, 2005. LEITE, A.; GIRARDI, R. Um processo para a engenharia de domínio e de aplicações multiagente: As fases de projeto de domínio e de aplicações. III Simpósio Brasileiro de Componentes, Arquiteturas e Reutilização de Software. [S.l.: s.n.], 2009. LIDDLE, S. W. Model-Driven Software Development. 2010. Acesso em: 07/12/2010. Disponível em: http://www.deg.byu.edu/papers/LiddleMDD.pdf LIKERT, R. A Technique for the Measurement of Attitudes. Archives of Psychology, v. 22, n. 140, 55 p, 1932. LINKEHR Site, acesso em: 01/12/2011. Disponível em: http://www.linkehr.com/ LUCREDIO, D. Uma Abordagem Orientada a Modelos para Reutilização de Software. Tese (Doutorado) — Universidade de São Paulo, São Paulo, 2009. MDA, 2010. Acesso em: 22/09/2010. Disponível em: http://www.omg.org/mda/ MELLOR; A. CLARK; T. FUTAGAMI Model-Driven Development, IEEE Software, vol. 20, pp. 14-18, 2003. MELLOR; BALCER, Executable UML: A Foundation for Model-Driven Architecture: Addison Wesley, 2002. MENEZES, A. L.; CIRILO, C. E.; MORAES, L. C.; SOUZA, W. L.; PRADO, A. F., Using Archetypes and Domain Specific Languages on Development of Ubiquitous Applications to Pervasive Healthcare. In: Proceedings of the 23rd IEEE International Symposium on Computer-Based Medical Systems - CBMS. Perth, 2010.

111

MERNIK, M.; HEERING, J.; SLOANE, A. M. When and how to develop domain-specific languages. ACM Comput. Surv., ACM, New York, NY, USA, v. 37, p. 316–344, December 2005. ISSN 0360-0300. Acesso em: 10/09/2010. Disponível em:

http://doi.acm.org/10.1145/1118890.1118892 MOF 2.0, 2006. Acesso em: 22/09/2010. Disponível em: http://www.omg.org/spec/MOF/2.0/ MOFSCRIPT, acesso em 10/06/2011. Disponível em: http://www.eclipse.org/gmt/mofscript/ NARDON, F, FRANÇA, T. e NAVES, H., Construção de Aplicações em Saúde Baseadas em Arquétipos, XXI Congresso Brasileiro de Informática em Saúde (CBIS), 2011. OBJECT MANAGEMENT GROUP - OMG. MDA Guide, v.1.0.1, OMG Document formal/2003-06-01 edition. Needham, MA, USA, 2003. OBJECT MANAGEMENT GROUP. Unified Modeling Language: Superstructure, v. 2.1.2, OMG Document formal/2007-11-02 edition. Needham, MA, USA, 2007. OCL - Object Constraint Language, 2009a. Acesso em: 16/10/2010. Disponível em: http://www.omg.org/technology/documents/formal/ocl.htm OLDEVIK, J. MOFScript Eclipse PlugIn: MetamodelBased Code Generation. In: eclipse technology exchange workshop, Nantes. Nantes: [s. n.], 2006. OLDEVIK, J. MOFScript User Guide. p.33. Guia do usuário, [s. l.]: [s. n.], 2009. OPENEHR CKM. Clinical Knowledge Manager. 2011. Acesso em: 10/10/2011. Disponível em: http://www.openehr.org/knowledge/ OPENEHR. openEHR Fundation. 2011. Acesso em: 22/10/2011. Disponível em: http://www.openehr.org PAPYRUS UML. Acesso em: 10/07/2011. Disponível em: www.papyrusuml.org/ PHONEGAP FRAMEWORK. Acesso em: 01/05/2012. Disponível em: http://phonegap.com/about

112

POOLEY, R. J.; WILCOX, P. Applying UML: advanced application. Oxford: ButterwortHeinemann, 2004. POPMA, R. JET Tutorial Part 1 (Introduction to JET). May 2004. Eclipse Corner Article. Acesso em: 10/11/2010. Disponível em: http://www.eclipse.org/articles/Article-JET/jet_tutorial1.html PORRES, I. et al. Development of an Ubiquitous Decision Support System for Clinical Guidelines using MDA. In: 19TH INTERNATIONAL CONFERENCE ON ADVANCED INFORMATION SYSTEMS ENGINEERING, 2007, Trondheim. Proceedings. Trondheim: Springer, 2007. PORTARIA Nº 2.073. Acesso em: 24/12/2011. Disponível em: http://bvsms.saude.gov.br/bvs/saudelegis/gm/2011/prt2073_31_08_2011.html PRESSMAN, R. S., Software Engineering: a Practitioner's Approach. [S.l.]: McGraw-Hill, 2005. SAMPAIO, G. B. GeoProfile – Um Perfil UML para Modelagem Conceitual de Bancos de Dados Geográficos. 65f. Dissertação (Mestrado em Ciência Da Computação). Universidade Federal de Viçosa, Viçosa, 2009. SCHMIDT, D. C. Guest editor’s introduction: Model-driven engineering. IEEE Computer v.39, n. 2, p. 25–31, 2006. SEIDEWITZ E., What Models Mean, IEEE Software, vol. 20, pp. 26-32, 2003. SILVA, M. S. CSS3 - desenvolva aplicações web profissionais com uso dos poderosos recursos de estilização das css3, 2007. SILVA, M. S. JQuery Mobile Desenvolva aplicativos para dispositivos móveis com HTML5, CSS3, AJAX, Jquery e JQuery UI, 2012. SOFTWARE ENGINEERING INSTITUTE - SEI. Current Perspectives on Interoperability. ISR Technical Report # CMU/SEI-2004-TR-009 ESC-TR-009. Carnegie Mellon, Pittsburgh, EUA, 2004. 2p.

113

SOUZA, R E DE OLIVERA, A., Abordagens Orientadas a Modelos no desenvolvimento de software em Saúde: Contribuições e Perspectivas. Acesso em: 01/08/2012. Disponível em: http://www.lbd.dcc.ufmg.br/colecoes/wim/2012/001.pdf STAFIELD, B. Atenção primária: equilíbrio entre necessidades de saúde, serviços e tecnologia, volume 4. UNESCO, Ministério da Saúde, Brasília, Brasil, 2002. STEINBERG, D. et al. EMF Eclipse Modeling Framework. [S.l.]: Addison-Wesley, 2008. VOELTER, M.; GROHER, I. Product line implementation using aspect-oriented and modeldriven software development. Software Product Line Conference, International, Computer Society, Los Alamitos, CA, USA, v. 0, p. 233–242, 2007. WANDERLEY, F.; DA SILVEIRA, D. An Infrastructure to Diminish the Gap between the Business Specialist and the Software Designer, 8th International Conference on the Quality of Information and Communications Technology, Lisbon, Portugal, 3 to 6 September 2012. WATSON, A. UML vs. DSL: a false dichotomy, [s. l.]: [s. n.], 2007. XMI 2.1.1, 2007. Acesso em: 25/09/2010. Disponível em: http://www.omg.org/spec/XMI/2.1.1/ IEEE

114