Uma abordagem orientada a modelos no desenvolvimento de sistemas clínicos baseado em arquétipos
-
Upload
vinicius-cardoso-garcia -
Category
Documents
-
view
315 -
download
1
description
Transcript of Uma abordagem orientada a modelos no desenvolvimento de sistemas clínicos baseado em arquétipos
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/