Vous êtes sur la page 1sur 114
U NIVERSIDADE DE P ERNAMBUCO E SCOLA P OLITÉCNICA DE P ERNAMBUCO P ROGRAMA DE

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.

U NIVERSIDADE DE P ERNAMBUCO E SCOLA P OLITÉCNICA DE P ERNAMBUCO P ROGRAMA DE

UNIVERSIDADE DE PERNAMBUCO

ESCOLA POLITÉCNICA DE PERNAMBUCO

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

Legilmo Marcelo Fontes de Oliveira

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

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

Orientador: Prof. Dr. Vinicius Cardoso Garcia

Recife, 2012.

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

AGRADECIMENTOS

Os meus sinceros agradecimentos são destinados:

Aos meus pais, Lélia Oliveira e João Gilberto, que em toda minha vida me incentivaram a crescer com conhecimento. Em especial, a minha mãe pelos conselhos, incentivos e cuidados contínuos;

Aos meus irmãos: João Gilberto, Wellington Andre e Gíllia Valeria pelo companheirismo. Agradeço principalmente à minha irmã Gíllia, pelo seu exemplo de luta, pelo apoio, incentivo e união de sempre;

À minha esposa, Daniela Eugenia, que me ajudou desde a inscrição do mestrado, e que esteve presente em todas as etapas, até o final. Para cada “vai conseguir!” dita, por me tranquilizar nos meus momentos de estresse, por me alegrar, por me fazer feliz e muitas vezes e efetuar o meu papel de pai dos nossos filhos, suprindo a minha ausência por causa da minha dedicação ao mestrado;

Aos meus filhos Mariela, Fernanda e Daniel. A presença de vocês na minha vida é um estímulo de energia. Foi em vocês que ganhei forças para ultrapassar cada dificuldade encontrada durante o mestrado;

À minha família em geral, tios e primos. Em especial a minha tia Ivone, que é uma referência de conhecimento e experiência, fornecendo informações essenciais nas minhas escolhas;

Aos amigos, Jose Damaricio, Marcos Pereira, Felipe Leão, Christian Lins, Rafael Oliveira, Guilherme Camacho e Priscila Alcantara pelas experiências compartilhadas durante esses anos. Em especial, a Jose Damaricio pelas orientações, sugestões técnicas, companheirismo e contínua colaboração;

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

A minha sogra e ao meu sogro: Lucineide e Antonio, pelo apoio dado e o preenchimento do vazio que deixo em casa por causa da minha ausência pelo envolvimento no mestrado;

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

Aos amigos da UPE, Eric Souza, Ariane Nunes, Maurício Manoel, Anthony Lins e Fernando Wanderley pelas experiências compartilhadas durante as disciplinas. Em

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 nanceiramente, 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 !

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

Sandro Andrade

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

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

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

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

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

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

CBISCongresso Brasileiro de Informática de Saúde

CCs Conceitos Clínicos

CIM Modelo Independente da Computação

CKMClinical 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

JSONJavaScript 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

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

UML Unified Modeling Language XMI XML Metadata Interchange

Interface do Usuário

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

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

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.

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.

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;

de ferramentas para o desenvolvimento orientado a modelos, com

Implementação

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;

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.

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;

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).

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

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.

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

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.

ser desenvolvidos em qualquer estágio de uso dos mesmos. Figura 2. Informação x Arquétipos A Figura

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.

Figura 3. Estrutura de pacotes (OPENEHR, 2011) Conforme ilustrado na Figura 3 e descrito em

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.

core, patterns e domain, cada um com seus respectivos pacotes e subdivisões. Figura 4. Pacote Core

Figura 4. Pacote Core RM (OPENEHR, 2011)

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.

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

uma lista de listas, ou outra estrutura de profundidade Figura 5. Visão dos pacotes do patterns

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.

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

configurações de privacidade para a informação no RES. Figura 6. Pacotes pertencentes ao domain (OPENEHR, 2011)

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.

dos pacotes composition e ehr são apresentados na Figura 7. Figura 7. Modelo de informação EHR

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

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.

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

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

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.

uma visão detalhada do modelo das informações demográficas. Figura 9. Modelo Dados Demográficos (OPENEHR, 2011) 31

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

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.

dos arquétipos e templates, bem como o seu uso na openEHR. Figura 10. Estrutura do Pacote

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.

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.

2008). Uma visão geral da estrutura de uma ADL é apresentada na Figura 11. Figura 11.

Figura 11.Estrutura ADL (OPENEHR, 2011)

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.

trecho da ADL do arquétipo para o registro dos dados do paciente. Figura 12. ADL Dados

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

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.

Figura 13. Mapa Mental de Temperatura Corporal (OPENEHR CKM, 2011) 2.5 S ÍNTESE DO C

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.

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

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).

diferentes níveis de abstração (VOELTER; GROHER, 2007). Figura 14. Processo de Criação de Software (LUCRÉDIO,

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

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.

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

O conceito de ER é o princípio básico fundamental para modelagem

informações

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

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.

Figura 15. Representação das iniciativas de Moden-Driven (AMELLER, 2009) Na MDA são descritos três tipos

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.

16 que apresenta o sentido dos três níveis de abstração. Figura 16. Níveis de abstrações de

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.

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. sistema atribui um identificador para o pacote.

O

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

O

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:

É mostrado na caixa cortada (pontilhada) da Figura 17: Figura 17. Fluxo de Transformação Geral As

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.

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.

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 metamodelo 1 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.

produção de software e a camada M0 são os objetos em si. Figura 18. Quatro Camadas

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.

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

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).

Object

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

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

Constraints

podem

ser

expressas

usando

uma

linguagem

natural,

ou

a

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.

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.

value required com o valor true referente ao atributo value. Figura 19. Exemplo de preenchimento de

Figura 19.Exemplo de preenchimento de tagged value no modelo

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

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:

As linguagens declarativas

Lisp, Haskell, SQL, etc duas anteriores.

Já as linguagens híbridas são aquelas combinam características das

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.

Figura 20. Interface da ferramenta UML Papyrus Entre outros recursos interessantes para modelagem de sistemas

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.

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

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.

Figura 21. Exemplo de HTML com Jquery Mobile 4.2 H YPERTEXT M ARKUP L ANGUAGE

Figura 21.Exemplo de HTML com Jquery Mobile

É 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

Figura 22. Linha do tempo HTML Na década de 1990, o HTML ganhou popularidade quando

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

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

apresenta um exemplo do trecho código na linguagem HTML5. Figura 23. Exemplo de Código HTML5 4.3

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,

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

demonstra a definição padrão e um exemplo básico do CSS Figura 24. Definição e Exemplo de

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.

seção. A Figura 25 apresenta a linha do tempo referente à evolução do CSS. Figura 25.

Figura 25.Linha do Tempo CSS (W3C)

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:

Figura 26. Modelo e Exemplo de JSON Um objeto é um conjunto sem ordenação dos

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.

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.

na escolha desse framework na realização desse trabalho. Figura 27. Plataformas suportadas com FPG (PHONEGAP

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

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

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.

Em 2009: Em abril de 2009 o FPG foi vencedor do Web 2.0 Expo LaunchPad e ainda no primeiro semestre foram lançadas duas novas versões dessa API, as versões: 0.6.0 e a 0.7.2 para Android e IPhone. No início do segundo semestre foram adicionados o suporte as plataformas:Windows Mobile e Nokia WRT. No último trimestre do ano a versão 0.8 foi aceita pela Apply para AppStore, a infoWorld elegeu o FPG como “top emerging enterprise technology” na categoria "cross-platform mobile app development" e no final desse ano foi adicionado o suporte para Palm.

Em 2010: A plataforma Symbian adicionou o FPG.

Em 2011: Ocorreu a publicação da versão candidata 1.0 do FPG. Em outubro desse ano a empresa Adobe anunciou a aquisição da empresa Nitobi Software fabricante da FPG. O código do FPG foi contribuído para a Apache Software Foundation visando iniciar um novo projeto chamado Apache Cordova. Neste trabalho, iremos utilizar a sigla FPG para representar o Apache Cordova ou framework PhoneGap com o objetivo de uniformizar o nome do framework e facilitar as suas citações nas próximas seções desse documento (APACHE CORDOVA, 2012).

Em 2012: Em janeiro de 2012 foi publicada a versão 1.4 contendo várias correções e novidades para as diversas plataformas móveis. A última versão baixada e utilizada no desenvolvimento deste trabalho foi a versão 1.9.

Inicio do FPG
Inicio
do FPG

2008

Integração Symbian
Integração
Symbian

2010

Lançamento das versões 1.4 até a 1.9 2012
Lançamento
das versões 1.4
até a 1.9
2012
Symbian 2010 Lançamento das versões 1.4 até a 1.9 2012 O FPG foi premiado 2009 2011
O FPG foi premiado
O FPG foi
premiado

2009

2011

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

Figura 29.Histórico anual do FPG

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).

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

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.

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.

5.

TRABALHOS RELACIONADOS

- mapeamento do estado da arte na abordagem de desenvolvimento orientado a modelos utilizando modelos clínicos - arquétipos.

o levantamento e

Este capítulo descreve uma revisão bibliográfica

RB para

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

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.

Definição das Definição das Realização da Seleção dos Classificações Publicação das Fontes de Questões
Definição das
Definição das
Realização da
Seleção dos
Classificações
Publicação das
Fontes de
Questões
Pesquisa
Estudos
dos Estudos
Conclusões
Dados
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?

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

Figura 32. Fluxo do Processo da Pesquisa 5.2.4 S ELEÇÃO DOS E STUDOS Como pode

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,

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

Eliminar

artigos

resumo e

avaliando o título, resumo e conclusão.

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.

Critério Inicial 39 trabalhos
Critério Inicial
39 trabalhos
Critério por Duplicidade 32 trabalhos
Critério por Duplicidade
32 trabalhos

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

2 trabalhos

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

5.2.5 CLASSIFICAÇÃO DOS ESTUDOS

Após a seleção das obras observou-se a necessidade de classificá-las de acordo com seu conteúdo. As classificações dos estudos foram realizadas seguindo a mesma idéia de categorização que utiliza duas facetas, por se tratar de uma maneira estruturada de fazer tal tarefa (KITCHENHAM, 2007). A primeira faceta é baseada nas questões criadas para guiar a pesquisa (seção 3.2.2), e a outra faceta de acordo com o tipo de pesquisa. A execução da classificação foi apenas realizada no conjunto final dos estudos, ou seja, após os processos de filtragem. As classes que formam a faceta de tipos de pesquisa estão descritas na Tabela 6.

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

Classes

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

 

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

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

Experiências

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

A model-driven approach for representing clinical archetypes for Semantic Web environments (Catalina et al, 2008).

Solução

02

Proposta de

Clinical data interoperability based on archetype transformation (Catalina et al, 2011).

Solução

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

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.

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

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.

A Figura 34 apresenta a visão da abordagem proposta. Figura 34. Visão da Abordagem Proposta Na

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.

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

reutilização, é chamado de Engenharia de Domínio e o desenvolvimento de um produto (desenvolvimento com reutilização), de Engenharia de Aplicação (LUCRÉDIO, 2009).

Para essa abordagem, utilizamos a engenharia de domínio com foco na análise de domínio clínico, usando como referência os Modelos de Arquétipos - AMs, selecionando os requisitos semelhantes que pertencem ao subdomínio OBSERVATION. Conforme detalhado na seção 2.2, a classe genérica OBSERVATION é uma das quatro classes que especializam a classe CARE_ENTRY e é utilizada para registro de informações de Cuidado á Saúde. As informações de Cuidado a Saúde registradas são: os registros de tudo que puder ser observado, medido ou respondido pelo paciente. Esses requisitos são independentes de especialidade médica, por exemplo: Temperatura Corporal.

Além disso, de acordo com a abordagem de Lucrédio (2009) foi adicionada o uso de MDD na Engenharia de Domínio com o objetivo da modelagem fazer parte desta abordagem, para aumentar o nível de abstração do desenvolvimento das soluções de cuidado a saúde. A Figura 35 apresenta as duas etapas da abordagem.

Engenharia de Domínio + MDD Engenharia de Aplicação
Engenharia de Domínio
+ MDD
Engenharia de
Aplicação

Figura 35.Etapas da abordagem

Na ED os mapas mentais do subdomínio clínico dos arquétipos são selecionados e recuperados do repositório Clinical Knowledge Manager - CKM (OPENEHR, 2012). O modelo conceitual é refinado e projetado utilizando a ferramenta MagicDraw que é uma ferramenta para modelagem baseada na UML e utilizada pela OpenEHR na definição dos seus metamodelos de arquétipos - AOM (OpenEHR, 2011); são implementadas: o componente de apoio e as transformações M2C para a geração de artefatos reusáveis;

Todos os artefatos da ED são usados como apoio a Engenharia de aplicação EA, onde os sistemas de cuidado de saúde são desenvolvidos baseados no refinamento dos metamodelos da ED. Alguns dos artefatos são utilizados no refinamento e nas transformações.

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.

como: Análise de Domínio, Projeção e Implementação. Figura 36. Diagrama do Macroprocesso - Engenharia de

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.

Figura 37. Diagrama do Macroprocesso - Engenharia de Aplicação 6.3 E TAPAS DA A BORDAGEM

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.

Figura 38. Processo Proposto para Engenharia de Domínio Análise de Domínio - AD Conforme exposto

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).

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

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.

com o refinamento do tipo e do nome do atributo. Figura 39. Exemplo de Modelo Conceitual

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.

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

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.

Figura 41. Diagrama de Classe do perfil UML A atividade Implementar Complemento , visa complementar

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.

Figura 42. Tela inicial A atividade Desenvolver Transformações M2C é responsável pela construção dos programas

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.

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

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

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

Regras de Transformação

Extensã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

 

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.

Figura 44. Diagrama de Processo EA Na abordagem proposta, a etapa EA é responsável pela

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.

visam coletar observações sobre sinais vitais do paciente. Figura 45. Mapas mentais do SOT (OPENEHR CKM,

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

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.

das aferições das temperaturas corporais do paciente. Figura 46. Diagrama de Casos de Uso do SOT

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.

Figura 47. Diagrama de Sequência para registrar Temperatura Corporal Projeto Nesta fase os artefatos resultantes

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

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.

um trecho do código da tela gerada em HTML5 da aplicação SOT. Figura 48. Trecho de

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

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.

um trecho de código da tela inicial do sistema SOT. Figura 49. Trecho de código da

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.

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.

(analista de sistemas). A Figura 50 ilustra a interface da aplicação SOT em execução. Figura 50.

Figura 50.SOT em execução

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.

apresenta uma visão geral do funcionamento da aplicação – SASVM. Figura 51. Visão Funcional do aplicativo

Figura 51.Visão Funcional do aplicativo SASVM

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.

Neste retorno foram analisados alguns mapas mentais apresentados na Figura 52. Figura 52. Alguns Mapas Mentais

Figura 52.Alguns Mapas Mentais do SASVM

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.

Figura 53. Diagrama de Casos de Uso do SASVM Depois de iniciar o levantamento de

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).

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

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.

Figura 55. Mapeamento de Modelo conceitual para Modelo de Domínio 7.1.3 I MPLEMENTAÇÃO Nesta fase
Figura 55. Mapeamento de Modelo conceitual para Modelo de Domínio 7.1.3 I MPLEMENTAÇÃO Nesta fase
Figura 55. Mapeamento de Modelo conceitual para Modelo de Domínio 7.1.3 I MPLEMENTAÇÃO Nesta fase

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.

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.

a funcionalidade de adicionar o peso corporal do paciente. Figura 56. Trecho de código HTML5 e

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

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.

telas referentes ao registro de sinais e medidas do SASVM. Figura 57. Testes do registro de

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

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.

conforme interface da tela apresentada na Figura 58. Figura 58. Testes da Consulta do Histórico Sinal

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.

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.

com valor calculado, como acontece com Blood Pressure. Figura 59. Gráfico LOC Automática x Manual dos

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).

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

Concorda

Nem concorda nem discorda

Discorda

Discorda

plenamente

parcialmente

parcialmente

totalmente

1.Foi fácil utilizar a tecnologia apresentada.

4

(80%)

1 (20%)

--

--

--

5 (100%)

--

--

--

--

2.Adoção dessa tecnologia dificulta a relação médico-paciente.

 

--

--

--

--

5

(100%)

--

--

--

1 (20%)

4(80%)

3. É essencial o uso dessa tecnologia no seu dia-a- dia.

3 (60%)

1 (20%)

1 (20%)

--

--

4 1(20%)

(80%)

--

--

--

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.

 

--

--

--

--

5

(100%)

--

--

--

1 (20%)

4

(80%)

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.

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;

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.

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:

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

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

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. Disp