UNIVERSIDADE DE PERNAMBUCO

ESCOLA POLITÉCNICA DE PERNAMBUCO

PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO

Legilmo Marcelo Fontes de Oliveira

Uma abordagem orientada a modelos no desenvolvimento de

sistemas clínicos baseado em arquétipos

Dissertação de Mestrado

Recife, 2012.

UNIVERSIDADE DE PERNAMBUCO

ESCOLA POLITÉCNICA DE PERNAMBUCO

PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO

Legilmo Marcelo Fontes de Oliveira

Uma abordagem orientada a modelos no desenvolvimento de

sistemas clínicos baseado em arquétipos

Dissertação de Mestrado apresentada ao

Programa de Pós-Graduação em Engenharia

da Computação da Universidade de

Pernambuco, como requisito parcial para

obtenção do Título de Mestre em Engenharia

da Computação.

Orientador: Prof. Dr. Vinicius Cardoso Garcia

Recife, 2012.

Dedico este trabalho as pessoas que sempre

estiveram ao meu lado, meus filhos (Mariela,

Fernanda e Daniel) e esposa Daniela. Pelo

amor incondicional, pelo apoio nas minhas

decisões, pela força transmitida que me

encoraja a enfrentar os momentos difíceis.

iv

AGRADECIMENTOS

Os meus sinceros agradecimentos são destinados:

Aos meus pais, Lélia Oliveira e João Gilberto, que em toda minha vida me incentivaram a

crescer com conhecimento. Em especial, a minha mãe pelos conselhos, incentivos e

cuidados contínuos;

Aos meus irmãos: João Gilberto, Wellington Andre e Gíllia Valeria pelo companheirismo.

Agradeço principalmente à minha irmã Gíllia, pelo seu exemplo de luta, pelo apoio,

incentivo e união de sempre;

À minha esposa, Daniela Eugenia, que me ajudou desde a inscrição do mestrado, e que

esteve presente em todas as etapas, até o final. Para cada “vai conseguir!” dita, por me

tranquilizar nos meus momentos de estresse, por me alegrar, por me fazer feliz e muitas

vezes e efetuar o meu papel de pai dos nossos filhos, suprindo a minha ausência por causa

da minha dedicação ao mestrado;

Aos meus filhos Mariela, Fernanda e Daniel. A presença de vocês na minha vida é um

estímulo de energia. Foi em vocês que ganhei forças para ultrapassar cada dificuldade

encontrada durante o mestrado;

À minha família em geral, tios e primos. Em especial a minha tia Ivone, que é uma

referência de conhecimento e experiência, fornecendo informações essenciais nas minhas

escolhas;

Aos amigos, Jose Damaricio, Marcos Pereira, Felipe Leão, Christian Lins, Rafael

Oliveira, Guilherme Camacho e Priscila Alcantara pelas experiências compartilhadas

durante esses anos. Em especial, a Jose Damaricio pelas orientações, sugestões técnicas,

companheirismo e contínua colaboração;

Aos casais da igreja, que vêm nos apoiando nas nossas ausências dos encontros e eventos

religiosos e sociais;

A minha sogra e ao meu sogro: Lucineide e Antonio, pelo apoio dado e o preenchimento

do vazio que deixo em casa por causa da minha ausência pelo envolvimento no mestrado;

A todos os entrevistados que influenciaram diretamente o resultado deste trabalho;

Aos amigos da UPE, Eric Souza, Ariane Nunes, Maurício Manoel, Anthony Lins e

Fernando Wanderley pelas experiências compartilhadas durante as disciplinas. Em

v

especial, a Fernando Wanderley pelas orientações, paciência, companheirismo e contínua

colaboração;

Ao meu orientador, Vinicius, que me acolheu, acreditou em mim e orientou durante estes

anos;

Aos membros da banca examinadora, Daniel Lucrédio, Maria Lencastre com seus valiosos

comentários durante a defesa ajudaram a enriquecer muito este trabalho;

A todos os professores do programa de pós-graduação em Engenharia da Computação da

Universidade de Pernambuco por todos os ensinamentos recebidos;

Aos membros da equipe do CESAR que faço parte, Walter Jardim, Felipe Evangelista,

Marcelo Goncalves, Wilton Oliveira, Paloma Nunes, Liane Bandeira, Amaro Elton,

Carlos Gomes e Allan Araujo pela compreensão e apoio no andamento do mestrado;

Às instituições que fizeram com que esta trajetória fosse possível. Estas incluem a UPE,

por ter sido a minha casa durante estes anos, à CAPES que em diversos momentos me

ajudou financeiramente, espero ter correspondido e continuar correspondendo à altura este

investimento em mim realizado.

Agradeço a Deus por me iluminar, guiar meus passos, por me dar forças dia a dia para

concluir mais uma caminhada.

Obrigado a todos !

vi

Nada poderá me abalar, nada poderá me

derrotar, pois minha força e vitória têm um

nome e é Jesus...

Sandro Andrade

vii

RESUMO

A área da saúde vem recebendo investimentos em todo mundo para o desenvolvimento de

sistemas de informação que proporcionam apoio às suas atividades. No entanto, existem ainda

alguns desafios a serem enfrentados para que o processo de desenvolvimento destes sistemas

tenha maior produtividade e qualidade. O desenvolvimento de ambientes para a

implementação de sistemas de informações de saúde apresenta alguns desafios, dentre os

quais a complexidade dos processos de cuidado à saúde se destaca. Neste contexto, a tentativa

de minimizar a complexidade no aprendizado do domínio clínico e a necessidade de aumentar

a produtividade e a qualidade na construção dos sistemas de informação de saúde (Healthcare

Information System – HIS) surge como requisitos essenciais. Para diminuir a complexidade

dos Processos de Cuidado a Saúde e aumentar a produtividade e qualidade na construção dos

HIS, a adoção de arquétipos integrada a uma abordagem de desenvolvimento orientada a

modelos aparecem como uma alternativa potencial para resolver esses problemas. Conforme

definido, arquétipos são fatias de conhecimento que apontam como representar conceitos ou

informações de um determinado domínio. Adicionalmente, as abordagens orientadas a

modelos apresentam um potencial relevante para lidar de forma adequada com esses desafios

pelo fato de oferecerem um nível mais alto de abstração no desenvolvimento de software. Tal

característica proporciona, entre outros benefícios: reusabilidade, portabilidade e

interoperabilidade, aumentando a produtividade do processo e a qualidade das aplicações.

Neste contexto, este trabalho de mestrado apresenta uma abordagem, referente ao

desenvolvimento dirigido a modelos (Model-Driven Development – MDD) na confecção de

aplicações para o Cuidado de Saúde do paciente baseada em arquétipos clínicos. Com a

adoção de MDD, a abordagem proposta é composta por um conjunto de atividades que visam

ajudar e aumentar a produtividade das equipes no desenvolvimento de sistemas clínicos.

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

viii

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

ix

LISTA DE FIGURAS

Figura 1. Projeto de Especificação openEHR (OPENEHR, 2011) ....................................................................... 22

Figura 2. Informação x Arquétipos ....................................................................................................................... 24

Figura 3. Estrutura de pacotes (OPENEHR, 2011) ............................................................................................... 25

Figura 4. Pacote Core RM (OPENEHR, 2011) ..................................................................................................... 25

Figura 5. Visão dos pacotes do patterns (OPENEHR, 2011) ................................................................................ 27

Figura 6. Pacotes pertencentes ao domain (OPENEHR, 2011) ............................................................................. 28

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

Figura 8. Relacionamento das informações para o Processo de Investigação (OPENEHR, 2011) ....................... 30

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

Figura 10. Estrutura do Pacote AM (OPENEHR, 2011) ....................................................................................... 32

Figura 11. Estrutura ADL (OPENEHR, 2011) ...................................................................................................... 33

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

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

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

Figura 15. Representação das iniciativas de Moden-Driven (AMELLER, 2009) ................................................. 42

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

Figura 17. Fluxo de Transformação Geral ............................................................................................................ 43

Figura 18. Quatro Camadas da Arquitetura do Metamodelo (LIDDLE, 2010) ..................................................... 45

Figura 19. Exemplo de preenchimento de tagged value no modelo ...................................................................... 48

Figura 20. Interface da ferramenta UML Papyrus ................................................................................................ 51

Figura 21. Exemplo de HTML com Jquery Mobile .............................................................................................. 54

Figura 22. Linha do tempo HTML ........................................................................................................................ 55

Figura 23. Exemplo de Código HTML5 ............................................................................................................... 56

Figura 24. Definição e Exemplo de CSS ............................................................................................................... 57

Figura 25. Linha do Tempo CSS (W3C) ............................................................................................................... 57

Figura 26. Modelo e Exemplo de JSON ............................................................................................................... 59

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

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

FRAMEWORK, 2012) ................................................................................................................................. 61

Figura 29. Histórico anual do FPG ....................................................................................................................... 62

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

Figura 31. Protocolo Definido para a Pesquisa ..................................................................................................... 66

Figura 32. Fluxo do Processo da Pesquisa ............................................................................................................ 68

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

Figura 34. Visão da Abordagem Proposta ............................................................................................................ 73

Figura 35. Etapas da abordagem ........................................................................................................................... 75

x

Figura 36. Diagrama do Macroprocesso - Engenharia de Domínio ...................................................................... 76

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

Figura 38. Processo Proposto para Engenharia de Domínio ................................................................................. 78

Figura 39. Exemplo de Modelo Conceitual Refinado ........................................................................................... 80

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

Figura 41. Diagrama de Classe do perfil UML ..................................................................................................... 82

Figura 42. Tela inicial ........................................................................................................................................... 83

Figura 43. Modelo Domínio x trecho código MOFScript x HTML gerado .......................................................... 84

Figura 44. Diagrama de Processo EA ................................................................................................................... 87

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

Figura 46. Diagrama de Casos de Uso do SOT ..................................................................................................... 88

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

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

Figura 49. Trecho de código da Tela inicial do aplicativo SOT............................................................................ 91

Figura 50. SOT em execução ................................................................................................................................ 92

Figura 51. Visão Funcional do aplicativo SASVM ............................................................................................... 93

Figura 52. Alguns Mapas Mentais do SASVM ..................................................................................................... 94

Figura 53. Diagrama de Casos de Uso do SASVM .............................................................................................. 96

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

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

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

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

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

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

xi

LISTA DE TABELAS

Tabela 1. Categoria (tipos) de dados do openEHR ............................................................................................... 26

Tabela 2. Estruturas Genéricas do openEHR ........................................................................................................ 27

Tabela 3. Strings de Busca .................................................................................................................................... 67

Tabela 4. Fontes de Pesquisa ................................................................................................................................ 67

Tabela 5. Critérios de Inclusão e Exclusão de Trabalhos Relacionados ............................................................... 68

Tabela 6. Descrição das classes das facetas por conteúdo .................................................................................... 69

Tabela 7. Classificação das obras de acordo com os tipos .................................................................................... 70

Tabela 8. Regras de Transformação ...................................................................................................................... 85

Tabela 9. Matriz do Resultado dos Formulários Preenchidos ............................................................................. 103

xii

LISTA DE ACRÔNIMOS

AD – Análise de Domínio

ADL – Archetype Definition Language

AM – Archetype Model

AOM – Metamodelos de arquétipos

AP – Archetype Profile

CBIS– Congresso Brasileiro de Informática de Saúde

CCs – Conceitos Clínicos

CIM – Modelo Independente da Computação

CKM– Clinical Knowledge Manager

EA – Engenharia de Aplicação

ED – Engenharia de Domínio

EHRs – Registros Eletrônicos de Saúde

ER – Entidade-Relacionamento

FPG – Framework PhoneGap

HIS – Health Information Systems

JSON– JavaScript Object Notation

LOC – Lines of Code

M2C – Model to Code

M2M – Model to Model

M2T – Model to Text

MD – Modelar Domínio

MDA – Model-Driven Architecture

MDD – Model-Driven Development

MDE – Model-Driven Engineering

MM – Mapas Mentais

MOF – MetaObject Facility

OCL – Object Constraint Language

OWL – Ontology Web Language

PEP – Prontuário Eletrônico do Paciente

PIM – Modelo Independente de Plataforma

PSM – Modelo plataforma específica

RES – Registro Eletrônico de Saúde

xiii

RM – Reference Model

RMOP – Registro Médico Orientado a Problemas

SASVM – Sistema de Acompanhamento dos Múltiplos Sinais Vitais e Medidas do Paciente

SUS – Sistema Único de Saúde

SE – Engenharia de Software

SEI – Software Engineering Institute

TAM – Technology Acceptance Model

TOM – Template Object Model

UI – Interface do Usuário

UML – Unified Modeling Language

XMI – XML Metadata Interchange

xiv

SUMÁRIO

1. Introdução 16

1.1 Caracterização do Problema 16 1.2 Motivação 17 1.3 Objetivos 17 1.4 Escopo Negativo 18 1.5 Organização do Trabalho 20

2 Arquétipos 21

2.1 Fundação openEHR 23 2.2 Modelo Dual 23

2.2.1 Modelo de Referência - RM 24 2.2.2 Modelo Arquétipo - AM 32

2.3 Archetype Definition Language - ADL 33 2.4 Mapa Mental 35 2.5 Síntese do Capítulo 36

3 Desenvolvimento Dirigido a Modelos 37

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

4 Tecnologias Web 52

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

5. Trabalhos Relacionados 65

5.1 Introdução 65 5.2 Método e Protocolo de Busca 66

5.2.1 Definição das Questões 66 5.2.2 Realização da Pesquisa 67 5.2.3 Definição das Fontes de Pesquisas 67 5.2.4 Seleção dos Estudos 68 5.2.5 Classificação dos Estudos 69 5.2.6 Conclusões da Pesquisa 70

6. Abordagem Proposta 72

6.1 Objetivos da abordagem 73 6.2 Visão Geral 74 6.3 Etapas da Abordagem 77

6.3.1 Engenharia de Domínio - ED 77 6.3.2 Engenharia de Aplicação - EA 86

xv

7. Estudo de Caso - Sistema 93

7.1 Engenharia de Aplicação - EA 94 7.1.1 Análise 94 7.1.2 Projeto 97 7.1.3 Implementação 98 7.1.4 Testes 100

7.2 Resultados 101 7.2.1 Lines of Code - LOC 101 7.2.2 Avaliação 102

8. Conclusões e Trabalhos Futuros 104

8.1 Sumário das Conclusões 104 8.2 Contribuições 105 8.3 Dificuldades encontradas 105 8.4 Limitações 105 8.5 Trabalhos Futuros 106

Referências 107

16

1. INTRODUÇÃO

Este capítulo motiva e caracteriza o problema a ser resolvido nesta dissertação,

apresenta o objetivo a ser atingido, além da definição do escopo negativo. Por fim, descreve a

estrutura na qual estão organizados os demais capítulos deste documento.

1.1 CARACTERIZAÇÃO DO PROBLEMA

O crescente aumento das exigências por sistemas de qualidade refletem uma maior

exatidão os seus processos organizacionais. Diante desse cenário, a indústria de

desenvolvimento de software tem trabalhado com o objetivo de criar novas tecnologias que

atendam a tais necessidades (SOUZA; OLIVERA, 2012).

Segundo Bergmann (2010), em todo mundo têm sido feitos grandes investimentos

para o desenvolvimento de Sistemas de Informação em Saúde (Health Information Systems –

HIS), com o objetivo de prover um ganho de produtividade na área da saúde, através da

captação dos benefícios proporcionados pelas novas tecnologias utilizadas no

desenvolvimento de software. Portanto, tem sido dada uma considerável atenção ao potencial

das abordagens orientadas a modelos no suporte ao desenvolvimento de HIS.

Bergmann (2010) menciona também que a tendência global em cuidados de saúde está

voltada para modelos de atenção mais centrados no paciente, baseada na manutenção do bem-

estar, ao invés dos modelos tradicionais centrados no médico que são focados nas doenças.

Neste sentido, abordagens orientadas a modelos, tais como: Desenvolvimento

Orientado a Modelos (Model-Driven Development – MDD) apresentam um potencial

importante para colaborar na melhoria da produtividade do processo e da qualidade do

produto de software. MDD é um paradigma de desenvolvimento de sistemas dirigido a

modelos que visa aprimorar a forma com que o software é desenvolvido, via a representação

das principais características de um sistema em modelos, os quais são construídos e refinados

conforme o sistema é desenvolvido (VOELTER; GROHER, 2007).

Além disso, MDD possibilita a especificação do sistema de maneira a tornar possível a

geração dos artefatos da aplicação de forma automática através de operações de

transformações de modelo para texto.

17

Por outro lado, as soluções adotadas no desenvolvimento dos HIS são complexas e

mudam constantemente, isto eleva a dificuldade de implementação e manutenção dos HIS

(DENNIS, 2009).

Neste contexto, o conjunto de especificações proposto pela Fundação openEHR

(BEALE,2002) conhecida como Arquétipos, a qual tem o intuito do desenvolvimento de

padrões abertos para a construção de HIS, fornece meios para uma separação entre a

modelagem da informação e a modelagem de dados clínicos, chamado de modelo Dual,

diminuindo assim a complexidade no entendimento dos Conceitos Clínicos. A proposta da

Fundação openEHR é, através da confecção do padrão que representa formalmente arquétipo,

possibilitar que as especificações dos conceitos clínicos sejam compartilhados e ajudem na

confecção dos HIS baseados em conceitos sólidos. Um exemplo da representação de um

conceito clínico através de arquétipo é o “Peso Corporal”, que é formada por uma quantidade

(valor e unidade) e a data da ocorrência da aferição (NARDON et al, 2011).

1.2 MOTIVAÇÃO

A tentativa de melhorar a produtividade e a qualidade no desenvolvimento dos HIS é

desafiadora por si só. Adicionalmente a isso, desenvolver HIS reduzindo a complexidade é

ainda mais estimulante.

Com a adoção do desenvolvimento orientado a modelos – MDD espera-se uma

melhoria da produtividade dos esforços de desenvolvimento, através da utilização de

conceitos que são menos associados à tecnologia de desenvolvimento, e mais próximos do

domínio do problema, possibilitando assim a confecção dos HIS realizadas por especialista de

domínio e não necessariamente por um especialista em computação.

1.3 OBJETIVOS

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

aumento da produtividade e a diminuição da complexidade na construção de HIS baseados em

conceitos clínicos (arquétipos) através da abordagem de desenvolvimento orientado a

modelos.

18

Para alcançar o objetivo desse trabalho, faz-se necessário estabelecer objetivos

específicos:

Definir um perfil UML que possibilite a modelagem das informações dos Conceitos

Clínicos utilizados nesta pesquisa. A definição de um perfil UML neste trabalho foi

estimulada através da criação da openEHR uma iniciativa de modelagem de informações

clínicas com arquétipos e perfil UML (Clinical Information Modelling Initiative – CIMI).

Esse grupo funciona através de uma colaboração internacional e se dedica a fornecer um

formato comum para especificações detalhadas visando a representação do conteúdo de

informação de saúde (CIMI, 2011);

Modelar os Conceitos Clínicos de Cuidado à Saúde pertencente ao domínio dos

metamodelos clínicos - Arquétipos baseado no perfil UML;

Construir programas geradores utilizando uma abordagem Model Driven Development -

MDD para transformar o modelo de domínio das informações clínicas em artefatos

conforme tecnologias adotadas;

Descrever uma abordagem de desenvolvimento baseada nas etapas Engenharia de

Domínio - ED com MDD e Engenharia de Aplicação - EA. Durante a etapa ED serão

confeccionados artefatos que serão uteis na EA. Um estudo de caso utilizará essa

abordagem especificada para construir um protótipo;

Avaliar o ambiente através da realização de um estudo de caso que confecciona um

protótipo. Esse protótipo tem a utilização avaliada por analistas de sistemas e estudantes.

1.4 ESCOPO NEGATIVO

Algumas atividades não serão contempladas pelo corrente trabalho, entre elas:

Atividades relativas à evolução e/ou manutenção dos artefatos, tais como: gerenciamento

de projetos, gerenciamento de configuração ou merge de modelos;

Implementação de ferramentas para o desenvolvimento orientado a modelos, com

funcionalidades para:

o Transformação de modelo para modelo;

o Transformação reversa, isto é, transformação de texto para modelo;

o Validação dos modelos e validação das transformações;

o Desenvolvimento de ferramenta case – UML;

19

Transformação dos subconjuntos do metamodelo clínico - arquétipos;

Transformação das regras de restrições dos demais subconjuntos do metamodelo clínico -

arquétipos;

Geração de código responsável pela comunicação e segurança entre HIS;

Desenvolvimento de artefatos para a disciplina de implantação.

20

1.5 ORGANIZAÇÃO DO TRABALHO

Neste capítulo descreveu-se a caracterização do problema onde foram apresentados os

problemas alvo e metas desta dissertação. Além disso, foi apresentada a motivação da

realização da pesquisa, os principais objetivos / metas e a definição de escopo desse trabalho.

Na sequência, ilustramos a organização desse documento:

Capítulo 2 - Arquétipos

• São apresentados os principais conceitos e os relevantes modelos;

Capítulo 3 - Desenvolvimento Orientado a Modelos

• São apresentados os conceitos sobre desenvolvimento orientado a modelos, as principais técnicas e abordagem.

Capítulo 4 - Tecnologias WEB

• São apresentados os conceitos sobre as tecnologias WEB utilizadas nessa pesquisa.

Capítulo 5 - Trabalhos Relacionados

• São apresentados os trabalhos relacionados a essa pesquisa, através de uma revisão bibliográfica.

Capítulo 6 - Abordagem Proposta

• É apresentada uma abordagem proposta que será utilizada nessa pesquisa;

Capítulo 7 - Estudo de Caso

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

Capítulo 8 - Conclusão

• São descritas de forma conclusiva as contribuições, dificuldades, limitações, trabalhos futuros e considerações finais;

21

2 ARQUÉTIPOS

Neste capítulo são apresentados os principais conceitos e técnicas sobre arquétipos, seus

modelos, formas de apresentações em: ADL e Mapa Mental.

Em um ponto de vista mais genérico, considerando a definição do termo arquétipo no

Dicionário online Merriam-Webster que é: "o padrão original ou modelo do qual todas as

coisas do mesmo tipo são representados ou um perfeito exemplo".

Conforme definição de Beale (2007), arquétipos são pedaços de conhecimento que

indicam como representar conceitos ou informação. Um arquétipo que representa o conceito

“temperatura corporal”, por exemplo, pode definir que este conceito é formado por uma

quantidade (um número e uma unidade) e por uma data que indica o momento em que a

temperatura foi aferida. Arquétipo é a definição formal de combinações prescritas das classes

definidas no Modelo de Referência para domínios ou organizações clínicas específicas. Ou

seja, arquétipo é uma expressão formal de um conceito distinto em nível de domínio, expresso

na forma de restrições sobre os dados cujas instâncias estejam em conformidade com o

modelo de referência.

Desta forma, a utilização de arquétipos permite compartilhar conceitos e

conhecimento clínico, formando sistemas a partir de um conjunto de integração. Esta é a

proposta da Fundação openEHR (BEALE, 2007): criar um padrão que permita representar

formalmente arquétipos, possibilitando assim que as especificações de conceitos clínicos

criadas com este formalismo sejam compartilhadas e resultem na construção de sistemas de

informação em saúde fundamentados em conceitos sólidos. Arquétipos são descritos como

um modelo formal e reutilizável de um conceito do domínio. Assim, se um conceito é

representado por um arquétipo, este conceito pode ser reutilizado nos vários cenários em que

ele se aplica.

O que torna o uso de arquétipos uma boa alternativa para representação do

conhecimento é a concentração de todo o conceito numa única estrutura. Sempre

desenvolvido sob a orientação e auxílio de profissionais especialistas da área, o conceito

descrito por um arquétipo pode ser visto como o refinamento da ontologia daquele domínio,

trazendo benefícios para a comunicação humana, interoperabilidade ao nível conceitual,

enriquecimento do domínio e desenvolvimento de sistemas padronizados (BEALE, 2001).

22

Figura 1. Projeto de Especificação openEHR (OPENEHR, 2011)

A Figura 1 ilustra o projeto de especificação openEHR. Este projeto é responsável por

desenvolver as especificações em que o plataforma computacional openEHR se baseia. As

relações entre as partes da plataforma da computação e as especificações são indicadas no

diagrama. Os resultados do projeto incluem requisitos, especificações abstratas,

especificações de implementação de tecnologia, expressões computáveis e critérios de

conformidade.

As especificações abstratas consistem no: Reference Model (RM), o Service Model

(SM) e Archetype Model (AM). Os RM e AM correspondem aos pontos de vista de

informações e computacional, respectivamente. O SM formaliza a ponte entre modelos de

informação e recursos de conhecimento.

As especificações resumo publicado pela openEHR são definidos usando a notação

UML e especificações formais da classe textuais. Estes modelos constituem as referências

primárias para toda a semântica openEHR. O estilo de apresentação destas especificações

abstratas está deliberadamente à intenção de ser clara e semanticamente próxima das idéias

que estão sendo comunicadas. Assim, as especificações não seguem modismos ou limitações

de linguagens de programação, linguagens específicas de esquema ou outros formalismos.

23

2.1 FUNDAÇÃO OPENEHR

A Fundação openEHR (OPENEHR, 2011b) é uma fundação internacional sem fins

lucrativos fundada em 2003 pela equipe da University College London e a companhia

australiana Ocean Informatics. A Fundação openEHR é dedicada ao desenvolvimento para

área de saúde, tornando essa área aberta. A openEHR tem como foco a pesquisa das

necessidades clínicas, criação de especificações e implementações. As especificações

assumem a forma de modelos de informação modulares, modelos de serviço e modelos de

informação clínica (BEALE, 2001);

A Fundação openEHR é dedicada à pesquisa e ao desenvolvimento dos Registros

Eletrônicos de Saúde – EHRs, que empregam arquétipos na especificação de uma arquitetura

livre baseada numa abordagem de duas camadas (BEALE, 2001), a qual separa o modelo de

dados (ou modelo de persistência) do modelo de representação do domínio. Aqui no Brasil, os

registros eletrônicos de saúde que possuem as informações dos cuidados a saúde do paciente

são conhecidos como Prontuário Eletrônico do Paciente – PEP.

Os principais objetivos, destacamos os objetivos do Projeto Arquétipo criado pela

openEHR de tornar a tecnologia dos PEPs adaptável e à prova de futuro. Assim, os PEPs

devem ser bases confiáveis para possibilitar as suas evoluções por mais de cem anos

(BEALE, 2001).

2.2 MODELO DUAL

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

(Reference Model – RM) composto por classes, que representam estruturas genéricas do

Registro Eletrônico de Saúde - RES ou de dados demográficos (FREIRE et al., 2008). O

modelo de representação do domínio (segunda camada) é composto por regras que restringem

o RM e especificam como os conceitos clínicos são usados no RES. Essas regras são

definidas pelos arquétipos e essa camada é representada pelo Modelo de Arquétipo

(Archetype Model - AM). Sendo o RM mais estável e menos sujeito a alterações que o AM,

essa separação habilita o desenvolvimento de “sistemas à prova de futuro” (BEALE, 2001),

permitindo os mecanismos de persistência serem pouco alterados e o AM ser afetado pelas

alterações de estrutura e de regras de negócio (FREIRE et al., 2008). Neste modelo dual

empregado pela openEHR, apenas a primeira camada é implementada em software. Dessa

24

forma, os sistemas tornam-se consideravelmente menores, mais sustentáveis e inerentemente

auto-adaptativos, já que são construídos para consumir arquétipos, os quais poderão ser

desenvolvidos em qualquer estágio de uso dos mesmos.

Figura 2. Informação x Arquétipos

A Figura 2 ilustra que o uso dos arquétipos gera novos relacionamentos entre

informações e modelos. Um sistema planejado de maneira clássica, com toda a semântica do

domínio codificada no software ou banco de dados, estaria limitado do lado esquerdo da

figura e seus dados conforme apenas a um modelo de dados. Com o uso do modelo dual,

todos os dados em tempo de execução estão relacionados semanticamente aos arquétipos,

expressos em Archetype Definitions Language (ADL), bem como concretamente relacionados

ao modelo de referência (BEALE; HEARD, 2007b).

2.2.1 MODELO DE REFERÊNCIA - RM

O Modelo de Referência representa as características globais dos componentes do

registro em saúde, como eles são agregados, e a informação contextual necessária para

atender aos requisitos éticos, legais e de proveniência. Este modelo define o conjunto de

classes que formam os blocos genéricos para construir o Registro Eletrônico de Saúde – RES.

25

Figura 3.Estrutura de pacotes (OPENEHR, 2011)

Conforme ilustrado na Figura 3 e descrito em (BEALE; HEARD, 2007b) e também

mencionado por MENEZES et al (2011), o RM pode ser dividido em core, patterns e domain,

cada um com seus respectivos pacotes e subdivisões.

Figura 4. Pacote Core RM (OPENEHR, 2011)

26

A Figura 4 apresenta o diagrama de pacotes que pertencem ao core. O core é a parte

do RM que é subdivido nos seguintes modelos de informações (BEALE et al., 2008d):

Support Information Model corresponde aos conceitos mais básicos requeridos por todos

os demais pacotes, sendo formado pelos pacotes: definitions, identification, terminology e

measurement. A semântica definida nestes pacotes permite que todos os outros modelos

usem os identificadores e tenham acesso aos serviços de conhecimento, tais como

terminologia e outros dados. Além disso, o pacote support compreende os tipos usados

pelos modelos da openEHR, inclusive os tipos primitivos definidos por outras entidades.

Este pacote é um guia para a integração de modelos openEHR adequadas para os sistemas.

Data Types Information Model define um conjunto de tipos de dados subjacentes a todos

os demais modelos, provendo tanto os tipos de dados genéricos quanto os específicos

requeridos pelas formas de infomação em Saúde. A Tabela 1 (BEALE et al., 2008b) lista

as categorias de tipos de dados definidas pelo data types information model.

Tabela 1. Categoria (tipos) de dados do openEHR

Categoria Descrição

Basic Types boolean, integer, real, etc.

Text texto simples, texto codificado, parágrafos

Quantities qualquer tipo ordenado, incluindo valores ordinais, medições com

valores e unidades, etc.

Data/Time data hora, tipos de data e hora, e tipos de data e hora parciais

Encapsulated data multimídia, conteúdo processável

Data Structures Information Model é composto pelas estruturas genéricas, listadas na

Tabela 2, que são usadas para expressar o conteúdo da estrutura particular definida pelos

arquétipos. Essas estruturas pertencem ao pacote item_structure exibido na Figura 4

(BEALE et al., 2008a). Além desse pacote, data_structures também contém o pacote

history, o qual descreve uma noção genérica de história linear, permitindo o registro de

informações ao longo do tempo.

27

Tabela 2. Estruturas Genéricas do openEHR

Estrutura Descrição

Single itens simples, utilizado para conter qualquer valor , exemplo: peso

ou altura

List lista linear de itens nominais, tais como alguns testes patológicos

Table dado tabular, incluindo tabelas de tamanhos limitados e ilimitados,

com colunas nominadas e ordenadas

Tree dados em forma de árvore que podem ser conceitualmente uma lista

de listas, ou outra estrutura de profundidade

Figura 5.Visão dos pacotes do patterns (OPENEHR, 2011)

A Figura 5 apresenta o diagrama de pacotes que pertencem ao patterns. O patterns é a

parte do RM que é subdivida nos dois modelos de informações (BEALE et al, 2010):

Common Information Model é um conjunto de vários pacotes contendo conceitos

abstratos e padrões de projetos, que são usados em modelos de mais alto nível do

openEHR. O archetyped habilita o emprego do modelo dual da openEHR, fazendo a

ligação entre os modelos de informação e de arquétipos; o pacote generic contém classes

que formam “padrões de análise”, os quais são genéricos por todo o domínio e comumente

relacionados a referências realizadas a entidades demográficas por outros dados; o pacote

directory provê uma abstração simples e reutilizável de uma estrutura de pasta com

controle de versão; o pacote change_control define uma semântica generalizada das

alterações de um repositório lógico ao longo do tempo, sendo que cada item no repositório

tem sua versão controlada para permitir que o repositório como um todo tenha seu

controle de versão garantido; o pacote resource define a semântica de um recurso de

autoria (documentos), fornecendo suporte as traduções em vários idiomas, metadados

descritivos e históricos de revisão.

28

Security Information Model define a semântica de controle de acesso e as configurações de

privacidade para a informação no RES.

Figura 6. Pacotes pertencentes ao domain (OPENEHR, 2011)

A Figura 6 apresenta o diagrama de pacotes e seus subpacotes que pertencem à parte

do RM chamada de domain. Um detalhamento maior dos pacotes composition e ehr são

apresentados na Figura 7.

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

29

A Figura 7 apresenta uma visão detalhada do modelo de informação EHR. O modelo

de informação EHR contém a estrutura de mais alto nível, que consiste de um objeto

HER_ACCESS, um objeto EHR_STATUS, recipientes de controle de versão de dados na

forma de VERSIONED_COMPOSITION, opcionalmente indexado por uma hierarquia de

diretórios de FOLDER. Uma coleção de CONTRIBUTION, que documenta as mudanças do

RES ao longo do tempo, também é incluída: o pacote composition é o recipiente de dados de

mais alto nível num RES, sendo descrito pela classe COMPOSITION; o pacote content

contém os pacotes navigation e entry, sendo que suas classes descrevem a estrutura e a

semântica do conteúdo das composições num RES.

Uma questão importante a ser destacada no modelo do padrão openEHR é a

capacidade, por exemplo, de oferecer um melhor suporte ao Registro Médico Orientado a

Problemas-RMOP, proposto por Lawrence Weed (1968), e registrado através do método

SOAP, que significa a sequencia da evolução de: Subjetivo, Objetivo, Avaliação e Plano. Este

método é destacado como um dos relevantes princípios da clínica médica, principalmente na

atenção básica de saúde, por aumentar a organização do RES e direcionar o olhar para o

cuidado do paciente, não apenas para a sua patologia (STAFIELD, 2002). Um problema é

resolvido fazendo observações, formando opiniões (hipóteses), e prescrevendo ações

(instruções) para os próximos passos, que podem ser investigação adicional, ou podem ser

intervenções concebidas para resolver o problema, e, finalmente, a execução das instruções

(ações). A Figura 8 demonstra o relacionamento das informações para o Processo de

Investigação usando o método SOAP.

30

Figura 8.Relacionamento das informações para o Processo de Investigação

(OPENEHR, 2011)

O diagrama de classe adicionado à sequencia de passos ilustrados na Figura 8

apresenta o núcleo clínico do modelo de informação do Registro Eletrônico de Cuidado a

Saúde. O EHR Information Model possui a classe de entrada (ENTRY) que é definida em dois

grupos principais de informação no modelo de entrada: 1) Informações de Cuidado (CARE

ENTRY); 2) Informações Administrativas (ADMIN ENTRY) (BEALE, 2007).

Conforme mencionado por Gaete et al (2012), as Informações do Cuidado a Saúde

estão relacionadas ao registro clínico de fato, enquanto as Informações Administrativas dizem

respeito a todo o resto que não faz parte do processo de cuidado/assistência de Saúde. Existem

quatro classes genéricas de registro de Informações do Cuidado (BEALE et al., 2007): 1)

OBSERVATION, para registrar tudo o que puder ser observado, medido ou respondido pelo

paciente; 2) EVALUATION, para registrar avaliações, diagnósticos e planos de cuidado; 3)

INSTRUCTION, afirmações que podem ser executadas, como prescrições / receitas de

31

medicamentos, orientações, exames, encaminhamento, entre outros; 4) ACTION, informações

que se registram como resultado da execução das instruções.

Integration Information Model define classes que permitem representar dados externos

ou legados numa árvore de dados. Este tipo de entrada de dados possui seu próprio tipo de

arquétipos, denominados arquétipos de integração, os quais podem ser usados em

conjunto com os arquétipos clínicos em sistemas de integração de dados.

Demographic Information Model determina os conceitos genéricos de PARTY, ROLE e

os detalhes relacionados aos endereços de contato. O modelo de arquétipos define a

semântica das restrições nas PARTY, permitindo que arquétipos para qualquer tipo de

pessoa, organização, papel e relacionamento de papéis possam ser descritos. A Figura 9

apresenta uma visão detalhada do modelo das informações demográficas.

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

32

2.2.2 MODELO ARQUÉTIPO - AM

O pacote AM contém os modelos necessários para descrever a semântica dos

arquétipos e templates, bem como o seu uso na openEHR.

Figura 10.Estrutura do Pacote AM (OPENEHR, 2011)

Como pode ser observado na Figura 10, o Archetype Model - AM inclui a ADL, os

pacotes archetype e template, que definem a semântica orientada a objetos desses arquétipos e

templates, e o pacote openehr_profile, que define um perfil genérico do modelo de arquétipo

para o uso na openEHR (BEALE; HEARD, 2007b).

Archetype Object Model - AOM define em Unified Modeling Language - UML o

modelo de objetos equivalente aos arquétipos. Sendo um modelo genérico, o AOM pode ser

usado para definir arquétipos para qualquer modelo de referência numa forma padronizada. O

openEHR Archetype Profile - oAP define classes de arquétipos personalizadas, e suas

sintaxes personalizadas equivalentes, que podem ser usadas no refinamento de certas classes

do RM. O Template Object Model - TOM define o modelo de objetos para os templates, os

quais são usados para combinar arquétipos em estruturas de informações específicas e assim

suprir as necessidades de variações locais, usualmente correspondendo aos formulários de tela

(BEALE, 2008). A Archetype Definition Language – ADL tem o objetivo de prover uma

sintaxe abstrata capaz de representar textualmente arquétipos e templates.

33

2.3 ARCHETYPE DEFINITION LANGUAGE - ADL

Archetype Definition Language (ADL) é uma linguagem formal desenvolvida pela

OpenEHR visando expressar arquétipos a fim de torná-los processáveis. Para descrever as

restrições nos dados, que são instâncias de algum modelo de informação, a ADL emprega três

sintaxes: dADL para expressar dados; cADL para expressar restrições; e uma versão de lógica

de predicados de primeira ordem. Via o uso da ADL, arquétipos podem ser escritos para

qualquer domínio onde existam modelos formais que descrevem instâncias de dados

(BEALE; HEARD, 2008).

Arquétipos expressos em ADL lembram códigos de linguagens de programação e

possuem uma sintaxe definida. A cADL é usada para expressar a seção de definição de

arquétipos, enquanto que a dADL é usada para expressar os dados que aparecem nas seções

de idioma, descrição, ontologia e histórico de revisão (BEALE; HEARD, 2008). Uma visão

geral da estrutura de uma ADL é apresentada na Figura 11.

Figura 11.Estrutura ADL (OPENEHR, 2011)

34

Usando uma sintaxe interpretável, a ADL possui um relacionamento formal com

modelos estruturais, tais como os representados pela UML. Enquanto a sintaxe da ADL

permanece como o principal formalismo para expressar arquétipos, o AOM estabelece a sua

semântica, definindo principalmente os relacionamentos que precisam ser garantidos entre

suas partes, para que esse arquétipo seja considerado válido como um todo. A Figura 12

apresenta um trecho da ADL do arquétipo para o registro dos dados do paciente.

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

35

2.4 MAPA MENTAL

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

uma ideia ou conceito central, utilizado para visualizar, classificar, estruturar conceitos e gerar

novas ideias (BUZAN, 2003). É similar a uma rede semântica, ou um mapa cognitivo, porém

sem restrições nos tipos de conexões usadas. Nele os elementos são ordenados de forma

intuitiva, de acordo com a importância dos conceitos relacionados a um domínio, que então

são organizados em agrupamentos, ramificações ou áreas. Em outras palavras, um mapa

mental é um diagrama radial que através de vocabulários (palavras-chave), distribuídas em

certa ordem e correlacionadas possam representar e modelar cognitivamente um conceito ou

um domínio específico. Segundo Buzan (2003), os principais benefícios em utilizar mapas

mentais são: organização, utilização de palavras-chave, associação, agrupamento de ideias,

memória visual, criatividade e inovação com simplicidade.

Nesta pesquisa, o mapa mental é utilizado com o propósito de representar um mapa

cognitivo, tendo como objetivo extrair, estruturar e organizar o conhecimento ou domínio de

saúde, advindo dos arquétipos, de forma espacial, abstraindo as complexidades dos

arquétipos centrando o domínio em dados persistentes (DATA) para um sistema de

informação de saúde.

Alguns trabalhos (DOWNS, 1973) e (KITCHIN, 1994) destacam que esse tipo de

representação facilita a mente humana em processar melhor as informações, reduzindo a carga

cognitiva para a absorção do conhecimento ou domínio. Neste contexto, o mapa mental foi

adotado com o intuito de facilitar a comunicação e simplificar a modelagem de domínio pelo

Especialista de Domínio, tornando este processo mais ágil e eficaz.

A Fundação openEHR utiliza-se de mapas mentais como um dos diagramas de

representação de conhecimento para os registros de prontuários eletrônicos A Figura 13

apresenta um exemplo de mapa mental do conceito clínico Temperatura Corporal definida

pela openEHR.

36

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

2.5 SÍNTESE DO CAPÍTULO

De maneira geral, este capítulo apresentou definições referentes aos Arquétipos. A seção

2.1 explicitou detalhes sobre a Fundação openEHR, seus principais objetivos e focos de

atuação.

Na seção 2.2, foi detalhado o Modelo Dual, apresentando conceitos e descrevendo o

Modelo de Referência - RM e Modelo Arquétipo – AM. Os submodelos foram apresentados,

seus pacotes e classes ilustradas. Além disso, o processo de investigação clínica também foi

demonstrado.

Na seção 2.3, os conceitos e exemplos de Archetype Definition Language - ADL foram

ilustrados.

Por fim, a seção 2.4, os conceitos e exemplos sobre os mapas mentais foram

apresentados. Também é justificada nesta seção a adoção de mapas mentais no corrente

trabalho.

37

3 DESENVOLVIMENTO DIRIGIDO A MODELOS

Este capítulo fornece uma visão detalhada sobre o paradigma de desenvolvimento

orientado a modelos, apresentando desde a sua definição, linha do tempo, utilização e

abordagens mais frequentes.

Antes de iniciar esta seção, faz-se necessário a apresentação de algumas definições do

termo modelo. O termo modelo é um dos mais utilizados, mas seu significado pode

visivelmente ser alterado entre contextos (amplamente explicado por (SEIDEWITZ, 2003;

KÜHNE, 2005). Por exemplo, em Engenharia Software o termo modelo tradicionalmente

refere-se a um artefato formulado em alguma linguagem de modelagem. Esta definição é

estreito para MDE, onde o código de um programa pode ser interpretado como um modelo em

alguns casos. No livro "MDA Explained" (KLEPPE; WARMER; BAST, 2003) o termo

modelo é definido como: peça "Uma descrição (de) um sistema de escrita em uma linguagem

bem definida".

Em um ponto de vista mais genérico, considerando a definição do termo modelo no

Dicionário online Merriam-Webster que é: "uma exata representação de algo de tamanho

muito reduzido" ou a definição do dicionário Cambridge que é: "uma representação de algo,

como um objeto físico que é geralmente menor que o objeto real, ou como uma simples

descrição do objeto que possa ser utilizado nos cálculos".

3.1 DEFINIÇÃO

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

objetivo de facilitar a análise de um problema, sendo úteis apenas num primeiro instante. Com

a evolução das atividades do desenvolvimento, esses artefatos vão se tornando obsoletos e

deixam de representar fielmente a realidade da aplicação. Isto ocorre porque normalmente as

mudanças e manutenções são confeccionadas diretamente no código, fazendo com que os

esforços despendidos na construção desses artefatos não sejam aproveitados diretamente na

produção de aplicações (BITTAR, 2009; LUCREDIO, 2009).

Neste sentido, o Desenvolvimento Dirigido a Modelos (Model-Driven Development -

MDD) visa aprimorar a forma com que o software é desenvolvido, via a representação das

relevantes características de um sistema em modelos, os quais são construídos e refinados

38

conforme o sistema é desenvolvido (VOELTER; GROHER, 2007). Em contraste com o

desenvolvimento de software não dirigido a modelos, no MDD os modelos não constituem

apenas a documentação, sendo processados por ferramentas que permitem suas

transformações em diferentes níveis de abstração (VOELTER; GROHER, 2007).

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

Conforme ilustra a Figura 14 (LUCREDIO, 2009), o MDD pode desobrigar o

Engenheiro de Sistemas da interação direta com o código fonte, abstraindo o seu trabalho das

complexidades inerentes à implementação em diferentes plataformas (FRANCE; RUMPE,

2007; LUCREDIO, 2009). Mecanismos automáticos são responsáveis por efetuar

transformações e gerar os códigos a partir dos modelos, fazendo com que estes deixem de ser

apenas guias para o processo de desenvolvimento e também façam parte do software

(LUCREDIO, 2009).

De acordo com (DEURSEN; KLINT, 1998; KLEPPE et al., 2003; LUCREDIO, 2009;

MERNIK et al, 2005), as principais vantagens do MDD relacionam-se à: 1) produtividade,

porque as tarefas repetitivas podem ser implementadas nas transformações, poupando tempo e

esforço, e o tempo de desenvolvimento é melhor aproveitado, já que é empregado na

produção de modelos de mais alto nível; 2) portabilidade, porque um mesmo modelo pode

39

gerar código para diferentes plataformas; grau de integração, porque diferentes partes do

modelo podem ser transformados em códigos para diferentes plataformas, resultando num

software que corresponde à heterogeneidade do ambiente sem perder sua funcionalidade

global; manutenção e documentação, porque as alterações são realizadas diretamente nos

modelos, mantendo-os em conformidade com o código, e a documentação permanece sempre

atualizada, facilitando assim a manutenção; 3) comunicação, porque os especialistas de

domínio podem usar os modelos para identificar os conceitos de negócio, não dependendo

diretamente de conhecimento técnico relativo à plataforma; 4) reutilização, porque o reuso de

artefatos de alto nível traz maiores benefícios que o reuso de código-fonte; 5) verificação e

otimização, porque os modelos facilitam o emprego de verificadores semânticos e

otimizações automáticas, o que pode reduzir a ocorrência de erros semânticos e fornecer

implementações mais eficientes; e 6) corretude, porque as ferramentas usadas nas

transformações não geram erros acidentais (e.g., erros de digitação) e erros conceituais podem

ser identificados em níveis superiores de abstração.

Essas vantagens do MDD relacionam-se à minimização de tarefas repetitivas para a

transformação de modelos em código fonte, as quais passam a ser realizadas com o auxílio de

ferramentas, permitindo a sua automação e a manutenção da consistência dos modelos, isso

mesmo mediante a realização de atividades de urgência, tais como a correção de erros

(LUCREDIO, 2009).

Entre as desvantagens causadas pelo MDD, alguns autores, como Ambler (2003),

Thomas (2004), entre outros, citam: 1) Rigidez: o MDD causa maior rigidez no software

produzido, uma vez que grande parte do código é gerado e fica além do alcance do

desenvolvedor; 2) Curva de aprendizado: o desenvolvimento dos artefatos específicos do

MDD exigem profissionais com habilidades na construção de linguagens, ferramentas de

modelagem, transformações e geradores de código. O aprendizado destas técnicas, apesar de

não ser extremamente difícil, requer um treinamento dedicado; 3) Alto investimento inicial:

assim como a reutilização de software, o MDD depende de maior investimento inicial, uma

vez que a construção de uma infraestrutura de reutilização orientada a modelos requer mais

tempo e esforço. Porém, os ganhos posteriores são significativos, fazendo com que este

investimento tenha retorno em poucas interações.

40

3.2 HISTÓRICO

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

de desenvolvimento automático ou semiautomático, conforme descrito por Ameller (2009).

Uma das mais transcendentes linguagens baseadas em modelos foi a linguagem de

Entidade-Relacionamento - ER proposta por Chen (1976). A declaração a seguir, também

realizada pelo mesmo autor, resume a importância da contribuição ER: "Entidades e

relacionamentos são uma maneira natural de organizar as coisas físicas bem como as

informações... O conceito de ER é o princípio básico fundamental para modelagem

conceitual. Ele tem estado conosco desde há milhares de anos e estará conosco por muitos

anos vindouros.”.

A modelagem conceitual era um tópico de investigação ativo durante a década de

1980, algumas abordagens foram publicadas para estender ER. As bases de Unified Modeling

Language - UML surgiram com as contribuições de Booch, Rumbaugh e Jacobson (1992).

Vinte e um anos depois de ER, em 1997, a primeira versão do UML foi apresentada. Hoje em

dia, UML é usado como o idioma baseada em modelo padrão para desenvolvimento de

software. ER e UML são as raízes do MDE. MDE nasceu nos primeiros anos da década de

2000 com o lançamento do Model-Driven Architecture (MDA, 2001), e uma unificação

progressiva das iniciativas que levam modelos como um elemento principal no

desenvolvimento de software.

3.3 INICIATIVAS

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

orientado a Modelos são nomeadas por siglas, são as seguintes as mais representativas e

apresentadas cronologicamente decrescente:

Model-Driven Engineering (MDE): Em 2006, um artigo publicado no IEEE definiu

MDE como: "As tecnologias da Model-driven engineering oferecem uma abordagem

promissora para tratar a incapacidade das linguagens de terceira geração para aliviar a

complexidade de plataformas e conceitos de domínio expressas de forma eficaz.". Por esta

definição podemos entender MDE como a evolução das ferramentas CASE. A iniciativa

propõe definições de MDE mais amplas em relação aos processos (não se limitando ao

41

desenvolvimento como MDD), e suporte para análise do modelo para tomar decisões ou

simplesmente para o raciocínio (SCHMIDT, 2006).

Model-Driven Development (MDD): Em 2003 um artigo com o mesmo nome como a

iniciativa (MELLOR et al, 2003) é publicado em IEEE Software. O artigo define: "Model-

Driven Development é simplesmente a noção de que podemos construir um modelo de um

sistema que pode então se transformar em coisa real.". Uma diferença entre MDD e MDA é

que MDD não é aderente algumas das normas da OMG. Foi dito por Fowler (2009), que a

principal contribuição do MDD é a flexibilidade oferecida para definir processos de

desenvolvimento.

Model-Driven Architecture (MDA): O primeiro artigo do OMG referindo-se ao MDA

foi publicado em 2000. Mais tarde, em 2003, a atual versão do guia MDA (MDA GUIDE,

2003) foi publicado. Todas as iniciativas model-driven seguem o princípio de que "tudo é um

modelo", declarou em (BÉZIVIN, 2005).

Em uma sessão plenária celebrada em Montreal entre os dias 23 e 26 de Agosto de

2004, a seguinte definição de MDA foi concedida: “A MDA é uma iniciativa OMG que se

propõe a definir um conjunto de padrões proprietários que especificam tecnologias

interoperáveis para realizar Model-Driven Development com transformações automatizadas”.

Nem todas essas tecnologias se referem diretamente as transformações envolvidas na MDA.

MDA não necessariamente depende da UML, mas, como um tipo especial de Model-

Driven Development - MDD, MDA necessariamente envolve o uso de modelo (s) em

desenvolvimento, o que implica que a modelagem, pelo menos, uma linguagem deve ser

usado. Qualquer linguagem de modelagem utilizada na MDA deve ser descrita em termos da

linguagem MOF, para permitir que os metadados possam ser entendidos de uma forma

padrão, que é uma condição prévia para qualquer capacidade para realizar transformações

automatizadas.

A Figura 15 representa a evolução temporal dessas três iniciativas. Note-se que as

iniciativas MDD e MDE surgirem mais cedo do que o ano mencionado. Os anos mostrados na

figura representam os anos respectivos anos onde ocorreu a primeira publicação em revista.

42

Figura 15.Representação das iniciativas de Moden-Driven (AMELLER, 2009)

Na MDA são descritos três tipos de abstrações e ilustrados através da Figura 16 que

apresenta o sentido dos três níveis de abstração.

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

Estes três tipos de modelos referem-se aos estágios de desenvolvimento de software

(AMELLER, 2009):

Compute Independent Model - CIM: A CIM é uma visão do sistema do ponto de vista

independente da computação. CIM é muitas vezes chamado de modelo de negócio. Um

exemplo de CIM poderia ser o modelo que representa o processo para entregar um pacote

(simplificado):

1. Um funcionário leva o pacote a partir de casa do cliente e o leva para o escritório mais

próximo.

2. O pacote é transportado para o escritório mais próximo do destinatário.

3. Um funcionário leva o pacote para o destinatário.

43

Platform Independent Model - PIM: Um modelo que não contém detalhes que têm

significado apenas dentro de uma plataforma específica. Este tipo de modelo não tem

relação com qualquer tecnologia de implementação. Na sequência do exemplo anterior, o

modelo de PIM irá conter apenas as partes que são suposto ser feito pelo computador

(simplificado):

1. O sistema atribui um identificador para o pacote.

2. O sistema calcula a rota mais econômica para entregar o pacote.

Platform Specific Model - PSM: Um modelo que contém detalhes que têm significado

apenas dentro de uma plataforma específica. Este tipo de modelo tem normalmente uma

relação com algumas tecnologias de implementação. Em comparação com o exemplo

anterior, neste caso, o modelo de PSM irá conter as mesmas peças do processo, mas

especificando concretamente uma tecnologia (simplificado):

1. O sistema usa um gatilho de banco de dados Oracle para gerar um identificador para

cada pacote.

2. O sistema calcula a rota mais econômica para entregar o pacote utilizar os serviços

web das companhias aéreas contratadas.

3.4 METODOLOGIA

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

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

da Figura 17:

Figura 17.Fluxo de Transformação Geral

As caixas (M2M e M2T) são transformações. As caixas marcadas com a sigla M2M

refere-se à transformação de Modelo para Modelo. Já a caixa com a sigla M2T, também

conhecida com M2C, refere-se à transformação Modelo para Texto.

44

As transformações entre os modelos (M2M) são definidos como a transformação de

idiomas. As transformações de um modelo para um arquivo de texto - M2T são normalmente

feitas por algumas linguagens de script ou baseadas em modelo, alguns exemplos dessas

linguagens: Velocity (Apache Velocity), MOFScript (MOFScript), JET (POPMA, 2004).

Faz parte do escopo desse trabalho utilizar o processo de transformação M2T, com o

objetivo de gerar artefatos textuais a partir de modelos de domínios projetados. Neste

documento, daqui por diante será utilizado o termo M2C para identificar o processo de

transformação modelo para texto.

3.5 UNIFIED MODELING LANGUAGE - UML

Segundo (WATSON, 2007), a história da modelagem gráfica de software pode ser

dividida em dois períodos: antes da UML e depois da UML. Antes da criação dessa

linguagem, o cenário da modelagem de software era repleto de notações incompatíveis, o que

levava ao enfraquecimento do mercado de ferramentas, deixando os modelos fora do processo

de desenvolvimento de software. No entanto, após a especificação da UML e sua grande

adoção no processo de produção de sistema, as incompatibilidades de notação até então

existentes foram praticamente eliminadas.

A UML, criada em 1996, hoje na sua versão 2.x (OMG, 2007) é composta por 13

diagramas que definem a notação e semântica para os seguintes domínios:

A interação do usuário ou modelo de casos de uso descreve os limites e interações entre o

sistema e seus usuários, correspondendo a um modelo de requisitos, em alguns aspectos;

O modelo de interação ou comunicação descreve como objetos do sistema interagem entre

si;

O modelo dinâmico ou de estados descreve os estados ou condições que as classes

possuem ao longo do tempo. Gráficos de atividades descrevem o fluxo de trabalho que o

sistema irá seguir;

O modelo lógico ou de classes descreve as classes e objetos que fazem parte do sistema;

O modelo físico de componentes descreve o software (e algumas vezes componentes de

hardware) que fazem parte do sistema;

O modelo físico de implantação descreve a arquitetura física e a implantação de elementos

na arquitetura de hardware.

45

3.6 METAMODELAGEM

A UML foi desenvolvida seguindo uma abordagem de metamodelagem que adapta

técnicas de especificação formal. Além disso, a UML segue um padrão arquitetural de quatro

camadas (ver Figura 18) onde a camada M3 corresponde ao metamodelo1 MetaObject

Facility - MOF (OMG, 2007), a camada M2 é a própria UML, a camada M1 são os modelos

utilizados no processo de produção de software e a camada M0 são os objetos em si.

Figura 18. Quatro Camadas da Arquitetura do Metamodelo (LIDDLE, 2010)

A Figura 18 descreve as camadas:

M3: A camada que contém meta-meta-metadata (meta-metamodelo) que descrevem as

propriedades que meta-metadados podem exibir. Se houvesse uma camada M4 seria da

mesma forma como M3, porque M3 é auto-descritivo. Meta Object Facility (MOF) é um

padrão do OMG. MOF é uma linguagem para descrever metamodelos. Para se ter uma

idéia aproximada do que é MOF, nós poderiamos pensar em UML limitado a diagramas

de classe. O MOF foi utilizado também na própria definição do metamodelo da UML.

M2: A camada que contém os meta-metadados (metamodelo) que descrevem as

propriedades que os metadados podem apresentar (por exemplo, tais elementos UML

como classe, a Operação atributo). Aqui encontramos metamodelos, uma descrição ou

definição de uma linguagem bem definida na forma de um modelo.

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

elementos de um modelo.

46

M1: A camada que contém os metadados do aplicativo (por exemplo, de acordo com a

Figura 18 define que a classe Book é caracterizada pelo atributo title).

M0: A camada que contém os dados de aplicação (por exemplo, o casos que preenchem

um sistema orientado a objetos em tempo de execução ou linhas de tabelas relacionais de

banco de dados. Na Figura 18 essa instância é representada pelo livro intitulado:

Executable UML: A Fundation for Model-Driven Architectures).

3.7 MECANISMOS DE EXTENSÃO DA UML

Os mecanismos de extensão da UML existem desde suas versões iniciais, porém

somente a partir da sua segunda versão é que a noção de perfil foi definida para proporcionar

a extensão da linguagem de forma mais estruturada e precisa (OBJECT MANAGEMENT

GROUP, 2007). Em Sampaio (2009) foi utilizado o mecanismo de perfis UML para gerar

uma linguagem específica de domínio, em que o domínio pretendido foi o de aplicações

geográficas.

Nas subseções seguintes são explicados os mecanismos de extensão da UML

(estereótipos, tagged values e constraints), assim como perfis UML.

Estereótipos

Estereótipo é um mecanismo de extensão da UML que define como uma metaclasse

existente pode ser estendida e habilita o uso de uma terminologia específica para um domínio

ou plataforma específicos em lugar da, ou em adição à, terminologia usada para a metaclasse

estendida (OBJECT MANAGEMENT GROUP, 2007).

Eriksson et al. (2004), assim como OBJECT MANAGEMENT GROUP (2007),

caracterizam estereótipos como um dos principais veículos para a customização da UML. Um

estereótipo pode estender uma metaclasse ou outro estereótipo, permitindo assim, que sejam

criados novos elementos de modelagem. Não há limite no número de vezes que uma

metaclasse pode ser estendida por um estereótipo, nem há regras que limitem o número de

classes que podem aplicar um estereótipo.

Um estereótipo é definido por um nome e pelo conjunto de elementos do metamodelo

com os quais ele pode ser conectado. Graficamente, eles são definidos em caixas

estereotipadas como: <<stereotype>> (FUENTES; VALLECILLO, 2004). Os elementos do

47

metamodelo são indicados por classes estereotipadas como <<metaclass>>. Eles podem

também mudar a aparência visual dos elementos do modelo estendidos usando ícones gráficos

(OBJECT MANAGEMENT GROUP, 2007).

Tagged Values

Um tagged value é um meta-atributo adicional que é vinculado a uma metaclasse do

metamodelo estendido por um perfil. Eles adicionam informações aos elementos do modelo,

as quais podem ser utilizadas por seres humanos e por máquinas, podendo assim ser expressos

por alguma linguagem natural ou computacional. Seres humanos podem usar esses meta-

atributos para adicionar informações administrativas sobre o modelo como, por exemplo, o

autor do modelo e a data e hora da última modificação. Máquinas podem usá-los, por

exemplo, para a geração de código (ERIKSSON et al., 2004). Tagged values têm um nome e

um tipo, e são associados a um estereótipo específico (OBJECT MANAGEMENT GROUP,

2007).

Constraints

Constraints são restrições em forma de regras ou definição de condições que são

aplicadas a elementos do modelo. A todo elemento da UML está associada alguma semântica.

Isso quer dizer que cada elemento gráfico dessa linguagem possui um significado bem

definido que, uma vez entendido, fica implícito na utilização do elemento em algum

diagrama. As restrições permitem estender ou alterar a semântica natural de um elemento

gráfico (BEZERRA, 2002).

As restrições podem ser associadas aos estereótipos, impondo, assim, restrições aos

elementos do metamodelo correspondente. As regras definidas para um estereótipo se aplicam

a cada elemento do modelo para os quais o estereótipo é aplicado e cada elemento do modelo

para os quais o estereótipo precisa aderir às regras (ALHIR, 2003).

Constraints podem ser expressas usando uma linguagem natural, ou a Object

Constraint Language (OCL), que é adotada pelo OMG para expressar restrições e

propriedades de elementos do modelo (FUENTES; VALLECILLO, 2004).

Algumas restrições foram escritas, em OCL, nos metamodelos Arquétipos – AM pela

Fundação openEHR, mas não será objeto de estudo desse trabalho.

48

3.8 PERFIS UML

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

provê mecanismos de adaptação a domínios específicos chamados de perfis UML. Então, um

perfil UML é um conjunto dos mecanismos de extensão da UML (estereótipos, tagged values

e constraints), agrupados em um pacote UML estereotipado como <<profile>>. Como

mencionado anteriormente, esses mecanismos permitem a extensão da sintaxe e semântica

dos elementos da UML, porém sem violar a semântica original desses elementos.

A intenção é fornecer um mecanismo direto para adaptar um metamodelo existente

com construtores que são específicos para um domínio, plataforma ou método em particular.

Tais adaptações são agrupadas em um perfil (OMG, 2007).

O pacote de perfis contém mecanismos que permitem metaclasses de metamodelos

existentes serem estendidas para adaptá-las a diferentes propósitos. Isso inclui a habilidade

para customizar a UML a diferentes plataformas ou domínios específicos como, por exemplo,

aplicações em tempo-real ou modelagem de processos de negócios. O mecanismo de perfis é

consistente com o MOF (OMG, 2007). A Figura 19 apresenta a tela de preenchimento em um

modelo da tagged value definida em um perfil UML. Esse exemplo demonstra o

preenchimento da tagged value required com o valor true referente ao atributo value.

Figura 19.Exemplo de preenchimento de tagged value no modelo

49

Com o objetivo de manter uma sincronia com o desenvolvimento e evolução dos

metamodelos arquétipos produzidos pela comunidade que participa da Fundação openEHR,

esse trabalho adotou o uso de perfis UML para possibilitar a extensão da sintaxe e semântica

da UML e prover mecanismos adaptativos a domínios específicos (Cuidado a Saúde),

possibilitando assim o desenvolvimento baseado em modelos, através da realização das

transformações de modelo para texto.

3.9 TRANSFORMAÇÕES DE MODELOS

Transformação de modelos é o processo de converter um modelo em outro modelo do

mesmo sistema (OMG, 2003). A transformação utiliza os mapeamentos, mas também contém

outras informações como, por exemplo, a condição no modelo fonte para disparar a

transformação, a linguagem do modelo-alvo, a linguagem-fonte, etc. (KLEPPE; WARMER;

BAST, 2003).

Um mapeamento é especificado usando alguma linguagem para descrever uma

transformação de um modelo em outro. A descrição pode ser em linguagem natural ou em

uma linguagem de transformação de modelos. Uma qualidade desejável de uma linguagem

de transformação é a portabilidade. Isso habilita o uso de um mapeamento com diferentes

ferramentas (OMG, 2003).

Linguagem de Transformação

Sendall e Kozaczynski (2003) descrevem algumas características que são desejáveis

para essas linguagens de transformação de modelos. A linguagem deve ser implementável de

maneira eficiente, ser executável e deve oferecer editores gráficos, os quais proveem uma

maneira mais intuitiva quando comparados com os textuais.

Em geral, essas linguagens de transformação de modelos podem ser imperativas,

declarativas ou híbridas. As linguagens imperativas são aquelas que descrevem como atingir

determinado objetivo através de uma sequência de ações que devem ser executadas pelo

computador. Exemplos são: Cobol, Fortran, C, Pascal, Java, etc.. As linguagens declarativas

são aquelas que descrevem o objetivo que deve ser atingido pelo computador, deixando para o

computador escolher a melhor maneira de realizá-lo. Exemplos desse tipo de linguagem são:

50

Lisp, Haskell, SQL, etc.. Já as linguagens híbridas são aquelas combinam características das

duas anteriores.

Em 2004, a OMG lançou uma requisição de propostas (Object Management Group,

2004) com o objetivo de padronizar a transformação de modelos para representação textual,

onde foi solicitada a criação de uma nova linguagem ou a extensão de uma linguagem já

existente para transformação de modelos em texto. Estava entre os principais requisitos dessa

linguagem de transformação a compatibilidade com o metamodelo MOF 2.0, funções de

manipulação de strings e o suporte aos mecanismos de extensão da UML.

A linguagem MOFScript atende a todos os requisitos básicos da OMG e adiciona

outros requisitos avaliados como importantes para uma linguagem desse tipo, tais como

suporte a mecanismos de controle de fluxo, interação com serviços do sistema operacional

(e.g. consultar a data e hora do sistema), e um equilíbrio entre facilidade de uso e poder de

expressividade dos domínios. Também é fornecido um editor de transformações na forma de

um plug-in para a IDE Eclipse, chamado MOFScript tool (OLDEVIK, 2006), que tem um

editor léxico com coloração de sintaxe e assistente de digitação de código, visualizador

estrutural de regras, gerenciador de configurações e visualizador de problemas. MOFScript já

provou ser adequada para a tarefa de transformação de modelos em UML para texto (M2T)

em outras situações como no trabalho de Porres et al. (2007) onde sistemas de apoio à decisão

foram gerados a partir de diagramas de Máquina de Estados. Um conjunto completo de

instruções de uso da ferramenta e da linguagem pode ser encontrado em seu manual do

usuário (OLDEVIK, 2009).

Além disso, a adoção da linguagem MOFScript neste trabalho foi baseada na utilização de

(CATALINA et al, 2008) conforme resultado da revisão sistemática apresentado no capitulo

5.

Papyrus UML2 Modeler

A ferramenta CASE Papyrus UML2 Modeler (PAPYRUS UML, 2011) mostrou-se

uma opção interessante por ser uma ferramenta de código aberto (opensource). Ela se basea

no ambiente Eclipse e está sob a licença EPL (Eclipse Public License). A Figura 20 ilustra a

interface principal da ferramenta.

51

Figura 20.Interface da ferramenta UML Papyrus

Entre outros recursos interessantes para modelagem de sistemas utilizando o padrão

UML2, a ferramenta dá suporte à criação de perfis UML, que é um dos objetivos de estudo

desse trabalho. O perfil é criado selecionando-se os estereótipos a serem utilizados e as

metaclasses que serão estendidas por esses estereótipos. Além disso, as programas

transformadores M2C escritos em MOFScript podem ser editados e executados no Papyrus,

tornando assim, uma ferramenta única para realização da modelagem de domínio, criação do

perfil UML, confecção dos programas transformadores e execução das transformações.

3.10 SÍNTESE DO CAPÍTULO

De maneira geral, este capítulo apresentou as definições referentes ao paradigma de

desenvolvimento orientado a modelos. Inicialmente foram apresentados conceitos sobre o

próprio modelo.

A seção 3.1 fundamentou conceitualmente e apresentou as principais características de

MDD. Adicionalmente foram apresentadas as principais vantagens e/ou desvantagens da

adoção de MDD e os pontos de vistas sobre sua adoção.

52

Nas seções 3.2 e 3.3, foram apresentadas a linha do tempo sobre o paradigma de

desenvolvimento orientado a modelos e suas principais iniciativas apresentando as

relevantes características.

Nas seções 3.4, 3.5 e 3.6, as metodologias, definição sobre UML e a conceituação sobre

metamodelagem são apresentadas. Na seção 3.4 foi apresentada a metodologia usada com

MDD, detalhando os processos de transformações, tais como: M2M ou M2C. Na seção 3.5

foi realizada uma fundamentação teórica sobre UML, com o objetivo de facilitar ainda mais

o entendimento das próximas seções. Na seção 3.6 foi conceituada a metamodelagem, suas

principais características e suas camadas de abstrações.

Nas seções 3.7 e 3.8, os conceitos e exemplos sobre os mecanismos de extensão e perfil

UML são apresentados.

Por fim, a seção 3.9 que apresentou a definição sobre as transformações de modelos, as

características das linguagens de transformação e a ferramenta Papyrus que possibilita a

criação de perfil UML, programas transformadores e a própria execução da geração de

artefatos automáticos.

4 TECNOLOGIAS WEB

Este capítulo apresenta as tecnologias WEB utilizadas no desenvolvimento desse

trabalho, detalhando as definições e históricos sobre Jquery Mobile, HTML, CSS, JSON e o

Framework PhoneGap.

4.1 JQUERY MOBILE

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

utilizado para o desenvolvimento WEB e é otimizado para interação por toque (Touch). Esse

framework é um fácil caminho para a confecção de aplicações web que são acessíveis em

todos os dispositivos móveis populares como: smartphones e tablets.

A confecção desse framework tem o objetivo de fornecer mecanismos que

possibilitam a criação de sistemas unificados de interface do usuário (UI), baseados em

Jquery , JQuery UI, HTML5 e CSS3. Esses sistemas não apenas adicionam funcionalidades

53

para criação do layout (listas, painéis, layers etc.), mas também fornecem um rico conjunto de

controles e widgets (entre outros: sliders, toggles, abas) (SILVA, 2012).

O framework efetua o princípio “fazer mais escrevendo menos”, que dita o

desenvolvimento da biblioteca jQuery, com a finalidade de criar aplicações únicas para todos

os dispositivos móveis e sistemas operacionais.

Em relação a interoperabilidade entre navegadores e plataformas móveis, esse

framework foi desenvolvido baseado em um diretriz que estabelece que se trata de uma

ferramenta capaz de implementar aplicações que sejam suportadas pela grande maioria dos

modernos navegadores desktop e das plataformas para smartphones, e tablets.

Histórico

Em 16 de outubro de 2010, John Resig (criador do Jquery) anunciou o lançamento da

primeira versão alfa do framework, o jQuery Mobile 1.0 alfa 1, com as seguintes

funcionalidades: 1) tema e layout; 2) topo e rodapé (fixos e prsistentes); 3) controles de

formulário; 4) caixas de diálogo; 5) listagens; 6) eventos e transições.

Em 2011, foram lançadas várias versões candidatas a lançamento do framework,

contendo as seguintes novas características: 1) suportes para Blackbarry 5, Mini Opera e

séries 60 do smartphone Nokia; 2) Refinamentos, otimizações e melhoria de desempenho; 3)

correções de bugs;

Para utilizar o Framework JQuery Mobile no ambiente de desenvolvimento não é

requerido a execução de instalações prévias. É necessário apenas criar, na marcação HTML5

do documento, os seguintes links: 1) um link para a biblioteca JQuery; 2) um outro link para a

biblioteca desse framework; 3) Um link para a folha de estilo (CSS3) padrão do framework.

Essas criações permitem a maximização do uso das funcionalidades e principalmente da

simplicidade de implementar para quase todos os dispositivos móveis existentes no mercado,

independentes de marcas, modelos e plataformas ou sistemas operacionais.

A Figura 21 apresenta um modelo mínimo para desenvolver uma página para

dispositivo móvel.

54

Figura 21.Exemplo de HTML com Jquery Mobile

4.2 HYPERTEXT MARKUP LANGUAGE – HTML

É uma linguagem de marcação (linguagem de marcação de hipertexto) global para

estruturação e apresentação de conteúdo para WEB criada e mantida pelo consórcio W3C. A

HTML foi concebida essencialmente como uma linguagem para descrever semanticamente

documentos científicos, embora a sua concepção geral e adaptações ao longo dos anos

permitiu-lhe ser usada para descrever uma série de outros tipos de documentos (HISTORY

HTML, 2012).

O W3C descreve que HTML é baseado no conceito de Hipertexto. Os Hipertextos são

conjuntos de elementos ligados por conexões. Estes elementos podem ser, entre outros:

palavras, imagens, vídeos, áudio, documentos. Estes elementos ligados criam uma grande

rede de informação. A conexão feita em um hipertexto é algo imprevisto que permite a

comunicação de dados, organizando conhecimentos e guardando informações relacionadas.

Um relevante propósito do HTML é ser uma linguagem universalmente entendida por

diversos meios de acesso, isto é, possibilitar distribuição da informação de maneira global.

Histórico

A linha do tempo do HTML é apresentada nesta seção. A Figura 22 apresenta a linha

do tempo do HTML. Neste trabalho utilizamos o HTML5

55

Figura 22.Linha do tempo HTML

Na década de 1990, o HTML ganhou popularidade quando o navegador Mosaic

ganhou força. Com isso, fabricantes de navegadores e desenvolvedores usaram o HTML

como base para a implementação de suas aplicações.

Em 1996, o W3C publicou a versão HTML 2 que corrigia alguns erros e

No ano de 1997, O W3C recomendou a versão 3.2 do HTML, essa versão continha as

seguintes novas características, entre outras: 1) Fontes, tag: <font>; 2) Tabelas, tag: <table>;

3) applets; 4) superscripts e subscripts.

Em 1998, o W3C recomendou a versão HTML 4.0, onde a sua mais nova importante

característica foi à adoção de folhas de estilo (CSS).

No ano de 2000, o W3C lançou o XHTML 1.0 como uma reformulação do HTML

4.0.1 no formato XML.

Em paralelo às evoluções do XHTML, a partir de 2004, um grupo chamado Web

HyperText Application Tecnology Working Group (WHATWG) foi fundado por

desenvolvedores de empresas como Mozilla, Apple e Opera que trabalhavam em uma versão

do HTML que trazia mais leveza e flexibilidade para a produção de aplicações WEB.

Em 2006, foi anunciada uma parceria entre o grupo WHATWG e a equipe de

desenvolvimento do XHTML visando o desenvolvimento do HTML versão 5 (HTML5).

Contudo o XHTML continuou sendo desenvolvido até o ano de 2009, onde teve o

desenvolvimento parado.

Em 2008, o W3C anunciou a primeira especificação do HTML5, que contem as

seguintes características: 1) Funções para embutir som, vídeos e gráficos; 2) armazenamento

de dados no lado cliente; 3)documentos interativos. Com essas novas característica poderá

ser eliminada a dependência de plug-ins para manipulação de multimídia em navegadores, por

56

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

na linguagem HTML5.

Figura 23.Exemplo de Código HTML5

4.3 CASCADING STYLE SHEETS - CSS

Conforme definição do consórcio W3C, Cascading Style Sheet, ou em português:

Folhas de Estilo em Cascata são: “Um mecanismo simples para adicionar estilos (por

exemplo: fontes, cores, espaçamentos) aos documentos WEB”.

Conforme definido em Silva (2007), o CSS formata a informação entregue pelo

HTML ou XML. Essa informação pode ser, entre outras: imagem, texto, vídeo, áudio ou

qualquer outro elemento criado. Essa formatação na maioria das vezes é visual, mas não

obrigatoriamente.

As CSS têm por finalidade devolver à marcação HTML/XML o propósito inicial da

linguagem. Isto significa que a HTML foi criada para ser uma linguagem exclusivamente de

marcação e estruturação de conteúdos. A responsabilidade do HTML é fornecer informações

a qualquer dispositivo (por exemplo: navegadores e dispositivos móveis) que sejam capazes

de interpretar um documento escrito em uma linguagem de marcação. É competência,

responsabilidade, do CSS as funcionalidades de apresentação dos elementos de um

documento HTML/XML. O CSS têm a finalidade de possibilitar a estilização dos elementos,

57

configurando, por exemplo: 1) definição de cores de fontes; 2) definição de tamanho de

fontes.

A Figura 24 demonstra a definição padrão e um exemplo básico do CSS

Figura 24. Definição e Exemplo de CSS

O seletor representa uma estrutura que é usada como uma condição para determinar

quais elementos de um grupo de elementos será formatada.

A propriedade é a característica que se deseja modificar no elemento (exemplos: color,

width) ou conjunto de elementos. O valor representa o valor referente a esta característica. Se

modificar a cor do texto, o valor é um Hexadecimal, RGBA ou até mesmo o nome da cor por

extenso (exemplo: color:red).

O exemplo ilustrado no lado direito da Figura 24 representa o código CSS que define

para o seletor corpo: 1) fonte padrão Arial, caso não exista substitui por Verdana; 2) define o

valor da propriedade cor de fundo do corpo da página para vermelha; 3) define os valores para

a propriedade margem.

Nesta pesquisa utilizamos o CSS3 na solução proposta com o objetivo de estilizar

elementos dos formulários gerados.

Histórico

A linha do tempo do CSS é apresentada nesta seção. A Figura 25 apresenta a linha do

tempo referente à evolução do CSS.

Figura 25.Linha do Tempo CSS (W3C)

58

Em 1996, o consórcio W3C lançou a primeira edição do CSS, contemplando as

seguintes características: 1) Introdução da 'id' única para cada propriedade e introdução de

classes para as propriedades que devem ter os mesmos atributos estilos eram as coisas mais

importantes existiam; 2) Margem, borda, espaçamento e posicionamento também alimentado

por folhas de estilo, embora pudesse ser feito usando os elementos HTM; 3)Espaçamento

entre linhas e linhas de tabelas também são facilmente definidos usando as folhas de estilo.

Em 1998, o consórcio W3C lançou a edição (nível) 2.0 do CSS, contendo, entre

outras, as seguintes características: 1) Controlar o posicionamento visual do conteúdo da

página através de identação de texto, margens, floats, e posicionamentos absoluto e relativo;

2) Prover efeitos visuais, como sombras; 3)Eliminar imagens e espaços em branco usados

para o posicionamento.

Em 2012, a edição 3.0 do CSS que se encontra em desenvolvimento, busca

implementar, entre outras, as seguintes funcionalidades: 1) Manipulação de opacidade; 2)

Texto de estouro de consultas; 3) Meios de comunicação; 4) Gradiente em textos e elementos;

5) bordas arredondadas; 6) sombras em texto e elementos; 7) controle de rotação.

4.4 JAVASCRIPT OBJECT NOTATION - JSON

JavaScript Object Notation – É um formato de troca de dados simples e leve. Esse

formato é fácil para: 1) os seres humanos lerem e escreverem; 2) máquinas para analisarem e

gerarem. Esse formato, baseia-se em um subconjunto da linguagem de programação

JavaScript, Standard ECMA-262 3 ª Edição - Dezembro de 1999. JSON é um formato de

texto que é completamente independente de linguagem, mas usa convenções que são

familiares aos desenvolvedores da família C de linguagens, incluindo: C, C + +, C #, Java,

JavaScript, Python, e muitos outros. JSON é construído baseado nas estruturas de dados

universais:

1. Uma coleção de pares: nome / valor. Em várias linguagens, Esta coleção é percebida

como um objeto de: registro, dicionário, struct, tabela hash, a lista com chave e etc.

2. Uma lista ordenada de valores. Na maioria das linguagens, isto é percebido como uma

matriz, vetor e etc.

A Figura 26 apresenta do lado esquerdo o modelo de um objeto JSON e no lado direito

um exemplo de objeto preenchido no formato JSON:

59

Figura 26.Modelo e Exemplo de JSON

Um objeto é um conjunto sem ordenação dos pares: nome / valor. Um objeto começa

com {(chave esquerda) e termina com} (chave direita). Cada nome (exemplo:string) é seguido

por: (dois pontos) e os pares nome / valor são separados por, (vírgula). O lado direito da

Figura 26 apresenta um exemplo do objeto preenchimento no formato JSON.

4.5 FRAMEWORK PHONEGAP

O PhoneGap é um framework para o desenvolvimento de sistemas para dispositivos

móveis que permite confeccionar aplicativos híbridos (web e móvel), onde o desenvolvimento

é feito em JavaScript, HTML5 e CSS3, e através da sua API, é possível ter acesso aos

recursos nativos do dispositivo além de possibilitar facilmente as criações de plugins

(PHONEGAP FRAMEWORK, 2012).

A adoção do framework PhoneGap (FPG) elimina a necessidade de aprendizado das

diversas linguagens utilizadas no desenvolvimento de aplicativos para plataformas móveis.

Com esse framework um sistema é desenvolvido utilizando JavaScript, HTML, CSS3 e

JQuery Mobile; e compilado para o sistema operacional da plataforma móvel destino como se

fosse um sistema nativo.

Com o FPG a construção das aplicações móveis é baseada em padrões WEB, baseada

em tecnologia WEB como o HTML5 e javascript. Inclusive, o FPG permite ao desenvolvedor

utilizar características nativas dos dispositivos móveis e possibilita implantar um mesmo

sistema em múltiplas plataformas móveis. A Figura 28 apresenta a lista das principais

características dos dispositivos móveis suportadas pelo FPG versus os respectivos sistemas

operacionais das plataformas móveis homologadas.

60

O FPG é uma implementação open source de padrões aberto. Ela será sempre livre e

de código aberto sob a Licença Apache, Versão 2.0. Isso significa que os desenvolvedores,

instituições educacionais e/ou empresas podem usar PhoneGap para aplicações móveis que

estão livres, código aberto, comercial, ou qualquer combinação destes.

Além disso, o FPG possui uma crescente e ativa comunidade que vem evoluindo as

documentações, criando e publicando aplicativos e plugins novos, utilizando blogs e faqs para

troca de informações sobre essa API e principalmente evoluindo as características desse

framework.

A Figura 27 apresenta as plataformas móveis homologadas, suportadas, para rodar

aplicações construídas com o FPG. Essa grande diversidade de plataformas suportadas foi um

fator decisivo na escolha desse framework na realização desse trabalho.

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

61

Figura 28.Características suportadas pelo FPG x Sistemas Operacionais dos

dispositivos móveis (PHONEGAP FRAMEWORK, 2012)

Histórico

A Figura 29 apresenta anualmente a evolução histórica do framework PhoneGap,

destacando ano a ano as relevantes ocorrências no histórico do componente, partindo do ano

de 2008, ano de surgimento do framework e finalizando no fim do primeiro semestre de 2012.

Em 2008 o FPG foi criado inicialmente pela empresa Nitobi Software para participar

do evento iPhoneDevCamp em São Francisco nos EUA em agosto desse ano; No último

trimestre do ano de 2008 foi adicionado ao FPG o suporte as plataformas móveis Android e

BlackBerry.

62

Em 2009: Em abril de 2009 o FPG foi vencedor do Web 2.0 Expo LaunchPad e ainda

no primeiro semestre foram lançadas duas novas versões dessa API, as versões: 0.6.0 e a

0.7.2 para Android e IPhone. No início do segundo semestre foram adicionados o suporte as

plataformas:Windows Mobile e Nokia WRT. No último trimestre do ano a versão 0.8 foi

aceita pela Apply para AppStore, a infoWorld elegeu o FPG como “top emerging enterprise

technology” na categoria "cross-platform mobile app development" e no final desse ano foi

adicionado o suporte para Palm.

Em 2010: A plataforma Symbian adicionou o FPG.

Em 2011: Ocorreu a publicação da versão candidata 1.0 do FPG. Em outubro desse

ano a empresa Adobe anunciou a aquisição da empresa Nitobi Software fabricante da FPG. O

código do FPG foi contribuído para a Apache Software Foundation visando iniciar um novo

projeto chamado Apache Cordova. Neste trabalho, iremos utilizar a sigla FPG para

representar o Apache Cordova ou framework PhoneGap com o objetivo de uniformizar o

nome do framework e facilitar as suas citações nas próximas seções desse documento

(APACHE CORDOVA, 2012).

Em 2012: Em janeiro de 2012 foi publicada a versão 1.4 contendo várias correções e

novidades para as diversas plataformas móveis. A última versão baixada e utilizada no

desenvolvimento deste trabalho foi a versão 1.9.

Figura 29.Histórico anual do FPG

2008

2009

2010

2011

2012

Inicio

do FPG

O FPG foi

premiado

Integração

Symbian

- A adobe Adquiriu o FPG

- Mudou nome para Apache

Cordova

Lançamento

das versões 1.4

até a 1.9

63

O Construtor PhoneGap é um serviço que possibilita ao desenvolvedor compilar na

internet (cloud) um aplicativo (integrado ao PhoneGap Framework), gerando assim

compatibilidade desse aplicativo com várias plataformas móveis, entre outras: Android,

Bada, Apple iOS e Windows Phone 7. O Processo ocorre conforme os seguintes passos: 1)

Fazer upload da aplicação integrada ao FPG e escrita em javascript, HTML5 e CSS3 para o

Buid PhoneGap; 2) submeter ao serviço Buid PhoneGap; 3) Receber o aplicativo compatível

com a plataforma desejada. A Figura 30 apresenta uma visão geral do funcionamento do

Build PhoneGap (Build PhoneGap, 2012).

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

4.6 SÍNTESE DO CAPÍTULO

De maneira geral, este capítulo apresentou as definições referentes às tecnologias WEB

adotadas no corrente trabalho. Além disso, foram apresentadas justificativas sobre adoção

dessas tecnologias.

A seção 4.1 apresentou as principais características sobr JQuery Mobile e sua respectiva

linha do tempo.

As seções 4.2 e 4.3, foram apresentadas as definições, exemplos e linha do tempo sobre,

respectivamente, HTML e CSS.

A seção 4.4 apresentou o conceito e as principais características sobre JSON. Além

disso, foi apresentada a linha do tempo sobre JSON e ilustrado exemplo do modelo JSON.

64

Por fim, a seção 4.5 apresentou as principais características sobre o framework

PhoneGap e sua respectiva linha do tempo. As tecnologias apresentadas nas seções 4.1, 4.2,

4.3 e 4.4 são utilizadas diretamente pela arquitetura do framework PhoneGap. Além disso

essa seção justificou a adoção do framework PhoneGap no trabalho corrente.

65

5. TRABALHOS RELACIONADOS

Este capítulo descreve uma revisão bibliográfica - RB para o levantamento e

mapeamento do estado da arte na abordagem de desenvolvimento orientado a modelos

utilizando modelos clínicos - arquétipos.

Neste trabalho, foi realizada uma sistematizada revisão bibliográfica baseada em

algumas das principais atividades de uma revisão sistemática, visando obter evidências de

trabalhos relacionados a essa pesquisa que utilizaram uma abordagem de desenvolvimento

orientada a modelos integrados aos arquétipos. Assim, a seção 5.1 introduz o conceito de

revisão sistemática, aqui abreviado como RS. A seção 5.2 descreve o método da RS usado

neste trabalho e o motivo do seu uso; nas subseções é apresentado como foi planejada e

executada a pesquisa, como foi feita a seleção dos dados analisados, e como foi feito a análise

em si.

5.1 INTRODUÇÃO

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

muita atenção ultimamente em Engenharia de Software - SE (KITCHENHAM, 2007) e é

inspirado em pesquisas médicas. Resumidamente, uma revisão sistemática (RS) passa por

relatórios primários existentes, revê-los em profundidade e descreve a sua metodologia e

resultados.

Comparado com revisões de literatura comuns em qualquer projeto de pesquisa, um

RS tem várias vantagens: a metodologia bem definida reduz viés, uma ampla gama de

situações e contextos pode permitir que mais conclusões gerais e uso de meta-análise

estatística pode detectar mais estudos individuais isoladamente (KITCHENHAM, 2007). No

entanto, RSs também têm várias desvantagens, a principal é o considerável esforço

necessário. As RSs em engenharia de software concentraram-se em estudos quantitativos e

empírico, mas um grande conjunto de métodos para a síntese de resultados de pesquisas

qualitativas existe conforme colocado em (DIXON-WOODS et al., 2005).

Um planejamento antecipado e claro de quais atividades serão executadas e quais

endereçamentos serão levados em consideração no momento de tomada de decisões, pode ser

bastante benéfico na execução de uma RB. Apesar da não obrigatoriedade da criação do

protocolo (nome dado a esse planejamento), os autores que o fizeram incentivam o seu uso

66

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

mapeamento.

5.2 MÉTODO E PROTOCOLO DE BUSCA

Este trabalho apresenta um estudo de revisão sistemática realizada a fim de verificar o

estado da arte sobre o desenvolvimento orientado a modelos integrado aos arquétipos clínicos

através de análise de evidências, como também identificação de aglutinação e ausências de

pesquisas relacionadas com temas da área. O objetivo foi evidenciar, através de informações

confiáveis, como a academia vem abordando o assunto.

O protocolo criado para esta pesquisa pode ser visualizado através da Figura 31. Ele

inclui a definição das questões a serem respondidas pela pesquisa, a estratégia de busca, a

definição das fontes de pesquisa, a seleção dos estudos, a classificação dos estudos, além das

conclusões da pesquisa. Cada uma das etapas do protocolo será explicada nas sessões

seguintes, que detalham a condução do mesmo.

Figura 31.Protocolo Definido para a Pesquisa

5.2.1 DEFINIÇÃO DAS QUESTÕES

A questão principal que orienta este estudo de mapeamento e reflete o nosso objetivo

é: RQ1. Qual a evidência sobre a adoção do desenvolvimento orientado a modelos integrado

aos arquétipos clínicos?

Definição das Questões

Realização da Pesquisa

Definição das Fontes de

Dados

Seleção dos Estudos

Classificações dos Estudos

Publicação das Conclusões

67

5.2.2 REALIZAÇÃO DA PESQUISA

Os termos de pesquisa adotados neste estudo foram definidos utilizando a abordagem

descrita por (KITCHENHAM, 2007), que descreve cinco etapas: 1) termos devem derivar das

perguntas; 2) identificação de grafias alternativas e sinônimas, 3) a constatação de palavra-

chave, 4) utilização de OR; 5) e definição de operadores de fundir as seqüências de pesquisa.

As strings de busca da pesquisa estão disponíveis na Tabela 3.

Tabela 3. Strings de Busca

"Model-driven" AND

("clinical archetype" or "openehr archetype")

5.2.3 DEFINIÇÃO DAS FONTES DE PESQUISAS

Foram definidos quais engenhos de busca deveriam ser utilizados nas pesquisas. Os

engenhos de busca escolhidos foram os considerados como as principais bases de

armazenamento de publicações na área de engenharia de software e informática médica.

Outro critério de escolha dos engenhos de busca foi a possibilidade de utilização de

seus recursos via internet, e a capacidade de leitura dos trabalhos de forma gratuita para

alunos da Universidade de Pernambuco através do portal da CAPES. As três fontes de

pesquisas escolhidas podem ser visualizadas na Tabela 4. Adicionalmente, foi realizada uma

pesquisa manual, relacionada ao objetivo do estudo, no Congresso Brasileiro de Informática

de Saúde – CBIS. Os dois níveis de pesquisa (manual e automático) foram processados

juntos. A Figura 32 ilustra o fluxo do processo de pesquisa executado.

Tabela 4. Fontes de Pesquisa

Engenho de Busca Nº de Obras Encontradas

Busca Manual (CBIS) 0

IEEE Xplore 0

ScienceDirect 1

PubMed 2

Scholar Google 36

TOTAL: 39

68

Figura 32.Fluxo do Processo da Pesquisa

5.2.4 SELEÇÃO DOS ESTUDOS

Como pode ser visualizado na Tabela 4, ao se executar as buscas utilizando as strings

predefinidas nos engenhos de busca, gerou-se como resultado um baixo número de trabalhos a

serem avaliados (39). Apesar do número baixo dos trabalhos encontrados, foi aplicado um

filtro para evitar esforço desnecessário. A tabela 5 apresenta Critérios de Inclusão e Exclusão

de Trabalhos Relacionados.

Tabela 5. Critérios de Inclusão e Exclusão de Trabalhos Relacionados

Tipo Critério Descrição Objetivo

Exclusão Duplicidade Algumas vezes a mesma obra foi

retornada por diferentes engenhos de

busca ou através de diferentes strings.

Neste caso, apenas uma obra foi

selecionada e as demais descartadas.

Remover re-trabalho, ou

seja, leitura de um

mesmo artigo

repetidamente ou por

especialistas diferentes.

Exclusão Títulos,

resumo e

conclusão

Foram analisados os títulos, resumos e

conclusões dos artigos e verificado se

os mesmos condiziam com o foco da

pesquisa.

Eliminar artigos

avaliando o título,

resumo e conclusão.

A ordem na qual os critérios de inclusão e exclusão foram aplicados e a quantidade de

trabalhos obtidos como resultados podem ser observados na Figura 33.

69

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

5.2.5 CLASSIFICAÇÃO DOS ESTUDOS

Após a seleção das obras observou-se a necessidade de classificá-las de acordo com seu

conteúdo. As classificações dos estudos foram realizadas seguindo a mesma idéia de

categorização que utiliza duas facetas, por se tratar de uma maneira estruturada de fazer tal

tarefa (KITCHENHAM, 2007). A primeira faceta é baseada nas questões criadas para guiar a

pesquisa (seção 3.2.2), e a outra faceta de acordo com o tipo de pesquisa.

A execução da classificação foi apenas realizada no conjunto final dos estudos, ou seja,

após os processos de filtragem. As classes que formam a faceta de tipos de pesquisa estão

descritas na Tabela 6.

Tabela 6. Descrição das classes das facetas por conteúdo

Classes Descrição

Pesquisa de Validação Técnicas novas que ainda não foram implementadas na prática.

Trata-se de experimentos feitos em laboratórios.

Pesquisa de Avaliação Técnicas aplicadas na prática e com avaliação conduzida, ou seja,

é mostrado como a técnica foi implementada na prática e quais

seus pontos positivos e de melhorias. Esta classe também leva em

consideração a identificação de problemas na indústria.

Proposta de Solução Uma solução para um determinado problema é proposto podem

ser totalmente nova ou extensão de uma técnica existente. Os

potenciais benefícios e aplicabilidade da solução são indicados por

um pequeno exemplo ou uma satisfatória linha de argumentação.

Artigos Filosofia Estes artigos apresentam uma nova maneira de visualizar as coisas

existentes pela estruturação através de taxonomia ou modelos

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

2 trabalhos

Critério por Duplicidade

32 trabalhos

Critério Inicial

39 trabalhos

70

conceituais.

Artigos que descrevem opiniões Estes trabalhos expressão a opinião de alguém sobre determinada

técnica. Eles não dependem de trabalhos relacionados e

metodologia de pesquisa.

Artigos que descrevem

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

5.2.6 CONCLUSÕES DA PESQUISA

O objetivo desta revisão bibliográfica foi verificar o estado da arte sobre o

desenvolvimento orientado a modelos integrado a arquétipos e não explicitar de forma

detalhada como os artigos adotam arquétipos e MDD. A lista de todas as obras e suas

respectivas classificações pode ser visualizada na Tabela 7.

A classificação baseada nos tipos das pesquisas nos ajudou na conclusão que os trabalhos

tratam de Proposta de Solução e que utilizam uma abordagem de desenvolvimento orientado a

modelos integradas a Arquétipos.

Tabela 7. Classificação das obras de acordo com os tipos

# Classificação Artigo

01 Proposta de

Solução

A model-driven approach for representing clinical archetypes for

Semantic Web environments (Catalina et al, 2008).

02 Proposta de

Solução

Clinical data interoperability based on archetype transformation

(Catalina et al, 2011).

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

RQ1. Qual as evidências sobre a adoção do desenvolvimento orientado a modelos integrado

aos arquétipos clínicos?

01) Foi encontrada evidência da utilização do desenvolvimento orientado a modelos com

arquétipos clínicos no artigo de (CATALINA et al, 2008). Esse artigo trata de uma

proposta de solução que combina tecnologias de Web Semântica e MDE para transformar

Archetype Definition Language - ADL em Ontology Web Language - OWL usando a

linguagem de transformação MOFScript.

Esse artigo evidenciou a integração de arquétipos com MDE através de uma solução

proposta que transformou ADL para OWL. Foi sentida falta de informações que avaliassem

ou quantificassem os ganhos utilizando MOFScript na transformação dos conceitos clínicos

71

representados em ADL para OWL. De qualquer forma, concluiu-se que a integração de MDE

com arquétipos foi evidenciada e a linguagem MOFScript foi utilizada para efetuar as

transformações.

02) Foi encontrada evidência da adoção de técnicas de desenvolvimento orientado a modelos

integrado com arquétipo no artigo (CATALINA et al, 2011). Esse artigo foca na

interoperabilidade semântica dos registros eletrônicos de saúde. Esse artigo utilizou e

estendeu as regras de transformações definidas no artigo 01.

Esse artigo não efetuou nenhuma proposta nova em relação as técnicas de MDE

utilizadas em relação ao artigo 01.

72

6. ABORDAGEM PROPOSTA

Este capítulo propõe uma abordagem para adotar o desenvolvimento orientado a

modelos na confecção de um sistema de cuidado à saúde conforme os arquétipos clínicos.

Visando fornecer suporte ao desenvolvimento do HIS, foi definida uma abordagem de

desenvolvimento com o intuito de determinar atividades e artefatos que auxiliam a

modelagem dos conceitos clínicos – Arquétipos. Na especificação desta abordagem,

utilizamos técnicas de MDD para geração semi-automática de alguns dos artefatos. Assim,

esta abordagem de desenvolvimento utiliza o paradigma de desenvolvimento dirigido a

modelos - MDD para a implementação de aplicações de domínio clínico baseadas

respectivamente em metamodelos clínicos. A entrada da abordagem ocorre com o

fornecimento de Conceitos Clínicos – CCs que são obtidos no repositório CKM da OpenEHR

e representados através de mapa mental.

Conforme explanado no capítulo 2, os arquétipos indicam como representar conceitos

ou informações de um domínio via expressões computáveis, sendo que essas expressões

baseiam-se num modelo de Referência - RM e são definidas na forma de restrições

estruturais. A estrutura do RM é restringida pelo arquétipo empregado, disponibilizando uma

estrutura resultante que possui as características do conceito clínico definido pelo arquétipo. A

Fundação openEHR fornece algumas formas de representar os conceitos clínicos –

Arquétipos. Entre essas representações destacamos os mapas mentais que são diagramas que

através de palavras-chave podem representar e modelar cognitivamente um conceito ou um

domínio específico. Alguns trabalhos (DOWNS, 1973) e (KITCHIN, 1994) ressaltam que

esse tipo de representação facilita a mente humana em processar melhor as informações,

reduzindo a carga cognitiva para a absorção do conhecimento ou domínio. Neste contexto, o

mapa mental foi empregado nesta abordagem com o intuito de facilitar a comunicação e

simplificar a modelagem de domínio pelo Especialista de Domínio, tornando esta abordagem

mais ágil e eficaz e consequentemente reduzindo a complexidade dos conceitos clínicos -

arquétipos.

Conforme pode ser visto na Figura 34, esses mapas mentais que representam os

conceitos clínicos (arquétipos) são transformados automaticamente em modelos conceituais,

visando diminuir o gap entre o especialista do negócio e o engenheiro de sistema, através da

abordagem proposta por (WANDERLEY et al, 2012). Em seguida, esses modelos conceituais

73

são refinados e projetados manualmente pelos especialistas de domínio e, finalmente, são

transformados automaticamente em artefatos executáveis com conformidade com o

framework PhoneGap. A Figura 34 apresenta a visão da abordagem proposta.

Figura 34.Visão da Abordagem Proposta

Na sequência deste capítulo são apresentados os objetivos da abordagem, visão geral

da mesma e a descrição das etapas, contendo os detalhes dos seus conjuntos de atividades.

6.1 OBJETIVOS DA ABORDAGEM

O principal objetivo deste trabalho foi propor uma abordagem que possibilite uma

melhoria na produtividade e qualidade na construção de um sistema clínico, utilizando o

paradigma de desenvolvimento orientado a modelos – MDD.

74

Outra motivação foi a tentativa de diminuir a complexidade do desenvolvimento de

soluções de cuidado da saúde. Mesmo arquétipos sendo uma proposta de padronização,

melhoria de qualidade semântica para os sistemas da área de saúde, foram encontrados

problemas na sua adoção conforme ressaltados por HAJAR (2011), que relatou a existência

de alguns desafios enfrentados na adoção de arquétipos, entre eles: 1) Ser enorme e

complicado: Arquétipos é, naturalmente, grande e complexo e esta complexidade não é

inesperada já que os arquétipos definidos pela openEHR são considerados como uma solução

para um problema complicado em um domínio complexo (ou seja, o domínio clínico é

naturalmente complicado). Por exemplo, o enorme modelo arquétipo permite expressar

conceitos complexos clínicos, portanto, um desenvolvedor inexperiente para prover soluções

baseadas em arquétipos deve esperar passar algum tempo para aprender os conceitos

openEHR. 2) Falhas em aspectos educacionais: A compreensão de um conceito é o primeiro

passo para ser capaz de adotá-lo, e esta é ainda mais válida para conceitos tão complexos

como os dos arquétipos clínicos definidos pela openEHR. Infelizmente encontramos: pouca

documentação formal, guias para iniciantes, raras sessões de formações (treinamentos) e

poucas pessoas formadoras ao redor do mundo.

Visando minimizar a complexidade na utilização de arquétipos, ou na tentativa de

diminuir a curva de aprendizado dos conceitos clínicos (arquétipos), foram utilizados Mapas

Mentais – MM para facilitar o entendimento do domínio do Cuidado a Saúde. Além disso, a

adoção da infraestrutura de (WANDERLEY et al, 2012) nesta proposta tem o objetivo de

aumentar a produtividade na construção dos modelos conceituais clínicos, através da geração

automática do modelo conceitual baseado em mapa mental. Adicionalmente, o emprego dos

conceitos de desenvolvimento orientado a modelos - MDD no processo proposto permite que

os refinamentos inerentes à abordagem proposta de desenvolvimento sejam apoiados por

modelos e que os artefatos gerados sejam reutilizáveis. Consequentemente teremos um ganho

de produtividade, já que uma parte dos artefatos não será refeitos, isto é, esses artefatos serão

reusáveis.

6.2 VISÃO GERAL

Essa abordagem consiste em duas etapas: Engenharia de Domínio – ED e Engenharia

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

75

reutilização, é chamado de Engenharia de Domínio e o desenvolvimento de um produto

(desenvolvimento com reutilização), de Engenharia de Aplicação (LUCRÉDIO, 2009).

Para essa abordagem, utilizamos a engenharia de domínio com foco na análise de

domínio clínico, usando como referência os Modelos de Arquétipos - AMs, selecionando os

requisitos semelhantes que pertencem ao subdomínio OBSERVATION. Conforme detalhado

na seção 2.2, a classe genérica OBSERVATION é uma das quatro classes que especializam a

classe CARE_ENTRY e é utilizada para registro de informações de Cuidado á Saúde. As

informações de Cuidado a Saúde registradas são: os registros de tudo que puder ser

observado, medido ou respondido pelo paciente. Esses requisitos são independentes de

especialidade médica, por exemplo: Temperatura Corporal.

Além disso, de acordo com a abordagem de Lucrédio (2009) foi adicionada o uso de

MDD na Engenharia de Domínio com o objetivo da modelagem fazer parte desta abordagem,

para aumentar o nível de abstração do desenvolvimento das soluções de cuidado a saúde. A

Figura 35 apresenta as duas etapas da abordagem.

Figura 35.Etapas da abordagem

Na ED os mapas mentais do subdomínio clínico dos arquétipos são selecionados e

recuperados do repositório Clinical Knowledge Manager - CKM (OPENEHR, 2012). O

modelo conceitual é refinado e projetado utilizando a ferramenta MagicDraw que é uma

ferramenta para modelagem baseada na UML e utilizada pela OpenEHR na definição dos seus

metamodelos de arquétipos - AOM (OpenEHR, 2011); são implementadas: o componente de

apoio e as transformações M2C para a geração de artefatos reusáveis;

Todos os artefatos da ED são usados como apoio a Engenharia de aplicação – EA,

onde os sistemas de cuidado de saúde são desenvolvidos baseados no refinamento dos

metamodelos da ED. Alguns dos artefatos são utilizados no refinamento e nas transformações.

Engenharia de Domínio + MDD

Engenharia de Aplicação

76

As transformações M2C são reutilizadas para geração de diversos artefatos descritos na

abordagem proposta. A Figura 36 apresenta um diagrama do macroprocesso demonstrando os

principais atores envolvidos na ED e as respectivas fases da ED proposta, como: Análise de

Domínio, Projeção e Implementação.

Figura 36.Diagrama do Macroprocesso - Engenharia de Domínio

A ED tem início na fase Análise de Domínio (AD). A AD começa com a coleta dos

requisitos do domínio do problema, a definição do escopo, refinamento do modelo conceitual

e tem como alvo a modelagem do domínio. Durante a realização dessa atividade o engenheiro

de domínio é guiado pelo Modelo de Arquétipo (AM), representados por Mapas Mentais –

MM que são obtidos no repositório de arquétipos CKM (OPENEHR, 2011).

Na fase de Projeção, o engenheiro de sistemas realiza algumas atividades

referentes ao mapeamento do modelo conceitual para o modelo de domínio. As principais

atividades realizadas na fase projeção são: 1) Refinamento visando definir submódulos,

criando interfaces, abstrações, definindo fronteiras; 2) Refinamento do modelo conforme,

tecnologias e padrões adotados;

Para a implementação, as atividades começam com o desenvolvimento

preliminar que precede o refinamento e a transformação M2C, seguida de algumas outras

atividades, entre elas: 1) Desenvolver Perfil UML; 2) Montar ambiente; 3) Desenvolver

manualmente o complemento funcional e não funcional; 4) Confeccionar transformação.

A Figura 37 apresenta o diagrama do macroprocesso referente as atividades da

EA que envolvem algumas das disciplinas tradicionais de engenharia de software, tais como:

Análise, Projeto, Implementação e Testes. Durante a realização dessas fases, o Engenheiro

de Aplicação é guiado pela UML e pelos diagramas de classes dos metamodelos RM e AM,

utilizando as ferramentas MagicDraw e o Papyrus.

77

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

6.3 ETAPAS DA ABORDAGEM

Nesta seção, descrevemos as etapas da abordagem, visando facilitar o

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

modelos.

6.3.1 ENGENHARIA DE DOMÍNIO - ED

Conforme apresentado por Leite e Girard (2009) a ED é uma etapa voltada para a

confecção de artefatos reusáveis pertencentes a um domínio específico. Outra característica

relevante da ED é a determinação das características comuns quanto também das variações

das aplicações de um domínio particular (LUCRÉDIO, 2009). Na abordagem proposta,

utilizaremos a ED para identificar as características semelhantes do domínio clínico,

especificamente dos subdomínios gerais da área de conhecimento OBSERVATION definida

pela openEHR e ilustrada na Figura 8. A Figura 38 demonstra através de um diagrama de

processo quais as fases e suas atividades, sequencias e como essas atividades da ED são

relacionadas.

78

Figura 38.Processo Proposto para Engenharia de Domínio

Análise de Domínio - AD

Conforme exposto por Lucrédio (2009), a fase de Análise de Domínio - AD é o

começo da ED que contempla a identificação dos principais conceitos e elementos de um

domínio e a determinação de seu escopo. Essa fase inicial é responsável por coletar

informações do domínio para as fases subsequentes da abordagem proposta.

Essa fase inicia com a seleção de um conjunto preliminar de conceitos clínicos (CCs)

baseados em arquétipos, representados por Mapas Mentais (MM), que são adotados em

distintas especialidades médicas do domínio do Cuidado de Saúde. A finalização da AD

ocorre com a realização da atividade Modelar Domínio - MD, que é iniciada com a execução

da atividade Executar a infraestrutura de (WANDERLEY et al, 2012) com o objetivo de obter

o modelo conceitual para a realização do refinamento deste modelo conceitual.

As atividades da fase Análise de Domínio - AD adotadas neste trabalho são:

A Seleção de Arquétipos em Mapa Mentais, nesta atividade o engenheiro de

domínio com o auxílio do especialista de domínio, pesquisa, estuda e seleciona (coleta) no

repositório CKM os arquétipos (openEHR, 2011), ilustrados através dos mapas mentais

representando os conceitos clínicos pertencentes ao subdomínio desejado (define escopo).

79

Como fluxo excepcional, caso o conceito clínico geral desejado pelo especialista do domínio

não esteja no repositório CKM de arquétipos – openEHR, esse especialista cria o novo

conceito clínico usando a ferramenta linkEHR com o auxílio de um engenheiro de sistemas.

Esse novo conceito clínico criado é enviado para a ativa comunidade openEHR, onde a

openEHR realiza uma avaliação desse novo conceito, visando evitar repetição, inconsistência.

Em seguida, caso tenha resultado positivo da avaliação, é efetuada uma publicação desse novo

conceito clínico, colocando-o no repositório de CKM e que passa a ser gerenciado pela

openEHR.

A exportação do mapa mental (no formato XML), nesta subatividade o especialista

de domínio realiza a exportação dos mapas mentais no formato XML para serem insumos,

entradas, para a execução da abordagem de Wanderley; A Figura 13 ilustra um exemplo de

MM;

A execução da abordagem Wanderley, nesta subatividade o especialista de domínio

fornece um XML que representa o mapa mental e executa a abordagem de Wanderley

(Wanderley et AL, 2012), que após transformação M2C, gera um arquivo no formato XML

Metadata Interchange - XMI representando respectivamente o modelo conceitual do conceito

clínico fornecido como mapa mental.

Na atividade Refinar Modelo de Domínio, o engenheiro de domínio é apoiado

quando necessário pelo especialista do domínio que realiza o refinamento no modelo

conceitual baseado no uso da ferramenta Case Papyrus adicionado com os AMs e RMs, perfis

UML da OpenEHR e um novo perfil UML confeccionado previamente para possibilitar a

extensão das características dos elementos dos modelos. Entre outras atividades de

refinamento, é possível modificar o modelo conceitual para: 1) a identificação e descrição dos

CCs; 2) definir associações entre as entidades; 3) Determinar ordem de apresentação (mesma

ordem dos atributos nas classes); 4) Identificar os tipos de dados dos atributos; 5) em alguns

casos, identificação de informações sobre restrições de valores possíveis dos atributos. Essa

atividade é comumente baseada nos MM e em casos que necessitam de um detalhamento

maior (por exemplo: restrição de valores de um determinado atributo) os engenheiros de

domínio obtêm um detalhamento dos conceitos clínicos através de consultas manuais aos CCs

que estão descritos em ADLs. A saída desta atividade é o modelo de domínio especificado; A

Figura 39 ilustra um exemplo do Modelo Conceitual Refinado. Do lado esquerdo da Figura

80

39 é apresentado um modelo conceitual oriundo da abordagem de (Wanderley et al, 2012) e

do lado direito é apresentado o modelo conceitual correspondente com o refinamento do tipo

e do nome do atributo.

Figura 39.Exemplo de Modelo Conceitual Refinado

Projeção de Domínio - PD

A projeção de domínio é uma fase essencial da engenharia de domínio (BOSCH,

2000). Um dos seus objetivos é definir um conjunto de artefatos reutilizáveis que podem ser

combinados para desenvolver aplicativos mais rapidamente e com maior qualidade.

Conforme descrito por LUCRÉDIO (2009), a projeção de domínio é um processo

iterativo de refinamento. Inicia-se com o domínio todo, e a cada iteração é feito um

refinamento que identifica novos módulos, que serão refinados na próxima iteração, e assim

por diante, até que o projeto esteja concluído, em função de um entendimento satisfatório

sobre o que deverá ser implementado.

Nesta fase, ocorre a atividade Projetar Modelo de Domínio, a qual é responsável pela

realização do mapeamento do modelo conceitual já refinado para o modelo de domínio. Essa

atividade inicia com características de modelo conceitual oriundo da AD, e esse modelo é

refinado e projetado manualmente conforme padrões, componentes, plataformas e tecnologias

que viabilizarão a fase de implementação. A Figura 40 apresenta o resultado da atividade

Projetar Modelo de Domínio.

81

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

Implementação de Domínio

Nesta fase é realizada a implementação manual com base nas especificações contidas

no modelo de domínio resultante da fase de projeção.

Na atividade Desenvolver Perfil UML é confeccionado um perfil UML que

possibilita ao Engenheiro de Domínio incluir informações no modelo referentes à

apresentação, negócio e persistência das entidades modeladas além de: 1) possibilitar ao

Engenheiro de Domínio realizar refinamentos; 2) possibilitar ao engenheiro de sistemas

realizar a projeção (mapeamento) do modelo conceitual para o modelo de domínio. Além

disso, esse perfil UML criado pode ser utilizado em conjunto com os perfis UML dos

modelos da openEHR nas fases AD e Projeção de Domínio. A Figura 41 ilustra o diagrama

de classe do perfil UML criado.

82

Figura 41.Diagrama de Classe do perfil UML

A atividade Implementar Complemento, visa complementar as soluções de domínio

clínico dos requisitos funcionais e não funcionais, essa atividade contempla, entre outras, a

implementação manual das classes utilitárias, extensões de padrões de projetos e demais

características dos requisitos funcionais, por exemplo: associar a classe Paciente a um

Componente ou biblioteca de Controle de Acesso, isto para os sistemas onde o paciente será o

responsável pelo registro autenticado das suas observações. Além dos requisitos funcionais,

ocorrerá desenvolvimento manual visando atender também aos requisitos de qualidade (não

funcionais), tais como: desempenho, facilidade de uso (usabilidade). A Figura 42 apresenta

um trecho de código da tela inicial.

83

Figura 42.Tela inicial

A atividade Desenvolver Transformações M2C é responsável pela construção dos

programas transformadores que são editados através da ferramenta Papyrus (PAPYRUS

UML, 2011). Esses programas transformadores M2C são escritos na linguagem MOFScript e

tem o objetivo de transformar modelos em texto (M2C). O uso dos modelos na construção de

transformações tem se destacado dentre as demais técnicas existentes conforme mencionado

por Lucrédio (2009).

Isto significa que nesta atividade são criadas as transformações M2C, que são

aplicadas aos modelos construídos na Engenharia de Aplicação. Essas transformações têm o

objetivo de diminuir os esforços de implementação dos CCs e possibilitar o reuso dos

modelos de domínio.

84

Figura 43. Modelo Domínio x trecho código MOFScript x HTML gerado

A Figura 43 apresenta um exemplo de M2C, o item 1) apresenta o modelo de domínio

identificado com os respectivos estereótipos (persistence, view) das classes e as tagged values

dos atributos. As regras de transformações adotadas são descritas na Tabela 8; 2) É um trecho

do programa transformador escrito em MOFScript, que recebe como entrada o modelo de

domínio resultante do item 1 e transforma-o no artefato de saída (item 3); 3) É o layout da tela

de cadastro da temperatura corporal que foi gerada automaticamente pelo programa

apresentado no item 2. Além disso, a Figura 43 ilustra: a seta identificada por A que destaca o

estereotipo view na classe BodyTemperature no modelo de domínio e o uso desse mesmo

estereótipo no programa de transformação escrito em MOFScript; seta B apresenta a linha de

85

código que escreve a palavra <html> no arquivo de saída, o layout HTML da tela de cadastro

da temperatura corporal; A seta C descreve a linha de código que obtém a tagged value label

da classe BodyTemperature que está sendo lida pelo programa transformador gerando assim o

título da tela de cadastro da temperatura corporal.

A Tabela 8 apresenta as regras de transformação utilizadas com os mecanismos de

extensão criados no perfil UML.

Tabela 8. Regras de Transformação

Mecanismos de

Extensão

Regras de Transformação

<< View>> Este estereótipo é aplicado para classes, onde as entidades

identificadas com esse estereótipo são processadas pelo

programa gerador que as transformam em layouts de tela em

HTML5,conforme FPG.

Label Nesta tagged Value o Engenheiro de Sistema informa a descrição

do label que aparecerá no título e cabeçalho das telas nos layouts

HTML5.

<<persistence>> Este estereótipo é aplicado para classes, onde as entidades

identificadas com esse estereótipo são processadas pelo

programa gerador que as transformam em programas javascript

responsáveis pela manipulação (persistência) dos respectivos

dados.

nameTable Nesta tagged Value o Engenheiro de Sistema informa o nome da

tabela que representa essa entidade no banco Sql Lite. Caso não

seja informado nenhum valor para essa tagged value, o programa

gerador utiliza o nome da classe para transformar no nome da

tabela no banco de dados SQL Lite.

commentTable Nesta tagged Value o Engenheiro de Sistema informa a descrição

do comentário da tabela da entidade do banco de dados.

<<propertyAdditional>> Este estereótipo é aplicado para os atributos das classes.

Label Nesta tagged Value o Engenheiro de Sistema informa a descrição

do label que será transformado pelo gerador em um label da tela

HTML5. Esse label da tela aparecerá do lado esquerdo do

campo.

Required Nesta tagged Value o Engenheiro de Sistema informa true or

false para identificar se o atributo será obrigatório. Com isso, o

gerador transforma em código javascript que obriga o

preenchimento do atributo.

defaultValue Nesta tagged Value o Engenheiro de Sistema informa o valor

padrão inicial para o atributo.

unique Nesta tagged Value o Engenheiro de Sistema informa true or

false para identificar se o atributo será o indentificador único da

entidade. Com isso, o gerador transforma em código SQL que

86

identifica o campo como Chave Primária - PK.

typePresentation Nesta tagged Value o Engenheiro de Sistema informa o tipo de

apresentação (Exemplo: String, password) do atributo. Com isso,

o gerador transforma em código correspondente na linguagem

HTML5.

orderBy Nesta tagged Value o Engenheiro de Sistema informa true or

false para identificar se o atributo será usado na ordenação da

entidade. Com isso, o gerador transforma em código SQL

correspondente.

sortDirection Nesta tagged Value o Engenheiro de Sistema informa asc ou desc

para identificar o sentido da ordenação do atributo. Com isso, o

gerador transforma em código SQL correspondente.

valueInitialAllow Nesta tagged Value o Engenheiro de Sistema informa o menor

valor permitido para o atributo. Com isso, o gerador transforma

em código javascript correspondente.

valueFinishAllow Nesta tagged Value o Engenheiro de Sistema informa o maior

valor permitido para o atributo. Com isso, o gerador transforma

em código javascript correspondente.

nameColumn Nesta tagged Value o Engenheiro de Sistema informa o nome da

coluna que representa o atributo no banco Sql Lite. Caso não seja

informado nenhum valor para essa tagged value, o programa

gerador utiliza o nome do atributo para transformar no nome da

coluna no banco de dados SQL Lite.

initialValueNormal Nesta tagged Value o Engenheiro de Sistema informa o limite

inferior da normalidade do valor para o atributo. Com isso, o

gerador transforma em código javascript correspondente.

finishValueNormal Nesta tagged Value o Engenheiro de Sistema informa o limite

superior da normalidade do valor para o atributo. Com isso, o

gerador transforma em código javascript correspondente.

6.3.2 ENGENHARIA DE APLICAÇÃO - EA

A EA é uma etapa da abordagem proposta que tem o objetivo de confeccionar

aplicações específicas de um dado domínio (LEITE; GIRARDI, 2009). A EA reusa os

artefatos oriundos da ED e suas atividades são baseadas em quatro disciplinas da engenharia

de software: Análise, Projeto, Implementação e Testes. A Figura 44 ilustra o diagrama de

processo da etapa EA.

87

Figura 44.Diagrama de Processo EA

Na abordagem proposta, a etapa EA é responsável pela confecção de aplicações de

CCs dos subdomínios semelhantes da classe OBSERVATION que compõe o MA.

Visando demonstrar o objetivo relevante da construção de aplicações específicas da

EA, foram escolhidos os CCs do subdomínio OBSERVATION: Paciente e Temperatura

Corporal com o intuito de construir o aplicativo móvel para registrar a coleta da temperatura

corporal do paciente - SOT. O Sistema para Registrar a Temperatura do Paciente - SOT é um

aplicativo Web e Móvel que possibilita os pacientes ou profissionais de saúde que realizam

assistência domiciliar efetuar registro das aferições das temperaturas corporais do paciente. O

principal objetivo do SOT é permitir o registro da temperatura do paciente. Conforme

abordado por Carvalho et al (2011), os sistemas móveis adotados na construção de sistemas

de cuidado à saúde durante a assistência domiciliar visam coletar observações sobre sinais

vitais do paciente.

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

88

A Figura 45 apresenta os mapas mentais utilizados para a construção do SOT:

Paciente e Body Temperature.

Análise

A etapa Análise é responsável pela especificação dos requisitos funcionais referentes

aos CCs pertencentes ao subdomínio OBSERVATION para o aplicativo SOT. O Engenheiro

de aplicação ou Analista de Sistemas utiliza a ferramenta MagicDraw para produzir artefatos,

tais como: Diagrama de Casos de Uso, Diagrama de Colaboração, Diagramas de Estado.

Além disso, o engenheiro de aplicação utiliza a ferramenta Papyrus para produzir diagrama de

classe. Com o objetivo de descrever a relação dos usuários com a aplicação SOT, alguns

artefatos são confeccionados durante a atividade especificar requisitos, entre eles: O

Diagrama de Caso de Uso que é responsável por identificar e descrever os atores e as suas

respectivas ações exercidas no aplicativo SOT. Por exemplo, a Figura 46 apresenta o

diagrama de casos de uso do sistema SOT, descrevendo: os principais requisitos funcionais do

sistema SOT relativos ao registro da temperatura corporal do paciente, e a consulta do

histórico das aferições das temperaturas corporais do paciente.

Figura 46.Diagrama de Casos de Uso do SOT

Outro artefato produzido na atividade especificar requisitos é o diagrama de sequência,

também conhecido como diagrama de colaboração. O diagrama de sequência é criado com o

objetivo de descrever como o usuário vai interagir com o sistema de acordo com cada caso de

uso. A Figura 47, apresenta um diagrama de sequência que descreve a interação do usuário

com o sistema para registrar temperatura corporal do paciente.

89

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

Projeto

Nesta fase os artefatos resultantes da fase da Análise são refinados conforme as

tecnologias de hardware e software envolvidos, tais como o framework PhoneGap que é

baseado em HTML5, CSS3 e JQuery Mobile (JavaScript).

Na atividade de Refinar/Projetar Modelo de Domínio o Engenheiro de Domínio ou

engenheiro de sistemas é responsável por mapear o modelo conceitual para o modelo de

domínio utilizando como entrada o Modelo Conceitual oriundo da fase de Análise. O modelo

de domínio resultante da fase Projeto representa as informações da aplicação referente ao

Registro da Temperatura Corporal do Paciente. Como especificado no diagrama de casos de

uso ilustrado na Figura 46, o usuário registra a temperatura corporal aferida em seu

dispositivo móvel.

Implementação

Nesta fase ocorre a codificação da aplicação e a geração dos artefatos oriundos do

modelo de domínio.

Com o auxílio da ferramenta Papyrus, o Engenheiro de Aplicação realiza a atividade

Geração Automática de Artefatos executando as transformações M2C, que são aplicadas

aos modelos de domínio para gerar os seguintes artefatos da aplicação SOT: 1) as telas da

90

aplicação (view); 2) funções responsáveis por restringir o conteúdo dos atributos das

entidades; 3) funções responsáveis pela manipulação dos dados (persistência); 4) estrutura de

criação dos objetos do banco de dados SQL Lite. A Figura 48 apresenta um trecho do código

da tela gerada em HTML5 da aplicação SOT.

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

91

A atividade Implementação Complementar é realizada pelo engenheiro de sistema

ou engenheiro de aplicação com o intuito de confeccionar manualmente algumas

características funcionais e ou requisitos de qualidade do sistema SOT. Por exemplo, a tela

inicial do aplicativo SOT, foi desenvolvida manualmente com o objetivo de facilitar a

navegação no sistema e atender ao requisito de qualidade: facilidade de uso. A Figura 49

apresenta um trecho de código da tela inicial do sistema SOT.

Figura 49.Trecho de código da Tela inicial do aplicativo SOT

Além disso, a Figura 49 apresenta trecho do código em HTML5 e JavaScript em

conformidade com o framework PhoneGap, podendo assim, ser compilado e executado em

várias plataformas móveis distintas conforme descrito na seção 4.5.

92

Testes

Na fase de Testes são realizados os testes de sistema, o SOT é executado com o

objetivo de verificar se os aspectos gerais do sistema estão sendo atendidos. Os requisitos

funcionais e não funcionais do sistema são testados através da execução do SOT pelo

engenheiro de aplicação (analista de sistemas). A Figura 50 ilustra a interface da aplicação

SOT em execução.

Figura 50.SOT em execução

93

7. ESTUDO DE CASO - SISTEMA

Este capítulo apresenta a realização de um estudo de caso referente à criação de um

protótipo com o objetivo de avaliar a abordagem proposta no capítulo 6. Adicionalmente,

foram apresentadas métricas na seção 7.2 como resultado da avaliação do protótipo.

No corrente capítulo são apresentadas as etapas da abordagem sendo executadas na

implementação de um sistema, protótipo, que permite ao Paciente, registrar as suas medidas

dos diversos sinais vitais e que consequentemente possibilita ao profissional de saúde,

responsável pelo acompanhamento do paciente, receber essas observações das aferições.

O Sistema de Registro e Acompanhamento dos Múltiplos Sinais Vitais e Medidas do

Paciente – SASVM é formado por duas partes: 1) O lado cliente ou lado observado, a parte da

aplicação que possibilita aos pacientes efetuarem o registro dos seus múltiplos sinais vitais em

vários dispositivos de plataformas móveis diferentes (exemplo: Android e IOS). Esses

registros são persistidos inicialmente em um banco de dados local, dentro do dispositivo

móvel. Além disso, essas observações clínicas são enviadas e persistidas em uma aplicação

WEB que está sendo executado em um servidor WEB; 2) O lado Observador, é um módulo

web que disponibiliza uma tela (interface) que permite ao profissional de saúde acompanhar a

evolução dos sinais vitais dos seus pacientes. A Figura 51 apresenta uma visão geral do

funcionamento da aplicação – SASVM.

Figura 51.Visão Funcional do aplicativo SASVM

94

7.1 ENGENHARIA DE APLICAÇÃO - EA

Este estudo de caso permitiu avaliar a etapa EA da abordagem proposta com a

reutilização dos artefatos confeccionados na Engenharia de Domínio - ED. Serviu ainda para

refinar a ED na especificação e projeto do modelo de domínio, na construção das

transformações M2C e na realização dos testes de sistema.

7.1.1 ANÁLISE

Esta fase inicia a EA com a especificação da aplicação, onde o engenheiro da

aplicação ou analista de sistemas realiza o levantamento de requisitos e define o escopo do

sistema. Os Conceitos Clínicos – CCs semelhantes, pertencentes à classe OBSERVATION do

Metamodelo de Arquétipos – AM, contemplados pelo SASV, são: 1) Pressão Sanguínea; 2)

Peso Corporal; 3) Altura/Comprimento; 4) Consultar o Índice de Massa Corpórea - IMC; 5)

Frequência Cardíaca; 6) Frequência Respiratória; 7) Temperatura Corporal. Como muitos

desses CCs não tinham sido contemplados na Engenharia de Domínio - ED, foi realizado uma

volta as fases da ED para efetuar uma atualização no metamodelo. Neste retorno foram

analisados alguns mapas mentais apresentados na Figura 52.

Figura 52.Alguns Mapas Mentais do SASVM

95

Na fase de Análise, o Engenheiro de Aplicação ou Analista de Sistemas na atividade

de especificar requisitos confeccionam os artefatos: 1) Diagrama de Casos de Uso - é

responsável por identificar e descrever os atores e as suas respectivas ações; 2) Diagrama de

Sequência - descreve como o usuário vai interagir com o sistema de acordo com cada caso de

uso.

O diagrama de casos de uso foi construído pelo Engenheiro da Aplicação, ajudado

pela ferramenta MagicDraw, com o objetivo de especificar os requisitos do SASVM

referentes as seguintes funcionalidades: 1) Registrar Os Múltiplos Sinais Vitais; 2) Consultar

o Histórico dos Múltiplos Sinais Vitais. Outra funcionalidade, disparada automaticamente

pelo relógio (ator clock), é o envio do registro dos sinais vitais e medidas que não foram

enviados. A Figura 53 ilustra o diagrama de casos de uso do SASVM.

96

Figura 53.Diagrama de Casos de Uso do SASVM

Depois de iniciar o levantamento de requisitos, através do desenvolvimento do

diagrama de casos de uso, o Engenheiro de Aplicação descreve manualmente o diagrama de

sequência com o objetivo de refinar o caso de uso. A Figura 54 ilustra o diagrama de

sequência do caso de uso Consultar Histórico do Sinal Vital (lado Observador).

97

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

7.1.2 PROJETO

Nesta fase da EA, o modelo de domínio referente aos CCs do SASVM é desenvolvido

de acordo com as tecnologias envolvidas para a implementação do Lado Cliente e do Lado

Observador. O módulo do lado cliente é baseado no Framework phoneGap, com tecnologias

baseada em HTML5, javascript (JQuery Mobile) e o banco de dados Sql Lite. Já para o Lado

observador, a aplicação servidora terá a ccamada de apresentação com HTML5 e para

processar as requisições foi adotado Servlet na linguagem Java. Além disso, para possibilitar

persistência no banco de dados foi usado Spring com Hibernate e banco de dados MySql.

Para confeccionar o modelo de domínio, o Engenheiro de Aplicação utiliza a

ferramenta Papyrus conforme a fase de análise fazendo o refinamento, mapeamento, do

modelo conceitual para o modelo de domínio, modelando e utilizando elementos definidos no

perfil UML construído na ED. A Figura 55 apresenta um diagrama de classe que mostra uma

parte do mapeamento entre os modelos.

98

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

7.1.3 IMPLEMENTAÇÃO

Nesta fase da EA, é realizada a implementação da aplicação, em conformidade com as

tecnologias adotadas na atividade de projeto, modelo de domínio e com base no reuso dos

artefatos gerados na ED.

99

Com o auxílio da ferramenta Papyrus, é realizada a atividade de Geração automática

de Artefatos, através da execução do programa gerador (escrito em MOFScript) que é

responsável pela transformação M2C. Os seguintes artefatos foram gerados: 1) Layout de

Tela (HTML5); 2) funções de validações e restrições de conteúdo em javascript; 3) funções

de manipulação de dados (persistência) e estrutura dos objetos do banco de dados Sql Lite. A

Figura 56 apresenta um trecho do código HTML5 e JavaScript gerados que representa o

layout da tela no formato HTML5 referente a funcionalidade de adicionar o peso corporal do

paciente.

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

100

A atividade Implementação Complementar é executada nesta fase com o objetivo de

desenvolver manualmente alguns requisitos, entre eles destacamos: a implementação do caso

de uso responsável por enviar os registros dos sinais vitais e medidas pendentes de envio da

aplicação do lado cliente para o modulo lado observador.

7.1.4 TESTES

Nesta Fase da EA, os testes de sistemas são executados com o objetivo de verificar o

funcionamento geral do aplicativo SASVM. O módulo da aplicação SASVM do lado cliente

foi submetido para o phoneGap Build gerá-lo para a plataforma Android. O funcionamento do

phoneGap Build foi explanado na seção 4.5 dessa trabalho. A Figura 57 apresenta algumas

das interfaces executadas referentes à funcionalidade de registrar sinais vitais, mais

especificamente: Peso e Temperatura. A Figura 57 apresenta a interface gráfica das telas

referentes ao registro de sinais e medidas do SASVM.

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

101

O módulo do lado Observador foi instalado em um servidor Web, possibilitando ao

profissional de saúde efetuar a consulta do histórico dos sinais vitais e medidas dos seus

pacientes observados (acompanhados), conforme interface da tela apresentada na Figura 58.

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

7.2 RESULTADOS

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

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

7.2.1 LINES OF CODE - LOC

Com o resultado produzido na adoção da EA neste capítulo, observamos que as

atividades executadas e os artefatos gerados, contribuíram para o aumento da produtividade

na construção do SASVM. Uma demonstração desse aumento da produtividade ocorre na

geração dos CCs em artefatos executáveis, apoiados pelas transformações M2C.

102

Cerca de 76% das linhas de código (HTML e javascript) dos artefatos executáveis

foram gerados. A Figura 59 apresenta um gráfico que ilustra para alguns CCs os respectivos

quantitativos das linhas de códigos - LOC geradas automaticamente e desenvolvidas

manualmente. As implementações manuais realizadas pelo engenheiro de aplicação são

decorrentes do desenvolvimento de funcionalidades adicionais, como: atributo com valor

calculado, como acontece com Blood Pressure.

Figura 59.Gráfico LOC Automática x Manual dos CCs 7.2.2 AVALIAÇÃO

Para realizar a avaliação do protótipo SASVM, foi efetuada uma apresentação /

treinamento para 10 pessoas, cinco engenheiros de sistemas experientes (com mais de 3 anos

de experiência) em desenvolvimento de HIS e cinco estudantes do curso de pós-graduação em

Engenharia da Computação da Universidade de Pernambuco. A estratégia de avaliação

adotada foi o modelo: Technology Acceptance Model – TAM. O TAM possibilita avaliar a

facilidade de utilização e a própria utilidade da tecnologia que é percebida pelos usuários

(DAVIS, 1989).

Depois da utilização e navegação no SASVM, foram aplicados os formulários de

avaliação, baseados no TAM, aos respectivos usuários. Neste formulário continham cinco

afirmativas, e as respostas dessas afirmações eram especificações do nível de concordância

sobre uma determinada afirmativa, de acordo com a escala de Likert (1932).

103

Além disso, foram realizados convites para três profissionais de saúde (enfermeiros e

médico) para participarem da avaliação do protótipo SASVM. Porém, até a data da confecção

desta dissertação, os profissionais de saúde estavam com indisponibilidade de tempo para

executarem esta avaliação.

A Tabela 9 apresenta uma matriz contendo os resultados dos formulários preenchidos

pelos avaliadores. Cada linha dessa matriz representa uma afirmativa conforme TAM, que

cruzam com os quantitativos das respectivas respostas baseadas na escala de Likert.

Tabela 9. Matriz do Resultado dos Formulários Preenchidos

Concorda

plenamente

Concorda

parcialmente

Nem concorda nem

discorda

Discorda

parcialmente

Discorda

totalmente

1.Foi fácil utilizar a

tecnologia apresentada.

4 (80%)

5 (100%)

1 (20%)

--

--

--

--

--

--

--

2.Adoção dessa

tecnologia dificulta a

relação médico-paciente.

--

--

--

--

--

--

--

1 (20%)

5 (100%)

4(80%)

3. É essencial o uso dessa

tecnologia no seu dia-a-

dia.

3 (60%)

4 (80%)

1 (20%)

1(20%)

1 (20%)

--

--

--

--

--

4. É difícil registrar

informações nesta

tecnologia.

--

--

--

--

--

--

1 (20%)

--

4 (80%)

5 (100%)

5.Não foi possível

recuperar dados com

essa tecnologia.

--

--

--

--

--

--

--

1 (20%)

5 (100%)

4 (80%)

104

8. CONCLUSÕES E TRABALHOS FUTUROS

Este capítulo objetiva apresentar as conclusões deste trabalho, descrever as

contribuições, dificuldades encontradas e limitações, assim como apresentar as

recomendações para trabalhos futuros.

8.1 SUMÁRIO DAS CONCLUSÕES

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

dos sistemas de informação, a área da saúde vem enfrentando alguns desafios referentes ao

aumento da produtividade e a qualidade no processo de desenvolvimento do HIS. A

complexidade no entendimento dos processos de Cuidado a Saúde é outra relevante

dificuldade encontrada no desenvolvimento dos HIS.

Motivado por estes desafios, e visando minimizar as dificuldades, este trabalho propôs

uma abordagem para o desenvolvimento de HIS baseado em arquétipos e utilizando o

paradigma de desenvolvimento dirigido a modelos. A adoção de MDD na abordagem

proposta ajudou a:

Combater os desafios referentes às necessidades de melhorar a produtividade e qualidade

do processo de desenvolvimento de HIS. A capacidade de automação e a geração de

código resultaram em um ganho da produtividade. Além disso, a mudança do foco das

atividades para a modelagem ofereceu um nível mais alto de abstração, o que

proporcionou uma melhor qualidade do produto;

Minimizar as dificuldades referentes à complexidade do processo de desenvolvimento,

tornando-o mais simples através da geração automática de artefatos que possibilitou uma

diminuição na quantidade de artefatos confeccionados manualmente.

A adoção de Arquétipos na abordagem proposta auxiliou a:

Diminuir a curva de aprendizado dos Conceitos Clínicos, representados através dos

Mapas Mentais;

Aumentar da produtividade na construção dos modelos conceituais, através da adoção

da abordagem Wanderley, que gerou o modelo conceitual a partir de um XML que

representava um Mapa Mental de determinado Conceito Clínico.

105

8.2 CONTRIBUIÇÕES

Como principais contribuições associadas a este trabalho pode-se assinalar:

O próprio desenvolvimento da pesquisa que reúne um rico e variado referencial

teórico, com ênfase em Desenvolvimento Orientado a Modelos e Arquétipos;

Adoção de uma abordagem de desenvolvimento de HIS baseando em Engenharia de

Domínio e Engenharia de Aplicação;

O desenvolvimento de um perfil UML, que adicionado aos programas

transformadores escritos na linguagem MOFScript possibilitaram a geração

automática de vários artefatos executáveis;

O SASVM é um protótipo resultante do estudo de caso executado neste trabalho.

8.3 DIFICULDADES ENCONTRADAS

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

mais relevantes pode-se citar:

Dificuldade de obtenção de informação sobre arquétipos, ausência de treinamentos;

Alta curva requerida de aprendizado referente ao entendimento dos Metamodelos

Arquétipos, tanto o modelo de referência quanto o modelo de Arquétipos. Esses

modelos são complexos, possuindo diagramas de classes enormes, com muitos níveis

de herança, dificultando o entendimento dos comportamentos e responsabilidades das

classes.

8.4 LIMITAÇÕES

Apesar do resultado apresentado na seção 7.2 desse trabalho algumas limitações foram

encontradas, entre as mais relevantes pode-se citar:

Não foram desenvolvidos programas transformadores que contemplassem as regras de

negócio referentes às informações resultantes de cálculos e ou fórmulas clínicas, como

por exemplo: O Índice de Massa Corporal – IMC que é resultado da divisão do peso

corporal sobre o quadrado da altura do paciente;

106

O SASVM não foi integrado a um sistema desenvolvido por terceiros visando validar

a interoperabilidade semântica;

Não foi implementada integrações on-line com dispositivos que medem sinais vitais

do paciente, como por exemplo: termômetro digital.

8.5 TRABALHOS FUTUROS

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

produzido nesta dissertação. Entre esses trabalhos, destacam-se:

A confecção de programas transformadores que tem o objetivo de transformar

automaticamente os Conceitos Clínicos escritos em ADL para Modelo Conceitual em

UML, aumentando assim a produtividade dos especialistas de domínio no

desenvolvimento de HIS;

Desenvolvimento de programas transformadores com o intuito de fazer transformação do

tipo Model to Model - M2M, isto é, converter os modelos conceituais para modelos de

domínio e vice e versa, aumentando assim a produtividade referente às atividades de

refinamento e projeto;

Geração de artefatos relacionados às disciplinas de requisitos e de testes, aumentando a

produtividade e melhorando a qualidade do HIS. Exemplo de artefato a ser produzido: os

testes unitários;

Criação de programas escritos em OCL com o objetivo de validar e garantir a consistência

dos modelos conceituais e modelos de domínio especificados durante a produção do HIS;

Desenvolvimento da integração com equipamentos e/ou dispositivos que aferem sinais

vitais, por exemplo, termômetro, e com isso efetuar o registro dos sinais vitais medidos

on-line na aplicação que roda no dispositivo móvel. Assim, seria eliminada a necessidade

de registro manual pelo paciente.

Outra pesquisa a ser explorada consiste em estender a proposta neste trabalho para

tratar as variabilidades dos Conceitos Clínicos e aplicar técnicas de Linhas de Produtos de

Software na construção dos Conceitos clínicos pertencentes ao domínio OBSERVATION.

107

REFERÊNCIAS

ALHIR, S. Learning UML. Sebastopol: O’Reilly&Associates, Inc. 252p, 2003.

AMELLER, Considering Non-Functional Requirements in Model- Driven Engineering,

2009.

APACHE CORDOVA. Acesso em 07/05/2012. Disponível em:

http://incubator.apache.org/cordova/#about

APACHE VELOCITY, acesso em: 02/02/2012. Disponível em: http://velocity.apache.org/

BEALE, T. Archetype Object Model. Novembro 2008. Acesso em: 22/01/2011. Disponível

em: http://www.openehr.org

BEALE, T. Archetype constraint-based domain models for future-proof information systems.

p. 69, 2001. Disponível em: http://www.deepthought.com.au

BEALE, T. et al. Data Types Information Model. Novembro 2008. Acesso em: 22/03/2011.

Disponível em: http://www.openehr.org

BEALE, T. The openEHR Archetype Model: openEHR Templates. Fevereiro 2010. Acesso

em: 22/03/2011. Disponível em: http://www.openehr.org

BEALE, T; FRANKEL, H. The openEHR Information Model: Extract Information Model.

Maio 2010. Acesso em 22/03/2011. Disponível em: http://www.openehr.org

BEALE, T.; HEARD, S. Archetype Definition and Principles. 2007. Acesso em: 11/01/2011.

Disponível em: http://www.openehr.org

BEALE, T.; HEARD, S. openEHR Architecture Overview. Abril 2007. Acesso em:

22/03/2011. Disponível em: http://www.openehr.org

BEALE, T.; HEARD, S. Archetype Definition Language. Dezembro 2008. Acesso em:

23/03/2011. Disponível em: http://www.openehr.org

108

BEALE, T. et al. Data Structures Information Model. Novembro 2008. Acesso em:

23/03/2011. Disponível em: http://www.openehr.org

BEALE, T. et al. Data Types Information Model. Novembro 2008. Acesso em: 22/03/2011.

Disponível em: http://www.openehr.org

BEALE, T. et al. EHR Information Model. Agosto 2008. Acesso em: 22/03/2011.

Disponível em: http://www.openehr.org

BEALE, T. et al. Support Information Model. 2008. Acesso em: 22/03/2011.

Disponível em: http://www.openehr.org

BEALE, T. et al. Commom Information Model. Abril 2010. Acesso em: 22/03/2011.

Disponível em: http://www.openehr.org

BERGMANN, N. Better Design Methods for eHealth Software, International Journal of

Engineering and Industries, v. 1, n. 1, p. 1-9, 2010.

BEZERRA, E. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro:

Elsevier, 320p, 2002.

BÉZIVIN, On the Unification Power of Models, Software and Systems Modeling, vol. 4, pp.

171-188, 2005.

BITTAR, T. J. et al. Web communication and interaction modeling using model-driven

development. In: Proceedings of the 27th ACM international conference on Design of

communication. New York, NY, USA: ACM, 2009. (SIGDOC ’09), p. 193–198. ISBN 978-

1-60558-559-8. Disponível em: http://doi.acm.org/10.1145/1621995.1622033

BUILD PHONEGAP. Acesso em 07/05/2012. Disponível em: https://build.phonegap.com/

BUZAN, T. The Mind Map Book, BBC Active, 2003.

CAMBRIDGE DICTIONARY - Cambridge University Press. Acesso em: 23/01/2012.

Disponível em: http://www.dictionary.cambridge.org

109

CARVALHO, S, COPETTI, A. E FILHO, O. Sistema de computação ubíqua na assistência

domiciliar à saúde, 2011.

CHEN, P. The Entity-Relationship Model: Toward a Unified View of Data, ACM Trans. on

Database Systems, vol. 1, pp. 9-36, 1976.

CIMI - Clinical Information Modelling Initiative. Acesso em 07/08/2011. Disponível em:

http://www.openehr.org/326-OE

DAVIS, F. D. Perceived Usufulness, Perceived Ease of Use, and User Acceptance of

Information Technology. MIS Quarterly, v. 13, n. 3, p. 318–341, 1989.

DENNIS et al. Archetype-based electronic health records: a literature review and evaluation

of their applicability to health data interoperability and access. Acesso em 03/05/2011.

Disponível em:

http://www.himaa.org.au/members/journal/himj_38_2_2009/wollersheim_archetype-

based_elec_health_rec.pdf

DEURSEN, A. V.; KLINT, P. Little languages: little maintenance? Journal of Software

Maintenance, v. 10, n. 2, p. 75–92, 1998.

DICTIONARY AND THESAURUS - Merriam-Webster Online. Acesso em: 23/01/2012.

Disponível em: http://www.merriam-webster.com

DOWNS, R. G. and Stea D. Image & Environment: Cognitive Mapping and Spatial Behavior,

1973.

ERIKSSON, H. et al. UML 2 Toolkit. Indianapolis: Wiley Publishing, 2004. 552p.

FOWLER, M. home page, Language Workbenches and Model Driven Architecture. Acesso

em: 10/11/2010. Disponível em:

http://martinfowler.com/articles/mdaLanguageWorkbench.html

FRANCE, R.; RUMPE, B. Model-driven development of complex software: A research

roadmap. In: 2007 Future of Software Engineering. Washington, DC, USA: IEEE Computer

110

Society, 2007. (FOSE ’07), p. 37–54. ISBN 0-7695-2829-5. Disponível em:

http://dx.doi.org/10.1109/FOSE.2007.14

FRANKEL, Model Driven Architecture: Applying MDA to Enterprise Computing: Wiley

Publishing, 2003.

FREIRE, S. M. et al. Utilizando o modelo dual para a representação e persistência de contexto

em aplicações ubíquas de telemonitoramento. VIII Workshop de Informática Médica, p. 252–

255, 2008.

FUENTES-FERNÁNDEZ, L.; VALLECILLO-MORENO, A. An introduction to UML

profiles. European Journal for the Informatics Professional, [s.l.]: Novática, v. 5, n. 2, p. 6-

15, 2004.

GAETE, R. A. C. ; RALHA, Célia Ghedini, Proposta Metodologica de Desenvolvimento de

Arquétipos Aplicado a Vigilância Alimentar e Nutricional Em: XII Workshop de Informática

Médica (WIM 2012), 2012, Curitiba. Anais do XII WIM. Porto Alegre : SBC, v. 1, p. 1-10,

2012.

HAJAR, The Intersection of Clinical Decision Support and Electronic Health Record: A

Literature Review. Acesso em: 01/12/2011. Disponível em:

http://fedcsis.eucip.pl/proceedings/pliks/13.pdf

HISTORY HTML – W3C. Acesso em: 03/03/2012. Disponível em:

http://dev.w3.org/html5/spec/introduction.html#history-1

HUMM, U. SCHREIER, and J. SIEDERSLEBEN, Model-Driven Development: Hot Spots in

Business Information Systems, European Conf. on Model Driven Architecture Foundations

and Applications (ECMDA-FA). Nuremberg, Germany, 2005.

INTRODUCING JSON. Acesso em: 05/03/2012. Disponível em: http://www.json.org/

KITCHENHAM, B. and CHARTERS, S. Guidelines for performing Systematic Literature

Reviews in Software Engineering. Technical Report EBSE 2007-001, Keele University and

Durham University Joint Report, 2007.

111

KITCHIN, R. M., Maps Cognitive: O que são eles e porque o estudo deles? Environment

Psychology Journal, 14: 1-19, 1994.

KLEPPE, A.; WARMER, J.; BAST, W., MDA Explained - The Model Driven Architecture

Practice and Promise. [S.l.]: Addison-Wesley, 2003. (Object Technology Series)

KÜHNE T. What is a Model? in Dagstuhl Seminar Proceedings, 2005.

LEITE, A.; GIRARDI, R. Um processo para a engenharia de domínio e de aplicações

multiagente: As fases de projeto de domínio e de aplicações. III Simpósio Brasileiro de

Componentes, Arquiteturas e Reutilização de Software. [S.l.: s.n.], 2009.

LIDDLE, S. W. Model-Driven Software Development. 2010. Acesso em: 07/12/2010.

Disponível em: http://www.deg.byu.edu/papers/LiddleMDD.pdf

LIKERT, R. A Technique for the Measurement of Attitudes. Archives of Psychology, v. 22,

n. 140, 55 p, 1932.

LINKEHR Site, acesso em: 01/12/2011. Disponível em: http://www.linkehr.com/

LUCREDIO, D. Uma Abordagem Orientada a Modelos para Reutilização de Software. Tese

(Doutorado) — Universidade de São Paulo, São Paulo, 2009.

MDA, 2010. Acesso em: 22/09/2010. Disponível em: http://www.omg.org/mda/

MELLOR; A. CLARK; T. FUTAGAMI Model-Driven Development, IEEE Software, vol.

20, pp. 14-18, 2003.

MELLOR; BALCER, Executable UML: A Foundation for Model-Driven Architecture:

Addison Wesley, 2002.

MENEZES, A. L.; CIRILO, C. E.; MORAES, L. C.; SOUZA, W. L.; PRADO, A. F.,

Using Archetypes and Domain Specific Languages on Development of Ubiquitous

Applications to Pervasive Healthcare. In: Proceedings of the 23rd IEEE International

Symposium on Computer-Based Medical Systems - CBMS. Perth, 2010.

112

MERNIK, M.; HEERING, J.; SLOANE, A. M. When and how to develop domain-specific

languages. ACM Comput. Surv., ACM, New York, NY, USA, v. 37, p. 316–344, December

2005. ISSN 0360-0300. Acesso em: 10/09/2010. Disponível em:

http://doi.acm.org/10.1145/1118890.1118892

MOF 2.0, 2006. Acesso em: 22/09/2010. Disponível em: http://www.omg.org/spec/MOF/2.0/

MOFSCRIPT, acesso em 10/06/2011. Disponível em: http://www.eclipse.org/gmt/mofscript/

NARDON, F, FRANÇA, T. e NAVES, H., Construção de Aplicações em Saúde Baseadas em

Arquétipos, XXI Congresso Brasileiro de Informática em Saúde (CBIS), 2011.

OBJECT MANAGEMENT GROUP - OMG. MDA Guide, v.1.0.1, OMG Document

formal/2003-06-01 edition. Needham, MA, USA, 2003.

OBJECT MANAGEMENT GROUP. Unified Modeling Language: Superstructure, v. 2.1.2,

OMG Document formal/2007-11-02 edition. Needham, MA, USA, 2007.

OCL - Object Constraint Language, 2009a. Acesso em: 16/10/2010. Disponível em:

http://www.omg.org/technology/documents/formal/ocl.htm

OLDEVIK, J. MOFScript Eclipse PlugIn: MetamodelBased Code Generation. In: eclipse

technology exchange workshop, Nantes. Nantes: [s. n.], 2006.

OLDEVIK, J. MOFScript User Guide. p.33. Guia do usuário, [s. l.]: [s. n.], 2009.

OPENEHR CKM. Clinical Knowledge Manager. 2011. Acesso em: 10/10/2011.

Disponível em: http://www.openehr.org/knowledge/

OPENEHR. openEHR Fundation. 2011. Acesso em: 22/10/2011. Disponível em:

http://www.openehr.org

PAPYRUS UML. Acesso em: 10/07/2011. Disponível em: www.papyrusuml.org/

PHONEGAP FRAMEWORK. Acesso em: 01/05/2012. Disponível em:

http://phonegap.com/about

113

POOLEY, R. J.; WILCOX, P. Applying UML: advanced application. Oxford: Butterwort-

Heinemann, 2004.

POPMA, R. JET Tutorial Part 1 (Introduction to JET). May 2004. Eclipse Corner Article.

Acesso em: 10/11/2010. Disponível em:

http://www.eclipse.org/articles/Article-JET/jet_tutorial1.html

PORRES, I. et al. Development of an Ubiquitous Decision Support System for Clinical

Guidelines using MDA. In: 19TH INTERNATIONAL CONFERENCE ON ADVANCED

INFORMATION SYSTEMS ENGINEERING, 2007, Trondheim. Proceedings. Trondheim:

Springer, 2007.

PORTARIA Nº 2.073. Acesso em: 24/12/2011. Disponível em:

http://bvsms.saude.gov.br/bvs/saudelegis/gm/2011/prt2073_31_08_2011.html

PRESSMAN, R. S., Software Engineering: a Practitioner's Approach. [S.l.]: McGraw-Hill,

2005.

SAMPAIO, G. B. GeoProfile – Um Perfil UML para Modelagem Conceitual de Bancos de

Dados Geográficos. 65f. Dissertação (Mestrado em Ciência Da Computação). Universidade

Federal de Viçosa, Viçosa, 2009.

SCHMIDT, D. C. Guest editor’s introduction: Model-driven engineering. IEEE Computer

v.39, n. 2, p. 25–31, 2006.

SEIDEWITZ E., What Models Mean, IEEE Software, vol. 20, pp. 26-32, 2003.

SILVA, M. S. CSS3 - desenvolva aplicações web profissionais com uso dos poderosos

recursos de estilização das css3, 2007.

SILVA, M. S. JQuery Mobile Desenvolva aplicativos para dispositivos móveis com HTML5,

CSS3, AJAX, Jquery e JQuery UI, 2012.

SOFTWARE ENGINEERING INSTITUTE - SEI. Current Perspectives on Interoperability.

ISR Technical Report # CMU/SEI-2004-TR-009 ESC-TR-009. Carnegie Mellon, Pittsburgh,

EUA, 2004. 2p.

114

SOUZA, R E DE OLIVERA, A., Abordagens Orientadas a Modelos no desenvolvimento de

software em Saúde: Contribuições e Perspectivas. Acesso em: 01/08/2012. Disponível em:

http://www.lbd.dcc.ufmg.br/colecoes/wim/2012/001.pdf

STAFIELD, B. Atenção primária: equilíbrio entre necessidades de saúde, serviços e

tecnologia, volume 4. UNESCO, Ministério da Saúde, Brasília, Brasil, 2002.

STEINBERG, D. et al. EMF Eclipse Modeling Framework. [S.l.]: Addison-Wesley, 2008.

VOELTER, M.; GROHER, I. Product line implementation using aspect-oriented and model-

driven software development. Software Product Line Conference, International, IEEE

Computer Society, Los Alamitos, CA, USA, v. 0, p. 233–242, 2007.

WANDERLEY, F.; DA SILVEIRA, D. An Infrastructure to Diminish the Gap between the

Business Specialist and the Software Designer, 8th International Conference on the Quality

of Information and Communications Technology, Lisbon, Portugal, 3 to 6 September 2012.

WATSON, A. UML vs. DSL: a false dichotomy, [s. l.]: [s. n.], 2007.

XMI 2.1.1, 2007. Acesso em: 25/09/2010. Disponível em:

http://www.omg.org/spec/XMI/2.1.1/