UNIVERSIDADE DE PERNAMBUCO ESCOLA POLITCNICA DE PERNAMBUCO PROGRAMA DE PS-GRADUAO EM ENGENHARIA DA COMPUTAO

Legilmo Marcelo Fontes de Oliveira

Uma abordagem orientada a modelos no desenvolvimento de sistemas clnicos baseado em arqutipos

Dissertao de Mestrado

Recife, 2012.

UNIVERSIDADE DE PERNAMBUCO ESCOLA POLITCNICA DE PERNAMBUCO PROGRAMA DE PS-GRADUAO EM ENGENHARIA DA COMPUTAO

Legilmo Marcelo Fontes de Oliveira

Uma abordagem orientada a modelos no desenvolvimento de sistemas clnicos baseado em arqutipos

Dissertao de Mestrado apresentada ao Programa de Ps-Graduao em Engenharia da Computao da Universidade de Pernambuco, como requisito parcial para obteno do Ttulo de Mestre em Engenharia da Computao.

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 decises, pela fora transmitida que me encoraja a enfrentar os momentos difceis.

AGRADECIMENTOS
Os meus sinceros agradecimentos so destinados: Aos meus pais, Llia Oliveira e Joo Gilberto, que em toda minha vida me incentivaram a crescer com conhecimento. Em especial, a minha me pelos conselhos, incentivos e cuidados contnuos; Aos meus irmos: Joo Gilberto, Wellington Andre e Gllia Valeria pelo companheirismo. Agradeo principalmente minha irm Gllia, pelo seu exemplo de luta, pelo apoio, incentivo e unio de sempre; minha esposa, Daniela Eugenia, que me ajudou desde a inscrio 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 ausncia por causa da minha dedicao ao mestrado; Aos meus filhos Mariela, Fernanda e Daniel. A presena de vocs na minha vida um estmulo de energia. Foi em vocs que ganhei foras para ultrapassar cada dificuldade encontrada durante o mestrado; minha famlia em geral, tios e primos. Em especial a minha tia Ivone, que uma referncia de conhecimento e experincia, fornecendo informaes essenciais nas minhas escolhas; Aos amigos, Jose Damaricio, Marcos Pereira, Felipe Leo, Christian Lins, Rafael Oliveira, Guilherme Camacho e Priscila Alcantara pelas experincias compartilhadas durante esses anos. Em especial, a Jose Damaricio pelas orientaes, sugestes tcnicas, companheirismo e contnua colaborao; Aos casais da igreja, que vm nos apoiando nas nossas ausncias 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 ausncia pelo envolvimento no mestrado; A todos os entrevistados que influenciaram diretamente o resultado deste trabalho; Aos amigos da UPE, Eric Souza, Ariane Nunes, Maurcio Manoel, Anthony Lins e Fernando Wanderley pelas experincias compartilhadas durante as disciplinas. Em

iv

especial, a Fernando Wanderley pelas orientaes, pacincia, companheirismo e contnua colaborao; Ao meu orientador, Vinicius, que me acolheu, acreditou em mim e orientou durante estes anos; Aos membros da banca examinadora, Daniel Lucrdio, Maria Lencastre com seus valiosos comentrios durante a defesa ajudaram a enriquecer muito este trabalho; A todos os professores do programa de ps-graduao em Engenharia da Computao da Universidade de Pernambuco por todos os ensinamentos recebidos; Aos membros da equipe do CESAR que fao parte, Walter Jardim, Felipe Evangelista, Marcelo Goncalves, Wilton Oliveira, Paloma Nunes, Liane Bandeira, Amaro Elton, Carlos Gomes e Allan Araujo pela compreenso e apoio no andamento do mestrado; s instituies que zeram com que esta trajetria fosse possvel. Estas incluem a UPE, por ter sido a minha casa durante estes anos, CAPES que em diversos momentos me ajudou nanceiramente, espero ter correspondido e continuar correspondendo altura este investimento em mim realizado. Agradeo a Deus por me iluminar, guiar meus passos, por me dar foras dia a dia para concluir mais uma caminhada. Obrigado a todos !

Nada poder me abalar, nada poder me derrotar, pois minha fora e vitria tm um nome e Jesus... Sandro Andrade

vi

RESUMO
A rea da sade vem recebendo investimentos em todo mundo para o desenvolvimento de sistemas de informao 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 implementao de sistemas de informaes de sade apresenta alguns desafios, dentre os quais a complexidade dos processos de cuidado sade se destaca. Neste contexto, a tentativa de minimizar a complexidade no aprendizado do domnio clnico e a necessidade de aumentar a produtividade e a qualidade na construo dos sistemas de informao de sade (Healthcare Information System HIS) surge como requisitos essenciais. Para diminuir a complexidade dos Processos de Cuidado a Sade e aumentar a produtividade e qualidade na construo dos HIS, a adoo de arqutipos integrada a uma abordagem de desenvolvimento orientada a modelos aparecem como uma alternativa potencial para resolver esses problemas. Conforme definido, arqutipos so fatias de conhecimento que apontam como representar conceitos ou informaes de um determinado domnio. Adicionalmente, as abordagens orientadas a modelos apresentam um potencial relevante para lidar de forma adequada com esses desafios pelo fato de oferecerem um nvel mais alto de abstrao no desenvolvimento de software. Tal caracterstica proporciona, entre outros benefcios: reusabilidade, portabilidade e

interoperabilidade, aumentando a produtividade do processo e a qualidade das aplicaes. Neste contexto, este trabalho de mestrado apresenta uma abordagem, referente ao desenvolvimento dirigido a modelos (Model-Driven Development MDD) na confeco de aplicaes para o Cuidado de Sade do paciente baseada em arqutipos clnicos. Com a adoo de MDD, a abordagem proposta composta por um conjunto de atividades que visam ajudar e aumentar a produtividade das equipes no desenvolvimento de sistemas clnicos.

Palavras-chave: MDE, MDD, MDA, Arqutipo clnico, 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 Especificao openEHR (OPENEHR, 2011) ....................................................................... 22 Figura 2. Informao x Arqutipos ....................................................................................................................... 24 Figura 3. Estrutura de pacotes (OPENEHR, 2011) ............................................................................................... 25 Figura 4. Pacote Core RM (OPENEHR, 2011) ..................................................................................................... 25 Figura 5. Viso dos pacotes do patterns (OPENEHR, 2011) ................................................................................ 27 Figura 6. Pacotes pertencentes ao domain (OPENEHR, 2011) ............................................................................. 28 Figura 7. Modelo de informao EHR (OPENEHR, 2011) .................................................................................. 28 Figura 8. Relacionamento das informaes para o Processo de Investigao (OPENEHR, 2011) ....................... 30 Figura 9. Modelo Dados Demogrficos (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 Criao de Software (LUCRDIO, 2009) ....................................................................... 38 Figura 15. Representao das iniciativas de Moden-Driven (AMELLER, 2009) ................................................. 42 Figura 16. Nveis de abstraes de MDA ............................................................................................................. 42 Figura 17. Fluxo de Transformao 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 Cdigo HTML5 ............................................................................................................... 56 Figura 24. Definio 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. Caractersticas suportadas pelo FPG x Sistemas Operacionais dos dispositivos mveis (PHONEGAP FRAMEWORK, 2012) ................................................................................................................................. 61 Figura 29. Histrico anual do FPG ....................................................................................................................... 62 Figura 30. Viso 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 Aplicao dos Critrios .................................................................................. 69 Figura 34. Viso da Abordagem Proposta ............................................................................................................ 73 Figura 35. Etapas da abordagem ........................................................................................................................... 75

ix

Figura 36. Diagrama do Macroprocesso - Engenharia de Domnio ...................................................................... 76 Figura 37. Diagrama do Macroprocesso - Engenharia de Aplicao .................................................................... 77 Figura 38. Processo Proposto para Engenharia de Domnio ................................................................................. 78 Figura 39. Exemplo de Modelo Conceitual Refinado ........................................................................................... 80 Figura 40. Projeo do Modelo Conceitual para Modelo de Domnio .................................................................. 81 Figura 41. Diagrama de Classe do perfil UML ..................................................................................................... 82 Figura 42. Tela inicial ........................................................................................................................................... 83 Figura 43. Modelo Domnio x trecho cdigo 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 Sequncia para registrar Temperatura Corporal ............................................................. 89 Figura 48. Trecho de Cdigo Gerado da Tela em HTML5 ................................................................................... 90 Figura 49. Trecho de cdigo da Tela inicial do aplicativo SOT............................................................................ 91 Figura 50. SOT em execuo ................................................................................................................................ 92 Figura 51. Viso 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 sequncia do caso de uso Consultar Histrico do Sinal Vital......................................... 97 Figura 55. Mapeamento de Modelo conceitual para Modelo de Domnio ............................................................ 98 Figura 56. Trecho de cdigo HTML5 e JavaScript Gerados................................................................................. 99 Figura 57. Testes do registro de Sinais Vitais e Medidas do SASVM ................................................................ 100 Figura 58. Testes da Consulta do Histrico Sinal Vital Lado Observador do SASVM ................................... 101 Figura 59. Grfico LOC Automtica x Manual dos CCs .................................................................................... 102

LISTA DE TABELAS
Tabela 1. Categoria (tipos) de dados do openEHR ............................................................................................... 26 Tabela 2. Estruturas Genricas do openEHR ........................................................................................................ 27 Tabela 3. Strings de Busca .................................................................................................................................... 67 Tabela 4. Fontes de Pesquisa ................................................................................................................................ 67 Tabela 5. Critrios de Incluso e Excluso de Trabalhos Relacionados ............................................................... 68 Tabela 6. Descrio das classes das facetas por contedo .................................................................................... 69 Tabela 7. Classificao das obras de acordo com os tipos .................................................................................... 70 Tabela 8. Regras de Transformao ...................................................................................................................... 85 Tabela 9. Matriz do Resultado dos Formulrios Preenchidos ............................................................................. 103

xi

LISTA DE ACRNIMOS
AD Anlise de Domnio ADL Archetype Definition Language AM Archetype Model AOM Metamodelos de arqutipos AP Archetype Profile CBIS Congresso Brasileiro de Informtica de Sade CCs Conceitos Clnicos CIM Modelo Independente da Computao CKM Clinical Knowledge Manager EA Engenharia de Aplicao ED Engenharia de Domnio EHRs Registros Eletrnicos de Sade 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 Domnio 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 Pronturio Eletrnico do Paciente PIM Modelo Independente de Plataforma PSM Modelo plataforma especfica RES Registro Eletrnico de Sade

xii

RM Reference Model RMOP Registro Mdico Orientado a Problemas SASVM Sistema de Acompanhamento dos Mltiplos Sinais Vitais e Medidas do Paciente SUS Sistema nico de Sade SE Engenharia de Software SEI Software Engineering Institute TAM Technology Acceptance Model TOM Template Object Model UI Interface do Usurio UML Unified Modeling Language XMI XML Metadata Interchange

xiii

SUMRIO
1. Introduo
1.1 1.2 1.3 1.4 1.5 Caracterizao do Problema Motivao Objetivos Escopo Negativo Organizao do Trabalho 16 17 17 18 20

16

Arqutipos
2.1 Fundao openEHR 2.2 Modelo Dual 2.2.1 Modelo de Referncia - RM 2.2.2 Modelo Arqutipo - AM 2.3 Archetype Definition Language - ADL 2.4 Mapa Mental 2.5 Sntese do Captulo 23 23 24 32 33 35 36

21

Desenvolvimento Dirigido a Modelos

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 Definio Histrico Iniciativas Metodologia Unified Modeling Language - UML Metamodelagem Mecanismos de Extenso da UML Perfis UML Transformaes de Modelos Sntese do Captulo 37 40 40 43 44 45 46 48 49 51

37

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 Sntese do Captulo 52 54 56 58 59 63

52

5. Trabalhos Relacionados
5.1 Introduo 5.2 Mtodo e Protocolo de Busca 5.2.1 Definio das Questes 5.2.2 Realizao da Pesquisa 5.2.3 Definio das Fontes de Pesquisas 5.2.4 Seleo dos Estudos 5.2.5 Classificao dos Estudos 5.2.6 Concluses da Pesquisa 65 66 66 67 67 68 69 70

65

6. Abordagem Proposta
6.1 Objetivos da abordagem 6.2 Viso Geral 6.3 Etapas da Abordagem 6.3.1 Engenharia de Domnio - ED 6.3.2 Engenharia de Aplicao - EA 73 74 77 77 86

72

xiv

7. Estudo de Caso - Sistema

7.1 Engenharia de Aplicao - EA 7.1.1 Anlise 7.1.2 Projeto 7.1.3 Implementao 7.1.4 Testes 7.2 Resultados 7.2.1 Lines of Code - LOC 7.2.2 Avaliao 94 94 97 98 100 101 101 102

93

8. Concluses e Trabalhos Futuros

8.1 8.2 8.3 8.4 8.5 Sumrio das Concluses Contribuies Dificuldades encontradas Limitaes Trabalhos Futuros

104
104 105 105 105 106

Referncias

107

xv

1. INTRODUO
Este captulo motiva e caracteriza o problema a ser resolvido nesta dissertao, apresenta o objetivo a ser atingido, alm da definio do escopo negativo. Por fim, descreve a estrutura na qual esto organizados os demais captulos deste documento.

1.1

C ARACTERIZAO DO P ROBLEMA
O crescente aumento das exigncias por sistemas de qualidade refletem uma maior

exatido os seus processos organizacionais. Diante desse cenrio, a indstria 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 tm sido feitos grandes investimentos para o desenvolvimento de Sistemas de Informao em Sade (Health Information Systems HIS), com o objetivo de prover um ganho de produtividade na rea da sade, atravs da captao dos benefcios proporcionados pelas novas tecnologias utilizadas no

desenvolvimento de software. Portanto, tem sido dada uma considervel ateno ao potencial das abordagens orientadas a modelos no suporte ao desenvolvimento de HIS. Bergmann (2010) menciona tambm que a tendncia global em cuidados de sade est voltada para modelos de ateno mais centrados no paciente, baseada na manuteno do bemestar, ao invs dos modelos tradicionais centrados no mdico que so focados nas doenas. 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 representao das principais caractersticas de um sistema em modelos, os quais so construdos e refinados conforme o sistema desenvolvido (VOELTER; GROHER, 2007). Alm disso, MDD possibilita a especificao do sistema de maneira a tornar possvel a gerao dos artefatos da aplicao de forma automtica atravs de operaes de transformaes de modelo para texto.

16

Por outro lado, as solues adotadas no desenvolvimento dos HIS so complexas e mudam constantemente, isto eleva a dificuldade de implementao e manuteno dos HIS (DENNIS, 2009). Neste contexto, o conjunto de especificaes proposto pela Fundao openEHR (BEALE,2002) conhecida como Arqutipos, a qual tem o intuito do desenvolvimento de padres abertos para a construo de HIS, fornece meios para uma separao entre a modelagem da informao e a modelagem de dados clnicos, chamado de modelo Dual, diminuindo assim a complexidade no entendimento dos Conceitos Clnicos. A proposta da Fundao openEHR , atravs da confeco do padro que representa formalmente arqutipo, possibilitar que as especificaes dos conceitos clnicos sejam compartilhados e ajudem na confeco dos HIS baseados em conceitos slidos. Um exemplo da representao de um conceito clnico atravs de arqutipo o Peso Corporal, que formada por uma quantidade (valor e unidade) e a data da ocorrncia da aferio (NARDON et al, 2011).

1.2

M OTIVAO
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 adoo do desenvolvimento orientado a modelos MDD espera-se uma melhoria da produtividade dos esforos de desenvolvimento, atravs da utilizao de conceitos que so menos associados tecnologia de desenvolvimento, e mais prximos do domnio do problema, possibilitando assim a confeco dos HIS realizadas por especialista de domnio e no necessariamente por um especialista em computao.

1.3

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

aumento da produtividade e a diminuio da complexidade na construo de HIS baseados em conceitos clnicos (arqutipos) atravs da abordagem de desenvolvimento orientado a modelos.

17

Para alcanar o objetivo desse trabalho, faz-se necessrio estabelecer objetivos especficos: Definir um perfil UML que possibilite a modelagem das informaes dos Conceitos Clnicos utilizados nesta pesquisa. A definio de um perfil UML neste trabalho foi estimulada atravs da criao da openEHR uma iniciativa de modelagem de informaes clnicas com arqutipos e perfil UML (Clinical Information Modelling Initiative CIMI). Esse grupo funciona atravs de uma colaborao internacional e se dedica a fornecer um formato comum para especificaes detalhadas visando a representao do contedo de informao de sade (CIMI, 2011); Modelar os Conceitos Clnicos de Cuidado Sade pertencente ao domnio dos metamodelos clnicos - Arqutipos baseado no perfil UML; Construir programas geradores utilizando uma abordagem Model Driven Development MDD para transformar o modelo de domnio das informaes clnicas em artefatos conforme tecnologias adotadas; Descrever uma abordagem de desenvolvimento baseada nas etapas Engenharia de Domnio - ED com MDD e Engenharia de Aplicao - EA. Durante a etapa ED sero confeccionados artefatos que sero uteis na EA. Um estudo de caso utilizar essa abordagem especificada para construir um prottipo; Avaliar o ambiente atravs da realizao de um estudo de caso que confecciona um prottipo. Esse prottipo tem a utilizao avaliada por analistas de sistemas e estudantes.

1.4

E SCOPO N EGATIVO
Algumas atividades no sero contempladas pelo corrente trabalho, entre elas:

Atividades relativas evoluo e/ou manuteno dos artefatos, tais como: gerenciamento de projetos, gerenciamento de configurao ou merge de modelos; Implementao de ferramentas para o desenvolvimento orientado a modelos, com funcionalidades para: o Transformao de modelo para modelo; o Transformao reversa, isto , transformao de texto para modelo; o Validao dos modelos e validao das transformaes; o Desenvolvimento de ferramenta case UML;

18

Transformao dos subconjuntos do metamodelo clnico - arqutipos; Transformao das regras de restries dos demais subconjuntos do metamodelo clnico arqutipos; Gerao de cdigo responsvel pela comunicao e segurana entre HIS; Desenvolvimento de artefatos para a disciplina de implantao.

19

1.5

O RGANIZAO DO T RABALHO
Neste captulo descreveu-se a caracterizao do problema onde foram apresentados os

problemas alvo e metas desta dissertao. Alm disso, foi apresentada a motivao da realizao da pesquisa, os principais objetivos / metas e a definio de escopo desse trabalho. Na sequncia, ilustramos a organizao desse documento:

Captulo 2 - Arqutipos
So apresentados os principais conceitos e os relevantes modelos;

Captulo 3 - Desenvolvimento Orientado a Modelos

So apresentados os conceitos sobre desenvolvimento orientado a modelos, as principais tcnicas e abordagem.

Captulo 4 - Tecnologias WEB

So apresentados os conceitos sobre as tecnologias WEB utilizadas nessa pesquisa.

Captulo 5 - Trabalhos Relacionados

So apresentados os trabalhos relacionados a essa pesquisa, atravs de uma reviso bibliogrfica.

Captulo 6 - Abordagem Proposta

apresentada uma abordagem proposta que ser utilizada nessa pesquisa;

Captulo 7 - Estudo de Caso

apresentada de forma detalhada um estudo de caso que utilizada o MDD no desenvolvimento de HIS baseado em arqutipos e apresenta os resultados obtidos na avaliao;

Captulo 8 - Concluso
So descritas de forma conclusiva as contribuies, dificuldades, limitaes, trabalhos futuros e consideraes finais;

20

2 ARQUTIPOS
Neste captulo so apresentados os principais conceitos e tcnicas sobre arqutipos, seus modelos, formas de apresentaes em: ADL e Mapa Mental. Em um ponto de vista mais genrico, considerando a definio do termo arqutipo no Dicionrio online Merriam-Webster que : "o padro original ou modelo do qual todas as coisas do mesmo tipo so representados ou um perfeito exemplo". Conforme definio de Beale (2007), arqutipos so pedaos de conhecimento que indicam como representar conceitos ou informao. Um arqutipo que representa o conceito temperatura corporal, por exemplo, pode definir que este conceito formado por uma quantidade (um nmero e uma unidade) e por uma data que indica o momento em que a temperatura foi aferida. Arqutipo a definio formal de combinaes prescritas das classes definidas no Modelo de Referncia para domnios ou organizaes clnicas especficas. Ou seja, arqutipo uma expresso formal de um conceito distinto em nvel de domnio, expresso na forma de restries sobre os dados cujas instncias estejam em conformidade com o modelo de referncia. Desta forma, a utilizao de arqutipos permite compartilhar conceitos e conhecimento clnico, formando sistemas a partir de um conjunto de integrao. Esta a proposta da Fundao openEHR (BEALE, 2007): criar um padro que permita representar formalmente arqutipos, possibilitando assim que as especificaes de conceitos clnicos criadas com este formalismo sejam compartilhadas e resultem na construo de sistemas de informao em sade fundamentados em conceitos slidos. Arqutipos so descritos como um modelo formal e reutilizvel de um conceito do domnio. Assim, se um conceito representado por um arqutipo, este conceito pode ser reutilizado nos vrios cenrios em que ele se aplica. O que torna o uso de arqutipos uma boa alternativa para representao do conhecimento a concentrao de todo o conceito numa nica estrutura. Sempre desenvolvido sob a orientao e auxlio de profissionais especialistas da rea, o conceito descrito por um arqutipo pode ser visto como o refinamento da ontologia daquele domnio, trazendo benefcios para a comunicao humana, interoperabilidade ao nvel conceitual, enriquecimento do domnio e desenvolvimento de sistemas padronizados (BEALE, 2001).

21

Figura 1. Projeto de Especificao openEHR (OPENEHR, 2011) A Figura 1 ilustra o projeto de especificao openEHR. Este projeto responsvel por desenvolver as especificaes em que o plataforma computacional openEHR se baseia. As relaes entre as partes da plataforma da computao e as especificaes so indicadas no diagrama. Os resultados do projeto incluem requisitos, especificaes abstratas, especificaes de implementao de tecnologia, expresses computveis e critrios de conformidade. As especificaes abstratas consistem no: Reference Model (RM), o Service Model (SM) e Archetype Model (AM). Os RM e AM correspondem aos pontos de vista de informaes e computacional, respectivamente. O SM formaliza a ponte entre modelos de informao e recursos de conhecimento. As especificaes resumo publicado pela openEHR so definidos usando a notao UML e especificaes formais da classe textuais. Estes modelos constituem as referncias primrias para toda a semntica openEHR. O estilo de apresentao destas especificaes abstratas est deliberadamente inteno de ser clara e semanticamente prxima das idias que esto sendo comunicadas. Assim, as especificaes no seguem modismos ou limitaes de linguagens de programao, linguagens especficas de esquema ou outros formalismos.

22

2.1

F UNDAO OPEN EHR

A Fundao openEHR (OPENEHR, 2011b) uma fundao internacional sem fins

lucrativos fundada em 2003 pela equipe da University College London e a companhia australiana Ocean Informatics. A Fundao openEHR dedicada ao desenvolvimento para rea de sade, tornando essa rea aberta. A openEHR tem como foco a pesquisa das necessidades clnicas, criao de especificaes e implementaes. As especificaes assumem a forma de modelos de informao modulares, modelos de servio e modelos de informao clnica (BEALE, 2001); A Fundao openEHR dedicada pesquisa e ao desenvolvimento dos Registros Eletrnicos de Sade EHRs, que empregam arqutipos na especificao de uma arquitetura livre baseada numa abordagem de duas camadas (BEALE, 2001), a qual separa o modelo de dados (ou modelo de persistncia) do modelo de representao do domnio. Aqui no Brasil, os registros eletrnicos de sade que possuem as informaes dos cuidados a sade do paciente so conhecidos como Pronturio Eletrnico do Paciente PEP. Os principais objetivos, destacamos os objetivos do Projeto Arqutipo criado pela openEHR de tornar a tecnologia dos PEPs adaptvel e prova de futuro. Assim, os PEPs devem ser bases confiveis para possibilitar as suas evolues por mais de cem anos (BEALE, 2001).

2.2

M ODELO D UAL
O modelo de dados (primeira camada) simbolizado por um Modelo de Referncia

(Reference Model RM) composto por classes, que representam estruturas genricas do Registro Eletrnico de Sade - RES ou de dados demogrficos (FREIRE et al., 2008). O modelo de representao do domnio (segunda camada) composto por regras que restringem o RM e especificam como os conceitos clnicos so usados no RES. Essas regras so definidas pelos arqutipos e essa camada representada pelo Modelo de Arqutipo (Archetype Model - AM). Sendo o RM mais estvel e menos sujeito a alteraes que o AM, essa separao habilita o desenvolvimento de sistemas prova de futuro (BEALE, 2001), permitindo os mecanismos de persistncia serem pouco alterados e o AM ser afetado pelas alteraes de estrutura e de regras de negcio (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 sustentveis e inerentemente auto-adaptativos, j que so construdos para consumir arqutipos, os quais podero ser desenvolvidos em qualquer estgio de uso dos mesmos.

Figura 2. Informao x Arqutipos A Figura 2 ilustra que o uso dos arqutipos gera novos relacionamentos entre informaes e modelos. Um sistema planejado de maneira clssica, com toda a semntica do domnio 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 execuo esto relacionados semanticamente aos arqutipos, expressos em Archetype Definitions Language (ADL), bem como concretamente relacionados ao modelo de referncia (BEALE; HEARD, 2007b).

2.2.1 MODELO DE REFERNCIA - RM

O Modelo de Referncia representa as caractersticas globais dos componentes do registro em sade, como eles so agregados, e a informao contextual necessria para atender aos requisitos ticos, legais e de provenincia. Este modelo define o conjunto de classes que formam os blocos genricos para construir o Registro Eletrnico de Sade RES.

24

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

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 informaes (BEALE et al., 2008d): Support Information Model corresponde aos conceitos mais bsicos requeridos por todos os demais pacotes, sendo formado pelos pacotes: definitions, identification, terminology e measurement. A semntica definida nestes pacotes permite que todos os outros modelos usem os identificadores e tenham acesso aos servios de conhecimento, tais como terminologia e outros dados. Alm 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 integrao 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 genricos quanto os especficos requeridos pelas formas de infomao em Sade. 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 Descrio boolean, integer, real, etc. texto simples, texto codificado, pargrafos qualquer tipo ordenado, incluindo valores ordinais, medies com valores e unidades, etc. Data/Time data Encapsulated data hora, tipos de data e hora, e tipos de data e hora parciais multimdia, contedo processvel

Data Structures Information Model composto pelas estruturas genricas, listadas na Tabela 2, que so usadas para expressar o contedo da estrutura particular definida pelos arqutipos. Essas estruturas pertencem ao pacote item_structure exibido na Figura 4 (BEALE et al., 2008a). Alm desse pacote, data_structures tambm contm o pacote history, o qual descreve uma noo genrica de histria linear, permitindo o registro de informaes ao longo do tempo.

26

Tabela 2. Estruturas Genricas do openEHR Estrutura Single Descrio itens simples, utilizado para conter qualquer valor , exemplo: peso ou altura List Table lista linear de itens nominais, tais como alguns testes patolgicos 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.Viso 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 informaes (BEALE et al, 2010): Common Information Model um conjunto de vrios pacotes contendo conceitos abstratos e padres de projetos, que so usados em modelos de mais alto nvel do openEHR. O archetyped habilita o emprego do modelo dual da openEHR, fazendo a ligao entre os modelos de informao e de arqutipos; o pacote generic contm classes que formam padres de anlise, os quais so genricos por todo o domnio e comumente relacionados a referncias realizadas a entidades demogrficas por outros dados; o pacote directory prov uma abstrao simples e reutilizvel de uma estrutura de pasta com controle de verso; o pacote change_control define uma semntica generalizada das alteraes de um repositrio lgico ao longo do tempo, sendo que cada item no repositrio tem sua verso controlada para permitir que o repositrio como um todo tenha seu controle de verso garantido; o pacote resource define a semntica de um recurso de autoria (documentos), fornecendo suporte as tradues em vrios idiomas, metadados descritivos e histricos de reviso.

27

Security Information Model define a semntica de controle de acesso e as configuraes de privacidade para a informao 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 so apresentados na Figura 7.

Figura 7.Modelo de informao EHR (OPENEHR, 2011)

28

A Figura 7 apresenta uma viso detalhada do modelo de informao EHR. O modelo de informao EHR contm a estrutura de mais alto nvel, que consiste de um objeto HER_ACCESS, um objeto EHR_STATUS, recipientes de controle de verso de dados na forma de VERSIONED_COMPOSITION, opcionalmente indexado por uma hierarquia de diretrios de FOLDER. Uma coleo de CONTRIBUTION, que documenta as mudanas do RES ao longo do tempo, tambm includa: o pacote composition o recipiente de dados de mais alto nvel num RES, sendo descrito pela classe COMPOSITION; o pacote content contm os pacotes navigation e entry, sendo que suas classes descrevem a estrutura e a semntica do contedo das composies num RES. Uma questo importante a ser destacada no modelo do padro openEHR a capacidade, por exemplo, de oferecer um melhor suporte ao Registro Mdico Orientado a Problemas-RMOP, proposto por Lawrence Weed (1968), e registrado atravs do mtodo SOAP, que significa a sequencia da evoluo de: Subjetivo, Objetivo, Avaliao e Plano. Este mtodo destacado como um dos relevantes princpios da clnica mdica, principalmente na ateno bsica de sade, por aumentar a organizao do RES e direcionar o olhar para o cuidado do paciente, no apenas para a sua patologia (STAFIELD, 2002). Um problema resolvido fazendo observaes, formando opinies (hipteses), e prescrevendo aes (instrues) para os prximos passos, que podem ser investigao adicional, ou podem ser intervenes concebidas para resolver o problema, e, finalmente, a execuo das instrues (aes). A Figura 8 demonstra o relacionamento das informaes para o Processo de Investigao usando o mtodo SOAP.

29

Figura 8.Relacionamento das informaes para o Processo de Investigao (OPENEHR, 2011) O diagrama de classe adicionado sequencia de passos ilustrados na Figura 8 apresenta o ncleo clnico do modelo de informao do Registro Eletrnico de Cuidado a Sade. O EHR Information Model possui a classe de entrada (ENTRY) que denida em dois grupos principais de informao no modelo de entrada: 1) Informaes de Cuidado (CARE ENTRY); 2) Informaes Administrativas (ADMIN ENTRY) (BEALE, 2007). Conforme mencionado por Gaete et al (2012), as Informaes do Cuidado a Sade esto relacionadas ao registro clnico de fato, enquanto as Informaes Administrativas dizem respeito a todo o resto que no faz parte do processo de cuidado/assistncia de Sade. Existem quatro classes genricas de registro de Informaes 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 avaliaes, diagnsticos e planos de cuidado; 3) INSTRUCTION, afirmaes que podem ser executadas, como prescries / receitas de

30

medicamentos, orientaes, exames, encaminhamento, entre outros; 4) ACTION, informaes que se registram como resultado da execuo das instrues.

Integration Information Model define classes que permitem representar dados externos ou legados numa rvore de dados. Este tipo de entrada de dados possui seu prprio tipo de arqutipos, denominados arqutipos de integrao, os quais podem ser usados em conjunto com os arqutipos clnicos em sistemas de integrao de dados.

Demographic Information Model determina os conceitos genricos de PARTY, ROLE e os detalhes relacionados aos endereos de contato. O modelo de arqutipos define a semntica das restries nas PARTY, permitindo que arqutipos para qualquer tipo de pessoa, organizao, papel e relacionamento de papis possam ser descritos. A Figura 9 apresenta uma viso detalhada do modelo das informaes demogrficas.

Figura 9.Modelo Dados Demogrficos (OPENEHR, 2011)

31

2.2.2 MODELO ARQUTIPO - AM

O pacote AM contm os modelos necessrios para descrever a semntica dos arqutipos 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 semntica orientada a objetos desses arqutipos e templates, e o pacote openehr_profile, que define um perfil genrico do modelo de arqutipo para o uso na openEHR (BEALE; HEARD, 2007b). Archetype Object Model - AOM define em Unified Modeling Language - UML o modelo de objetos equivalente aos arqutipos. Sendo um modelo genrico, o AOM pode ser usado para definir arqutipos para qualquer modelo de referncia numa forma padronizada. O openEHR Archetype Profile - oAP define classes de arqutipos 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 so usados para combinar arqutipos em estruturas de informaes especficas e assim suprir as necessidades de variaes locais, usualmente correspondendo aos formulrios de tela (BEALE, 2008). A Archetype Definition Language ADL tem o objetivo de prover uma sintaxe abstrata capaz de representar textualmente arqutipos e templates.

32

2.3

A RCHETYPE D EFINITION L ANGUAGE - ADL

Archetype Definition Language (ADL) uma linguagem formal desenvolvida pela

OpenEHR visando expressar arqutipos a fim de torn-los processveis. Para descrever as restries nos dados, que so instncias de algum modelo de informao, a ADL emprega trs sintaxes: dADL para expressar dados; cADL para expressar restries; e uma verso de lgica de predicados de primeira ordem. Via o uso da ADL, arqutipos podem ser escritos para qualquer domnio onde existam modelos formais que descrevem instncias de dados (BEALE; HEARD, 2008). Arqutipos expressos em ADL lembram cdigos de linguagens de programao e possuem uma sintaxe definida. A cADL usada para expressar a seo de definio de arqutipos, enquanto que a dADL usada para expressar os dados que aparecem nas sees de idioma, descrio, ontologia e histrico de reviso (BEALE; HEARD, 2008). Uma viso geral da estrutura de uma ADL apresentada na Figura 11.

Figura 11.Estrutura ADL (OPENEHR, 2011)

33

Usando uma sintaxe interpretvel, 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 arqutipos, o AOM estabelece a sua semntica, definindo principalmente os relacionamentos que precisam ser garantidos entre suas partes, para que esse arqutipo seja considerado vlido como um todo. A Figura 12 apresenta um trecho da ADL do arqutipo 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 semntica, ou um mapa cognitivo, porm sem restries nos tipos de conexes usadas. Nele os elementos so ordenados de forma intuitiva, de acordo com a importncia dos conceitos relacionados a um domnio, que ento so organizados em agrupamentos, ramificaes ou reas. Em outras palavras, um mapa mental um diagrama radial que atravs de vocabulrios (palavras-chave), distribudas em certa ordem e correlacionadas possam representar e modelar cognitivamente um conceito ou um domnio especfico. Segundo Buzan (2003), os principais benefcios em utilizar mapas mentais so: organizao, utilizao de palavras-chave, associao, agrupamento de ideias, memria visual, criatividade e inovao com simplicidade. Nesta pesquisa, o mapa mental utilizado com o propsito de representar um mapa cognitivo, tendo como objetivo extrair, estruturar e organizar o conhecimento ou domnio de sade, advindo dos arqutipos, de forma espacial, abstraindo as complexidades dos

arqutipos centrando o domnio em dados persistentes (DATA) para um sistema de informao de sade. Alguns trabalhos (DOWNS, 1973) e (KITCHIN, 1994) destacam que esse tipo de representao facilita a mente humana em processar melhor as informaes, reduzindo a carga cognitiva para a absoro do conhecimento ou domnio. Neste contexto, o mapa mental foi adotado com o intuito de facilitar a comunicao e simplificar a modelagem de domnio pelo Especialista de Domnio, tornando este processo mais gil e eficaz. A Fundao openEHR utiliza-se de mapas mentais como um dos diagramas de representao de conhecimento para os registros de pronturios eletrnicos A Figura 13 apresenta um exemplo de mapa mental do conceito clnico Temperatura Corporal definida pela openEHR.

35

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

2.5

S NTESE DO C APTULO
De maneira geral, este captulo apresentou definies referentes aos Arqutipos. A seo

2.1 explicitou detalhes sobre a Fundao openEHR, seus principais objetivos e focos de atuao. Na seo 2.2, foi detalhado o Modelo Dual, apresentando conceitos e descrevendo o Modelo de Referncia - RM e Modelo Arqutipo AM. Os submodelos foram apresentados, seus pacotes e classes ilustradas. Alm disso, o processo de investigao clnica tambm foi demonstrado. Na seo 2.3, os conceitos e exemplos de Archetype Definition Language - ADL foram ilustrados. Por fim, a seo 2.4, os conceitos e exemplos sobre os mapas mentais foram apresentados. Tambm justificada nesta seo a adoo de mapas mentais no corrente trabalho.

36

3 DESENVOLVIMENTO DIRIGIDO A MODELOS

Este captulo fornece uma viso detalhada sobre o paradigma de desenvolvimento orientado a modelos, apresentando desde a sua definio, linha do tempo, utilizao e abordagens mais frequentes. Antes de iniciar esta seo, faz-se necessrio a apresentao de algumas definies do termo modelo. O termo modelo um dos mais utilizados, mas seu significado pode visivelmente ser alterado entre contextos (amplamente explicado por (SEIDEWITZ, 2003; KHNE, 2005). Por exemplo, em Engenharia Software o termo modelo tradicionalmente refere-se a um artefato formulado em alguma linguagem de modelagem. Esta definio estreito para MDE, onde o cdigo 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: pea "Uma descrio (de) um sistema de escrita em uma linguagem bem definida". Em um ponto de vista mais genrico, considerando a definio do termo modelo no Dicionrio online Merriam-Webster que : "uma exata representao de algo de tamanho muito reduzido" ou a definio do dicionrio Cambridge que : "uma representao de algo, como um objeto fsico que geralmente menor que o objeto real, ou como uma simples descrio do objeto que possa ser utilizado nos clculos".

3.1

D EFINIO
Muitos dos artefatos de alto nvel (por exemplo, modelos UML) so utilizados com o

objetivo de facilitar a anlise de um problema, sendo teis apenas num primeiro instante. Com a evoluo das atividades do desenvolvimento, esses artefatos vo se tornando obsoletos e deixam de representar fielmente a realidade da aplicao. Isto ocorre porque normalmente as mudanas e manutenes so confeccionadas diretamente no cdigo, fazendo com que os esforos despendidos na construo desses artefatos no sejam aproveitados diretamente na produo de aplicaes (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 representao das relevantes caractersticas de um sistema em modelos, os quais so construdos e refinados

37

conforme o sistema desenvolvido (VOELTER; GROHER, 2007). Em contraste com o desenvolvimento de software no dirigido a modelos, no MDD os modelos no constituem apenas a documentao, sendo processados por ferramentas que permitem suas transformaes em diferentes nveis de abstrao (VOELTER; GROHER, 2007).

Figura 14. Processo de Criao de Software (LUCRDIO, 2009)

Conforme ilustra a Figura 14 (LUCREDIO, 2009), o MDD pode desobrigar o Engenheiro de Sistemas da interao direta com o cdigo fonte, abstraindo o seu trabalho das complexidades inerentes implementao em diferentes plataformas (FRANCE; RUMPE, 2007; LUCREDIO, 2009). Mecanismos automticos so responsveis por efetuar transformaes e gerar os cdigos a partir dos modelos, fazendo com que estes deixem de ser apenas guias para o processo de desenvolvimento e tambm faam 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 transformaes, poupando tempo e esforo, e o tempo de desenvolvimento melhor aproveitado, j que empregado na produo de modelos de mais alto nvel; 2) portabilidade, porque um mesmo modelo pode

38

gerar cdigo para diferentes plataformas; grau de integrao, porque diferentes partes do modelo podem ser transformados em cdigos para diferentes plataformas, resultando num software que corresponde heterogeneidade do ambiente sem perder sua funcionalidade global; manuteno e documentao, porque as alteraes so realizadas diretamente nos modelos, mantendo-os em conformidade com o cdigo, e a documentao permanece sempre atualizada, facilitando assim a manuteno; 3) comunicao, porque os especialistas de

domnio podem usar os modelos para identificar os conceitos de negcio, no dependendo diretamente de conhecimento tcnico relativo plataforma; 4) reutilizao, porque o reuso de artefatos de alto nvel traz maiores benefcios que o reuso de cdigo-fonte; 5) verificao e otimizao, porque os modelos facilitam o emprego de verificadores semnticos e otimizaes automticas, o que pode reduzir a ocorrncia de erros semnticos e fornecer implementaes mais eficientes; e 6) corretude, porque as ferramentas usadas nas

transformaes no geram erros acidentais (e.g., erros de digitao) e erros conceituais podem ser identificados em nveis superiores de abstrao. Essas vantagens do MDD relacionam-se minimizao de tarefas repetitivas para a transformao de modelos em cdigo fonte, as quais passam a ser realizadas com o auxlio de ferramentas, permitindo a sua automao e a manuteno da consistncia dos modelos, isso mesmo mediante a realizao de atividades de urgncia, tais como a correo 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 cdigo gerado e fica alm do alcance do desenvolvedor; 2) Curva de aprendizado: o desenvolvimento dos artefatos especcos do MDD exigem prossionais com habilidades na construo de linguagens, ferramentas de modelagem, transformaes e geradores de cdigo. O aprendizado destas tcnicas, apesar de no ser extremamente difcil, requer um treinamento dedicado; 3) Alto investimento inicial: assim como a reutilizao de software, o MDD depende de maior investimento inicial, uma vez que a construo de uma infraestrutura de reutilizao orientada a modelos requer mais tempo e esforo. Porm, os ganhos posteriores so signicativos, fazendo com que este investimento tenha retorno em poucas interaes.

39

3.2

H ISTRICO
No incio o uso de modelos no desenvolvimento de sistemas no considerava as ideias

de desenvolvimento automtico ou semiautomtico, 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 declarao a seguir, tambm realizada pelo mesmo autor, resume a importncia da contribuio ER: "Entidades e relacionamentos so uma maneira natural de organizar as coisas fsicas bem como as informaes... O conceito de ER o princpio bsico 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 tpico de investigao ativo durante a dcada de 1980, algumas abordagens foram publicadas para estender ER. As bases de Unified Modeling Language - UML surgiram com as contribuies de Booch, Rumbaugh e Jacobson (1992). Vinte e um anos depois de ER, em 1997, a primeira verso do UML foi apresentada. Hoje em dia, UML usado como o idioma baseada em modelo padro para desenvolvimento de software. ER e UML so as razes do MDE. MDE nasceu nos primeiros anos da dcada de 2000 com o lanamento do Model-Driven Architecture (MDA, 2001), e uma unificao 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 so nomeadas por siglas, so 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 gerao para aliviar a complexidade de plataformas e conceitos de domnio expressas de forma eficaz.". Por esta definio podemos entender MDE como a evoluo das ferramentas CASE. A iniciativa prope definies de MDE mais amplas em relao aos processos (no se limitando ao

40

desenvolvimento como MDD), e suporte para anlise do modelo para tomar decises ou simplesmente para o raciocnio (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 noo de que podemos construir um modelo de um sistema que pode ento se transformar em coisa real.". Uma diferena entre MDD e MDA que MDD no aderente algumas das normas da OMG. Foi dito por Fowler (2009), que a principal contribuio 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 verso do guia MDA (MDA GUIDE, 2003) foi publicado. Todas as iniciativas model-driven seguem o princpio de que "tudo um modelo", declarou em (BZIVIN, 2005). Em uma sesso plenria celebrada em Montreal entre os dias 23 e 26 de Agosto de 2004, a seguinte definio de MDA foi concedida: A MDA uma iniciativa OMG que se prope a definir um conjunto de padres proprietrios que especificam tecnologias interoperveis para realizar Model-Driven Development com transformaes automatizadas. Nem todas essas tecnologias se referem diretamente as transformaes envolvidas na MDA. MDA no 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 padro, que uma condio prvia para qualquer capacidade para realizar transformaes automatizadas. A Figura 15 representa a evoluo temporal dessas trs 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 publicao em revista.

41

Figura 15.Representao das iniciativas de Moden-Driven (AMELLER, 2009) Na MDA so descritos trs tipos de abstraes e ilustrados atravs da Figura 16 que apresenta o sentido dos trs nveis de abstrao.

Figura 16.Nveis de abstraes de MDA

Estes trs tipos de modelos referem-se aos estgios de desenvolvimento de software (AMELLER, 2009): Compute Independent Model - CIM: A CIM uma viso do sistema do ponto de vista independente da computao. CIM muitas vezes chamado de modelo de negcio. Um exemplo de CIM poderia ser o modelo que representa o processo para entregar um pacote (simplificado): 1. Um funcionrio leva o pacote a partir de casa do cliente e o leva para o escritrio mais prximo. 2. O pacote transportado para o escritrio mais prximo do destinatrio. 3. Um funcionrio leva o pacote para o destinatrio.

42

Platform Independent Model - PIM: Um modelo que no contm detalhes que tm significado apenas dentro de uma plataforma especfica. Este tipo de modelo no tem relao com qualquer tecnologia de implementao. Na sequncia do exemplo anterior, o modelo de PIM ir conter apenas as partes que so suposto ser feito pelo computador (simplificado): 1. O sistema atribui um identificador para o pacote. 2. O sistema calcula a rota mais econmica para entregar o pacote.

Platform Specific Model - PSM: Um modelo que contm detalhes que tm significado apenas dentro de uma plataforma especfica. Este tipo de modelo tem normalmente uma relao com algumas tecnologias de implementao. Em comparao com o exemplo anterior, neste caso, o modelo de PSM ir conter as mesmas peas 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 econmica para entregar o pacote utilizar os servios web das companhias areas contratadas.

3.4

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

transformao como afirmado por (HUMM, 2005). mostrado na caixa cortada (pontilhada) da Figura 17:

Figura 17.Fluxo de Transformao Geral As caixas (M2M e M2T) so transformaes. As caixas marcadas com a sigla M2M refere-se transformao de Modelo para Modelo. J a caixa com a sigla M2T, tambm conhecida com M2C, refere-se transformao Modelo para Texto.

43

As transformaes entre os modelos (M2M) so definidos como a transformao de idiomas. As transformaes de um modelo para um arquivo de texto - M2T so 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 transformao M2T, com o objetivo de gerar artefatos textuais a partir de modelos de domnios projetados. Neste documento, daqui por diante ser utilizado o termo M2C para identificar o processo de transformao modelo para texto.

3.5

U NIFIED M ODELING L ANGUAGE - UML

Segundo (WATSON, 2007), a histria da modelagem grfica de software pode ser

dividida em dois perodos: antes da UML e depois da UML. Antes da criao dessa linguagem, o cenrio da modelagem de software era repleto de notaes incompatveis, o que levava ao enfraquecimento do mercado de ferramentas, deixando os modelos fora do processo de desenvolvimento de software. No entanto, aps a especificao da UML e sua grande adoo no processo de produo de sistema, as incompatibilidades de notao at ento existentes foram praticamente eliminadas. A UML, criada em 1996, hoje na sua verso 2.x (OMG, 2007) composta por 13 diagramas que definem a notao e semntica para os seguintes domnios: A interao do usurio ou modelo de casos de uso descreve os limites e interaes entre o sistema e seus usurios, correspondendo a um modelo de requisitos, em alguns aspectos; O modelo de interao ou comunicao descreve como objetos do sistema interagem entre si; O modelo dinmico ou de estados descreve os estados ou condies que as classes possuem ao longo do tempo. Grficos de atividades descrevem o fluxo de trabalho que o sistema ir seguir; O modelo lgico ou de classes descreve as classes e objetos que fazem parte do sistema; O modelo fsico de componentes descreve o software (e algumas vezes componentes de hardware) que fazem parte do sistema; O modelo fsico de implantao descreve a arquitetura fsica e a implantao de elementos na arquitetura de hardware.

44

3.6

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

tcnicas de especificao formal. Alm disso, a UML segue um padro arquitetural de quatro camadas (ver Figura 18) onde a camada M3 corresponde ao metamodelo1 MetaObject Facility - MOF (OMG, 2007), a camada M2 a prpria UML, a camada M1 so os modelos utilizados no processo de produo de software e a camada M0 so os objetos em si.

Figura 18. Quatro Camadas da Arquitetura do Metamodelo (LIDDLE, 2010) A Figura 18 descreve as camadas: M3: A camada que contm 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 padro do OMG. MOF uma linguagem para descrever metamodelos. Para se ter uma idia aproximada do que MOF, ns poderiamos pensar em UML limitado a diagramas de classe. O MOF foi utilizado tambm na prpria definio do metamodelo da UML. M2: A camada que contm os meta-metadados (metamodelo) que descrevem as propriedades que os metadados podem apresentar (por exemplo, tais elementos UML como classe, a Operao atributo). Aqui encontramos metamodelos, uma descrio ou definio de uma linguagem bem definida na forma de um modelo.

Um metamodelo um modelo que tem o objetivo de definir os relacionamentos entre vrios elementos de um modelo.

45

M1: A camada que contm 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 contm os dados de aplicao (por exemplo, o casos que preenchem um sistema orientado a objetos em tempo de execuo ou linhas de tabelas relacionais de banco de dados. Na Figura 18 essa instncia representada pelo livro intitulado: Executable UML: A Fundation for Model-Driven Architectures). 3.7

M ECANISMOS DE E XTENSO DA UML

Os mecanismos de extenso da UML existem desde suas verses iniciais, porm

somente a partir da sua segunda verso que a noo de perfil foi definida para proporcionar a extenso 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 especfica de domnio, em que o domnio pretendido foi o de aplicaes geogrficas. Nas subsees seguintes so explicados os mecanismos de extenso da UML (esteretipos, tagged values e constraints), assim como perfis UML.

Esteretipos
Esteretipo um mecanismo de extenso da UML que define como uma metaclasse existente pode ser estendida e habilita o uso de uma terminologia especfica para um domnio ou plataforma especficos em lugar da, ou em adio , terminologia usada para a metaclasse estendida (OBJECT MANAGEMENT GROUP, 2007). Eriksson et al. (2004), assim como OBJECT MANAGEMENT GROUP (2007), caracterizam esteretipos como um dos principais veculos para a customizao da UML. Um esteretipo pode estender uma metaclasse ou outro esteretipo, permitindo assim, que sejam criados novos elementos de modelagem. No h limite no nmero de vezes que uma metaclasse pode ser estendida por um esteretipo, nem h regras que limitem o nmero de classes que podem aplicar um esteretipo. Um esteretipo definido por um nome e pelo conjunto de elementos do metamodelo com os quais ele pode ser conectado. Graficamente, eles so definidos em caixas estereotipadas como: <<stereotype>> (FUENTES; VALLECILLO, 2004). Os elementos do

46

metamodelo so indicados por classes estereotipadas como <<metaclass>>. Eles podem tambm mudar a aparncia visual dos elementos do modelo estendidos usando cones grficos (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 informaes aos elementos do modelo, as quais podem ser utilizadas por seres humanos e por mquinas, podendo assim ser expressos por alguma linguagem natural ou computacional. Seres humanos podem usar esses metaatributos para adicionar informaes administrativas sobre o modelo como, por exemplo, o autor do modelo e a data e hora da ltima modificao. Mquinas podem us-los, por exemplo, para a gerao de cdigo (ERIKSSON et al., 2004). Tagged values tm um nome e um tipo, e so associados a um esteretipo especfico (OBJECT MANAGEMENT GROUP, 2007).

Constraints
Constraints so restries em forma de regras ou definio de condies que so aplicadas a elementos do modelo. A todo elemento da UML est associada alguma semntica. Isso quer dizer que cada elemento grfico dessa linguagem possui um significado bem definido que, uma vez entendido, fica implcito na utilizao do elemento em algum diagrama. As restries permitem estender ou alterar a semntica natural de um elemento grfico (BEZERRA, 2002). As restries podem ser associadas aos esteretipos, impondo, assim, restries aos elementos do metamodelo correspondente. As regras definidas para um esteretipo se aplicam a cada elemento do modelo para os quais o esteretipo aplicado e cada elemento do modelo para os quais o esteretipo 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 restries e propriedades de elementos do modelo (FUENTES; VALLECILLO, 2004). Algumas restries foram escritas, em OCL, nos metamodelos Arqutipos AM pela Fundao openEHR, mas no ser objeto de estudo desse trabalho.

47

3.8

P ERFIS UML
A UML permite uma personalizao e extenso da sua sintaxe e semntica, alm de

prov mecanismos de adaptao a domnios especficos chamados de perfis UML. Ento, um perfil UML um conjunto dos mecanismos de extenso da UML (esteretipos, tagged values e constraints), agrupados em um pacote UML estereotipado como <<profile>>. Como mencionado anteriormente, esses mecanismos permitem a extenso da sintaxe e semntica dos elementos da UML, porm sem violar a semntica original desses elementos. A inteno fornecer um mecanismo direto para adaptar um metamodelo existente com construtores que so especficos para um domnio, plataforma ou mtodo em particular. Tais adaptaes so agrupadas em um perfil (OMG, 2007). O pacote de perfis contm mecanismos que permitem metaclasses de metamodelos existentes serem estendidas para adapt-las a diferentes propsitos. Isso inclui a habilidade para customizar a UML a diferentes plataformas ou domnios especficos como, por exemplo, aplicaes em tempo-real ou modelagem de processos de negcios. 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 evoluo dos metamodelos arqutipos produzidos pela comunidade que participa da Fundao openEHR, esse trabalho adotou o uso de perfis UML para possibilitar a extenso da sintaxe e semntica da UML e prover mecanismos adaptativos a domnios especficos (Cuidado a Sade), possibilitando assim o desenvolvimento baseado em modelos, atravs da realizao das transformaes de modelo para texto. 3.9

T RANSFORMAES DE M ODELOS
Transformao de modelos o processo de converter um modelo em outro modelo do

mesmo sistema (OMG, 2003). A transformao utiliza os mapeamentos, mas tambm contm outras informaes como, por exemplo, a condio no modelo fonte para disparar a transformao, a linguagem do modelo-alvo, a linguagem-fonte, etc. (KLEPPE; WARMER; BAST, 2003). Um mapeamento especificado usando alguma linguagem para descrever uma transformao de um modelo em outro. A descrio pode ser em linguagem natural ou em uma linguagem de transformao de modelos. Uma qualidade desejvel de uma linguagem de transformao a portabilidade. Isso habilita o uso de um mapeamento com diferentes ferramentas (OMG, 2003).

Linguagem de Transformao
Sendall e Kozaczynski (2003) descrevem algumas caractersticas que so desejveis para essas linguagens de transformao de modelos. A linguagem deve ser implementvel de maneira eficiente, ser executvel e deve oferecer editores grficos, os quais proveem uma maneira mais intuitiva quando comparados com os textuais. Em geral, essas linguagens de transformao de modelos podem ser imperativas, declarativas ou hbridas. As linguagens imperativas so aquelas que descrevem como atingir determinado objetivo atravs de uma sequncia de aes que devem ser executadas pelo computador. Exemplos so: Cobol, Fortran, C, Pascal, Java, etc.. As linguagens declarativas so 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 so:

49

Lisp, Haskell, SQL, etc.. J as linguagens hbridas so aquelas combinam caractersticas das duas anteriores. Em 2004, a OMG lanou uma requisio de propostas (Object Management Group, 2004) com o objetivo de padronizar a transformao de modelos para representao textual, onde foi solicitada a criao de uma nova linguagem ou a extenso de uma linguagem j existente para transformao de modelos em texto. Estava entre os principais requisitos dessa linguagem de transformao a compatibilidade com o metamodelo MOF 2.0, funes de manipulao de strings e o suporte aos mecanismos de extenso da UML. A linguagem MOFScript atende a todos os requisitos bsicos da OMG e adiciona outros requisitos avaliados como importantes para uma linguagem desse tipo, tais como suporte a mecanismos de controle de fluxo, interao com servios do sistema operacional (e.g. consultar a data e hora do sistema), e um equilbrio entre facilidade de uso e poder de expressividade dos domnios. Tambm fornecido um editor de transformaes na forma de um plug-in para a IDE Eclipse, chamado MOFScript tool (OLDEVIK, 2006), que tem um editor lxico com colorao de sintaxe e assistente de digitao de cdigo, visualizador estrutural de regras, gerenciador de configuraes e visualizador de problemas. MOFScript j provou ser adequada para a tarefa de transformao de modelos em UML para texto (M2T) em outras situaes como no trabalho de Porres et al. (2007) onde sistemas de apoio deciso foram gerados a partir de diagramas de Mquina de Estados. Um conjunto completo de instrues de uso da ferramenta e da linguagem pode ser encontrado em seu manual do usurio (OLDEVIK, 2009). Alm disso, a adoo da linguagem MOFScript neste trabalho foi baseada na utilizao de (CATALINA et al, 2008) conforme resultado da reviso sistemtica apresentado no capitulo 5.

Papyrus UML2 Modeler

A ferramenta CASE Papyrus UML2 Modeler (PAPYRUS UML, 2011) mostrou-se uma opo interessante por ser uma ferramenta de cdigo aberto (opensource). Ela se basea no ambiente Eclipse e est sob a licena 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 padro UML2, a ferramenta d suporte criao de perfis UML, que um dos objetivos de estudo desse trabalho. O perfil criado selecionando-se os esteretipos a serem utilizados e as metaclasses que sero estendidas por esses esteretipos. Alm disso, as programas transformadores M2C escritos em MOFScript podem ser editados e executados no Papyrus, tornando assim, uma ferramenta nica para realizao da modelagem de domnio, criao do perfil UML, confeco dos programas transformadores e execuo das transformaes.

3.10 S NTESE DO C APTULO

De maneira geral, este captulo apresentou as definies referentes ao paradigma de desenvolvimento orientado a modelos. Inicialmente foram apresentados conceitos sobre o prprio modelo. A seo 3.1 fundamentou conceitualmente e apresentou as principais caractersticas de MDD. Adicionalmente foram apresentadas as principais vantagens e/ou desvantagens da adoo de MDD e os pontos de vistas sobre sua adoo.

51

Nas sees 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 caractersticas. Nas sees 3.4, 3.5 e 3.6, as metodologias, definio sobre UML e a conceituao sobre metamodelagem so apresentadas. Na seo 3.4 foi apresentada a metodologia usada com MDD, detalhando os processos de transformaes, tais como: M2M ou M2C. Na seo 3.5 foi realizada uma fundamentao terica sobre UML, com o objetivo de facilitar ainda mais o entendimento das prximas sees. Na seo 3.6 foi conceituada a metamodelagem, suas principais caractersticas e suas camadas de abstraes. Nas sees 3.7 e 3.8, os conceitos e exemplos sobre os mecanismos de extenso e perfil UML so apresentados. Por fim, a seo 3.9 que apresentou a definio sobre as transformaes de modelos, as caractersticas das linguagens de transformao e a ferramenta Papyrus que possibilita a criao de perfil UML, programas transformadores e a prpria execuo da gerao de artefatos automticos.

4 TECNOLOGIAS WEB
Este captulo apresenta as tecnologias WEB utilizadas no desenvolvimento desse trabalho, detalhando as definies e histricos 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 interao por toque (Touch). Esse framework um fcil caminho para a confeco de aplicaes web que so acessveis em todos os dispositivos mveis populares como: smartphones e tablets. A confeco desse framework tem o objetivo de fornecer mecanismos que possibilitam a criao de sistemas unificados de interface do usurio (UI), baseados em Jquery , JQuery UI, HTML5 e CSS3. Esses sistemas no apenas adicionam funcionalidades

52

para criao do layout (listas, painis, layers etc.), mas tambm fornecem um rico conjunto de controles e widgets (entre outros: sliders, toggles, abas) (SILVA, 2012). O framework efetua o princpio fazer mais escrevendo menos, que dita o desenvolvimento da biblioteca jQuery, com a finalidade de criar aplicaes nicas para todos os dispositivos mveis e sistemas operacionais. Em relao a interoperabilidade entre navegadores e plataformas mveis, esse framework foi desenvolvido baseado em um diretriz que estabelece que se trata de uma ferramenta capaz de implementar aplicaes que sejam suportadas pela grande maioria dos modernos navegadores desktop e das plataformas para smartphones, e tablets.

Histrico
Em 16 de outubro de 2010, John Resig (criador do Jquery) anunciou o lanamento da primeira verso 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 formulrio; 4) caixas de dilogo; 5) listagens; 6) eventos e transies. Em 2011, foram lanadas vrias verses candidatas a lanamento do framework, contendo as seguintes novas caractersticas: 1) suportes para Blackbarry 5, Mini Opera e sries 60 do smartphone Nokia; 2) Refinamentos, otimizaes e melhoria de desempenho; 3) correes de bugs; Para utilizar o Framework JQuery Mobile no ambiente de desenvolvimento no requerido a execuo de instalaes prvias. necessrio apenas criar, na marcao 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) padro do framework. Essas criaes permitem a maximizao do uso das funcionalidades e principalmente da simplicidade de implementar para quase todos os dispositivos mveis existentes no mercado, independentes de marcas, modelos e plataformas ou sistemas operacionais. A Figura 21 apresenta um modelo mnimo para desenvolver uma pgina para dispositivo mvel.

53

Figura 21.Exemplo de HTML com Jquery Mobile

4.2

H YPERTEXT M ARKUP L ANGUAGE HTML

uma linguagem de marcao (linguagem de marcao de hipertexto) global para

estruturao e apresentao de contedo para WEB criada e mantida pelo consrcio W3C. A HTML foi concebida essencialmente como uma linguagem para descrever semanticamente documentos cientficos, embora a sua concepo geral e adaptaes ao longo dos anos permitiu-lhe ser usada para descrever uma srie de outros tipos de documentos (HISTORY HTML, 2012). O W3C descreve que HTML baseado no conceito de Hipertexto. Os Hipertextos so conjuntos de elementos ligados por conexes. Estes elementos podem ser, entre outros: palavras, imagens, vdeos, udio, documentos. Estes elementos ligados criam uma grande rede de informao. A conexo feita em um hipertexto algo imprevisto que permite a comunicao de dados, organizando conhecimentos e guardando informaes relacionadas. Um relevante propsito do HTML ser uma linguagem universalmente entendida por diversos meios de acesso, isto , possibilitar distribuio da informao de maneira global.

Histrico
A linha do tempo do HTML apresentada nesta seo. A Figura 22 apresenta a linha do tempo do HTML. Neste trabalho utilizamos o HTML5

54

Figura 22.Linha do tempo HTML Na dcada de 1990, o HTML ganhou popularidade quando o navegador Mosaic ganhou fora. Com isso, fabricantes de navegadores e desenvolvedores usaram o HTML como base para a implementao de suas aplicaes. Em 1996, o W3C publicou a verso HTML 2 que corrigia alguns erros e No ano de 1997, O W3C recomendou a verso 3.2 do HTML, essa verso continha as seguintes novas caractersticas, entre outras: 1) Fontes, tag: <font>; 2) Tabelas, tag: <table>; 3) applets; 4) superscripts e subscripts. Em 1998, o W3C recomendou a verso HTML 4.0, onde a sua mais nova importante caracterstica foi adoo de folhas de estilo (CSS). No ano de 2000, o W3C lanou o XHTML 1.0 como uma reformulao do HTML 4.0.1 no formato XML. Em paralelo s evolues 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 verso do HTML que trazia mais leveza e flexibilidade para a produo de aplicaes WEB. Em 2006, foi anunciada uma parceria entre o grupo WHATWG e a equipe de desenvolvimento do XHTML visando o desenvolvimento do HTML verso 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 especificao do HTML5, que contem as seguintes caractersticas: 1) Funes para embutir som, vdeos e grficos; 2) armazenamento de dados no lado cliente; 3)documentos interativos. Com essas novas caracterstica poder ser eliminada a dependncia de plug-ins para manipulao de multimdia em navegadores, por

55

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

Figura 23.Exemplo de Cdigo HTML5

4.3

C ASCADING S TYLE S HEETS - CSS

Conforme definio do consrcio W3C, Cascading Style Sheet, ou em portugus:

Folhas de Estilo em Cascata so: Um mecanismo simples para adicionar estilos (por exemplo: fontes, cores, espaamentos) aos documentos WEB. Conforme definido em Silva (2007), o CSS formata a informao entregue pelo HTML ou XML. Essa informao pode ser, entre outras: imagem, texto, vdeo, udio ou qualquer outro elemento criado. Essa formatao na maioria das vezes visual, mas no obrigatoriamente. As CSS tm por finalidade devolver marcao HTML/XML o propsito inicial da linguagem. Isto significa que a HTML foi criada para ser uma linguagem exclusivamente de marcao e estruturao de contedos. A responsabilidade do HTML fornecer informaes a qualquer dispositivo (por exemplo: navegadores e dispositivos mveis) que sejam capazes de interpretar um documento escrito em uma linguagem de marcao. competncia, responsabilidade, do CSS as funcionalidades de apresentao dos elementos de um documento HTML/XML. O CSS tm a finalidade de possibilitar a estilizao dos elementos,

56

configurando, por exemplo: 1) definio de cores de fontes; 2) definio de tamanho de fontes. A Figura 24 demonstra a definio padro e um exemplo bsico do CSS

Figura 24. Definio e Exemplo de CSS O seletor representa uma estrutura que usada como uma condio para determinar quais elementos de um grupo de elementos ser formatada. A propriedade a caracterstica que se deseja modificar no elemento (exemplos: color, width) ou conjunto de elementos. O valor representa o valor referente a esta caracterstica. 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 cdigo CSS que define para o seletor corpo: 1) fonte padro Arial, caso no exista substitui por Verdana; 2) define o valor da propriedade cor de fundo do corpo da pgina para vermelha; 3) define os valores para a propriedade margem. Nesta pesquisa utilizamos o CSS3 na soluo proposta com o objetivo de estilizar elementos dos formulrios gerados.

Histrico
A linha do tempo do CSS apresentada nesta seo. A Figura 25 apresenta a linha do tempo referente evoluo do CSS.

Figura 25.Linha do Tempo CSS (W3C)

57

Em 1996, o consrcio W3C lanou a primeira edio do CSS, contemplando as seguintes caractersticas: 1) Introduo da 'id' nica para cada propriedade e introduo de classes para as propriedades que devem ter os mesmos atributos estilos eram as coisas mais importantes existiam; 2) Margem, borda, espaamento e posicionamento tambm alimentado por folhas de estilo, embora pudesse ser feito usando os elementos HTM; 3)Espaamento entre linhas e linhas de tabelas tambm so facilmente definidos usando as folhas de estilo. Em 1998, o consrcio W3C lanou a edio (nvel) 2.0 do CSS, contendo, entre outras, as seguintes caractersticas: 1) Controlar o posicionamento visual do contedo da pgina atravs de identao de texto, margens, floats, e posicionamentos absoluto e relativo; 2) Prover efeitos visuais, como sombras; 3)Eliminar imagens e espaos em branco usados para o posicionamento. Em 2012, a edio 3.0 do CSS que se encontra em desenvolvimento, busca implementar, entre outras, as seguintes funcionalidades: 1) Manipulao de opacidade; 2) Texto de estouro de consultas; 3) Meios de comunicao; 4) Gradiente em textos e elementos; 5) bordas arredondadas; 6) sombras em texto e elementos; 7) controle de rotao.

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 fcil para: 1) os seres humanos lerem e escreverem; 2) mquinas para analisarem e gerarem. Esse formato, baseia-se em um subconjunto da linguagem de programao JavaScript, Standard ECMA-262 3 Edio - Dezembro de 1999. JSON um formato de texto que completamente independente de linguagem, mas usa convenes que so familiares aos desenvolvedores da famlia C de linguagens, incluindo: C, C + +, C #, Java, JavaScript, Python, e muitos outros. JSON construdo baseado nas estruturas de dados universais: 1. Uma coleo de pares: nome / valor. Em vrias linguagens, Esta coleo percebida como um objeto de: registro, dicionrio, 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 ordenao dos pares: nome / valor. Um objeto comea com {(chave esquerda) e termina com} (chave direita). Cada nome (exemplo:string) seguido por: (dois pontos) e os pares nome / valor so separados por, (vrgula). 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

mveis que permite confeccionar aplicativos hbridos (web e mvel), onde o desenvolvimento feito em JavaScript, HTML5 e CSS3, e atravs da sua API, possvel ter acesso aos recursos nativos do dispositivo alm de possibilitar facilmente as criaes de plugins (PHONEGAP FRAMEWORK, 2012). A adoo do framework PhoneGap (FPG) elimina a necessidade de aprendizado das diversas linguagens utilizadas no desenvolvimento de aplicativos para plataformas mveis. Com esse framework um sistema desenvolvido utilizando JavaScript, HTML, CSS3 e JQuery Mobile; e compilado para o sistema operacional da plataforma mvel destino como se fosse um sistema nativo. Com o FPG a construo das aplicaes mveis baseada em padres WEB, baseada em tecnologia WEB como o HTML5 e javascript. Inclusive, o FPG permite ao desenvolvedor utilizar caractersticas nativas dos dispositivos mveis e possibilita implantar um mesmo sistema em mltiplas plataformas mveis. A Figura 28 apresenta a lista das principais caractersticas dos dispositivos mveis suportadas pelo FPG versus os respectivos sistemas operacionais das plataformas mveis homologadas.

59

O FPG uma implementao open source de padres aberto. Ela ser sempre livre e de cdigo aberto sob a Licena Apache, Verso 2.0. Isso significa que os desenvolvedores, instituies educacionais e/ou empresas podem usar PhoneGap para aplicaes mveis que esto livres, cdigo aberto, comercial, ou qualquer combinao destes. Alm disso, o FPG possui uma crescente e ativa comunidade que vem evoluindo as documentaes, criando e publicando aplicativos e plugins novos, utilizando blogs e faqs para troca de informaes sobre essa API e principalmente evoluindo as caractersticas desse framework. A Figura 27 apresenta as plataformas mveis homologadas, suportadas, para rodar aplicaes construdas com o FPG. Essa grande diversidade de plataformas suportadas foi um fator decisivo na escolha desse framework na realizao desse trabalho.

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

60

Figura 28.Caractersticas suportadas pelo FPG x Sistemas Operacionais dos dispositivos mveis (PHONEGAP FRAMEWORK, 2012)

Histrico
A Figura 29 apresenta anualmente a evoluo histrica do framework PhoneGap, destacando ano a ano as relevantes ocorrncias no histrico 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 So Francisco nos EUA em agosto desse ano; No ltimo trimestre do ano de 2008 foi adicionado ao FPG o suporte as plataformas mveis 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 lanadas duas novas verses dessa API, as verses: 0.6.0 e a 0.7.2 para Android e IPhone. No incio do segundo semestre foram adicionados o suporte as plataformas:Windows Mobile e Nokia WRT. No ltimo trimestre do ano a verso 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 publicao da verso candidata 1.0 do FPG. Em outubro desse ano a empresa Adobe anunciou a aquisio da empresa Nitobi Software fabricante da FPG. O cdigo do FPG foi contribudo 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 citaes nas prximas sees desse documento (APACHE CORDOVA, 2012). Em 2012: Em janeiro de 2012 foi publicada a verso 1.4 contendo vrias correes e novidades para as diversas plataformas mveis. A ltima verso baixada e utilizada no desenvolvimento deste trabalho foi a verso 1.9.

Inicio do FPG

Integrao Symbian

Lanamento das verses 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.Histrico anual do FPG

62

O Construtor PhoneGap um servio que possibilita ao desenvolvedor compilar na internet (cloud) um aplicativo (integrado ao PhoneGap Framework), gerando assim compatibilidade desse aplicativo com vrias plataformas mveis, entre outras: Android, Bada, Apple iOS e Windows Phone 7. O Processo ocorre conforme os seguintes passos: 1) Fazer upload da aplicao integrada ao FPG e escrita em javascript, HTML5 e CSS3 para o Buid PhoneGap; 2) submeter ao servio Buid PhoneGap; 3) Receber o aplicativo compatvel com a plataforma desejada. A Figura 30 apresenta uma viso geral do funcionamento do Build PhoneGap (Build PhoneGap, 2012).

Figura 30.Viso geral do Build PhoneGap (Build PhoneGap, 2012)

4.6

S NTESE DO C APTULO
De maneira geral, este captulo apresentou as definies referentes s tecnologias WEB

adotadas no corrente trabalho. Alm disso, foram apresentadas justificativas sobre adoo dessas tecnologias. A seo 4.1 apresentou as principais caractersticas sobr JQuery Mobile e sua respectiva linha do tempo. As sees 4.2 e 4.3, foram apresentadas as definies, exemplos e linha do tempo sobre, respectivamente, HTML e CSS. A seo 4.4 apresentou o conceito e as principais caractersticas sobre JSON. Alm disso, foi apresentada a linha do tempo sobre JSON e ilustrado exemplo do modelo JSON.

63

Por fim, a seo 4.5 apresentou as principais caractersticas sobre o framework PhoneGap e sua respectiva linha do tempo. As tecnologias apresentadas nas sees 4.1, 4.2, 4.3 e 4.4 so utilizadas diretamente pela arquitetura do framework PhoneGap. Alm disso essa seo justificou a adoo do framework PhoneGap no trabalho corrente.

64

5. TRABALHOS RELACIONADOS
Este captulo descreve uma reviso bibliogrfica - RB para o levantamento e mapeamento do estado da arte na abordagem de desenvolvimento orientado a modelos utilizando modelos clnicos - arqutipos. Neste trabalho, foi realizada uma sistematizada reviso bibliogrfica baseada em algumas das principais atividades de uma reviso sistemtica, visando obter evidncias de trabalhos relacionados a essa pesquisa que utilizaram uma abordagem de desenvolvimento orientada a modelos integrados aos arqutipos. Assim, a seo 5.1 introduz o conceito de reviso sistemtica, aqui abreviado como RS. A seo 5.2 descreve o mtodo da RS usado neste trabalho e o motivo do seu uso; nas subsees apresentado como foi planejada e executada a pesquisa, como foi feita a seleo dos dados analisados, e como foi feito a anlise em si.

5.1

I NTRODUO
A reviso sistemtica da literatura um mtodo de estudo secundrio que tem obtido

muita ateno ultimamente em Engenharia de Software - SE (KITCHENHAM, 2007) e inspirado em pesquisas mdicas. Resumidamente, uma reviso sistemtica (RS) passa por relatrios primrios existentes, rev-los em profundidade e descreve a sua metodologia e resultados. Comparado com revises de literatura comuns em qualquer projeto de pesquisa, um RS tem vrias vantagens: a metodologia bem definida reduz vis, uma ampla gama de situaes e contextos pode permitir que mais concluses gerais e uso de meta-anlise estatstica pode detectar mais estudos individuais isoladamente (KITCHENHAM, 2007). No entanto, RSs tambm tm vrias desvantagens, a principal o considervel esforo necessrio. As RSs em engenharia de software concentraram-se em estudos quantitativos e emprico, mas um grande conjunto de mtodos para a sntese de resultados de pesquisas qualitativas existe conforme colocado em (DIXON-WOODS et al., 2005). Um planejamento antecipado e claro de quais atividades sero executadas e quais endereamentos sero levados em considerao no momento de tomada de decises, pode ser bastante benfico na execuo de uma RB. Apesar da no obrigatoriedade da criao 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 reviso sistemtica realizada a fim de verificar o

estado da arte sobre o desenvolvimento orientado a modelos integrado aos arqutipos clnicos atravs de anlise de evidncias, como tambm identificao de aglutinao e ausncias de pesquisas relacionadas com temas da rea. O objetivo foi evidenciar, atravs de informaes confiveis, como a academia vem abordando o assunto. O protocolo criado para esta pesquisa pode ser visualizado atravs da Figura 31. Ele inclui a definio das questes a serem respondidas pela pesquisa, a estratgia de busca, a definio das fontes de pesquisa, a seleo dos estudos, a classificao dos estudos, alm das concluses da pesquisa. Cada uma das etapas do protocolo ser explicada nas sesses seguintes, que detalham a conduo do mesmo.

Definio das Questes

Realizao da Pesquisa

Definio das Fontes de Dados

Seleo dos Estudos

Classificaes dos Estudos

Publicao das Concluses

Figura 31.Protocolo Definido para a Pesquisa

5.2.1 DEFINIO DAS QUESTES

A questo principal que orienta este estudo de mapeamento e reflete o nosso objetivo : RQ1. Qual a evidncia sobre a adoo do desenvolvimento orientado a modelos integrado aos arqutipos clnicos?

66

5.2.2 REALIZAO 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) identificao de grafias alternativas e sinnimas, 3) a constatao de palavrachave, 4) utilizao de OR; 5) e definio de operadores de fundir as seqncias de pesquisa. As strings de busca da pesquisa esto disponveis na Tabela 3. Tabela 3. Strings de Busca "Model-driven" AND ("clinical archetype" or "openehr archetype")

5.2.3 DEFINIO 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 publicaes na rea de engenharia de software e informtica mdica. Outro critrio de escolha dos engenhos de busca foi a possibilidade de utilizao de seus recursos via internet, e a capacidade de leitura dos trabalhos de forma gratuita para alunos da Universidade de Pernambuco atravs do portal da CAPES. As trs 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 Informtica de Sade CBIS. Os dois nveis de pesquisa (manual e automtico) 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 SELEO 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 nmero de trabalhos a serem avaliados (39). Apesar do nmero baixo dos trabalhos encontrados, foi aplicado um filtro para evitar esforo desnecessrio. A tabela 5 apresenta Critrios de Incluso e Excluso de Trabalhos Relacionados. Tabela 5. Critrios de Incluso e Excluso de Trabalhos Relacionados Tipo Excluso Critrio Descrio 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 atravs de diferentes strings. Neste caso, apenas uma obra foi selecionada e as demais descartadas. Ttulos, resumo e concluso

Excluso

Foram analisados os ttulos, resumos e Eliminar artigos concluses dos artigos e verificado se avaliando o ttulo, os mesmos condiziam com o foco da resumo e concluso. pesquisa.

A ordem na qual os critrios de incluso e excluso foram aplicados e a quantidade de trabalhos obtidos como resultados podem ser observados na Figura 33.

68

Critrio Inicial

39 trabalhos
Critrio por Duplicidade

32 trabalhos
Critrio por Ttulo, Resumo e Concluso

2 trabalhos
Figura 33.Ordem e Resultados da Aplicao dos Critrios

5.2.5 CLASSIFICAO DOS ESTUDOS

Aps a seleo das obras observou-se a necessidade de classific-las de acordo com seu contedo. As classificaes dos estudos foram realizadas seguindo a mesma idia de categorizao que utiliza duas facetas, por se tratar de uma maneira estruturada de fazer tal tarefa (KITCHENHAM, 2007). A primeira faceta baseada nas questes criadas para guiar a pesquisa (seo 3.2.2), e a outra faceta de acordo com o tipo de pesquisa. A execuo da classificao foi apenas realizada no conjunto final dos estudos, ou seja, aps os processos de filtragem. As classes que formam a faceta de tipos de pesquisa esto descritas na Tabela 6. Tabela 6. Descrio das classes das facetas por contedo Classes Pesquisa de Validao Pesquisa de Avaliao Descrio
Tcnicas novas que ainda no foram implementadas na prtica. Trata-se de experimentos feitos em laboratrios. Tcnicas aplicadas na prtica e com avaliao conduzida, ou seja, mostrado como a tcnica foi implementada na prtica e quais seus pontos positivos e de melhorias. Esta classe tambm leva em considerao a identificao de problemas na indstria. Uma soluo para um determinado problema proposto podem ser totalmente nova ou extenso de uma tcnica existente. Os potenciais benefcios e aplicabilidade da soluo so indicados por um pequeno exemplo ou uma satisfatria linha de argumentao. Estes artigos apresentam uma nova maneira de visualizar as coisas existentes pela estruturao atravs de taxonomia ou modelos

Proposta de Soluo

Artigos Filosofia

69

conceituais.

Artigos que descrevem opinies

Estes trabalhos expresso a opinio de algum sobre determinada tcnica. Eles no dependem de trabalhos relacionados e metodologia de pesquisa.

Artigos que Experincias

descrevem Estes trabalhos descrevem experincias prticas do autor.

5.2.6 CONCLUSES DA PESQUISA

O objetivo desta reviso bibliogrfica foi verificar o estado da arte sobre o desenvolvimento orientado a modelos integrado a arqutipos e no explicitar de forma detalhada como os artigos adotam arqutipos e MDD. A lista de todas as obras e suas respectivas classificaes pode ser visualizada na Tabela 7. A classificao baseada nos tipos das pesquisas nos ajudou na concluso que os trabalhos tratam de Proposta de Soluo e que utilizam uma abordagem de desenvolvimento orientado a modelos integradas a Arqutipos. Tabela 7. Classificao das obras de acordo com os tipos # 01 Classificao Artigo Proposta de A model-driven approach for representing clinical archetypes for Soluo Semantic Web environments (Catalina et al, 2008). Proposta de Soluo Clinical data interoperability based on archetype transformation (Catalina et al, 2011).

02

Os resultados das classificaes baseada na questo RQ1 detalhado a seguir.

RQ1. Qual as evidncias sobre a adoo do desenvolvimento orientado a modelos integrado aos arqutipos clnicos? 01) Foi encontrada evidncia da utilizao do desenvolvimento orientado a modelos com arqutipos clnicos no artigo de (CATALINA et al, 2008). Esse artigo trata de uma proposta de soluo que combina tecnologias de Web Semntica e MDE para transformar Archetype Denition Language - ADL em Ontology Web Language - OWL usando a linguagem de transformao MOFScript. Esse artigo evidenciou a integrao de arqutipos com MDE atravs de uma soluo proposta que transformou ADL para OWL. Foi sentida falta de informaes que avaliassem ou quantificassem os ganhos utilizando MOFScript na transformao dos conceitos clnicos

70

representados em ADL para OWL. De qualquer forma, concluiu-se que a integrao de MDE com arqutipos foi evidenciada e a linguagem MOFScript foi utilizada para efetuar as transformaes. 02) Foi encontrada evidncia da adoo de tcnicas de desenvolvimento orientado a modelos integrado com arqutipo no artigo (CATALINA et al, 2011). Esse artigo foca na interoperabilidade semntica dos registros eletrnicos de sade. Esse artigo utilizou e estendeu as regras de transformaes definidas no artigo 01. Esse artigo no efetuou nenhuma proposta nova em relao as tcnicas de MDE utilizadas em relao ao artigo 01.

71

6. ABORDAGEM PROPOSTA
Este captulo prope uma abordagem para adotar o desenvolvimento orientado a modelos na confeco de um sistema de cuidado sade conforme os arqutipos clnicos. 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 clnicos Arqutipos. Na especificao desta abordagem, utilizamos tcnicas de MDD para gerao semi-automtica de alguns dos artefatos. Assim, esta abordagem de desenvolvimento utiliza o paradigma de desenvolvimento dirigido a modelos - MDD para a implementao de aplicaes de domnio clnico baseadas respectivamente em metamodelos clnicos. A entrada da abordagem ocorre com o fornecimento de Conceitos Clnicos CCs que so obtidos no repositrio CKM da OpenEHR e representados atravs de mapa mental. Conforme explanado no captulo 2, os arqutipos indicam como representar conceitos ou informaes de um domnio via expresses computveis, sendo que essas expresses baseiam-se num modelo de Referncia - RM e so definidas na forma de restries estruturais. A estrutura do RM restringida pelo arqutipo empregado, disponibilizando uma estrutura resultante que possui as caractersticas do conceito clnico definido pelo arqutipo. A Fundao openEHR fornece algumas formas de representar os conceitos clnicos Arqutipos. Entre essas representaes destacamos os mapas mentais que so diagramas que atravs de palavras-chave podem representar e modelar cognitivamente um conceito ou um domnio especfico. Alguns trabalhos (DOWNS, 1973) e (KITCHIN, 1994) ressaltam que esse tipo de representao facilita a mente humana em processar melhor as informaes, reduzindo a carga cognitiva para a absoro do conhecimento ou domnio. Neste contexto, o mapa mental foi empregado nesta abordagem com o intuito de facilitar a comunicao e simplificar a modelagem de domnio pelo Especialista de Domnio, tornando esta abordagem mais gil e eficaz e consequentemente reduzindo a complexidade dos conceitos clnicos arqutipos. Conforme pode ser visto na Figura 34, esses mapas mentais que representam os conceitos clnicos (arqutipos) so transformados automaticamente em modelos conceituais, visando diminuir o gap entre o especialista do negcio e o engenheiro de sistema, atravs da abordagem proposta por (WANDERLEY et al, 2012). Em seguida, esses modelos conceituais

72

so refinados e projetados manualmente pelos especialistas de domnio e, finalmente, so transformados automaticamente em artefatos executveis com conformidade com o framework PhoneGap. A Figura 34 apresenta a viso da abordagem proposta.

Figura 34.Viso da Abordagem Proposta Na sequncia deste captulo so apresentados os objetivos da abordagem, viso geral da mesma e a descrio 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 construo de um sistema clnico, utilizando o paradigma de desenvolvimento orientado a modelos MDD.

73

Outra motivao foi a tentativa de diminuir a complexidade do desenvolvimento de solues de cuidado da sade. Mesmo arqutipos sendo uma proposta de padronizao, melhoria de qualidade semntica para os sistemas da rea de sade, foram encontrados problemas na sua adoo conforme ressaltados por HAJAR (2011), que relatou a existncia de alguns desafios enfrentados na adoo de arqutipos, entre eles: 1) Ser enorme e complicado: Arqutipos , naturalmente, grande e complexo e esta complexidade no inesperada j que os arqutipos definidos pela openEHR so considerados como uma soluo para um problema complicado em um domnio complexo (ou seja, o domnio clnico naturalmente complicado). Por exemplo, o enorme modelo arqutipo permite expressar conceitos complexos clnicos, portanto, um desenvolvedor inexperiente para prover solues baseadas em arqutipos deve esperar passar algum tempo para aprender os conceitos openEHR. 2) Falhas em aspectos educacionais: A compreenso de um conceito o primeiro passo para ser capaz de adot-lo, e esta ainda mais vlida para conceitos to complexos como os dos arqutipos clnicos definidos pela openEHR. Infelizmente encontramos: pouca documentao formal, guias para iniciantes, raras sesses de formaes (treinamentos) e poucas pessoas formadoras ao redor do mundo. Visando minimizar a complexidade na utilizao de arqutipos, ou na tentativa de diminuir a curva de aprendizado dos conceitos clnicos (arqutipos), foram utilizados Mapas Mentais MM para facilitar o entendimento do domnio do Cuidado a Sade. Alm disso, a adoo da infraestrutura de (WANDERLEY et al, 2012) nesta proposta tem o objetivo de aumentar a produtividade na construo dos modelos conceituais clnicos, atravs da gerao automtica 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 reutilizveis. Consequentemente teremos um ganho de produtividade, j que uma parte dos artefatos no ser refeitos, isto , esses artefatos sero reusveis.

6.2

V ISO G ERAL
Essa abordagem consiste em duas etapas: Engenharia de Domnio ED e Engenharia

de Aplicao - EA. O desenvolvimento das partes gerais, desenvolvimento com foco em

74

reutilizao, chamado de Engenharia de Domnio e o desenvolvimento de um produto (desenvolvimento com reutilizao), de Engenharia de Aplicao (LUCRDIO, 2009). Para essa abordagem, utilizamos a engenharia de domnio com foco na anlise de domnio clnico, usando como referncia os Modelos de Arqutipos - AMs, selecionando os requisitos semelhantes que pertencem ao subdomnio OBSERVATION. Conforme detalhado na seo 2.2, a classe genrica OBSERVATION uma das quatro classes que especializam a classe CARE_ENTRY e utilizada para registro de informaes de Cuidado Sade. As informaes de Cuidado a Sade registradas so: os registros de tudo que puder ser observado, medido ou respondido pelo paciente. Esses requisitos so independentes de especialidade mdica, por exemplo: Temperatura Corporal. Alm disso, de acordo com a abordagem de Lucrdio (2009) foi adicionada o uso de MDD na Engenharia de Domnio com o objetivo da modelagem fazer parte desta abordagem, para aumentar o nvel de abstrao do desenvolvimento das solues de cuidado a sade. A Figura 35 apresenta as duas etapas da abordagem.

Engenharia de Domnio + MDD

Engenharia de Aplicao

Figura 35.Etapas da abordagem Na ED os mapas mentais do subdomnio clnico dos arqutipos so selecionados e recuperados do repositrio 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 definio dos seus metamodelos de arqutipos - AOM (OpenEHR, 2011); so implementadas: o componente de apoio e as transformaes M2C para a gerao de artefatos reusveis; Todos os artefatos da ED so usados como apoio a Engenharia de aplicao EA, onde os sistemas de cuidado de sade so desenvolvidos baseados no refinamento dos metamodelos da ED. Alguns dos artefatos so utilizados no refinamento e nas transformaes.

75

As transformaes M2C so reutilizadas para gerao 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: Anlise de Domnio, Projeo e Implementao.

Figura 36.Diagrama do Macroprocesso - Engenharia de Domnio A ED tem incio na fase Anlise de Domnio (AD). A AD comea com a coleta dos requisitos do domnio do problema, a definio do escopo, refinamento do modelo conceitual e tem como alvo a modelagem do domnio. Durante a realizao dessa atividade o engenheiro de domnio guiado pelo Modelo de Arqutipo (AM), representados por Mapas Mentais MM que so obtidos no repositrio de arqutipos CKM (OPENEHR, 2011). Na fase de Projeo, o engenheiro de sistemas realiza algumas atividades referentes ao mapeamento do modelo conceitual para o modelo de domnio. As principais atividades realizadas na fase projeo so: 1) Refinamento visando definir submdulos, criando interfaces, abstraes, definindo fronteiras; 2) Refinamento do modelo conforme, tecnologias e padres adotados; Para a implementao, as atividades comeam com o desenvolvimento preliminar que precede o refinamento e a transformao M2C, seguida de algumas outras atividades, entre elas: 1) Desenvolver Perfil UML; 2) Montar ambiente; 3) Desenvolver manualmente o complemento funcional e no funcional; 4) Confeccionar transformao. 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: Anlise, Projeto, Implementao e Testes. Durante a realizao dessas fases, o Engenheiro de Aplicao 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 Aplicao

6.3

E TAPAS DA A BORDAGEM
Nesta seo, descrevemos as etapas da abordagem, visando facilitar o

desenvolvimento de sistemas clnicos utilizando o paradigma de desenvolvimento orientado a modelos.

6.3.1 ENGENHARIA DE DOMNIO - ED

Conforme apresentado por Leite e Girard (2009) a ED uma etapa voltada para a confeco de artefatos reusveis pertencentes a um domnio especfico. Outra caracterstica relevante da ED a determinao das caractersticas comuns quanto tambm das variaes das aplicaes de um domnio particular (LUCRDIO, 2009). Na abordagem proposta, utilizaremos a ED para identificar as caractersticas semelhantes do domnio clnico, especificamente dos subdomnios gerais da rea de conhecimento OBSERVATION definida pela openEHR e ilustrada na Figura 8. A Figura 38 demonstra atravs de um diagrama de processo quais as fases e suas atividades, sequencias e como essas atividades da ED so relacionadas.

77

Figura 38.Processo Proposto para Engenharia de Domnio

Anlise de Domnio - AD
Conforme exposto por Lucrdio (2009), a fase de Anlise de Domnio - AD o comeo da ED que contempla a identicao dos principais conceitos e elementos de um domnio e a determinao de seu escopo. Essa fase inicial responsvel por coletar informaes do domnio para as fases subsequentes da abordagem proposta. Essa fase inicia com a seleo de um conjunto preliminar de conceitos clnicos (CCs) baseados em arqutipos, representados por Mapas Mentais (MM), que so adotados em distintas especialidades mdicas do domnio do Cuidado de Sade. A finalizao da AD ocorre com a realizao da atividade Modelar Domnio - MD, que iniciada com a execuo da atividade Executar a infraestrutura de (WANDERLEY et al, 2012) com o objetivo de obter o modelo conceitual para a realizao do refinamento deste modelo conceitual. As atividades da fase Anlise de Domnio - AD adotadas neste trabalho so: A Seleo de Arqutipos em Mapa Mentais, nesta atividade o engenheiro de domnio com o auxlio do especialista de domnio, pesquisa, estuda e seleciona (coleta) no repositrio CKM os arqutipos (openEHR, 2011), ilustrados atravs dos mapas mentais representando os conceitos clnicos pertencentes ao subdomnio desejado (define escopo).

78

Como fluxo excepcional, caso o conceito clnico geral desejado pelo especialista do domnio no esteja no repositrio CKM de arqutipos openEHR, esse especialista cria o novo conceito clnico usando a ferramenta linkEHR com o auxlio de um engenheiro de sistemas. Esse novo conceito clnico criado enviado para a ativa comunidade openEHR, onde a openEHR realiza uma avaliao desse novo conceito, visando evitar repetio, inconsistncia. Em seguida, caso tenha resultado positivo da avaliao, efetuada uma publicao desse novo conceito clnico, colocando-o no repositrio de CKM e que passa a ser gerenciado pela openEHR. A exportao do mapa mental (no formato XML), nesta subatividade o especialista de domnio realiza a exportao dos mapas mentais no formato XML para serem insumos, entradas, para a execuo da abordagem de Wanderley; A Figura 13 ilustra um exemplo de MM; A execuo da abordagem Wanderley, nesta subatividade o especialista de domnio fornece um XML que representa o mapa mental e executa a abordagem de Wanderley (Wanderley et AL, 2012), que aps transformao M2C, gera um arquivo no formato XML Metadata Interchange - XMI representando respectivamente o modelo conceitual do conceito clnico fornecido como mapa mental. Na atividade Refinar Modelo de Domnio, o engenheiro de domnio apoiado quando necessrio pelo especialista do domnio 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 extenso das caractersticas dos elementos dos modelos. Entre outras atividades de refinamento, possvel modificar o modelo conceitual para: 1) a identificao e descrio dos CCs; 2) definir associaes entre as entidades; 3) Determinar ordem de apresentao (mesma ordem dos atributos nas classes); 4) Identificar os tipos de dados dos atributos; 5) em alguns casos, identificao de informaes sobre restries de valores possveis dos atributos. Essa atividade comumente baseada nos MM e em casos que necessitam de um detalhamento maior (por exemplo: restrio de valores de um determinado atributo) os engenheiros de domnio obtm um detalhamento dos conceitos clnicos atravs de consultas manuais aos CCs que esto descritos em ADLs. A sada desta atividade o modelo de domnio 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

Projeo de Domnio - PD
A projeo de domnio uma fase essencial da engenharia de domnio (BOSCH, 2000). Um dos seus objetivos definir um conjunto de artefatos reutilizveis que podem ser combinados para desenvolver aplicativos mais rapidamente e com maior qualidade. Conforme descrito por LUCRDIO (2009), a projeo de domnio um processo iterativo de renamento. Inicia-se com o domnio todo, e a cada iterao feito um renamento que identica novos mdulos, que sero renados na prxima iterao, e assim por diante, at que o projeto esteja concludo, em funo de um entendimento satisfatrio sobre o que dever ser implementado. Nesta fase, ocorre a atividade Projetar Modelo de Domnio, a qual responsvel pela realizao do mapeamento do modelo conceitual j refinado para o modelo de domnio. Essa atividade inicia com caractersticas de modelo conceitual oriundo da AD, e esse modelo refinado e projetado manualmente conforme padres, componentes, plataformas e tecnologias que viabilizaro a fase de implementao. A Figura 40 apresenta o resultado da atividade Projetar Modelo de Domnio.

80

Figura 40.Projeo do Modelo Conceitual para Modelo de Domnio

Implementao de Domnio
Nesta fase realizada a implementao manual com base nas especificaes contidas no modelo de domnio resultante da fase de projeo. Na atividade Desenvolver Perfil UML confeccionado um perfil UML que possibilita ao Engenheiro de Domnio incluir informaes no modelo referentes apresentao, negcio e persistncia das entidades modeladas alm de: 1) possibilitar ao Engenheiro de Domnio realizar refinamentos; 2) possibilitar ao engenheiro de sistemas realizar a projeo (mapeamento) do modelo conceitual para o modelo de domnio. Alm disso, esse perfil UML criado pode ser utilizado em conjunto com os perfis UML dos modelos da openEHR nas fases AD e Projeo de Domnio. 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 solues de domnio clnico dos requisitos funcionais e no funcionais, essa atividade contempla, entre outras, a implementao manual das classes utilitrias, extenses de padres de projetos e demais caractersticas 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 responsvel pelo registro autenticado das suas observaes. Alm dos requisitos funcionais, ocorrer desenvolvimento manual visando atender tambm aos requisitos de qualidade (no funcionais), tais como: desempenho, facilidade de uso (usabilidade). A Figura 42 apresenta um trecho de cdigo da tela inicial.

82

Figura 42.Tela inicial A atividade Desenvolver Transformaes M2C responsvel pela construo dos programas transformadores que so editados atravs da ferramenta Papyrus (PAPYRUS UML, 2011). Esses programas transformadores M2C so escritos na linguagem MOFScript e tem o objetivo de transformar modelos em texto (M2C). O uso dos modelos na construo de transformaes tem se destacado dentre as demais tcnicas existentes conforme mencionado por Lucrdio (2009). Isto significa que nesta atividade so criadas as transformaes M2C, que so aplicadas aos modelos construdos na Engenharia de Aplicao. Essas transformaes tm o objetivo de diminuir os esforos de implementao dos CCs e possibilitar o reuso dos modelos de domnio.

83

Figura 43. Modelo Domnio x trecho cdigo MOFScript x HTML gerado A Figura 43 apresenta um exemplo de M2C, o item 1) apresenta o modelo de domnio identificado com os respectivos esteretipos (persistence, view) das classes e as tagged values dos atributos. As regras de transformaes adotadas so descritas na Tabela 8; 2) um trecho do programa transformador escrito em MOFScript, que recebe como entrada o modelo de domnio resultante do item 1 e transforma-o no artefato de sada (item 3); 3) o layout da tela de cadastro da temperatura corporal que foi gerada automaticamente pelo programa apresentado no item 2. Alm disso, a Figura 43 ilustra: a seta identificada por A que destaca o estereotipo view na classe BodyTemperature no modelo de domnio e o uso desse mesmo esteretipo no programa de transformao escrito em MOFScript; seta B apresenta a linha de

84

cdigo que escreve a palavra <html> no arquivo de sada, o layout HTML da tela de cadastro da temperatura corporal; A seta C descreve a linha de cdigo que obtm a tagged value label da classe BodyTemperature que est sendo lida pelo programa transformador gerando assim o ttulo da tela de cadastro da temperatura corporal. A Tabela 8 apresenta as regras de transformao utilizadas com os mecanismos de extenso criados no perfil UML. Tabela 8. Regras de Transformao Mecanismos de Extenso Este esteretipo aplicado para classes, onde as entidades identificadas com esse esteretipo so processadas pelo programa gerador que as transformam em layouts de tela em HTML5,conforme FPG. Nesta tagged Value o Engenheiro de Sistema informa a descrio Label do label que aparecer no ttulo e cabealho das telas nos layouts HTML5. Este esteretipo aplicado para classes, onde as entidades <<persistence>> identificadas com esse esteretipo so processadas pelo programa gerador que as transformam em programas javascript responsveis pela manipulao (persistncia) 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 no 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 descrio commentTable do comentrio da tabela da entidade do banco de dados. <<propertyAdditional>> Este esteretipo aplicado para os atributos das classes. Nesta tagged Value o Engenheiro de Sistema informa a descrio 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 obrigatrio. Com isso, o gerador transforma em cdigo javascript que obriga o preenchimento do atributo. Nesta tagged Value o Engenheiro de Sistema informa o valor defaultValue padro 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 cdigo SQL que << View>> Regras de Transformao

85

typePresentation

orderBy

sortDirection

valueInitialAllow

valueFinishAllow

nameColumn

initialValueNormal

finishValueNormal

identifica o campo como Chave Primria - PK. Nesta tagged Value o Engenheiro de Sistema informa o tipo de apresentao (Exemplo: String, password) do atributo. Com isso, o gerador transforma em cdigo correspondente na linguagem HTML5. Nesta tagged Value o Engenheiro de Sistema informa true or false para identificar se o atributo ser usado na ordenao da entidade. Com isso, o gerador transforma em cdigo SQL correspondente. Nesta tagged Value o Engenheiro de Sistema informa asc ou desc para identificar o sentido da ordenao do atributo. Com isso, o gerador transforma em cdigo SQL correspondente. Nesta tagged Value o Engenheiro de Sistema informa o menor valor permitido para o atributo. Com isso, o gerador transforma em cdigo javascript correspondente. Nesta tagged Value o Engenheiro de Sistema informa o maior valor permitido para o atributo. Com isso, o gerador transforma em cdigo javascript correspondente. Nesta tagged Value o Engenheiro de Sistema informa o nome da coluna que representa o atributo no banco Sql Lite. Caso no 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 cdigo 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 cdigo javascript correspondente.

6.3.2 ENGENHARIA DE APLICAO - EA

A EA uma etapa da abordagem proposta que tem o objetivo de confeccionar aplicaes especficas de um dado domnio (LEITE; GIRARDI, 2009). A EA reusa os artefatos oriundos da ED e suas atividades so baseadas em quatro disciplinas da engenharia de software: Anlise, Projeto, Implementao 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 responsvel pela confeco de aplicaes de CCs dos subdomnios semelhantes da classe OBSERVATION que compe o MA. Visando demonstrar o objetivo relevante da construo de aplicaes especficas da EA, foram escolhidos os CCs do subdomnio OBSERVATION: Paciente e Temperatura Corporal com o intuito de construir o aplicativo mvel para registrar a coleta da temperatura corporal do paciente - SOT. O Sistema para Registrar a Temperatura do Paciente - SOT um aplicativo Web e Mvel que possibilita os pacientes ou profissionais de sade que realizam assistncia domiciliar efetuar registro das aferies 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 mveis adotados na construo de sistemas de cuidado sade durante a assistncia domiciliar visam coletar observaes 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 construo do SOT: Paciente e Body Temperature.

Anlise
A etapa Anlise responsvel pela especificao dos requisitos funcionais referentes aos CCs pertencentes ao subdomnio OBSERVATION para o aplicativo SOT. O Engenheiro de aplicao ou Analista de Sistemas utiliza a ferramenta MagicDraw para produzir artefatos, tais como: Diagrama de Casos de Uso, Diagrama de Colaborao, Diagramas de Estado. Alm disso, o engenheiro de aplicao utiliza a ferramenta Papyrus para produzir diagrama de classe. Com o objetivo de descrever a relao dos usurios com a aplicao SOT, alguns artefatos so confeccionados durante a atividade especificar requisitos, entre eles: O Diagrama de Caso de Uso que responsvel por identificar e descrever os atores e as suas respectivas aes 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 histrico das aferies das temperaturas corporais do paciente.

Figura 46.Diagrama de Casos de Uso do SOT Outro artefato produzido na atividade especificar requisitos o diagrama de sequncia, tambm conhecido como diagrama de colaborao. O diagrama de sequncia criado com o objetivo de descrever como o usurio vai interagir com o sistema de acordo com cada caso de uso. A Figura 47, apresenta um diagrama de sequncia que descreve a interao do usurio com o sistema para registrar temperatura corporal do paciente.

88

Figura 47.Diagrama de Sequncia para registrar Temperatura Corporal

Projeto
Nesta fase os artefatos resultantes da fase da Anlise so 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 Domnio o Engenheiro de Domnio ou engenheiro de sistemas responsvel por mapear o modelo conceitual para o modelo de domnio utilizando como entrada o Modelo Conceitual oriundo da fase de Anlise. O modelo de domnio resultante da fase Projeto representa as informaes da aplicao referente ao Registro da Temperatura Corporal do Paciente. Como especificado no diagrama de casos de uso ilustrado na Figura 46, o usurio registra a temperatura corporal aferida em seu dispositivo mvel.

Implementao
Nesta fase ocorre a codificao da aplicao e a gerao dos artefatos oriundos do modelo de domnio. Com o auxlio da ferramenta Papyrus, o Engenheiro de Aplicao realiza a atividade Gerao Automtica de Artefatos executando as transformaes M2C, que so aplicadas aos modelos de domnio para gerar os seguintes artefatos da aplicao SOT: 1) as telas da

89

aplicao (view); 2) funes responsveis por restringir o contedo dos atributos das entidades; 3) funes responsveis pela manipulao dos dados (persistncia); 4) estrutura de criao dos objetos do banco de dados SQL Lite. A Figura 48 apresenta um trecho do cdigo da tela gerada em HTML5 da aplicao SOT.

Figura 48.Trecho de Cdigo Gerado da Tela em HTML5

90

A atividade Implementao Complementar realizada pelo engenheiro de sistema ou engenheiro de aplicao com o intuito de confeccionar manualmente algumas caractersticas 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 navegao no sistema e atender ao requisito de qualidade: facilidade de uso. A Figura 49 apresenta um trecho de cdigo da tela inicial do sistema SOT.

Figura 49.Trecho de cdigo da Tela inicial do aplicativo SOT Alm disso, a Figura 49 apresenta trecho do cdigo em HTML5 e JavaScript em conformidade com o framework PhoneGap, podendo assim, ser compilado e executado em vrias plataformas mveis distintas conforme descrito na seo 4.5.

91

Testes
Na fase de Testes so realizados os testes de sistema, o SOT executado com o objetivo de verificar se os aspectos gerais do sistema esto sendo atendidos. Os requisitos funcionais e no funcionais do sistema so testados atravs da execuo do SOT pelo engenheiro de aplicao (analista de sistemas). A Figura 50 ilustra a interface da aplicao SOT em execuo.

Figura 50.SOT em execuo

92

7. ESTUDO DE CASO - SISTEMA

Este captulo apresenta a realizao de um estudo de caso referente criao de um prottipo com o objetivo de avaliar a abordagem proposta no captulo 6. Adicionalmente, foram apresentadas mtricas na seo 7.2 como resultado da avaliao do prottipo. No corrente captulo so apresentadas as etapas da abordagem sendo executadas na implementao de um sistema, prottipo, que permite ao Paciente, registrar as suas medidas dos diversos sinais vitais e que consequentemente possibilita ao profissional de sade, responsvel pelo acompanhamento do paciente, receber essas observaes das aferies. O Sistema de Registro e Acompanhamento dos Mltiplos Sinais Vitais e Medidas do Paciente SASVM formado por duas partes: 1) O lado cliente ou lado observado, a parte da aplicao que possibilita aos pacientes efetuarem o registro dos seus mltiplos sinais vitais em vrios dispositivos de plataformas mveis diferentes (exemplo: Android e IOS). Esses registros so persistidos inicialmente em um banco de dados local, dentro do dispositivo mvel. Alm disso, essas observaes clnicas so enviadas e persistidas em uma aplicao WEB que est sendo executado em um servidor WEB; 2) O lado Observador, um mdulo web que disponibiliza uma tela (interface) que permite ao profissional de sade acompanhar a evoluo dos sinais vitais dos seus pacientes. A Figura 51 apresenta uma viso geral do funcionamento da aplicao SASVM.

Figura 51.Viso Funcional do aplicativo SASVM

93

7.1

E NGENHARIA DE A PLICAO - EA
Este estudo de caso permitiu avaliar a etapa EA da abordagem proposta com a

reutilizao dos artefatos confeccionados na Engenharia de Domnio - ED. Serviu ainda para refinar a ED na especificao e projeto do modelo de domnio, na construo das transformaes M2C e na realizao dos testes de sistema.

7.1.1 ANLISE
Esta fase inicia a EA com a especificao da aplicao, onde o engenheiro da aplicao ou analista de sistemas realiza o levantamento de requisitos e define o escopo do sistema. Os Conceitos Clnicos CCs semelhantes, pertencentes classe OBSERVATION do Metamodelo de Arqutipos AM, contemplados pelo SASV, so: 1) Presso Sangunea; 2) Peso Corporal; 3) Altura/Comprimento; 4) Consultar o ndice de Massa Corprea - IMC; 5) Frequncia Cardaca; 6) Frequncia Respiratria; 7) Temperatura Corporal. Como muitos desses CCs no tinham sido contemplados na Engenharia de Domnio - ED, foi realizado uma volta as fases da ED para efetuar uma atualizao no metamodelo. Neste retorno foram analisados alguns mapas mentais apresentados na Figura 52.

Figura 52.Alguns Mapas Mentais do SASVM

94

Na fase de Anlise, o Engenheiro de Aplicao ou Analista de Sistemas na atividade de especificar requisitos confeccionam os artefatos: 1) Diagrama de Casos de Uso - responsvel por identificar e descrever os atores e as suas respectivas aes; 2) Diagrama de Sequncia - descreve como o usurio vai interagir com o sistema de acordo com cada caso de uso. O diagrama de casos de uso foi construdo pelo Engenheiro da Aplicao, ajudado pela ferramenta MagicDraw, com o objetivo de especificar os requisitos do SASVM

referentes as seguintes funcionalidades: 1) Registrar Os Mltiplos Sinais Vitais; 2) Consultar o Histrico dos Mltiplos Sinais Vitais. Outra funcionalidade, disparada automaticamente pelo relgio (ator clock), o envio do registro dos sinais vitais e medidas que no 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, atravs do desenvolvimento do diagrama de casos de uso, o Engenheiro de Aplicao descreve manualmente o diagrama de sequncia com o objetivo de refinar o caso de uso. A Figura 54 ilustra o diagrama de sequncia do caso de uso Consultar Histrico do Sinal Vital (lado Observador).

96

Figura 54.Diagrama de sequncia do caso de uso Consultar Histrico do Sinal Vital

7.1.2 PROJETO
Nesta fase da EA, o modelo de domnio referente aos CCs do SASVM desenvolvido de acordo com as tecnologias envolvidas para a implementao do Lado Cliente e do Lado Observador. O mdulo 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 aplicao servidora ter a ccamada de apresentao com HTML5 e para processar as requisies foi adotado Servlet na linguagem Java. Alm disso, para possibilitar persistncia no banco de dados foi usado Spring com Hibernate e banco de dados MySql. Para confeccionar o modelo de domnio, o Engenheiro de Aplicao utiliza a ferramenta Papyrus conforme a fase de anlise fazendo o refinamento, mapeamento, do modelo conceitual para o modelo de domnio, modelando e utilizando elementos definidos no perfil UML construdo 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 Domnio

7.1.3 IMPLEMENTAO
Nesta fase da EA, realizada a implementao da aplicao, em conformidade com as tecnologias adotadas na atividade de projeto, modelo de domnio e com base no reuso dos artefatos gerados na ED.

98

Com o auxlio da ferramenta Papyrus, realizada a atividade de Gerao automtica de Artefatos, atravs da execuo do programa gerador (escrito em MOFScript) que responsvel pela transformao M2C. Os seguintes artefatos foram gerados: 1) Layout de Tela (HTML5); 2) funes de validaes e restries de contedo em javascript; 3) funes de manipulao de dados (persistncia) e estrutura dos objetos do banco de dados Sql Lite. A Figura 56 apresenta um trecho do cdigo 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 cdigo HTML5 e JavaScript Gerados

99

A atividade Implementao Complementar executada nesta fase com o objetivo de desenvolver manualmente alguns requisitos, entre eles destacamos: a implementao do caso de uso responsvel por enviar os registros dos sinais vitais e medidas pendentes de envio da aplicao do lado cliente para o modulo lado observador.

7.1.4 TESTES
Nesta Fase da EA, os testes de sistemas so executados com o objetivo de verificar o funcionamento geral do aplicativo SASVM. O mdulo da aplicao SASVM do lado cliente foi submetido para o phoneGap Build ger-lo para a plataforma Android. O funcionamento do phoneGap Build foi explanado na seo 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 grfica 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 mdulo do lado Observador foi instalado em um servidor Web, possibilitando ao profissional de sade efetuar a consulta do histrico dos sinais vitais e medidas dos seus pacientes observados (acompanhados), conforme interface da tela apresentada na Figura 58.

Figura 58.Testes da Consulta do Histrico Sinal Vital Lado Observador do SASVM

7.2

R ESULTADOS
Nesta seo so apresentadas as discusses referentes s observaes realizadas

durante o emprego da abordagem e das avaliaes realizadas no prottipo desenvolvido.

7.2.1 LINES OF CODE - LOC

Com o resultado produzido na adoo da EA neste captulo, observamos que as atividades executadas e os artefatos gerados, contriburam para o aumento da produtividade na construo do SASVM. Uma demonstrao desse aumento da produtividade ocorre na gerao dos CCs em artefatos executveis, apoiados pelas transformaes M2C.

101

Cerca de 76% das linhas de cdigo (HTML e javascript) dos artefatos executveis foram gerados. A Figura 59 apresenta um grfico que ilustra para alguns CCs os respectivos quantitativos das linhas de cdigos - LOC geradas automaticamente e desenvolvidas manualmente. As implementaes manuais realizadas pelo engenheiro de aplicao so decorrentes do desenvolvimento de funcionalidades adicionais, como: atributo com valor calculado, como acontece com Blood Pressure.

Figura 59.Grfico LOC Automtica x Manual dos CCs

7.2.2 AVALIAO
Para realizar a avaliao do prottipo SASVM, foi efetuada uma apresentao / treinamento para 10 pessoas, cinco engenheiros de sistemas experientes (com mais de 3 anos de experincia) em desenvolvimento de HIS e cinco estudantes do curso de ps-graduao em Engenharia da Computao da Universidade de Pernambuco. A estratgia de avaliao adotada foi o modelo: Technology Acceptance Model TAM. O TAM possibilita avaliar a facilidade de utilizao e a prpria utilidade da tecnologia que percebida pelos usurios (DAVIS, 1989). Depois da utilizao e navegao no SASVM, foram aplicados os formulrios de avaliao, baseados no TAM, aos respectivos usurios. Neste formulrio continham cinco afirmativas, e as respostas dessas afirmaes eram especificaes do nvel de concordncia sobre uma determinada afirmativa, de acordo com a escala de Likert (1932).

102

Alm disso, foram realizados convites para trs profissionais de sade (enfermeiros e mdico) para participarem da avaliao do prottipo SASVM. Porm, at a data da confeco desta dissertao, os profissionais de sade estavam com indisponibilidade de tempo para executarem esta avaliao. A Tabela 9 apresenta uma matriz contendo os resultados dos formulrios 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 Formulrios Preenchidos

Concorda plenamente
1.Foi fcil 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.Adoo dessa tecnologia dificulta a relao mdico-paciente. 3. essencial o uso dessa tecnologia no seu dia-adia. 4. difcil registrar informaes nesta tecnologia. 5.No foi possvel recuperar dados com essa tecnologia.

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

103

8. CONCLUSES E TRABALHOS FUTUROS

Este captulo objetiva apresentar as concluses deste trabalho, descrever as contribuies, dificuldades encontradas e limitaes, assim como apresentar as

recomendaes para trabalhos futuros.

8.1

S UMRIO DAS C ONCLUSES

Apesar do recebimento de investimentos em todo o mundo para o desenvolvimento

dos sistemas de informao, a rea da sade 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 Sade outra relevante dificuldade encontrada no desenvolvimento dos HIS. Motivado por estes desafios, e visando minimizar as dificuldades, este trabalho props uma abordagem para o desenvolvimento de HIS baseado em arqutipos 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 automao e a gerao de cdigo resultaram em um ganho da produtividade. Alm disso, a mudana do foco das atividades para a modelagem ofereceu um nvel mais alto de abstrao, o que proporcionou uma melhor qualidade do produto; Minimizar as dificuldades referentes complexidade do processo de desenvolvimento, tornando-o mais simples atravs da gerao automtica de artefatos que possibilitou uma diminuio na quantidade de artefatos confeccionados manualmente. A adoo de Arqutipos na abordagem proposta auxiliou a: Diminuir a curva de aprendizado dos Conceitos Clnicos, representados atravs dos Mapas Mentais; Aumentar da produtividade na construo dos modelos conceituais, atravs da adoo da abordagem Wanderley, que gerou o modelo conceitual a partir de um XML que representava um Mapa Mental de determinado Conceito Clnico. A adoo de MDD na abordagem

104

8.2

C ONTRIBUIES

Como principais contribuies associadas a este trabalho pode-se assinalar: O prprio desenvolvimento da pesquisa que rene um rico e variado referencial terico, com nfase em Desenvolvimento Orientado a Modelos e Arqutipos; Adoo de uma abordagem de desenvolvimento de HIS baseando em Engenharia de Domnio e Engenharia de Aplicao; O desenvolvimento de um perfil UML, que adicionado aos programas

transformadores escritos na linguagem MOFScript possibilitaram a gerao automtica de vrios artefatos executveis; O SASVM um prottipo resultante do estudo de caso executado neste trabalho.

8.3

D IFICULDADES ENCONTRADAS
Algumas dificuldades foram encontradas durante a realizao deste trabalho, entre as

mais relevantes pode-se citar: Dificuldade de obteno de informao sobre arqutipos, ausncia de treinamentos; Alta curva requerida de aprendizado referente ao entendimento dos Metamodelos Arqutipos, tanto o modelo de referncia quanto o modelo de Arqutipos. Esses modelos so complexos, possuindo diagramas de classes enormes, com muitos nveis de herana, dificultando o entendimento dos comportamentos e responsabilidades das classes.

8.4

L IMITAES
Apesar do resultado apresentado na seo 7.2 desse trabalho algumas limitaes foram

encontradas, entre as mais relevantes pode-se citar: No foram desenvolvidos programas transformadores que contemplassem as regras de negcio referentes s informaes resultantes de clculos e ou frmulas clnicas, como por exemplo: O ndice de Massa Corporal IMC que resultado da diviso do peso corporal sobre o quadrado da altura do paciente;

105

O SASVM no foi integrado a um sistema desenvolvido por terceiros visando validar a interoperabilidade semntica;

No foi implementada integraes on-line com dispositivos que medem sinais vitais do paciente, como por exemplo: termmetro digital.

8.5

T RABALHOS F UTUROS
Uma srie de trabalhos futuros pode ser vislumbrada com a continuao do que foi

produzido nesta dissertao. Entre esses trabalhos, destacam-se: A confeco de programas transformadores que tem o objetivo de transformar automaticamente os Conceitos Clnicos escritos em ADL para Modelo Conceitual em UML, aumentando assim a produtividade dos especialistas de domnio no

desenvolvimento de HIS; Desenvolvimento de programas transformadores com o intuito de fazer transformao do tipo Model to Model - M2M, isto , converter os modelos conceituais para modelos de domnio e vice e versa, aumentando assim a produtividade referente s atividades de refinamento e projeto; Gerao 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 unitrios; Criao de programas escritos em OCL com o objetivo de validar e garantir a consistncia dos modelos conceituais e modelos de domnio especificados durante a produo do HIS; Desenvolvimento da integrao com equipamentos e/ou dispositivos que aferem sinais vitais, por exemplo, termmetro, e com isso efetuar o registro dos sinais vitais medidos on-line na aplicao que roda no dispositivo mvel. 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 Clnicos e aplicar tcnicas de Linhas de Produtos de Software na construo dos Conceitos clnicos pertencentes ao domnio OBSERVATION.

106

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

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

107

BEALE, T. et al. Data Structures Information Model. Novembro 2008. Acesso em: 23/03/2011. Disponvel em: http://www.openehr.org BEALE, T. et al. Data Types Information Model. Novembro 2008. Acesso em: 22/03/2011. Disponvel em: http://www.openehr.org BEALE, T. et al. EHR Information Model. Agosto 2008. Acesso em: 22/03/2011. Disponvel em: http://www.openehr.org BEALE, T. et al. Support Information Model. 2008. Acesso em: 22/03/2011. Disponvel em: http://www.openehr.org BEALE, T. et al. Commom Information Model. Abril 2010. Acesso em: 22/03/2011. Disponvel 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. Princpios de anlise e projeto de sistemas com UML. Rio de Janeiro: Elsevier, 320p, 2002. BZIVIN, 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. 193198. ISBN 9781-60558-559-8. Disponvel em: http://doi.acm.org/10.1145/1621995.1622033 BUILD PHONEGAP. Acesso em 07/05/2012. Disponvel em: https://build.phonegap.com/ BUZAN, T. The Mind Map Book, BBC Active, 2003. CAMBRIDGE DICTIONARY - Cambridge University Press. Acesso em: 23/01/2012. Disponvel em: http://www.dictionary.cambridge.org

108

CARVALHO, S, COPETTI, A. E FILHO, O. Sistema de computao ubqua na assistncia domiciliar sade, 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. Disponvel 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. 318341, 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. Disponvel 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. 7592, 1998. DICTIONARY AND THESAURUS - Merriam-Webster Online. Acesso em: 23/01/2012. Disponvel 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. Disponvel 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. 3754. http://dx.doi.org/10.1109/FOSE.2007.14

ISBN 0-7695-2829-5. Disponvel em:

FRANKEL, Model Driven Architecture: Applying MDA to Enterprise Computing: Wiley Publishing, 2003. FREIRE, S. M. et al. Utilizando o modelo dual para a representao e persistncia de contexto em aplicaes ubquas de telemonitoramento. VIII Workshop de Informtica Mdica, p. 252 255, 2008. FUENTES-FERNNDEZ, L.; VALLECILLO-MORENO, A. An introduction to UML profiles. European Journal for the Informatics Professional, [s.l.]: Novtica, v. 5, n. 2, p. 615, 2004. GAETE, R. A. C. ; RALHA, Clia Ghedini, Proposta Metodologica de Desenvolvimento de Arqutipos Aplicado a Vigilncia Alimentar e Nutricional Em: XII Workshop de Informtica Mdica (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. Disponvel em: http://fedcsis.eucip.pl/proceedings/pliks/13.pdf HISTORY HTML W3C. Acesso em: 03/03/2012. Disponvel 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. Disponvel 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 so 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) KHNE T. What is a Model? in Dagstuhl Seminar Proceedings, 2005. LEITE, A.; GIRARDI, R. Um processo para a engenharia de domnio e de aplicaes multiagente: As fases de projeto de domnio e de aplicaes. III Simpsio Brasileiro de Componentes, Arquiteturas e Reutilizao de Software. [S.l.: s.n.], 2009. LIDDLE, S. W. Model-Driven Software Development. 2010. Acesso em: 07/12/2010. Disponvel 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. Disponvel em: http://www.linkehr.com/ LUCREDIO, D. Uma Abordagem Orientada a Modelos para Reutilizao de Software. Tese (Doutorado) Universidade de So Paulo, So Paulo, 2009. MDA, 2010. Acesso em: 22/09/2010. Disponvel 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. 316344, December 2005. ISSN 0360-0300. Acesso em: 10/09/2010. Disponvel em:

http://doi.acm.org/10.1145/1118890.1118892 MOF 2.0, 2006. Acesso em: 22/09/2010. Disponvel em: http://www.omg.org/spec/MOF/2.0/ MOFSCRIPT, acesso em 10/06/2011. Disponvel em: http://www.eclipse.org/gmt/mofscript/ NARDON, F, FRANA, T. e NAVES, H., Construo de Aplicaes em Sade Baseadas em Arqutipos, XXI Congresso Brasileiro de Informtica em Sade (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. Disponvel 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 usurio, [s. l.]: [s. n.], 2009. OPENEHR CKM. Clinical Knowledge Manager. 2011. Acesso em: 10/10/2011. Disponvel em: http://www.openehr.org/knowledge/ OPENEHR. openEHR Fundation. 2011. Acesso em: 22/10/2011. Disponvel em: http://www.openehr.org PAPYRUS UML. Acesso em: 10/07/2011. Disponvel em: www.papyrusuml.org/ PHONEGAP FRAMEWORK. Acesso em: 01/05/2012. Disponvel 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. Disponvel 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. Disponvel 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 Geogrficos. 65f. Dissertao (Mestrado em Cincia Da Computao). Universidade Federal de Viosa, Viosa, 2009. SCHMIDT, D. C. Guest editors introduction: Model-driven engineering. IEEE Computer v.39, n. 2, p. 2531, 2006. SEIDEWITZ E., What Models Mean, IEEE Software, vol. 20, pp. 26-32, 2003. SILVA, M. S. CSS3 - desenvolva aplicaes web profissionais com uso dos poderosos recursos de estilizao das css3, 2007. SILVA, M. S. JQuery Mobile Desenvolva aplicativos para dispositivos mveis 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 Sade: Contribuies e Perspectivas. Acesso em: 01/08/2012. Disponvel em: http://www.lbd.dcc.ufmg.br/colecoes/wim/2012/001.pdf STAFIELD, B. Ateno primria: equilbrio entre necessidades de sade, servios e tecnologia, volume 4. UNESCO, Ministrio da Sade, Braslia, 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. 233242, 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. Disponvel em: http://www.omg.org/spec/XMI/2.1.1/ IEEE

114