MODELO DE OBJETOS DO OPENEHR: UMA …DOAJ – Directory of Open AccesS Journals EHR – Electronic Health Record FDP – Foreign Data Providers FOL – First-Order predicate Logic

UNIVERSIDADE FUMEC – FUNDAÇÃO MINEIRA DE EDUCAÇÃO E CULTURA FACULDADE DE CIÊNCIAS EMPRESARIAIS – FACE

MESTRADO PROFISSIONAL EM SISTEMAS DE INFORMAÇÃO E GESTÃO DO CONHECIMENTO

REINALDO ARAÚJO DE ALKIMIM

MODELO DE OBJETOS DO OPENEHR: UMA AVALIAÇÃO EM

TERMOS DE QUALIDADE DE PROJETO ORIENTADO A OBJETO

Belo Horizonte

2014

REINALDO ARAÚJO DE ALKIMIM

MODELO DE OBJETOS DO OPENEHR: UMA AVALIAÇÃO EM TERMOS DE QUALIDADE DE PROJETO ORIENTADO A OBJETO

Dissertação apresentada ao Curso de Mestrado Profissional em Sistemas de Informação e Gestão do Conhecimento da Faculdade de Ciências Empresariais da Universidade Fundação Mineira de Educação e Cultura –FUMEC. Orientador: Prof. Dr. Fernando Silva Parreiras Coorientador: Prof. Dr. Marcelo Rodrigues dos Santos Área de concentração: Gestão de Sistemas de Informação e do Conhecimento. Linha de pesquisa: Tecnologia e Sistemas de Informação

Belo Horizonte 2014

Dedico este trabalho à minha mãe Thereza Marilac de

Araújo por todo incentivo e sacrifício que ela fez pelos

meus estudos em todas as fases de minha vida.

AGRADECIMENTOS

Agradeço a Deus pela saúde que tem me dado, ao longo de minha vida, para que

eu possa superar todos os obstáculos impostos.

Ao Professor Dr. Fernando Silva Parreiras, meu orientador, por todas as

contribuições para a qualidade deste trabalho e, principalmente, pela compreensão e incentivo

que teve para que eu conseguisse concretizá-lo.

Ao Professor Dr. Marcelo Rodrigues dos Santos, meu coorientador, pela

idealização deste trabalho e contribuição com seu grande conhecimento em Tecnologia da

Informação e Comunicação em Saúde.

A todos meus familiares, em especial minha mãe, Thereza Marilac de Araújo, e

meu irmão, Ricardo Araújo de Alkimim, que acompanharam de perto toda a minha trajetória

de vida até chegar neste momento especial.

À minha noiva Carla Cristina Santos, que esteve ao meu lado durante todo o

mestrado. Em especial, por sua compreensão e carinho nos vários momentos difíceis que

passei durante o decorrer do curso.

À empresa CONSULTBRASIL, pelo apoio e incentivo. Em especial, ao meu

gerente Edson Marçal Junior, pela compreensão nos momentos em que tive que dedicar a esta

dissertação.

Por fim, agradeço a todos que, direta ou indiretamente, ajudaram-me na conclusão

deste trabalho.

“Aquilo que não me destrói, me fortalece.”

(Friedrich Nietzsche)

RESUMO

Os sistemas de informação das instituições de saúde devem ser capazes de

comunicar entre si para apoiar a atenção ao paciente em diversos níveis. Para viabilizar este

objetivo, foi criado o Registro Eletrônico de Saúde (RES), um repositório de dados do

histórico integrado de saúde de um paciente processável eletronicamente, transmitido e

acessível por múltiplos usuários ou várias instituições de saúde. Dos principais padrões que

tratam a interoperabilidade em sistemas RES, destaca-se a abordagem da Fundação openEHR.

Entretanto, existem vários desafios na implementação de sistemas de RES por parte das

instituições de saúde. Na busca de soluções para os diversos desafios e problemas

relacionados ao desenvolvimento de software, métricas têm sido propostas na Engenharia de

Software. Especificamente, as métricas de Orientação a Objetos (OO) são as mais

direcionadas ao padrão openEHR, visto que ele possui um Modelo de Objetos que utiliza os

conceitos de OO. Este trabalho propõe avaliar a qualidade de Projeto Orientado a Objeto

(POO) do Modelo de Objetos do openEHR, utilizando métricas de OO. Dessa forma, uma

revisão bibliográfica foi feita para identificar o conjunto de métricas de OO e uma estratégia

para efetivação da medição. Após isso, um estudo experimental foi planejado e conduzido,

utilizando os artefatos da implementação em Java do openEHR e o conjunto de métricas OO

escolhido. Duas ferramentas de métricas de OO foram utilizadas no apoio do estudo

experimental para coleta das métricas e exportação dos resultados. A análise dos resultados

identificou que os atributos de qualidade, Reusabilidade e Funcionalidade, satisfizeram as

expectativas do modelo de qualidade. Já os atributos de qualidade, Extensabilidade e

Flexibilidade, mostraram-se instáveis, enquanto o atributo de qualidade Facilidade de

Compreensão esteve em todas as versões analisadas. Como resultado complementar, foram

identificados seis problemas de POO do total de dez previstos em estratégias de detecção de

problemas de POO.

Palavras-chave: Registro Eletrônico de Saúde. Modelo de Referência. Modelo de Objetos de

Arquétipos. Modelagem de Dois Níveis. OpenEHR. Métrica de Software. Qualidade de

Projeto Orientado a Objeto. Estudo Experimental.

ABSTRACT

The health institutions information systems must be able to communicate with each other to

support patient care at various levels. To facilitate this goal, was created the Electronic Health

Record (EHR), a repository of historical health data integrated of a patient, that is processable

electronically, transmitted and accessed by multiple users or multiple health institutions. In

Major standards that discuss interoperability in EHR systems, highlights the approach of the

openEHR Foundation. However, there are several challenges in the implementation of EHR

systems by health institutions. In the search for solutions to many challenges and problems in

software development, metrics have been proposed in Software Engineering. Specifically,

Object Oriented (OO) metrics are more directed to openEHR standard, since it has an Object

Model that uses the concepts of OO. This work proposes to evaluate the quality of Object

Oriented Design (OOD) of the openEHR Object Model, using OO metrics. Thus, a literature

review was done to identify the set of OO metrics and a strategy for effective measurement.

After, an experimental study was designed and conducted using the openEHR Java reference

implementation artifacts and OO metrics suite were chosen. Two OO metrics tools were used

to support the experimental study to collect metrics and to export the results. The results

identified that the quality attributes of Reusability and Functionality satisfied the expectations

of the quality model. The quality attributes of Flexibility and Extensibility proved unstable,

while the quality attribute Understandability decreased in all decreased versions. As a

complementary result, were identified six problems of OOD in ten planned for detection

strategies of problems of OOD.

Keywords: Electronic Health Record. Reference Model. Archetype Object Model. Two Level

Modeling. OpenEHR. Software Metrics. Quality of Object Oriented Design. Experimental

Study.

LISTA DE FIGURAS

FIGURA 1 – Visão geral do processo de estudo experimental .............................................. 19

FIGURA 2 – Contextualização de ambiente RES e seus relacionamentos ............................ 23

FIGURA 3 – Ambiente de modelagem do openEHR para geração de artefatos de software . 25

FIGURA 4 – Objetos do processo de parsing do ADL ......................................................... 28

FIGURA 5 – Exemplo de diagrama de classes com a classe Archetype e relacionamentos ... 30

FIGURA 6 – Níveis do modelo de qualidade QMOOD ........................................................ 36

FIGURA 7 – Exemplo de níveis do QMOOD para o atributo de qualidade Reusabilidade .... 37

FIGURA 8 – Estratégia de detecção de problemas de POO Classe Deus .............................. 45

FIGURA 9 – Estratégia de detecção de problema de POO Inveja de Funcionalidade ............ 46

FIGURA 10 – Estratégia de detecção de problema de POO Classe de Dados ....................... 47

FIGURA 11 – Estratégia de detecção de problema de POO Método Cérebro ....................... 48

FIGURA 12 – Estratégia de detecção de problema de POO Classe Cérebro ......................... 49

FIGURA 13 – Estratégia de detecção de problema de POO Acoplamento Intensivo ............. 51

FIGURA 14 – Estratégia de detecção de problema de POO Cirurgia de Espingarda ............. 52

FIGURA 15 – Estratégia de detecção de problema de POO Herança do Pai Recusada ......... 53

FIGURA 16 – Estratégia de detecção de problema de POO Quebrador de Tradição ............. 55

FIGURA 17 - Estratégia de pesquisa para as questões de pesquisa Q1 a Q3 ......................... 59

FIGURA 18 - Estratégia de pesquisa para a questão de pesquisa Q4 .................................... 60

LISTA DE GRÁFICOS

GRÁFICO 1 – Distribuição geográfica dos estudos relacionados ao openEHR..................... 61

GRÁFICO 2 – Evolução anual dos estudos relacionados ao openEHR ................................. 63

GRÁFICO 3 – Resultado das propriedades de projeto nas versões do JRI ............................ 79

GRÁFICO 4 – Resultado dos atributos de qualidade Flexibilidade, Funcionalidade,

Extensibilidade e Reusabilidade ........................................................................................... 81

GRÁFICO 5 – Resultado do atributo de qualidade Facilidade de Compreensão ................... 82

LISTA DE QUADROS

QUADRO 1 – Cruzamento objetivos específicos X metodologias ........................................ 20

QUADRO 2 – Atributos de qualidade de POO do modelo de qualidade QMOOD ............... 38

QUADRO 3 – Propriedades de POO do modelo de qualidade QMOOD .............................. 39

QUADRO 4 – Relacionamento de atributos de qualidade X propriedades no QMOOD ........ 40

QUADRO 5 – Propriedade de POO X Métrica no QMOOD ................................................ 41

QUADRO 6 – Resultado das ferramentas encontradas para coleta de métricas de OO .......... 65

QUADRO 7– Relacionamento de versões do Modelo de Objetos do openEHR X JRI .......... 72

QUADRO 8 – Definição do experimento ............................................................................. 73

LISTA DE TABELAS

TABELA 1 – Base estatística de valores limites para estratégia de detecção ........................ 43

TABELA 2 – Resultado das estratégias de detecção de problemas de POO .......................... 75

TABELA 3 – Resultado das propriedades de projeto com base no QMOOD ........................ 77

TABELA 4 – Resultado normalizado das propriedades de projeto com base no QMOOD ... 78

TABELA 5 – Resultado dos atributos de qualidade com base no QMOOD .......................... 80

LISTA DE SIGLAS E ABREVIATURAS

ADL – Archetype Definition Language

AMW – Average Method Weight

ANA – Average Number of Ancestors

ATFD – Access To Foreign Data

BDTD – Biblioteca Digital de Teses e Dissertações

BOvR – Base Class Overriding Ratio

BUR – Base Class Usage Ratio

CAM – Cohesion Among Method of Class

CC – Changing Classes

CG – Clínica Geral

CDISP – Coupling Dispersion

CFM – Conselho Federal de Medicina

CINT – Coupling Intensity

CIS – Class Interface Size

CM – Changing Methods

CYCLO – Cyclomatic Number

DAM – Data Access Metric

DCC – Direct Class Coupling

DSC – Design Size in Classes

DSOO – Desenvolvimento de Software Orientado a Objeto

DOAJ – Directory of Open AccesS Journals

EHR – Electronic Health Record

FDP – Foreign Data Providers

FOL – First-Order predicate Logic

GQM – Goal Question Metric

HL7 – Heath Level Seven

IHE – Integrating the Healthcare Enterprise

ISO – International Standardization Organization

JRI – Java Reference Implementation

LAA – Locality of Attribute Accesses

LOC – Lines of Code

MAXNESTING – Maximum Nesting Level

MFA – Measure of Functional Abstraction

MML – Medical Markup Language

MOA – Modelo de Objetos de Arquétipos

MOA – Measure of Agregation

MR – Modelo de Referência

NAS – Number of Added Services

NOAM – Number of Accessor Methods

NOAV – Number of Accessed Variables

NOH – Number of Hierarchies

NOM – Number of Methods

NOP – Number of Polimorphic Methods

NProtM – Number of Protected Members

OMG – Object Management Group

OO – Orientação a Objeto

OpenEHR – Fundação openEHR

OWL – Web Ontology Language

PEP – Prontuário Eletrônico do Paciente

PNAS – Percentage of Newly Added Services

POO – Projeto Orientado a Objeto

QMOOD – Quality Model for Object-Oriented Design

RES – Registro Eletrônico de Saúde

SAAT – Software Architecture Analysis Tool

SBIS – Sociedade Brasileira de Informática em Saúde

SI – Sistema de Informação

SLR – Systematic Literature Review

TCC – Tight Class Cohesion

TICS – Tecnologia da Informação e Comunicação em Saúde

UML – Unified Modelling Language

UTI – Unidades de Terapia Intensiva

WMC – Weighted Method Count

XML – eXtensible Markup Language

SUMÁRIO

1 INTRODUÇÃO ............................................................................................................... 15 1.1 Problema de pesquisa ................................................................................................... 18

1.2 Justificativa .................................................................................................................. 18

1.3 Objetivos geral e específicos ........................................................................................ 18

1.4 Procedimentos metodológicos ...................................................................................... 19

2 FUNDAMENTAÇÃO TEÓRICA .................................................................................. 22

2.1 Registro Eletrônico de Saúde ....................................................................................... 22

2.1.1 Modelo de Objetos do openEHR................................................................................. 24

2.1.1.1 Modelo de Referência ............................................................................................... 26

2.1.1.2 Modelo de Objeto de Arquétipos............................................................................... 27

2.2 Qualidade de Projeto Orientado a Objeto .................................................................. 31

2.2.1 Métrica de Orientação a Objeto .................................................................................. 31

2.2.2 Modelo de Qualidade QMOOD .................................................................................. 36

2.2.2.1 Primeiro nível - Atributos de Qualidade ................................................................... 37

2.2.2.2 Segundo nível - Propriedades de POO ..................................................................... 39

2.2.2.3 Terceiro nível - Métricas .......................................................................................... 40

2.2.2.4 Quarto nível - Componentes ..................................................................................... 41

2.2.3 Estratégias de detecção de problemas de Projeto Orientado a Objeto ........................ 42

2.2.3.1 Valores limites das estratégias de detecção de POO ................................................. 42

2.2.3.2 Estratégia de detecção “Classe Deus” ..................................................................... 44

2.2.3.3 Estratégia de detecção “Inveja de Funcionalidade” ................................................. 45

2.2.3.4 Estratégia de detecção “Classe de Dados” .............................................................. 46

2.2.3.5 Estratégia de detecção “Método Cérebro” ............................................................... 47

2.2.3.6 Estratégia de detecção “Classe Cérebro” ................................................................ 49

2.2.3.7 Estratégia de detecção “Acoplamento Intensivo” ..................................................... 50

2.2.3.8 Estratégia de detecção “Cirurgia de Espingarda” ................................................... 51

2.2.3.9 Estratégica de detecção “Herança do Pai Recusada” .............................................. 52

2.2.3.10 Estratégia de detecção “Quebrador de Tradição” .................................................. 54

2.3 Revisão sistemática da literatura ................................................................................. 56 2.3.1 Método ........................................................................................................................ 56 2.3.2 Bases de dados ............................................................................................................ 57 2.3.3 String de busca ........................................................................................................... 58

2.3.4 Critérios de inclusão e exclusão ................................................................................. 58 2.3.5 Estratégia de pesquisa ................................................................................................ 59 2.3.6 Resultados .................................................................................................................. 60

2.3.6.1 Questão de pesquisa Q1 ........................................................................................... 61




2.3.7 Conclusão ................................................................................................................... 66

2.4 Trabalhos relacionados ................................................................................................ 67

2.4.1 Avaliação da qualidade de POO entre código fonte X diagrama UML ...................... 67

2.4.2 Métricas de OO para identificação de complexidade e problemas de POO ................ 67

2.4.3 Avaliação da usabilidade de interface gráfica em sistemas RES ................................ 68

2.4.4 Avaliação orientada a aspectos e a objetos em sistemas de poços de petróleo ............ 68

2.4.5 Identificação de ferramentas para detecção de problemas de POO ............................ 68

3 EXPERIMENTO ............................................................................................................ 70

3.1 O Projeto Java Reference Implementation ................................................................... 70

3.2 Definição ....................................................................................................................... 72

3.3 Planejamento ................................................................................................................ 73

3.4 Operação ...................................................................................................................... 74

3.5 Resultados..................................................................................................................... 74

4 CONSIDERAÇÕES FINAIS .......................................................................................... 83 4.1 Limitações da pesquisa ................................................................................................ 84

4.2 Trabalhos futuros ......................................................................................................... 84

REFERÊNCIAS ................................................................................................................. 86

APÊNDICE A - Lista completa das estratégias de detecção de problemas de POO ....... 97

APÊNDICE B - Resultado das métricas de classes com problemas de POO................... 98

APÊNDICE C - Resultado das métricas de métodos com problemas de POO ................ 99

APÊNDICE D - Métrica DCC customizada ................................................................... 100

15

1 INTRODUÇÃO

Segundo a Sociedade Brasileira de Informática em Saúde (SBIS) e o Conselho

Federal de Medicina (CFM), a utilização da Tecnologia da Informação e Comunicação em

Saúde (TICS) vem crescendo. Nesse cenário, são grandes as possibilidades, os recursos e os

benefícios que a informática pode trazer para a área de saúde (SBIS; CFM, 2012). Essa

demanda vai aumentar gradualmente, a exemplo do governo americano, que, em 2011,

anunciou incentivos para esta área (SACHDEVA; BHALLA, 2009).

Como consequência desse crescimento e com o acesso compartilhado de

informações em nível mundial, tanto os pacientes como os profissionais de saúde esperam que

dados clínicos possam ser transmitidos de uma forma segura, confiável e eficiente em todas as

unidades de assistência médica. Assim, o histórico integrado de saúde de um paciente pode

ser visualizado por prestadores de assistência médica, independente do lugar e do momento

(HEDAYAT, 2010). Nessa linha de raciocínio, Costa, Tortosa e Maldonado (2009) enfatizam

que sistemas de informação das instituições de saúde devem ser capazes de comunicar entre si

para apoiar a atenção ao paciente em diversos níveis.

Para viabilizar este objetivo, foi criado o Registro Eletrônico de Saúde (RES) que

pode ser entendido como um repositório de dados do histórico integrado de saúde de um

paciente em uma forma processável eletronicamente, armazenado e transmitido com

segurança, e acessível por múltiplos usuários ou várias instituições de saúde, que, neste último

caso descreve um RES compartilhável (SANTOS, 2011). Para que isso seja possível, é

necessário que exista uma interoperabilidade entre os sistemas de informação para permitir o

compartilhamento do registro de saúde, preservando fielmente o significado clínico do autor

(KALRA, 2006).

Na busca dessa interoperabilidade, a abordagem que separa o domínio do

conhecimento do domínio da informação é apresentada como solução para o RES. Esta

abordagem é chamada de modelagem de dois níveis ou multinível. Separar em dois níveis

informação e conhecimento facilita a criação e manutenção desses sistemas de informação.

Nessa abordagem, é estabelecido um modelo de informação (referência) usado para

representar as propriedades genéricas da informação, e um modelo de conhecimento

representado pelo conceito de arquétipos. (SANTOS; BAX; PESSANHA, 2010a). Dos

principais padrões que tratam a interoperabilidade em sistemas RES, destacam-se a Fundação

16

openEHR, CEN 13606, Heath Level Seven (HL7) e o Integrating the Healthcare Enterprise

(IHE), DICOM e Medical Markup Language (MML) (KALRA, 2006; VELTE, 2011).

Lisa Thurston (2006, p. 1)1 destaca a representatividade da abordagem da

Fundação openEHR: “A abordagem da Fundação openEHR para RES tem ganhado atenção

na comunidade de informática em saúde”. É evidenciada esta representatividade também por

parte de Linda Velte: “O openEHR é um padrão muito completo [...]” (VELTE, 2011, p. 63)2.

A própria Fundação openEHR credita o sucesso devido à aceitação formal do CEN 13606

como um padrão da Europa e da ISO (OPENEHR, 2013a). Outra vantagem é a existência de

um ferramental pronto para uso como Archetype Editor, Archetype Workbench, Template

Designer, Clinical Knowledge (ATALAG; YANG; WARREN, 2011). Portanto, justifica-se a

escolha do padrão openEHR como objeto de estudo deste trabalho.

A Fundação openEHR é uma empresa sem fins lucrativos, que tem como seus

fundadores a University College London do Reino Unido e a Ocean Informatic Pty Ltd da

Austrália. Ela tem como objetivo principal facilitar a criação e o compartilhamento de registro

de saúde de pacientes para a comunidade médica (OPENEHR, 2013a; KALRA; BEALE;

HEARD, 2005). De acordo com Kalra (2006), a Fundação openEHR objetiva também:

a) promover e publicar a especificação de requisitos para representação e

comunicação de RES;

b) promover e publicar informação sobre arquiteturas de RES, modelos e

dicionários de dados que atendam a esses requisitos;

c) gerenciar a validação das arquiteturas RES por meio da implementação

e avaliação clínica;

d) manter implementações de código aberto para melhorar o conjunto de

ferramentas disponíveis ao apoio de sistemas clínicos;

e) colaborar com outros grupos de trabalho para a alta qualidade, sistemas

de informação de saúde interoperáveis.

Entretanto, implementar a especificação do padrão openEHR pode ser uma tarefa

trabalhosa. Segundo Velte (2011), trata-se de um padrão complexo e difícil de entender para

alguém novo na área. Além disso, a digitalização de registros de saúde é relativamente recente

1 “The openEHR approach to health record management is a novel approach and gaining attention in the health informatics community” (Tradução nossa). 2 “OpenEHR is a very complete standard [...]” (Tradução nossa).

17

e poucos sistemas de RES têm sido implementados no mundo. Em função disso, as

instituições de saúde terão de enfrentar muitos desafios durante a implementação de sistemas

de RES (THURSTON, 2006).

Na área de Engenharia de Software, em função de interesse de pesquisadores,

existe um estudo crescente de métricas na busca de soluções para os diversos desafios e

problemas relacionados ao desenvolvimento de software. Entre os benefícios das métricas de

software, destaca-se a maneira quantitativa de avaliar a qualidade de atributos internos do

produto. Isso permite que o engenheiro de software possa avaliar a qualidade do produto antes

de ser construído (PRESSMAN, 2010). Ainda segundo Pressman (1995)3 e Braga (1996)4

citado Vavassori (2002), uma das razões para considerar as medições de software é a

possibilidade de estimar o tamanho de um sistema antes de desenvolvê-lo. De acordo com

Peters e Pedrycz (2001), são conhecimentos obtidos pela medição de software:

a) custo que afeta o planejamento de projetos futuros;

b) testabilidade e manutenbilidade de processos e produtos;

c) eficácia do produto de software;

d) problemas a serem identificados;

e) qualidade do produto;

f) funcionalidade e facilidade de utilização do produto.

Levando-se em conta os benefícios e conhecimentos que podem ser adquiridos

com a medição de software, é justificada a sua utilização em sistemas de RES para minimizar

os desafios que as instituições de saúde terão que enfrentar, conforme citado anteriormente.

Especificamente, as métricas de Orientação a Objetos5 (OO) são as mais direcionadas ao

padrão openEHR, visto que ele possui um Modelo de Objetos que utiliza os conceitos de OO.

Existe um grande interesse no uso da abordagem orientada a objetos, tendo em

vista o fato de como ela pode melhorar o desenvolvimento de software, incluindo fatores

como maior reusabilidade e extensibilidade. Com o intuito de ajudar os gerentes e

desenvolvedores a atingir esses objetivos, uma variedade de métricas de OO tem sido

propostas para ajudar a controlar projetos de software (CHIDAMBER; DARCY; KEMERER,

1998). Essas métricas podem auxiliar também na manutenção de software para prever esforço

3 PRESSMAN, R. S. Engenharia de software. São Paulo: Makron Books, 1995. 4 BRAGA, A. Análise de Pontos de Função. IBPI Press, 1996. 5 Orientação a Objeto é uma abordagem para desenvolvimento de software.

18

de manutenção. Assim, grandes estudos têm sido feitos para estabelecer uma relação entre

métricas de OO e manutenção (MALVIYA; SINGH, 2011).

1.1 Problema de pesquisa

Pretende-se verificar o seguinte problema de pesquisa: Levando-se em

consideração o uso de métricas de Orientação a Objetos (OO), qual a qualidade de

Projeto Orientado a Objeto (POO) do Modelo de Objetos do openEHR?

1.2 Justificativa

Estudos de métricas de OO vêm sendo aplicadas na área de Engenharia de

Software. Até a realização desse projeto de pesquisa não se observaram estudos dessa

natureza voltados para o Modelos de Objetos do openEHR. Neste trabalho, é evidenciado a

importância do sistema de RES, a grande aceitação do Modelo de Objetos do openEHR e os

benefícios relacionados com a aplicação de métricas de software. Nesse cenário, uma

avaliação do Modelo de Objetos do openEHR, em relação à qualidade de POO, torna-se

relevante para qualquer organização que pretenda utilizá-lo na implementação de um sistema

de RES.

1.3 Objetivos geral e específicos

O presente trabalho tem como objetivo geral avaliar a qualidade de POO do

Modelo de Objetos da Fundação openEHR com base em métricas de Orientação a Objetos.

Os seguintes objetivos específicos foram definidos:

a) identificar um conjunto de métricas de OO para avaliação da qualidade

de POO do Modelo de Objetos do openEHR;

19

b) identificar e avaliar as ferramentas existentes para aplicação de métricas

de OO;

c) medir o Modelo de Objetos do openEHR, utilizando o conjunto de

métricas de OO identificadas e com apoio da ferramenta de extração de métrica

definida.

1.4 Procedimentos metodológicos

Esta pesquisa caracteriza-se como qualitativa de estudo experimental em

Engenharia de software. Basili, Shull e Lanubile (1999)6 citados por Lopes (2010) utilizam a

seguinte definição:

Um estudo experimental é uma atividade com o propósito de descobrir algo desconhecido ou de testar uma hipótese envolvendo uma investigação de coleta de dados e de execução de uma análise para determinar o significado dos dados. Isto cobre várias formas de análise e estratégias de pesquisa. (BASILI; SHULL; LANUBILE, 1999 citados por LOPES, 2010, p. 9).

FIGURA 1 - Visão geral do processo de estudo experimental Fonte: Adaptado de WOHLIN, 2012, p. 77.

6 BASILI, V. R.; SHULL, F.; LANUBILE, F. Building knowledge through families of experiments. Software Engineering, IEEE Transactions on, v. 25, n. 4, p. 456-473, 1999.

Definição

Planejamento

Operação

Análise e Interpretação

Apresentação e Empacotamento

Conclusão

Ideia do Experimento Processo de experimento

20

Para este trabalho foi adotado o estudo experimental em Engenharia de software

proposto por Wohlin et al. (2012). Nessa abordagem, o processo de experimento envolve

atividades de definição, planejamento, operação, análise e interpretação, validação e

empacotamento, conforme a FIG. 1.

Esta pesquisa também tem o caráter empírico, pois se baseia em evidência

sistemática e controlada. O empirismo é ideal para a linha de pesquisa deste trabalho,

conforme afirmado por Wazlawick (2008):

A computação, enquanto ciência, fundamenta suas pesquisas no empirismo e não no princípio da autoridade. Em computação, na maioria das vezes, pouco importa a opinião deste ou daquele expoente, mas as conclusões objetivas obtidas empiricamente. (WAZLAWICK, 2008, p. 44).

O universo da pesquisa corresponde ao Modelo de Objetos de Arquétipos e o

Modelo de Referência do openEHR, incluindo o código fonte do framework Reference Model

Java ITS do openEHR. No entendimento de Vergara (2005), o universo da pesquisa é

considerado como o conjunto de elementos selecionados de acordo com algum critério de

representatividade.

Os objetivos específicos listados anteriormente foram relacionados com a

respectiva metodologia, conforme apresentado no QUADRO 1:

QUADRO 1

Cruzamento objetivos específicos X metodologias

Objetivo Específicos Metodologia

Identificar um conjunto de métricas de OO para avaliação da qualidade de POO do Modelo de Objetos do openEHR

-Pesquisa bibliográfica

-Observação direta

Identificar e avaliar as ferramentas existentes de extração de métricas de OO

- Pesquisa bibliográfica

- Observação direta

Medir o Modelo de Objetos do openEHR utilizando o conjunto de métricas de OO identificadas e com apoio da ferramenta de extração de métrica definida

- Estudo experimental

Fonte: Elaborado pelo autor.

21

Nesse procedimento, as métricas de OO serão avaliadas com relação aos artefatos

exigidos, os resultados que podem ser obtidos e a existência de um ferramental para coleta de

dados.

22

2 FUNDAMENTAÇÃO TEÓRICA

A estrutura da fundamentação teórica está definida em quatro seções. A primeira

seção abrange os conceitos relativos ao RES, que é o ambiente da pesquisa. A segunda seção

aborda a qualidade de POO com apoio de métricas de OO. A terceira seção apresenta uma

revisão sistemática da literatura dos estudos que utilizam a abordagem multinível da

Fundação openEHR e as ferramentas existentes para coleta de métricas de OO que podem ser

utilizadas no Modelo de Objetos do openEHR. Por fim, a última seção descreve os trabalhos

relacionados a este estudo que foram encontrados na literatura, destacando-se as semelhanças

e diferenças existentes.

2.1 Registro Eletrônico de Saúde

De acordo com a Fundação openEHR, um RES tem a seguinte definição: “É um

registro de cuidado longitudinal, centrado no paciente e compartilhado entre as organizações

de atenção à saúde” (BEALE, 2013).

Para Hedayat (2010), o RES pode ser definido como um registro informático

persistente, longitudinal processável de informações de saúde do paciente, gerada por um ou

mais encontros em uma organização de saúde. Ele inclui todos os tipos de informação clínica

do paciente registrados ao longo do tempo.

A Sociedade Brasileira de Informática em Saúde (SBIS) e o Conselho Federal de

Medicina (CFM), por intermédio do manual para certificação de sistemas de registro

eletrônico em saúde definem, de forma prática, o RES como sendo: “Um repositório de

informação a respeito da saúde de indivíduos, numa forma processável eletronicamente”

(SILVA, 2011, p. 15). Um ambiente com um sistema RES é exibido na FIG. 2, mostrando a

relação do repositório central com demais sistemas e atores envolvidos.

23

FIGURA 2 - Contextualização de ambiente RES e seus relacionamentos Fonte: Adaptado de BEALE; HEARD, 2007, p. 14.

Nesse ambiente RES, unidades de atendimento de Clínica Geral (CG), hospitais

regionais, hospitais de referência e centros de especialidades enviam e recebem dados clínicos

de pacientes por meio da integração de um sistema de Prontuário Eletrônico do Paciente

(PEP) e do repositório RES, que pode ser de nível nacional, estadual ou municipal. Os

laboratórios de imagens e de patologia enviam os resultados de exames para o repositório

RES para serem integrados ao prontuário do paciente. Com apoio de sistemas de web seguros,

o prontuário do paciente pode ser acessado de casa, em clínicas de idosos, em organizações de

assistência social e por profissionais de enfermagem. No próprio repositório RES, o

prontuário consolidado do paciente e as informações de saúde podem ser trabalhadas para

obter-se diversas informações como indicadores e estatísticas.

De uma maneira comparativa, Santos (2011) esclarece as diferenças entre o

Registro Eletrônico de Saúde (RES) e o Prontuário Eletrônico do Paciente (PEP). O PEP é o

registro de informação de saúde de um paciente em uma organização de saúde, enquanto que

24

o RES é o registro de saúde do paciente mantido por meio de várias organizações de saúde,

que normalmente estão sob domínio de órgãos governamentais.

2.1.1 Modelo de objetos do openEHR

A arquitetura de RES da Fundação openEHR propõe uma modelagem de dois

níveis ou multinível. A principal característica oferecida pela modelagem de dois níveis é a

separação entre informação e conhecimento. A informação é modelada pelo Modelo de

Referência (MR), enquanto o conhecimento é modelado usando o Modelo de Objetos de

Arquétipos (MOA) (COSTA; TORTOSA; MALDONADO, 2009). Na modelagem de dois

níveis, o Modelo de Objetos do openEHR é dividido no Modelo de Referência (MR),

representando a visão da informação, e o Modelo de Objetos de Arquétipos (MOA)

representando o modelo de domínio (conhecimento) por meio de arquétipos (BEALE, 2007).

A Fundação openEHR fornece especificações de sistemas de informação de saúde

e mecanismos de interoperabilidade, utilizando notações que representam conceitos da

abordagem de Orientação a Objetos (OO). A OO é uma abordagem para desenvolvimento de

software que trata os problemas do mundo real como um conjunto de objetos distintos. Leva-

se em conta a estrutura e o comportamento dos dados para essa representação. A OO possui

características específicas como identidade, classificação, encapsulamento, herança,

polimorfismo e persistência (PFLEEGER, 2004). Já segundo Blaha e Rumbaugh, (2006), OO

significa que o software é organizado como uma coleção de objetos distintos incorporando

estrutura de dados e comportamento.

O Modelo de Objetos é expresso em diagramas UML7. É extremamente

importante que ele seja compreensível e implementável por pessoas técnicas, visto que os

principais usuários de uma especificação formal de padrões de informação de saúde são

desenvolvedores de sistemas de informação. Por essa razão, o padrão UML da OMG foi

adotado como modelo gráfico (BEALE, 2007).

Pfleeger (2004) define UML como:

É uma abordagem e notação, muito utilizada para descrever soluções orientadas a objetos. Ela pode ser adaptada para diferentes situações de desenvolvimento e ciclos

7 UML (Unified Modelling Language) é uma linguagem de modelagem padrão definida pelo Object Management Group (OMG).

25

de vida de softwares. Organizações como o Object Management Group adotaram a UML como notação padrão. (PFLEEGER, 2004, p. 220).

A OMG esclarece os objetivos da UML da seguinte forma:

O objetivo da UML é fornecer aos arquitetos de sistemas, engenheiros de software e desenvolvedores de software ferramentas para análise, projeto e implementação de sistemas baseados em software, como também para modelagem de negócios e processos similares. (OMG, 2011, p. 1).

A representação do Modelo de Objetos ocorre da seguinte forma: primeiramente

ele é modelado na linguagem Eiffel que se aproxima da UML 2.0. Este modelo é usado como

fonte para a publicação das especificações no formato PDF e convertido para UML 2.0 no

formato de uma instância XML (eXtensible Markup Language). Com base no UML 2.0, são

geradas diversas visões do Modelo de Objetos. Este ambiente de modelagem é exibido na

FIG. 3.

FIGURA 3 - Ambiente de modelagem do openEHR para geração de artefatos de software Fonte: Adaptado de BEALE, 2007, p. 4.

Na especificação do openEHR, os modelos são divididos utilizando a notação de

pacotes da UML (diagrama de pacotes). Cada pacote representa um contexto local das classes

que são apresentadas por meio de diagrama de classes. A UML utiliza vários diagramas para

as diferentes etapas do desenvolvimento de software. No contexto deste trabalho, destacam-se

26

apenas os diagramas relacionados ao projeto de sistemas e diagramas que podem ser obtidos

ou gerados pela especificação do openEHR.

2.1.1.1 Modelo de Referência

Na modelagem de dois níveis, o Modelo de Referência (MR) está no nível de

informação, o qual foi elaborado a partir da identificação de um pequeno conjunto de classes

genéricas e suficientes para representar os conceitos relativos ao RES (SANTOS, 2011). Uma

classe descreve um grupo de objetos com as mesmas propriedades, comportamento, tipo de

comportamento e semântica. Portanto, cada objeto é uma instância da classe (BLAHA;

RUMBAUGH, 2006).

O Modelo de Referência é o que contém o maior número de classes. Beale e

Heard (2007) exibem o modelo dividido nos seguintes pacotes:

a) Modelo de Informação de Suporte: pacote que contém os conceitos

básicos exigidos por todos os demais pacotes. Esse pacote define semânticas

que são acessadas por outros pacotes para obter serviços de terminologia e

outros dados;

b) Modelo de Informação de Tipos de Dados: pacote que define um

conjunto de tipos de dados para todos os modelos, além de oferecer tipos

clínicos específicos para todas as informações de saúde;

c) Modelo de Informação de Estrutura de Dados: pacote que contém as

estruturas de dados genéricas usadas para expressar conteúdo em que a

estrutura específica será definida por arquétipos. Assim, Single, List, Table,

Tree e History representam estruturas genéricas;

d) Modelo de Informação RES: pacote que define o contexto semântico de

EHR, COMPOSITION, SECTION e ENTRY. Essas classes são os principais

componentes de granulação RES;

e) Modelo de Informação de Extrato RES: pacote que define como o

extrato RES é construído a partir de COMPOSITIONs, dados demográficos e

informações de controle de acesso do RES. Suporta extrato RES completo,

CEN EN13606 e um extrato de sincronização openEHR;

27

f) Modelo de Informação de Integração: pacote que define as classes

GENERIC ENTRY para representar um legado ou dado externo como uma

árvore. Esse tipo possui um arquétipo específico chamado de arquétipo de

integração, o qual pode ser usado em conjunto com os arquétipos clínicos

como a base para uma ferramenta de sistema de integração de dados;

g) Modelo de Informação Demográfico: pacote que define conceitos

genéricos das classes PARTY, ROLE e detalhes relacionados como endereço de

contato. O modelo de arquétipos define as restrições de semântica nas classes

PARTYs, assim, permitindo arquétipos para qualquer tipo de pessoa,

organização e papel exercido.

Somente o MR é implementado em software, reduzindo o impacto em sistemas

implantados. Desta forma, os sistemas podem ser menores e mais fáceis de manter em relação

aos sistemas que não foram construídos na modelagem de dois níveis (BEALE; HEARD,

2007).

2.1.1.2 Modelo de Objeto de Arquétipos

O Modelo de Objeto de Arquétipos (MOA) é um modelo genérico que pode ser

usado para expressar arquétipos de qualquer modelo de referência. Este modelo pode ser

usado como base para desenvolvimento de sistemas que se baseiam na modelagem multinível,

citado anteriormente, e que processam arquétipos de forma independente. Como também,

pode ser usado para desenvolver parsers, que interpretam arquétipos em um formato de

linguagem de programação, como o ADL (Archetype Definition Language) (BEALE, 2008).

Arquétipos fornecem uma modelagem semântica e são expressos sob a forma de restrições

(constraints) nos dados em que as instâncias estão em conformidade com o MR. O MOA

define as relações que devem ser verdadeiras entre as partes de um arquétipo para que seja

válido como um todo. Ou seja, todos os arquétipos devem estar em conformidade com MOA

(SACHDEVA; BHALLA, 2009). Arquétipos podem ser compostos para formar estruturas

maiores equivalentes semanticamente a um arquétipo grande. Isso permite aos arquétipos

serem definidos de acordo com níveis naturais ou encapsulamentos de informação, e também

permite a reutilização de arquétipos menores (BEALE, 2008).

28

O MOA representa, por meio de arquétipos, os conceitos específicos de dados

clínicos como temperatura corporal, índice de massa corporal, pressão sanguínea, etc. Um

arquétipo descreve a configuração de instância de dados de classes do Modelo de Referência

(MR). Os arquétipos são definidos usando a linguagem Archetype Definition Language

(ADL). A ADL é uma linguagem que se baseia em modelos de restrições de entidades de

domínio, ou “regras de negócio estruturadas”. Descreve restrições para dados que são

instâncias de um modelo de referência qualquer (SANTOS; BAX; PEÇANHA, 2010b). O

MOA é relacionado com o Modelo de Referência (MR), de maneira que suas semânticas são

de restrições em instâncias de classes definidas no Modelo de Referência (MR). Se os dados

são criados e modificados usando arquétipos, então, tais arquétipos restringem a configuração

dos dados de acordo com o arquétipo.

FIGURA 4 - Objetos do processo de parsing do ADL Fonte: Adaptado de BEALE, 2008, p. 11.

O processo de parsing em um arquétipo ADL, exibido na FIG. 4, irá retornar

objetos de acordo com o Modelo de Objetos de Arquétipos (MOA) (COSTA; TORTOSA;

MALDONADO, 2009). Na ADL existem nós que representam as referências internas para

outros nós, chamados de nós de restrição de referência, os quais referem a uma restrição de

texto do atributo constraint_binding da seção ontology de um arquétipo, e nós de restrição de

29

arquétipo, que representam restrições sobre outros arquétipos que possuem permissão para

aparecer em um determinado ponto. Beale (2008) detalha os seguintes tipos de nós:

a) C_complex_object: qualquer nó interior representando uma restrição em

instâncias de tipos não primitivos como, por exemplo, ENTRY e SECTION;

b) C_attribute: um nó representando uma restrição no atributo em um tipo

de objeto;

c) C_primitive_object: um nó representando uma restrição em um tipo de

objeto primitivo;

d) Archetype_internal_ref: um nó que refere para outro nó de objeto

definido previamente no mesmo arquétipo;

e) Constraint_ref: nó que se refere a uma restrição, normalmente, em um

texto ou entidade de termo codificado. Na linguagem ADL é representada com

um código do tipo "acNNNN". A restrição é expressa como uma consulta em

uma entidade externa, normalmente uma terminologia ou ontologia;

f) Archetype_slot: um nó cujas declarações definem uma restrição que

determina que outros arquétipos podem aparecer naquele ponto do arquétipo

atual. Uma analogia pode ser o buraco de uma fechadura, em que poucas ou

muitas chaves podem encaixar, dependendo do formato específico. Tem a

mesma semântica de um C COMPLEX OBJECT, exceto que as restrições são

expressas em outro arquétipo.

Beale (2008) exibe o modelo dividido nos seguintes pacotes:

a) Arquétipo: este pacote contém apenas duas classes: ARCHETYPE e

VALIDITY KIND. Entretanto, a classe ARCHETYPE é a principal classe dentro

do Modelo de Objetos de Arquétipos. Um arquétipo é modelado como uma

especialização de AUTHORED RESOURCE e inclui meta-dado descritivo,

informação de idioma e histórico de revisão;

b) Modelo de Restrição: com base nas classes desse pacote é possível criar

estruturas de descrição do arquétipo que são uma alternância hierárquica de

objeto e atributo. Trata-se de uma consequência direta do princípio de

orientação a objetos, em que classes consistem em propriedades, que por sua

vez têm tipos que são classes;

30

c) Declaração: pacote que contém classes utilizadas para restringir dados

dentro do arquétipo. Utiliza expressões lógicas e são representadas nos

arquétipos em lógica de predicados de primeira ordem (First-Order predicate

Logic - FOL);

d) Ontologia: possui classes para representar a ontologia de um arquétipo.

Uma ontologia de arquétipo consiste em lista de termos definidos para o

arquétipo, lista de definição de restrição externa e um conjunto de uma ou mais

ligações de definições de termos para códigos de terminologias externas.

Uma visualização melhor das classes dos pacotes do Modelo de Objetos pode ser

obtida por meio do diagrama de classes que mostra as classes de suas relações, identidade,

propriedades (atributos) e métodos (comportamento). Um exemplo do diagrama de classes

com a classe Archetype e seus relacionamentos com outro pacote é exibido na FIG. 5.

FIGURA 5 - Exemplo de diagrama de classes com a classe Archetype e relacionamentos Fonte: BEALE, 2008, p. 14.

31

As classes podem estar ligadas a outras classes por meio de associações que

indicam cardinalidade, classificação e navegabilidade. Blaha e Rumbaugh (2006) acrescentam

a generalização como fator de compartilhamento da estrutura e comportamento,

caracterizando, assim, a herança.

Arquétipos podem ser especializados, sendo que existem regras formais de

especialização. De certa forma, um arquétipo é uma especialização de outro arquétipo quando

se menciona esse arquétipo como seu pai, e só faz alterações em sua definição em que suas

restrições sejam mais específicas do que as restrições do pai. Os dados criados por intermédio

da utilização do arquétipo especializado têm que estar em conformidade com ele e, também,

com o seu pai.

2.2 Qualidade de Projeto Orientado a Objeto

O movimento para o desenvolvimento de software de qualidade tem sido contínuo

e resultou em um grande número de organizações de melhoria da qualidade, bem como nos

padrões, normas, ferramentas e técnicas que existem atualmente. No entanto, a qualidade

continua a ser uma meta distante, especialmente quando se trata de requisitos não funcionais,

como visto no aspecto estrutural da qualidade de software. Um modelo de qualidade ajuda a

preencher a lacuna entre as métricas de software e as características de software de qualidade,

fazendo com que a qualidade de software intangível seja mais fácil de entender.

(CHOTJARATWANICH; ARPNIKANONDT, 2012).

Uma característica comum desse tipo de modelos de qualidade é que ele depende

de métricas para avaliação da qualidade. Assim, a próxima seção irá discutir sobre as métricas

de Projeto Orientado a Objeto.

2.2.1 Métrica de Orientação a Objeto

As métricas permitem a visão detalhada para criar modelos de análise e projeto,

código sólido e testes rigorosos (PRESSMAN, 2010). Métricas fornecem as perspectivas para

ajudar a prever e preparar para os desafios do desenvolvimento e da manutenção de software

(PFLEEGER, 2004).

32

Existem métricas tradicionais como pontos por função, bang, coesão,

acoplamento, etc. Mas existem técnicas específicas como a métrica de OO. Entretanto, as

métricas de software tradicionais não suportam os conceitos chaves de OO. Por isso, nas

métricas para sistemas OO são ajustadas as características que distinguem o software OO do

convencional. A abordagem OO foca a modelagem do mundo real em termos de objetos, em

contraste com a tradicional abordagem que enfatiza a visão orientada à função. Além disso, a

OO possui diferentes notações como classes, herança, encapsulamento e passagem de

mensagem que não são suportadas pelas métricas convencionais (CHIDAMBER;

KEMERER, 1994; PRESSMAN, 2010). Com o objetivo de tratar as limitações das métricas

tradicionais, pesquisadores propuseram mecanismos para formular regras baseadas em

métricas que capturavam os princípios e heurísticas do Projeto Orientado a Objeto

(BERTRÁN, 2009).

Na visão de Gill e Sikka (2011), o Desenvolvimento de Software Orientado a

Objeto (DSOO) suporta a reutilização por meio da instanciação e uso de classes previamente

definidas, reutilização por modelos genéricos e reutilização por herança. Nesse sentido, a

herança é uma técnica de reutilização que deve ser avaliada em termos de métrica de OO.

Na literatura de DSOO, (GILL; SIKKA, 2011; PFLEEGER, 2004), existem

questões a serem respondidas como:

a) As classes são reutilizáveis no futuro?

b) Qual é a quantidade de reutilização entre classes no sistema?

c) Uma vez implementado um sistema com OO, como medir suas

propriedades?

d) Existem características de POO que são desejáveis, como baixo

acoplamento e alta coesão. Como medir estas características em sistemas

orientados a objetos?

e) Qual a utilidade dessas medidas para o entendimento, controle e

previsão do sistema?

Questões como essas podem ser respondidas por meio das métricas de OO

disponíveis na literatura, mas deve-se destacar que existem várias maneiras de medir sistemas

orientados a objetos, e o melhor conjunto de métricas ainda não foi definido (PFLEEGER,

2004). As métricas utilizadas neste estudo foram divididas em dois grupos distintos: as

33

métricas do modelo de qualidade QMOOD e as métricas das estratégias de detecção de

problemas de POO. Eses dois grupos e suas métricas são detalhados a seguir.

O modelo de qualidade QMOOD é composto por métricas disponíveis na

literatura. Mas, por não existirem métricas de OO adequadas, Bansiya e Davis (2002) também

definiram novas métricas: CAM, DAM, DCC, MFA e MOA. Abaixo segue um detalhamento

das métricas utilizadas:

ANA (Average Number of Ancestors) - Número médio de ancestrais:

número médio de classes que outra classe herda de informação. Ele é calculado

por meio do número de classes ao longo de todos os caminhos da classe "raiz"

até a classe medida;

CAM (Cohesion Among Method of Class) - Coesão entre os métodos da

classe: calcula o parentesco entre os métodos de uma classe com base na lista

de parâmetros de métodos. É preferível um valor próximo a 1. (Faixa de 0 a 1);

CIS (Class Interface Size) - Tamanho da interface da classe: contagem

do número de métodos públicos de uma classe;

DAM (Data Access Metric) - Métrica de acesso a dados: relação do

número de atributos privados pelo número total de atributos declarados na

classe. Um valor alto para DAM é o desejado. (Faixa de 0 a 1);

DCC (Direct Class Coupling) - Acoplamento direto entre classes:

contagem do número de classes distintas em que a classe medida está

diretamente relacionada com as declarações de atributos e parâmetros em

métodos de outras classes;

DSC (Design Size in Classes) - Número de classes no projeto:

contagem do número total de classes no projeto;

MFA (Measure of Functional Abstraction) - Medida de abstração

funcional: relação do número de métodos herdados de uma classe pelo número

total de métodos acessíveis. (Faixa de 0 a 1);

MOA (Measure Of Agregation) - Medida de agregação: mede a

extensão da relação parte-todo realizado por meio de atributos. A métrica é

uma contagem do número de declarações de dados em que os tipos são classes

definidas pelo usuário;

34

NOH (Number of Hierarchies) - Número de hierarquias: contagem do

número de hierarquias de classe no projeto;

NOM (Number of Methods) - Número de métodos: contagem de todos

os métodos definidos em uma classe;

NOP (Number of Polimorphic Methods) - Número de métodos

polimórficos: contagem dos métodos que podem exibir o comportamento

polimórfico, ou seja, podem ter o comportamento modificado na classe filha.

As estratégias de detecção de problemas de POO, propostas por Lanza e

Marinescu (2006), são compostas por métricas existentes na literatura. Os autores também

definiram novas métricas: BOvR, BUR, CDISP, CINT, MAXNESTING, NAS, NOAV,

NProtM e PNAS. Segue abaixo o detalhamento de cada métrica:

AMW (Average Method Weight) - Peso médio de método: mede a

média da complexidade estática de todos os métodos em uma classe;

ATFD (Access to Foreign Data) - Acesso a dados estrangeiros: mede

quantos atributos de classes não relacionadas que são acessados diretamente ou

por meio de métodos de acesso;

BOvR (Base Class Overriding Ratio) - Relação de substituição de

classe base: mede o número de métodos da classe que está sendo medida, que

substituem (override) métodos da classe pai, dividido pelo número total de

métodos na classe;

BUR (Base Class Usage Ratio) - Relação de uso de classe base: mede o

número de membros específicos de herança usados pela classe que está sendo

medida, dividido pelo número total de membros específicos de herança da

classe pai;

CC (Changing Classes) - Mudando classes: conta o número de classes

que contêm métodos, os quais chamam o método que está sendo medido;

CDISP (Coupling Dispersion) - Dispersão de acoplamento: conta o

número de classes em que estão definidos os métodos chamados pelo método

que está sendo medido, dividido pelo resultado da métrica CINT;

CINT (Coupling Intensity) - Intensidade de acoplamento: conta o

número de métodos distintos chamados pelo método que está sendo medido;

35

CM (Changing Methods) - Mudando métodos: conta o número de

métodos distintos que chamam o método que está sendo medido;

CYCLO (Cyclomatic Number) - Número ciclomático: conta o número

de caminhos linearmente independentes de uma operação;

FDP (Foreign Data Providers) - Provedores de dados estrangeiros:

número de classes que possuem atributos acessados;

LAA (Locality of Attribute Accesses) - Localidade de atributos de

acesso: mede o número de atributos de métodos de classe dividido pelo número

total de variáveis acessadas;

LOC (Lines of Code) - Linhas de código: conta o número de linhas do

método;

MAXNESTING (Maximum Nesting Level) - Nível máximo de

aninhamento: representa o nível de aninhamento máximo de estruturas de

controle dentro de uma operação;

NAS (Number of Added Services) - Número de serviços adicionados:

mede o número de métodos públicos de uma classe que não são substituídos

(override), ou que não são especializados da classe pai;

NOAM (Number of Accessor Methods) - Número de métodos de

acesso: conta o número de métodos de acesso (Get e Set) de uma classe;

NOAV (Number of Accessed Variables) - Número de variáveis

acessadas: conta o número total de variáveis acessadas diretamente pela

operação;

NOM (Number of Methods) - Número de métodos: contagem de todos

os métodos definidos em uma classe;

NProtM (Number of Protected Members) - Número de membros

protegidos: mede o número de atributos e métodos protegidos de uma classe;

PNAS (Percentage of Newly Added Services) - Percentagem de

Serviços adicionados recentemente: mede o número de métodos públicos de

uma classe que não são substituídos (override), ou que não são especializados

da classe pai, dividido pelo número total de métodos públicos;

TCC (Tight Class Cohesion) - Coesão de classe: mede o número

relativo de pares de métodos de uma classe que acessam pelo menos um

atributo em comum da classe que está sendo medida;

36

WMC (Weighted Method Count) - Contagem ponderada de métodos:

considera a soma da complexidade de todos os métodos de uma classe.

As métricas descritas nessa seção são utilizadas nas próximas duas seções, modelo

de qualidade QMOOD e estratégias de detecção de POO.

2.2.2 Modelo de qualidade QMOOD

O Quality Model for Object-Oriented Design (QMOOD) é um modelo de

qualidade para POO que estabelece um modelo hierárquico definido e empiricamente

validado para avaliar atributos de qualidade de POO (Facilidade de Compreensão,

Reusabilidade, Flexibilidade, Funcionalidade e Extensibilidade). Nesse modelo, o

relacionamento entre atributos de qualidade, propriedades, métricas e componentes é dividido

em níveis e ligados entre si, conforme exibido na FIG. 6.

FIGURA 6 - Níveis do modelo de qualidade QMOOD Fonte: Adaptado de BANSIYA; DAVIS, 2002, p. 6.

No modelo, os atributos de qualidade relacionam-se com propriedades estruturais de

POO (Encapsulamento, Acoplamento, Coesão, Abstração, Herança, Polimorfismo e

Composição), que por sua vez relacionam-se com métricas de POO e, por fim, com

componentes de POO (BANSIYA; DAVIS, 2002). Em estudos recentes, o modelo de

qualidade QMOOD foi considerado um dos mais utilizados e referenciados (HADERER;

KHOMH; ANTONIOL, 2010).

37

No quarto nível estão os componentes que são mensurados pelas métricas do

terceiro nível, ou seja, o quarto nível está ligado (L34) ao terceiro nível. Essas métricas são

computadas para obter os valores das propriedades de POO no segundo nível, o que

representa a ligação do terceiro nível com o segundo nível (L23). Na última ligação (L12), são

aplicadas fórmulas nas propriedades de POO do segundo nível para chegar aos atributos de

qualidade de POO no primeiro nível.

FIGURA 7 - Exemplo de níveis do QMOOD para o atributo de qualidade Reusabilidade Fonte: Dados da pesquisa.

A FIG. 7 mostra um exemplo dos valores dos níveis do modelo de qualidade

QMOOD para o atributo de qualidade Reusabilidade. O atributo de qualidade Reusabilidade é

computado por meio das propriedades Encapsulamento, Acoplamento, Composição e

Polimorfismo, que são medidos pelas métricas DAM, DCC, MOA e NOP, respectivamente.

Essas métricas utilizam os componentes classe, atributos e método isoladamente ou em

conjunto.

2.2.2.1 Primeiro nível - Atributos de Qualidade

O modelo QMOOD foi baseado no modelo ISO 9126. Assim, alguns atributos de

qualidade foram derivados do modelo ISO 9126 e outros foram definidos. Os atributos

Portabilidade, Eficiência e Manutenabilidade do modelo ISO 9126 foram transformados,

respectivamente, em Extensabilidade, Eficácia e Facilidade de Compreensão do modelo

QMOOD. Já o atributo de qualidade Funcionalidade permaneceu inalterado. O atributo de

38

qualidade Reusabilidade foi incluído no modelo QMOOD com a justificativa de que o reuso é

uma maneira de desenvolver softwares confiáveis, adaptáveis e flexíveis, como prega a

abordagem OO. Também foi incluído o atributo de qualidade Flexibilidade, visto que novos

recursos precisam ser incorporados para atender as demandas do usuário final. Dessa forma, o

modelo de qualidade QMOOD ficou definido com os atributos de qualidade Funcionalidade,

Extensabilidade, Eficácia, Facilidade de Compreensão, Reusabilidade e Flexibilidade.

QUADRO 2

Atributos de qualidade de POO do modelo de qualidade QMOOD

Atributo de Qualidade

Definição

Eficácia Capacidade do projeto de obter a funcionalidade e o comportamento desejado, utilizando conceitos e técnicas de POO.

Extensibilidade Presença e uso de propriedades em um projeto existente, o que permite a incorporação de novos requisitos.

Facilidade de Compreensão

Propriedades do projeto que permitem que seja facilmente aprendido e compreendido. Está relacionado com a complexidade da estrutura do projeto.

Flexibilidade A capacidade de um projeto de ser adaptado para disponibilizar novos recursos.

Funcionalidade Recursos que são disponibilizados pelas classes através de suas interfaces públicas.

Reusabilidade Características de POO que permitem que um projeto seja reaplicado para um novo problema sem esforço significativo.

Fonte: Adaptado de BANSIYA; DAVIS, 2002, p. 7.

O QUADRO 2 descreve as características de cada um desses atributos de

qualidade. Bansiya e Davis (2002) ressaltam que esse conjunto de atributos de qualidade não

é exclusivo, ou seja, eles podem ser alterados de acordo com os objetivos desejados. Para este

trabalho serão selecionados atributos de qualidade Extensabilidade, Facilidade de

Compreensão, Flexibilidade, Funcionalidade e Reusabilidade.

39

2.2.2.2 Segundo nível - Propriedades de POO

No segundo nível, as propriedades de POO definidas no modelo QMOOD

mapeiam conceitos da abordagem OO. O QUADRO 3 exibe as propriedades de POO

utilizadas no modelo de qualidade QMOOD e suas respectivas definições.

QUADRO 3

Propriedades de POO do modelo de qualidade QMOOD

Fonte: Adaptado de BANSIYA; DAVIS, 2002, p.7.

Propriedade de Projeto

Definição

Abstração Aspecto generalização-especialização do projeto. Classes em um projeto que tem um ou mais descendentes apresentam esta propriedade de abstração.

Acoplamento Define a interdependência entre objetos de um projeto. É uma medida do número de objetos que teriam de ser acessados por outro objeto para que ele possa funcionar corretamente.

Coesão Avalia a relação dos métodos e atributos em uma classe. Forte sobreposição nos parâmetros do método e tipos de atributos é uma indicação de forte coesão.

Complexidade Grau de dificuldade em entender e compreender a estrutura interna e externa das classes e suas relações.

Composição É uma associação onde o objeto da classe A é composto de objetos da classe B. Isto sugere um tipo de relação parte-todo entre A e B.

Encapsulamento Delimitação de dados e comportamento de uma classe. Criação de classes que impedem o acesso a declarações de atributo e métodos, desta forma protegendo a representação interna dos objetos.

Herança Pode ser definido como o mecanismo para alcançar a idéia de generalização, onde uma classe B herda dados e comportamentos da classe A.

Hierarquias Hierarquias são usados para representar diferentes conceitos de generalização-especialização em POO. É uma contagem do número de classes não-hereditárias que têm descendentes em um projeto.

Polimorfismo Polimorfismo representa um conceito em que uma variável pode denotar objetos de classes diferentes que são ligadas por uma classe pai comum.

Tamanho do Projeto

Número de classes usadas em um POO.

Troca de mensagens

A contagem do número de método públicos que estão disponíveis como serviços para outras classes.

40

QUADRO 4

Relacionamento de atributos de qualidade X propriedades no QMOOD

Atributo de qualidade

Fórmula com base nas propriedades de projeto

Eficácia 0,2 x Abstração + 0,2 x Encapsulamento + 0,2 x Composição + 0,2 x Herança + 0,2 x Polimorfismo

Extensibilidade 0,5 x Abstração - 0,5 x Acoplamento + 0,5 x Herança + 0,5 x Polimorfismo


-0,33 x Abstração + 0,33 x Encapsulamento - 0,33 x Acoplamento + 0,33 x Coesão -0,33 x Polimorfismo - 0,33 x Complexidade - 0,33 x Tamanho do Projeto

Flexibilidade 0,25 x Encapsulamento - 0,25 x Acoplamento + 0,5 x Composição + 0,5 x Polimorfismo

Funcionalidade 0,12 x Coesão + 0,22 x Polimorfismo + 0,22 x Troca de Mensagens + 0,22 x Tamanho do Projeto + 0,22 x Hierarquias

Reusabilidade -0,25 x Acoplamento + 0,25 x Coesão + 0,5 x Troca de Mensagens + 0,5 x Tamanho do Projeto


Com os atributos de qualidade e as propriedades definidas, o modelo QMOOD

estabeleceu uma fórmula para obter os resultados dos atributos de qualidade com base nas

propriedades. Esse relacionamento é exibido no QUADRO 4.

2.2.2.3 Terceiro nível - Métricas

O terceiro nível do modelo de qualidade QMOOD é composto por métricas que

foram descritas na seção anterior. As métricas permitem mensurar as propriedades de POO do

segundo nível, que representam um atributo ou característica de POO. Na visão de Garzas e

Piattini (2007), métricas e modelos de qualidade são inseparáveis no processo de refatoração,

que são ações corretivas para melhorar a qualidade do código.

41

QUADRO 5

Propriedade de POO X Métrica no QMOOD

Propriedade de Projeto Métrica Relacionada

Tamanho do Projeto DSC

Hierarquias NOH

Abstração ANA

Encapsulamento DAM

Acoplamento DCC

Coesão CAM

Composição MOA

Herança MFA

Polimorfismo NOP

Troca de Mensagens CIS

Complexidade NOM


O QUADRO 5 exibe as propriedades de POO e as métricas relacionadas.

2.2.2.4 Quarto nível - Componentes

No quarto nível, estão os componentes que normalmente em uma arquitetura de

POO são identificados como classes, atributos, métodos, relacionamentos e hierarquia de

classes. Esses componentes são representados por declarações sintáticas em linguagens de

programação de OO. Assim, é possível coletar informações a partir desses componentes por

meio de ferramentas automatizadas. Neste trabalho, foi feita uma revisão sistemática da

literatura, descrita na seção 2.2.3, no intuito de identificar a melhor ferramenta para coletar

informações desses componentes por meio das métricas definidas no terceiro nível.

42

2.2.3 Estratégias de detecção de problemas de Projeto Orientado a Objeto

De acordo com Hu et al. (2010), a avaliação do QMOOD não é suficiente, visto

que ele não exibe os fragmentos de projeto que estão com problemas. Nesse sentido, para

complementar a análise do modelo de qualidade QMOO, este trabalho incorporou as

estratégias de detecção de problemas de POO propostas por Lanza e Marinescu (2006).

A estratégia de detecção é uma condição lógica, com base em métricas, em que

fragmentos de projeto com propriedades específicas são detectados no código-fonte. Dessa

forma, as estratégias de detecção tornam-se um mecanismo que permite ao engenheiro de

software trabalhar com métricas em um nível mais abstrato. O objetivo das estratégias de

detecção é fazer com que as regras de projeto e suas violações sejam quantificáveis. Assim, é

possível detectar problemas de projeto em um sistema de software OO, ou seja, encontrar os

fragmentos de projeto que são afetados por um problema de projeto particular (LANZA;

MARINESCU, 2006).

Na literatura, podemos encontrar esses problemas de projeto, citados como bad

smells ou code smells (GARZAS; PIATTINI, 2007). A identificação de potenciais bad smells

ou de problemas na estrutura é possível com consultas aos artefatos de código-fonte com base

nas estratégias de detecção. As estratégias mapeadas são baseadas em Lanza e Marinescu

(2006).

2.2.3.1 Valores limites das estratégias de detecção de POO

Na estratégia de detecção, são parametrizados valores limites, que possuem

influência na classificação das entidades de projeto, pois é necessário pontos de referência

para identificar o que é alto e o que é baixo. Ferreira (2011) destaca a importância dos valores

limites na interpretação das métricas e, consequentemente, na avaliação do software. Não é

uma tarefa fácil, mas normalmente, a escolha dos valores limites é um processo empírico

baseado em estatísticas (LORENZ; KIDD, 1994; MEI; XIE; YANG, 2002).

Lanza e Marinescu (2006) dividem os valores limites de duas formas: informação

estatística e aceitação geral. Na primeira forma, os valores são úteis para as métricas de

tamanho, na qual somente estatísticas podem dizer quais valores são frequentes ou incomuns.

43

Já na segunda forma, os valores limites relacionam-se com informações de conhecimento

geral da população e que normalmente são amplamente aceitas. Um bom exemplo é a

quantidade de horas de sono de um indivíduo.

TABELA 1

Base estatística de valores limites para estratégia de detecção

Métrica

Java C++

Baixo Média Alto Muito Alto

Baixo Média Alto Muito Alto

Cyclo / Line Of Code

0,16 0,20 0,24 0,36 0,20 0,25 0,30 0,45

LOC / Method 7,00 10 13 19,50 5 10 16 24

NOM/Class 4,00 7 10 15 4 9 15 22,5

WMC 5,00 14,00 31,00 47,00 4 23,00 72,00 108,00

AMW 1,1 2 3,1 4,7 1 2,5 4,8 7

LOC/Class 28,00 70,00 130,00 195,00 20 90,00 240,00 360,00

Fonte: Adaptado de LANZA; MARINESCU, 2006, p. 16.

Para obter uma base estatística de valores limites, Lanza e Marinuscu (2006)

coletaram métricas a partir de 45 projetos Java e 37 projetos em C + +, em que o critério de

escolha foi por diversidade. Sendo assim, os projetos possuem vários tamanhos e são de

domínios de aplicação variados, incluindo também sistemas industriais, comerciais e open-

sources. Um exemplo dos valores limites dessa base estatística são exibidos na TAB. 1.

Da mesma forma, Ferreira (2011) procurou identificar valores limites para um

conjunto de métricas com base em estudos empíricos realizados. Tal estudo empírico

envolveu a coleta de métricas de 40 softwares open-source com características e propriedades

diferentes. Os valores limites encontrados foram derivados da análise das propriedades

estatísticas dos dados, com base em valores mais utilizados na prática. Foram feitos dois

estudos de casos que indicaram que os valores limites são úteis na aplicação das métricas para

avaliação dos softwares.

Para Ahmed, Soliman e Sewisy (2013), existem pesquisas com valores limites e

métricas validadas empiricamente. Entretanto, cada uma delas possui seu próprio quadro com

propriedades diferentes. Dessa forma, os autores citam a necessidade de se desenvolver um

padrão para unificar o processo de validação de métricas e identificação de seus respectivos

valores limites.

44

Os valores limites utilizados nas estratégias de detecção desta dissertação são

baseados nos valores limites definidos por Lanza e Marinescu (2006) com base em seus

estudos empíricos realizados em projetos Java.

2.2.3.2 Estratégia de detecção “Classe Deus”

Em um POO, a classe que centraliza a inteligência do sistema é chamada de

“Classe Deus” (God Class) e, por isso, é considerada como falha de POO. Uma característica

desse tipo de classe é realizar muito trabalho por conta própria, com poucos detalhes

delegados para outras classes menos importantes e com o uso de dados de outras classes.

Como uma classe não pode ter muitas responsabilidades, então, fica em desacordo com os

princípios de um bom POO.

Esta estratégia de detecção possui as seguintes características:

a) a classe acessa dados de outras classes de forma direta ou usando

métodos de acesso;

b) a classe é grande e complexa;

c) a classe possui muitos métodos que não se comunicam. Dessa forma,

existe uma baixa coesão entre os métodos da classe.

45

FIGURA 8 - Estratégia de detecção de problemas de POO Classe Deus Fonte: Adaptado de LANZA; MARINESCU, 2006, p. 81.

Na estratégia de detecção Classe Deus, os resultados das métricas ATFD, WMC e

TCC devem estar dentro dos valores limites estabelecidos (condição E), conforme exibido na

FIG. 8.

2.2.3.3 Estratégia de detecção “Inveja de Funcionalidade”

A estratégia de detecção “Inveja de Funcionalidade” (Feature Envy) está

relacionada com métodos que acessam mais dados de outras classes do que sua própria classe.

O acesso aos dados de outra classe é feito diretamente ou por meio de métodos. Uma

mudança no método pode refletir em mudança em outro método. Além disso, pode indicar

que o método deve ser movido para outra classe.

Características dessa estratégia de detecção:

a) o método acessa diretamente muitos atributos de outras classes;

b) o método acessa mais atributos de outras classes do que da própria da

classe;

c) o método utiliza atributos "estrangeiros" que pertencem a poucas

classes ou somente uma classe.

46

FIGURA 9 - Estratégia de detecção de problema de POO Inveja de Funcionalidade Fonte: Adaptado de LANZA; MARINESCU, 2006, p. 85.

Na estratégia de detecção Inveja de Funcionalidade, os resultados das métricas

ATFD, LAA e FDP devem estar dentro dos valores limites estabelecidos (condição E),

conforme exibido na FIG. 9.

2.2.3.4 Estratégia de detecção “Classe de Dados”

Uma classe classificada como “Classe de Dados” (Data Class) indica uma falta de

métodos relevantes na mesma. Indica também uma falta de encapsulamento de dados, visto

que os dados (atributos) e o comportamento (métodos) não são mantidos em um só lugar.

Esse tipo de classe reduz a manutenção, testabilidade e compreensibilidade de um sistema.

Outro ponto importante é que a classe deixa que outras classes vejam e manipulem seus

dados. Dessa maneira, fica em desacordo com os princípios de um bom POO.

Características da estratégia de detecção:

a) a interface da classe possui dados, ao invés de oferecer serviços por

meio de métodos;

b) a classe possui vários atributos e não é complexa.

ATFD > 4

Baixa coesão

Inveja de Funcionalidade E

Acessam mais atributos de outras classes do que dela

LAA < 0,33

FDP <= 4

Acessam atributos "estrangeiros" que pertencem a poucas classes

Acessam diretamente muitos atributos de outras classes

47

FIGURA 10 - Estratégia de detecção de problema de POO Classe de Dados Fonte: Adaptado de LANZA; MARINESCU, 2006, p. 89.

Na estratégia de detecção Classe de Dados, os resultados das métricas NOAP,

NOAM e WMC devem estar dentro dos valores limites estabelecidos na primeira condição

“E”, ou (condição OU) as mesmas métricas devem estar dentro dos valores limites da segunda

condição “E”. Esta estratégia de detecção é exibida na FIG.10.

2.2.3.5 Estratégia de detecção “Método Cérebro”

O Método que tende a centralizar a funcionalidade de uma classe é chamado de

“Método Cérebro” (Brain Method). Ele é equivalente à Classe Deus, que centraliza a

funcionalidade de um subsistema ou de todo o sistema. Normalmente, é criado como um

método normal, mas por ganhar diversas funcionalidades ele fica fora de controle, tornando-

se difícil de manter ou compreender. Um método bem escrito tem uma complexidade

adequada, estando de acordo com o propósito do método.

NOAP + NOAM >2

E

Complexidade da classe não é alta

WMC < 31

NOAP + NOAM > 7

Classe tem muitos dados públicos

Mais do que alguns dados públicos

Complexidade da classe não é muito grande

WMC < 47

E

OU

Classe de Dados

48

FIGURA 11 - Estratégia de detecção de problema de POO Método Cérebro Fonte: Adaptado de LANZA; MARINESCU, 2006, p. 93.

Na estratégia de detecção Método Cérebro, os resultados das métricas LOC,

CYCLO, MAXNESTING e NOAV devem estar dentro dos valores limites estabelecidos

(condição E), conforme exibido na FIG. 11.


a) o método é muito grande;

b) o método possui muitas condições, ou seja, possui muitas estruturas de

controle if-else-if que evidencia o pouco uso do polimorfismo da abordagem

OO;

c) o método possui um nível profundo de aninhamento das suas estruturas

de controle;

d) o método utiliza muitas variáveis que dificultam o entendimento.

LOC > 130 / 2

E

Método possui muitas condições

CYCLO >= 0,24

MAXNESTING >= 5

Método possui aninhamento profundo

Método é muito grande

Método usa muitas variáveis

NOAV > 4

Método Cérebro

49

2.2.3.6 Estratégia de detecção “Classe Cérebro”

“Classe Cérebro” (Brain Class) representa uma classe complexa com uma grande

quantidade de inteligência, que normalmente possui vários métodos classificados como

Método Cérebro. Apesar da semelhança com Classe Deus, trata-se de problemas de projeto

distintos, visto que uma Classe Cérebro não acessa demasiadamente dados de outra classe e

possuem mais coesão.

FIGURA 12 - Estratégia de detecção de problema de POO Classe Cérebro Fonte: Adaptado de LANZA; MARINESCU, 2006, p. 98.

Na estratégia de detecção Classe Cérebro, o resultado da métrica LOC deve estar

dentro do valor limite estabelecido e (primeira condição E) a classe deve conter mais de um

método cérebro, ou (condição OU) a classe deve conter somente um método cérebro e

Classe Cérebro E

WMC >= 2 x 47

Complexidade funcional da classe é extremamente alta

LOC >= 19,5

Tamanho total dos métodos na classe é muito grande

Classe contém mais do que um Método Cérebro

Classe possui somente um Método Cérebro

LOC >= 2 x 19,5

Tamanho total dos métodos da classe é extremamente alto

WMC >= 47

Complexidade funcional da classe é muito alta

TCC < 0,5

Coesão da classe é baixa

E

E

OU

E

50

(segunda condição E) os resultados das métricas LOC e WMC devem estar dentro dos valores

limites estabelecidos. Ao mesmo tempo, os valores limites de WMC e (terceira condição E)

TCC devem estar dentro dos valores limites estabelecidos. Ao final, o resultado da estratégia

de detecção Classe Cérebro é a primeira ou a segunda condição “E” e (quarta condição E) a

terceira condição “E”. Esta estratégia de detecção é exibida na FIG. 12. Características da

estratégia de detecção:

a) a classe possui mais de um método classificado como Método Cérebro,

além de ser muito grande;

b) a classe possui apenas um método classificado como Método Cérebro

que é muito grande e complexo;

c) a classe é complexa e sem coesão.

2.2.3.7 Estratégia de detecção “Acoplamento Intensivo”

Na estratégia de detecção “Acoplamento Intensivo” (Intensive Coupling), o

objetivo é detectar um método que está muito ligado em vários outros métodos no sistema.

Em outras palavras, é uma estratégia para detectar um alto acoplamento, o que não é desejado

em um bom POO. Em termos práticos, existe uma classe cliente que está ligada à outra classe

provedora de diversos serviços na forma de métodos. Assim, entender a relação entre uma

classe cliente e uma classe provedora torna-se uma tarefa difícil.


a) o método chama muitos métodos de classes não relacionadas;

b) o método possui muitas estruturas condicionais aninhadas.

Na estratégia de detecção Acoplamento Intensivo, as métricas CINT e CDISP

devem estar dentro dos valores limites estabelecidos (primeira condição E), ou (condição OU)

as mesmas métricas devem estar dentro de outros valores limites estabelecidos (segunda

condição E).

51

FIGURA 13 - Estratégia de detecção de problema de POO Acoplamento Intensivo Fonte: Adaptado de LANZA; MARINESCU, 2006, p. 121.

Essa estratégia de detecção é exibida na FIG. 13.

2.2.3.8 Estratégia de detecção “Cirurgia de Espingarda”

A estratégia de detecção “Cirurgia de Espingarda” (Shotgun Surgery) tem como

objetivo encontrar classes em que uma mudança em seus métodos pode afetar

significativamente outros pontos do sistema. Tal problema de projeto refere-se ao forte

acoplamento de entrada e também à dispersão de acoplamento. Diferentemente das estratégias

de detecção No Acoplamento Intensivo e Acoplamento Dispersado, o interesse está,

exclusivamente, em dependências de entrada causadas por chamadas de método.


a) o método de uma determinada classe é chamado por vários outros

métodos de outras classes;

b) as chamadas de entrada são de várias classes.

CINT > 7

E

Classes estão “dispensadas” em outras classes

CDISP < 0,5

CINT > 4

Operação chama mais do que alguns métodos

Operações chamam muitos métodos

Chamadas estão “dispersadas” em poucas

classes CDISP < 0,25

E

OU

Acoplamento Intensivo

52

FIGURA 14 - Estratégia de detecção de problema de POO Cirurgia de Espingarda Fonte: Adaptado de LANZA; MARINESCU, 2006, p. 134.

Na estratégia de detecção Cirurgia de Espingarda, as métricas CM e CC devem

estar dentro dos valores limites estabelecidos (condição E). Essa estratégia de detecção é

exibida na FIG. 14.

2.2.3.9 Estratégica de detecção “Herança do Pai Recusada”

Na estratégia de detecção “Herança do Pai Recusada” (Refused Parent Bequest), o

objetivo é encontrar classes filhas que não utilizam métodos ou dados da classe pai, sendo que

a classe pai foi preparada para ser reutilizada pelas classes filhas. Se isso não ocorre, então o

principal objetivo da herança em POO não é alcançado, que é a reutilização. O que pode

acarretar classes filhas que implementem códigos já criados na classe pai e, dessa maneira,

contribuam para a duplicação de código.

Cirurgia de Espingarda E

CC > 5

As chamadas de entrada são de várias classes

CM > 7

Operação é chamada por vários outros métodos

53

FIGURA 15 - Estratégia de detecção de problema de POO Herança do Pai Recusada Fonte: Adaptado de LANZA; MARINESCU, 2006, p. 145.

Na estratégia de detecção Herança do Pai Recusada, os resultados das métricas

NProtM e BUR devem estar dentro dos valores limites estabelecidos (primeira condição E),

ou (primeira condição OU) a métrica BOvR deve estar dentro do valor limite estabelecido.

Paralelamente, o resultado da métrica AMW ou (segunda condição OU) o resultado da

métrica WMC devem estar dentro dos valores limites estabelecidos e (segunda condição E) o

resultado da métrica NOM deve estar dentro do valor limite estabelecido. Ao final, o

resultado da estratégia de detecção é a primeira condição “OU” e (terceira condição E) a

segunda condição “E”. Esta estratégia de detecção é exibida na FIG. 15.


NProtM > 4

E

Classe filha usa pouco da herança do pai

BUR < 0,33

BOvR < 0,33

Substituição de métodos é raro na classe filha

Classe pai fornece mais do que alguns membros protegidos

Complexidade funcional acima da média

AMW > 2

OU

WMC > 14

Complexidade de classe não inferior à média

Tamanho da classe acima da média

NOM > 7

E

OU

Herança do Pai Recusada E

54

a) a classe filha ignora a herança;

b) a classe filha não é pequena e simples como normalmente deveria ser.

2.2.3.10 Estratégia de detecção “Quebrador de Tradição”

A estratégia de detecção “Quebrador de Tradição” (Tradition Breaker) tem o

objetivo de encontrar classes filhas que forneçam um conjunto diversificado de serviços que

não estão relacionados com a classe pai. Dessa forma, a classe filha está “quebrando a

tradição” herdada da classe pai. Quando uma classe dificilmente especializa um serviço

herdado e, pelo contrário, só adiciona novos serviços que não dependem muito de herança,

então, isso indica que existe um problema de definição na interface da classe filha ou mesmo

um problema no relacionamento estabelecido.


a) um grande aumento na interface da classe filha;

b) a classe filha tem um tamanho e complexidade significativos;

c) a classe pai não é pequena e não é trivial.

Na estratégia de detecção Quebrador de Tradição, os resultados das métricas NAS

e PNAS devem estar dentro dos valores limites estabelecidos (primeira condição E).

Paralelamente, o resultado da métrica AMW ou (condição OU) o resultado da métrica WMC

devem estar dentro dos valores limites estabelecidos e (segunda condição E) o resultado da

métrica NOM deve estar dentro do valor limite estabelecido. Paralelamente, os resultados das

métricas AMW, NOM e WMC devem estar dentro dos valores limites estabelecidos (terceira

condição E). Ao final, o resultado da estratégia de detecção é a primeira, segunda e terceira

condição “E” (quarta condição E). Essa estratégia de detecção é exibida na FIG. 16.

55

FIGURA 16 - Estratégia de detecção de problema de POO Quebrador de Tradição Fonte: Adaptado de LANZA; MARINESCU, 2006, p. 152.

NAS >= 7

E

Serviços recém-adicionados são dominantes na classe filha

PNAS >= 0,66

AMW > 2

Complexidade do método na classe filha acima da média

Serviços mais recentemente adicionados do que a média NOM/class

Complexidade funcional da classe filha é muito alta

WMC >= 47

NOM >= 47

Classe tem número substancial de métodos

Complexidade funcional da classe pai acima da média

AMW > 2

E

OU

Pai tem mais da metade dos métodos da classe filha

NOM > 10 / 2

Complexidade das classes pais é mais da metade das classes filhas

WMC >= 47 / 2

E

Quebrador de Tradição E

56

2.3 Revisão Sistemática da Literatura

Este trabalho tem como objetivo apresentar uma Revisão Sistemática da Literatura

dos estudos que utilizam a abordagem multinível da Fundação openEHR e as ferramentas

existentes para coleta de métricas de OO que podem ser utilizadas no Modelo de Objetos do

openEHR. Uma Revisão Sistemática da Literatura ou Systematic Literature Review (SLR)

permite identificar e interpretar grandes informações relacionadas com uma questão de

pesquisa. Kitchenham e Charters (2007, p. 3)8 conceituam uma SLR como sendo “uma forma

de avaliar e interpretar toda pesquisa disponível que seja relevante para uma questão de

pesquisa em particular, uma área de concentração ou um fenômeno de interesse”.

Esta revisão pretende responder às seguintes questões de pesquisa:

Q1) Qual a distribuição geográfica dos estudos do openEHR?

Q2) Como foi a evolução anual dos estudos do openEHR desde a primeira

especificação (2004)?

Q3) Dentro dos estudos encontrados, quantos envolvem métricas de software?

Q4) Quais as ferramentas disponíveis para coleta de métricas de OO que

podem ser utilizadas no Modelo de Objetos do openEHR?

2.3.1 Método

Utiliza-se o método de Revisão Sistemática da Literatura por meio de

identificação e interpretação das pesquisas disponíveis na literatura. Trata-se de um método

robusto para mapear onde existe pouca pesquisa relevante, ou mesmo evidenciar que

nenhuma pesquisa tenha sido feita. Dessa forma, tem sido utilizado como um instrumento de

pesquisa comum na Engenharia de Software empírica (MACDONELL et al., 2010;

PETTICREW; ROBERTS, 2008).

8 “A systematic literature review (oftenreferred to as a systematic review) is a means of identifying, evaluating and interpreting all available research relevantto a particular research question, or topic area, or phenomenon of interest” (Tradução nossa).

57

2.3.2 Bases de dados

A pesquisa foi realizada nas principais bases de dados internacionais, as quais são

listadas abaixo:

ACM Digital Library;

Academic OneFile;

Biblioteca Digital de Teses e Dissertações (BDTD);

Biblioteca Virtual em Saúde (BIREME);

BioMed Central;

Cambridge University Press

Compendex (Engineering Village);

CrossRef;

Directory of Open AccesS Journals (DOAJ);

EBSCO;

Emerald;

IEEE Xplore;

INSPEC;

ISI Web of Science;

Sage;

ScienceDirect;

Scopus;

SpringerLink;

U.S. National Library of Medicine

Wiley.

58

2.3.3 String de busca

Para as questões de pesquisa Q1 a Q3 foi utilizada uma string de busca a partir

das seguintes palavras-chave em inglês: Registro Eletrônico de Saúde (com sinônimos) e

openEHR. Assim, a string de busca ficou da seguinte forma: (Electronic Health Record and

openEHR) OR (Electronic Medical Record and openEHR) OR (Electronic Medical System

and openEHR)

Para a qustão de pesquisa Q4 foi utilizado uma string de busca a partir das

seguintes palavras-chave em inglês: Ferramenta e Métrica e Orientação a Objeto. Assim, a

string de busca ficou da seguinte forma: (Metric AND Tool AND Object-Oriented) OR

(Metric AND Tool AND OO)

2.3.4 Critérios de inclusão e exclusão

Como seleção, foram considerados os critérios de inclusão:

CI1) idiomas português, inglês e espanhol;

C12) artigos completos publicados em periódicos e conferências;

C13) teses e dissertações defendidas.

Como critérios de exclusão:

CE1) ensaios;

CE2) artigos de revisão;

CE3) artigos em duplicidade.

CE4) trabalhos em que a abordagem openEHR existe apenas nas referências,

não sendo citada no estudo para as questões de pesquisa Q1 a Q3;

CE5) Ferramentas que não estão disponíveis para download para questão de

pesquisa Q4.

59

2.3.5 Estratégia de pesquisa

Foram utilizadas duas estratégias de pesquisa. Uma para as questões de Q1 a Q3 e

outra para questão de pesquisa Q4.

FIGURA 17 - Estratégia de pesquisa para as questões de pesquisa Q1 a Q3 Fonte: Dados da pesquisa.

A FIG. 17 exibe a estratégia de pesquisa utilizada nas questões de pesquisa Q1 a

Q3. Esta estratégia de pesquisa foi conduzida em três passos. Primeiro, utilizando-se as bases

de dados citadas anteriormente, foi efetuada uma pesquisa automática usando a string de

busca específica para as questões de pesquisa Q1 a Q3. No segundo passo, os critérios de

exclusão CE1, CE2 e CE3 foram aplicados no título e no resumo da publicação. No último

passo, os mesmos critérios de exclusão, acrescido do critério CE4, foram aplicados em todo o

conteúdo da publicação.

Bases de Dados

Pesquisa automática usando a string de busca

Passo 1 784 publicações

Aplicação dos critérios de exclusão CE1, CE2 e CE3 no

título e no resumo


Aplicação dos critérios de exclusão CE1, CE2, CE3 e CE4

na publicação inteira


60

FIGURA 18 - Estratégia de pesquisa para a questão de pesquisa Q4 Fonte: Dados da pesquisa.

A FIG. 18 exibe a estratégia de pesquisa utilizada na questão de pesquisa Q4. Essa

estratégia de pesquisa foi conduzida em quatro passos. Primeiro, utilizando-se as bases de

dados citadas anteriormente, foi efetuada uma pesquisa automática usando a string de busca

específica para a questão de pesquisa Q4. No segundo passo, os critérios de exclusão CE1,

CE2 e CE3 foram aplicados no título e no resumo da publicação. No terceiro passo, os

mesmos critérios de exclusão, acrescido do critério CE5, foram aplicados em todo o conteúdo

da publicação. No último passo, uma avaliação das ferramentas foi conduzida para obtenção

dos resultados descritos na próxima secção.

2.3.6 Resultados

Os resultados foram divididos de acordo com as questões de pesquisa Q1 a Q4.

Em cada seção é apresentado e discutido cada um desses resultados.

Bases de Dados

Pesquisa automática usando a string de busca

Passo 1 2.661 publicações

Aplicação dos critérios de exclusão CE1, CE2 e CE3 no

título e no resumo

Passo 2 1.184 publicações

Aplicação dos critérios de exclusão CE1, CE2, CE3 e CE5

na publicação inteira


Avaliação da ferramenta Passo 4 33 publicações

61

2.3.6.1 Questão de pesquisa Q1

Para a questão de pesquisa Q1, os projetos estão distribuídos geograficamente por

38 países.

GRÁFICO 1 - Distribuição geográfica dos estudos relacionados ao openEHR Fonte: Dados da pesquisa.

Estudos colaborativos entre países foram contabilizados em todos os países

envolvidos, exceto quando era aplicado ou financiado por um órgão de um país específico.

Nesse caso, foi creditado somente o país de aplicação. O GRAF. 1 exibe o resultado dessa

questão de pesquisa em números de publicações.

0 3 6 9 12 15 18 21 24 27 30

EspanhaReino Unido

AustráliaAlemanha

SuéciaEstados Unidos

HolandaÁustría

BrasilChina

Coréia do SulPortugal

FrançaItália

IrlandaRomênia

CanadáJapão

NoruegaTaiwan

DinamarcaTurquiaBélgica

FinlândiaSuíça

Indonésia

62

Nesse resultado não são apresentados os países com apenas um estudo

encontrado. São eles: Eslovênia, Nova Zelândia, Hungria, Uruguai, Israel, República Tcheca,

Peru, Tunísia, Colômbia, Grécia e Índia.

Dentre os países de destaque, com relação ao Reino Unido e à Austrália, era

esperada uma grande quantidade de estudos, visto que a Fundação openEHR foi fundada pela

University College London do Reino Unido e pela Ocean Informatics Pty Ltd da Austrália

(KALRA; BEALE; HEARD, 2005). Além disso, a maior parte dos conselheiros da Fundação

openEHR são professores-doutores desses dois países, o que ajuda a disseminar os estudos.

A Espanha foi o país com a maior quantidade de estudos encontrados, o que se

deve, principalmente, aos excelentes estudos que são reconhecidos pela Fundação openEHR

(OPENEHR, 2013b): desenvolvimento de bibliotecas Java para traduzir arquétipos openEHR

para OWL (LEZCANO; SICILIA; RODRÍGUEZ-SOLANO, 2011); editor arquétipo de

referência chamado LinkEHR (MALDONADO, et al., 2009); projeto POSEACLE para

facilitar a gestão semântica de informação e conhecimento em RES (MALDONADO, et al.,

2012; COSTA; TORTOSA; FERNÁNDEZ-BREIS, 2011; COSTA; TORTOSA;

FERNÁNDEZ-BREIS, 2010); projeto gestão de terminologias para arquétipos (ALLONES et

al., 2013; MEIZOSO GARCÍA et al., 2012).

A Alemanha também tem projetos destacados pela Fundação openEHR:

expressão de conjuntos de dados clínicos com arquétipos do openEHR ((DUFTSCHMID et

al., 2013; GARDE et al., 2006) e modelagem de prontuário eletrônico do paciente usando a

abordagem openEHR (BUCK et al., 2009).

A Suécia possui uma grande contribuição de estudos devido ao programa de

doutorado da Karolinska Institutet, o qual explora a tecnologia RES, em especial a abordagem

openEHR. O Brasil foi o único país sul-americano em destaque por contribuição das teses de

doutorado concluídas (DIAS, 2011; SANTOS, 2011) e por linhas de pesquisas existentes em

universidades e hospitais (ALVERNAZ; COOK; CAVALINI, 2012; SILVA; SANTOS;

CORREIA, 2013; SILVA et al., 2013; MORAES et al., 2013).

Em uma análise geral, foi observada a predominância dos estudos no continente

europeu, o qual representa 65,29%, seguido do continente asiático com 11,16%. Os estudos

realizados no Brasil compõem praticamente 4,96% do total do continente sul-americano.

63


A questão de pesquisa Q2 analisou a evolução anual dos estudos do openEHR

desde a primeira especificação do openEHR em 2004. O GRAF. 2 exibe o resultado dessa

questão de pesquisa.

GRÁFICO 2 - Evolução anual dos estudos relacionados ao openEHR Fonte: Dados da pesquisa.

De 2004 a 2008, a cada ano, a Fundação openEHR liberou uma nova versão da

especificação, o que corrobora para a evolução regular que houve nesse intervalo exibida no

GRAF. 2. A versão de 2008 é a última versão estável da especificação, o que culminava com

um grande aumento nos estudos realizados a partir desse marco. No ano de 2013, houve uma

queda no número estudos, provavelmente por haver publicações que ainda não foram

catalogadas nas bases de dados pesquisadas.

0

5

10

15

20

25

30

35

40

45

2004 2005 2006 2007 2008 2009 2010 2011 2012 2013

64


A questão de pesquisa Q3 procurou estudos que envolvem métricas de software.

Durante essa revisão, o único estudo encontrado foi o trabalho de Ahn et al. (2012), que tinha

como objetivo desenvolver métricas de qualidade para avaliar modelos clínicos detalhados.

Nesse estudo, foram desenvolvidas métricas de qualidade baseadas no modelo de qualidade

ISO 9126, assim como feito no modelo de qualidade QMOOD, utilizado nesta dissertação.

Entretanto, até o presente momento e com a estratégia de pesquisa utilizada, esta dissertação

foi a primeira a abordar métricas de qualidade de software para avaliar o modelo de objetos

do openEHR, o que evidencia a originalidade dessa obra.


A questão de pesquisa Q4 identificou as ferramentas disponíveis para coleta de

métricas de OO à disposição na literatura. Como resultado, foram encontradas 42 publicações,

nas quais 21 ferramentas estavam disponíveis para avaliação, conforme QUADRO 6.

Das ferramentas encontradas, foi feita uma primeira avaliação para identificar

quais eram aplicadas em código fonte em Java, visto que os Modelos de Objetos do openEHR

são medidos pela implementação de referência em Java, que é reconhecida pela Fundação

openEHR. Foram encontradas ferramentas que avaliam apenas modelos em notação UML,

como é o caso de MetricView, SDMetrics e Software Architecture Analysis Tool (SAAT).

Esse tipo de ferramenta coleta informações obtidas de diversos diagramas, como diagramas de

classes, estados, caso de uso, sequência e componentes. Entretanto, métricas de OO que

precisam de implementações em seus métodos ficam impossibilitadas de serem aplicadas.

Foram encontrados resultados em que as ferramentas eram aplicadas em código fonte, mas

não permitindo o uso de código fonte em Java, como no caso de QMOOD++, Cantata++ e

JBOOMT.

65

QUADRO 6

Resultado das ferramentas encontradas para coleta de métricas de OO

Ferramenta Usa código fonte em

Java Cantata++ Não

CCCC Não

CKJM Sim

Classycle Sim

DependencyFinder Sim

ES2 Não

InCode Sim

InFusion Sim

iplasma Sim

JBOOMT Não

JDepend Sim

JHawk Sim

Metric (Plugin Eclipse) Sim

MetricView Não

OOMeter Sim

QMOOD++ Não

SDMetrics Não Software Architecture Analysis Tool (SAAT)

Não

SourceMonitor Sim

Understand Sim

UnitMetrics Sim

XLSTAT Não Fonte: Dados da pesquisa.

Por fim, as ferramentas que coletam métricas de OO em código fonte Java foram

instaladas e avaliadas. As ferramentas Classycle, DependencyFinder, InCode, JDepend,

OOMeter, SourceMonitor, Understand e XLSTAT, possuem poucas métricas implementadas

das listadas na seção 2.2.1. Já as ferramentas CKJM, InFusion (2013), iPlasma (2009)e

JHawk (2013) possuem a maioria das métricas listadas na seção 2.2.1.

No caso das métricas relacionadas com as estratégias de detecção de problemas de

POO, a ferramenta InFusion possui todas as métricas listadas. Por essa razão, ela foi

selecionada para esta dissertação. Outra justificativa, é que essa ferramenta é uma evolução da

ferramenta iPlasma, que foi criada no projeto europeu FAMOOS ESPRIT, por Marinescu em

1998, citada no trabalho de Lanza e Marinescu (2006), e que foi o modelo para aplicação das

estratégias de detecção de POO desta dissertação. Além disso, ela foi utilizada em vários

66

projetos de sistemas industriais, incluindo vários sistemas open-source, como Mozilla e

Eclipse.

Já em relação às métricas do modelo de qualidade QMOOD, a ferramenta mais

adequada foi a CKJM que permitiu a aplicação de todas as métricas necessárias, com exceção

da métrica DCC. Além disso, a ferramenta disponibiliza um recurso de customização de

métricas, o qual foi utilizado para a montagem da métrica DCC. Dessa maneira, a ferramenta

permitiu a aplicação de todas as métricas do modelo de qualidade QMOOD.

2.3.7 Conclusão

É possível observar que o continente europeu é o grande centro dos estudos

relacionados com a abordagem openEHR. A Austrália é uma exceção nesse cenário, devido

principalmente ao fato de ter uma organização, a Ocean Informatics Pty Ltd, como uma das

fundadoras da Fundação openEHR e por ter professores doutores que fazem parte do conselho

dela. Pode-se concluir que uma versão estável da especificação openEHR contribuiu para o

grande aumento de estudos a partir de 2008.

Em relação às métricas de software aplicadas ao modelo do openEHR, até a

realização deste projeto de pesquisa, não se observaram estudos dessa natureza. Essa

inexistência de estudos é uma grande motivação que corresponde ao tema central deste

trabalho. Além disso, esta revisão possibilitou relacionar as ferramentas para coleta de

métricas de OO disponíveis na literatura. Após uma avaliação das ferramentas, foram

selecionadas as ferramentas InFusion e CKJM. A primeira por conter todas as métricas que

podem ser aplicadas nas estratégias de detecção de problemas de POO e por ser uma

ferramenta validada em vários projetos de sistemas industriais, como Mozilla e Eclipse. A

segunda ferramenta foi selecionada por permitir maior uso de métricas disponíveis na

aplicação do modelo de qualidade QMOOD e de possibilitar a customização de novas

métricas, recurso que foi utilizado para customizar a métrica DCC.

67

2.4 Trabalhos relacionados

Esta seção descreve os trabalhos relacionados com este estudo que foram

encontrados na literatura, após uma pesquisa bibliográfica e a revisão sistemática da literatura

discutida na seção anterior. O objetivo é apresentar uma breve descrição do trabalho,

destacando as semelhanças e diferenças existentes em relação a esta dissertação.

2.4.1 Avaliação da qualidade de POO entre código fonte X diagrama UML

O trabalho desenvolvido por Bertrán (2009) avalia a qualidade de POO com base

no modelo de qualidade QMOOD em complemento com as técnicas de detecção de

problemas de qualidade de POO. De forma específica, o estudo avaliou a qualidade de POO,

exclusivamente, a partir de diagramas em notação UML e com a validação dos resultados

obtidos com outros resultados que utilizaram técnicas e mecanismos de análise de código

fonte.

Esta dissertação tem como ponto em comum a avaliação da qualidade de POO

com a aplicação do modelo de qualidade QMOOD em conjunto com a utilização de

estratégias de detecção de problemas de POO. Entretanto, a avaliação do Modelo de Objetos

do openEHR é o tema central da discussão deste trabalho. Já Bertrán (2009) foca na avaliação

de qualidade de POO a partir de notação UML.

2.4.2 Métricas de OO para identificação de complexidade e problemas de POO

Os autores Reddy e Rao (2009) fizeram um trabalho para detectar a complexidade

e problemas de projeto com o uso de métricas de OO. A hipótese levantada pelos autores é de

que existe uma relação entre problemas de POO e complexidade, ou seja, quanto maior o

número de problemas de POO, maior é a complexidade. Este trabalho difere no conjunto de

métricas selecionadas pelos autores, pois estão relacionadas com complexidade, ao contrário

das métricas desta dissertação, que estão relacionadas com qualidade de POO.

68

2.4.3 Avaliação da usabilidade de interface gráfica em sistemas RES

Com o objetivo de identificar métricas existentes para avaliar interface gráfica de

usuários em sistemas de Registro Eletrônico de Saúde (RES), Kopanitsa, Tsvetkova e Veseli

(2012) fazem uma revisão da literatura na qual estudam várias abordagens e padrões. Esta

dissertação possui duas similaridades com o trabalho de Kopanitsa et al. (2012):, uma é a área

de domínio, sistema de RES, outra é a utilização de um conjunto de métricas para avaliação

do domínio em questão. Entretanto, os trabalhos se diferem quanto ao objetivo a ser

alcançado com a aplicação das métricas em sistemas de RES. O presente trabalho pretende

avaliar a qualidade de POO do modelo openEHR para sistemas de RES, enquanto o trabalho

dos autores pretende avaliar a usabilidade das interfaces gráficas de usuário de sistemas de

RES.

2.4.4 Avaliação orientada a aspectos e a objetos em sistemas de poços de petróleo

Freitas (2009) apresenta um conjunto de métricas baseadas em abordagens

existentes de avaliação de sistemas orientados a aspectos e a objetos. Tais métricas são

aplicadas em um sistema de monitoramento de poços de petróleo. Esse é um ponto em

comum com esta dissertação, visto que ambos os trabalhos têm como aplicação uma área de

domínio específica, apesar de serem domínios diferentes. Entretanto, o trabalho do autor faz

uma avaliação orientada a aspectos, além da avaliação de OO. Já este trabalho não tem como

objetivo uma avaliação orientada a aspectos.

2.4.5 Identificação de ferramentas para detecção de problemas de POO

O trabalho de Fontana, Braione e Zanoni (2012) tem como objetivo fazer uma

revisão sobre as ferramentas de detecção automática de problemas no código com base em um

conjunto de métricas. Para tal, os autores utilizam um amplo conjunto de métricas,

principalmente de métricas OO. As estratégias para detecção de problemas no código

69

envolvem principalmente a abordagem de Lanza e Marinescu (2006), abordagem que também

serve de base para esta dissertação. Outra similaridade é a busca por ferramentas para

detecção de problemas que fazem uso de métricas. Entretanto, a avaliação das ferramentas é

objetivo central do trabalho de Fontana, Braione e Zanoni (2012), enquanto nesta dissertação

as ferramentas são avaliadas e utilizadas apenas como meio para atingir o objetivo geral.

70

3 EXPERIMENTO

A medição é considerada o centro do estudo experimental, em que existe um

mapeamento do mundo experimental para o mundo formal, com o intuito de manipular os

atributos das entidades empíricas de maneira formal (TRAVASSOS; GUROV; AMARAL,

2002).

Para executar o experimento corretamente é necessário um processo que apoie o

pesquisador para alcançar seu objetivo e ser capaz de formular conclusões. O processo de

experimento definido por Wohlin et al. (2012) foi formulado para garantir que as ações

possam conduzir ao sucesso do experimento. Esse processo, adotado neste trabalho, está

dividido nas atividades de definição, planejamento, operação e análise dos resultados que são

detalhadas em seções deste capítulo.

3.1 O projeto Java Reference Implementation

O projeto Java Reference Implementation (JRI) é uma implementação de

referência na linguagem de programação Java, reconhecida e publicada no sítio da Fundação

openEHR (CHEN, 2006). Este projeto foi iniciado em 2004 com base nas especificações da

Fundação openEHR e foi implementado por uma equipe da Suécia especializada em sistemas

de RES. O kernel do JRI é composto pelo Modelo de Referência (MR) e pelo Modelo de

Objeto de Arquétipos (MOA), dessa forma, representando o Modelo de Objetos (CHEN;

KLEIN, 2007). Os objetivos do projeto são:

a) validar as especificações de projeto publicadas por meio das

implementações de código, além de fornecer feedbacks para a melhoria das

especificações;

b) criar uma aplicação em Java fiel às especificações do projeto e

tecnicamente sólida. Dessa forma, pode proporcionar uma finalidade

educacional para potencias desenvolvedores da especificação openEHR;

71

c) trabalhar ideias inovadoras de projeto para validá-las pelas

implementações que futuramente podem ser abstraídas em novas

especificações do projeto;

d) fornecer um framework comum, agrupado como componentes de

software reutilizáveis e coerentes como blocos de construção para sistemas de

RES.

O projeto JRI é destacado por Cavalini e Cook (2012) como uma exceção de uma

solução baseada na modelagem multinível que foi implementada em serviços de saúde, visto

que o JRI foi utilizado como base por algumas equipes de pesquisadores ao redor do mundo.

Primeiramente, em um projeto web para gerenciamento de quimioterapia no hospital da

Universidade Karolinska em Estocolmo. Serviu como base para a construção de uma série de

aplicações pelo grupo de informática médica da Universidade de Linköping. No Uruguai, foi

construída uma aplicação para ser utilizada em Unidades de Terapia Intensiva (UTI)

financiada pelo Ministério da Educação. Na Holanda, foi construído um sistema comercial

para cuidados clínicos de idosos. Também serviu para construção de um parser ADL

implementado por uma equipe de pesquisadores da Universidade Queensland da Austrália.

Utilizado em um framework de teste independente de plataforma para a validação de

implementações de arquétipos openEHR. No desenvolvimento de um sistema móvel de

enfermaria para uso em smartphones e tablets que utilizam a plataforma Android. Além do

desenvolvimento de software para conversão automática entre arquétipos openEHR e

modelos de um RES regional da Suécia. (CHEN; KLEIN, 2007; CHEN et al., 2008; 2009;

KOSTINGER et al., 2013; OSORIO et al., 2013).

Nem todas as versões do Modelo de Objetos da especificação openEHR foram

implementadas no JRI. O QUADRO 7 mostra a relação das versões do Modelo de Objetos do

openEHR com o JRI.

72

QUADRO 7

Relacionamento de versões do Modelo de Objetos do openEHR X JRI

Ordem Modelo de Objetos openEHR Java Reference Implementation

Versão Data Versão Data

1 0.9 04/05/2004 Não teve equivalente

2 0.95 15/03/2005 0.95 22/03/2006

3 1.0 07/02/2006 1.0 10/08/2006

4 1.0.1 15/04/2007 1.0.1 13/12/2007

5 1.0.2 31/12/2008 Não teve equivalente

6 Current Baseline 1.0.5

Fonte: OpenHER, 2013b. Disponível em: <http://www.openehr.org/about/foundation>. Acesso em: 4 abr. 2013

No QUADRO 7, é possível evidenciar que as versões 0.9 e 1.0.2 do Modelo de

Objetos openEHR não tiveram implementações no JRI. Além disso, a versão atual no projeto

JRI é identificada como 1.0.5, enquanto no Modelo de Objetos do openEHR é nomeada como

Current Baseline.

O projeto atual do JRI possui 51 pacotes, nos quais estão distribuídas 269 classes

que possuem 2.584 métodos e que totalizam 31.464 linhas de código.

3.2 Definição

Na definição do estudo é utilizada a abordagem Goal/Question/Metric (GQM)

com o intuito de especificar as metas, definir uma especificação de um conjunto de questões e

conjunto de regras para a interpretação dos dados de medição. A estrutura deste estudo é

exibida no QUADRO 8.

73

QUADRO 8

Definição do experimento

Analisar: o Modelo de Objetos

Com o propósito de: avaliar atributos de qualidade

Com respeito a: Projeto Orientada a Objeto

Do ponto de vista: do pesquisador

No contexto: da especificação openEHR

Fonte: Dados da pesquisa.

3.3 Planejamento

A seleção do contexto do experimento é a especificação da Fundação openEHR

que contempla documentos, diagramas UML e o código fonte do projeto Java Reference

Implementation. Além disso, foi criado um laboratório para o experimento por meio do uso de

máquina virtual. O uso desse contexto permite que outros pesquisadores tenham grandes

possibilidades de replicar esse experimento.

A avaliação da qualidade foi feita com base no modelo Quality Model for Object-

Oriented Design (QMOOD). O modelo QMOOD tem como objetivo avaliar atributos de

qualidade de POO, que podem ser quantificados por intermédio de métricas OO

(ALSHAMMARI; FIDGE; CORNEY, 2009; BERTRÁN, 2009).

As métricas de software são consideradas um mecanismo importante para avaliar

a qualidade de POO. Entretanto, apresenta uma limitação pela dificuldade em obter

interpretações adequadas nas medições efetuadas. Nesse sentido, o valor da métrica não deixa

clara a causa da não conformidade e, como consequência, afeta a relevância dos resultados

(LANZA; MARINESCU, 2006; MARINESCU, 2004). Como o modelo QMOOD possui essa

limitação, este estudo utiliza mecanismos definidos como estratégias de detecção. Esses

mecanismos capturam desvios dos princípios e heurísticas da OO por meio de valores limites

com base em estudos empíricos (BERTRÁN, 2009). A estratégia de detecção foi adotada

nesse estudo para auxiliar na interpretação dos resultados obtidos das métricas aplicadas ao

Modelo de Objetos.

74

Foram selecionados os atributos de qualidade Reusabilidade, Flexibilidade,

Funcionalidade e Facilidade de Compreensão. Eles pertencem ao conjunto de atributos de

qualidade definidos no modelo QMOOD.

3.4 Operação

Na primeira fase da operação, foram obtidos os artefatos necessários para este

estudo, que são compostos pelo código fonte do projeto Java Reference Implementation (JRI),

além das especificações e diagramas UML do Modelo de Objetos do openEHR. Todos esses

artefatos estão disponíveis no sítio da Fundação openEHR. Um mapeamento das versões do

Modelo Objetos em relação às versões do JRI foi efetuado com o objetivo de identificar a

correlação entre eles, e em alguns casos a inexistência dessa correlação. O resultado desse

mapeamento foi exibido no QUADRO 7.

Paralelamente, foram identificadas as ferramentas de extração das métricas

disponíveis na literatura por meio do método de Revisão Sistema da Literatura. As

ferramentas escolhidas foram InFusion e CKJM (INFUSION, 2013, CKJM, 2011). Os

motivos da escolha foram detalhados na seção dedicada à Revisão Sistemática da Literatura.

Na segunda fase da operação, as métricas foram aplicadas, por meio da ferramenta

CKJM, para obter os atributos de qualidade definidos pelo QMOOD. Esses resultados foram

exportados e analisados na próxima atividade do experimento. No caso das estratégias de

detecção de problemas de POO descritas na seção 2.2.2, primeiramente, foram parametrizados

os valores limites na ferramenta InFusion. Depois, as estratégias de detecção foram

executadas para que os problemas de projeto fossem identificados. Os resultados obtidos pela

ferramenta InFusion foram exportados para serem analisados e interpretados na próxima

atividade do experimento.

3.5 Resultados

Em relação aos resultados, existiram dois grupos: os resultados das estratégias de

detecção de problemas de POO e os resultados dos atributos de qualidade com base no

75

modelo QMOOD. Primeiramente, são discutidas as estratégias de detecção de problemas de

POO e depois os resultados dos atributos de qualidade do modelo QMOOD. De forma

colaborativa, os resultados das estratégias de detecção são relacionados com os resultados do

modelo de qualidade QMOOD, visto que eles identificam os pontos em que existem

problemas de POO. Em alguns casos de problemas de POO encontrados, são apresentadas

algumas técnicas de refatoração para a melhoria da qualidade.

A TAB. 2 exibe os resultados das estratégias de detecção. Em todas as versões

analisadas não houve problemas de projeto nas estratégias de detecção Acoplamento

Intensivo, Cirurgia de Espingarda, Herança do Pai Recusada e Quebrador de Tradição. De

forma contrária, as estratégias de detecção Classe de Dados e Inveja de Funcionalidade

tiverem problemas de projeto em todas as versões analisadas. Já as estratégias, Classe Deus e

Classe Cérebro tiveram problemas apenas nas duas últimas versões e na última versão,

respectivamente.

TABELA 2

Resultado das estratégias de detecção de problemas de POO

Estratégias de Detecção Versão

0.95 1.0 1.0.1 1.0.5

Acoplamento Intensivo 0 0 0 0

Cirurgia de Espingarda 0 0 0 0

Classe Cérebro 0 0 0 1

Classe de Dados 20 30 26 20

Classe Deus 0 0 1 7

Herança do Pai Recusada 0 0 0 0

Inveja de Funcionalidade 2 2 5 7

Método Cérebro 2 2 3 10

Quebrador de Tradição 0 0 0 0

Fonte: Dados da pesquisa

A estratégia Classe Deus identificou algumas classes com grandes

responsabilidades, na qual se destaca a classe Archetype, a principal classe do MOA que

possui 521 linhas de código e 27 métodos em sua última versão. Com esse tipo de classe

76

existirá dificuldades de evolução (LANZA; MARINESCU, 2006). Para correção desse

problema de projeto (refatoração), Shatnawi e Li (2011) propõem os seguintes passos: decidir

como dividir a classe, criar a nova classe, fazer uma ligação entre as duas classes, mover os

campos para a nova classe, e por fim, mover métodos para a nova classe.

Os métodos identificados na estratégia Inveja de Funcionalidade fazem parte

apenas das classes XMLSerializer e ADLSerializer. Essas classes não fazem parte do Modelo

de Objetos do openEHR, ou seja, trata-se de artifício utilizado pelo JRI no tratamento de

XML e de arquétipos em linguagem ADL. De acordo com Lanza e Marinescu (2006), tal

problema de projeto é resolvido movendo o método para a classe onde ele está mais acoplado.

A estratégia de detecção Classe de Dados foi a que teve o maior número de

ocorrências em todas as versões. As classes detectadas possuem a característica de ter muitos

dados, que são manipulados por outras classes, ao invés de implementar seus próprios

métodos. Exemplos encontrados são as classes Archetyped, EHR, EHRExtract e Entry.

A estratégia de detecção Classe Cérebro encontrou um problema de projeto na

classe Flattener somente na última versão. Essa classe foi criada no MOA 1.5 para atender à

funcionalidade de modelos (templates) de arquétipos. Essa classe se enquadrou nas

características de complexidade e na existência de muitos Métodos Cérebro. É a maior classe

do JRI com 1.732 linhas de código.

A estratégia Método Cérebro detectou problemas de projeto em todas as versões,

sendo que houve um aumento significativo na última versão por causa da inclusão do controle

de modelos de arquétipos. Esse modelo de arquétipos envolveu a classe Flattener, citada

anteriormente, a qual possui muitos Métodos Cérebro.

Na segunda parte, os resultados das propriedades de projeto do modelo QMOOD

foram obtidos e exibidos na TAB. 3.

77

TABELA 3

Resultado das propriedades de projeto com base no QMOOD

Propriedades de Projeto Versão

0.95 1.0 1.0.1 1.0.5

Abstração 0,31 0,29 0,39 0,41

Acoplamento 5,40 5,86 5,69 5,89

Coesão 0,41 0,42 0,44 0,45

Complexidade 1.548 1.821 2.862 3.635

Composição 1,25 1,33 0,95 0,88

Encapsulamento 0,70 0,71 0,69 0,65

Herança 0,05 0,04 0,05 0,05

Hierarquias 52,00 57,00 91,00 109,00

Polimorfismo 0,25 0,23 0,33 0,26

Tamanho do Projeto 169,00 194,00 231,00 269,00

Troca de mensagens 1.126,00 1.284,00 1.681,00 2.148,00


78

TABELA 4

Resultado normalizado das propriedades de projeto com base no QMOOD

Propriedades de Projeto Versão

0.95 1.0 1.0.1 1.0.5

Abstração 1,00 0,94 1,26 1,32

Acoplamento 1,00 1,09 1,05 1,09

Coesão 1,00 1,02 1,07 1,10

Complexidade 1,00 1,18 1,85 2,35

Composição 1,00 1,06 0,76 0,70

Encapsulamento 1,00 1,01 0,99 0,93

Herança 1,00 0,80 1,00 1,00

Hierarquias 1,00 1,10 1,75 2,10

Polimorfismo 1,00 0,92 1,32 1,04

Tamanho do Projeto 1,00 1,15 1,37 1,59

Troca de mensagens 1,00 1,14 1,49 1,91


Como os valores das métricas possuem intervalos diferentes para cada

propriedade de POO, então é necessário que seja feito uma normalização de todas as versões

dividindo o resultado de cada versão pela primeira versão. Assim, os resultados das

propriedades de POO da TAB. 3 foram normalizados em relação aos valores da versão 0.95 e

apresentadas na TAB. 4. Para uma melhor visualização, os mesmos dados da TAB. 4 são

apresentados no GRAF. 3.

As propriedades Complexidade, Hierarquias, Troca de Mensagens e Tamanho do

Projeto tiveram seus valores maiores em relação à versão anterior. Como as versões novas

incorporam novas funcionalidades, então, era esperado que a cada nova versão os valores

dessas propriedades fossem maiores.

De uma maneira discreta os valores da propriedade Coesão também aumentaram

em relação à versão anterior. Isso é um bom indicador, visto que uma alta coesão é desejada

em POO, já que um módulo altamente coeso tende a ser mais confiável, reutilizável e

compreensível (RAMNATH; DATHAN, 2011). O que corrobora com a composição dessa

propriedade nas fórmulas dos atributos de qualidade Reusabilidade e Facilidade de

Compreensão.

79

GRÁFICO 3 - Resultado das propriedades de projeto nas versões do JRI Fonte: Dados da pesquisa.

Em relação ao Acoplamento, o valor chegou a diminuir da versão 1.0 para 1.01,

mas voltou a subir na versão 1.0.5. O ideal é que não houvesse aumento nessa propriedade,

pois é desejado um baixo acoplamento em POO (BOOCH et al., 2007). Isso significa que a

dependência entre os módulos da versão corrente aumentou. Assim, uma modificação em um

módulo pode resultar em mudanças em outros módulos, o que pode gerar um efeito dominó e

dificultar o entendimento do projeto.

O valor da Composição diminuiu nas últimas duas versões. Nessas versões o

número de Hierarquias cresceu expressivamente, o que indica que, em alguns casos, a relação

de composição entre algumas classes foi substituída pela Herança.

A propriedade de Herança teve o mesmo valor em todas as versões, com exceção

da versão 1.0 na qual teve uma leve queda. Ou seja, de uma forma geral, manteve-se estável.

0,60

0,80

1,00

1,20

1,40

1,60

1,80

2,00

2,20

2,40

0.95 1.0 1.0.1 1.0.5

Abstração Acoplamento Coesão

Complexidade Composição Encapsulamento

Herança Hierarquias Polimorfismo

Tamanho do Projeto Troca de mensagens

80

Dessa maneira, essa propriedade irá afetar positivamente o atributo de qualidade

Reusabilidade, pois tem impacto importante no POO (SHATNAWI; ALZU’BI, 2011).

A propriedade polimorfismo foi a única que teve diferentes variações. O valor

diminuiu na versão 1.0, aumentou na versão 1.01 e voltou a diminuir na versão 1.0.5. O valor

da propriedade Encapsulamento esteve estável da versão 0.95 para a versão 1.0 e teve uma

leve queda da versão 1.01 para a versão 1.05. Isso não é um indicador bom, pois indica que os

atributos e métodos estão mais disponíveis para outras classes, não existindo uma barreira

explícita entre as diferentes abstrações que foram criadas (BOOCH et al., 2007). De forma

complementar, Shatnawi e Alzu’bi (2011) citam que a falta de encapsulamento viola a

segurança de classes e, consequentemente, a possibilidade de defeitos de software.

O resultado da TAB. 4 foi utilizado nas fórmulas dos atributos de qualidade

descritos no QUADRO 4 da seção 2.2.2. Assim, foram obtidos os resultados dos atributos de

qualidade em cada versão do JRI do modelo QMOOD, os quais são exibidos na TAB. 5.

TABELA 5

Resultado dos atributos de qualidade com base no QMOOD

Atributo de Qualidade Versão

0.95 1.0 1.0.1 1.0.5

Facilidade de Compreensão -0,99 -1,06 -1,58 -1,77

Flexibilidade 1,00 0,97 1,02 0,83

Funcionalidade 1,00 1,07 1,43 1,59

Extensibilidade 1,00 0,79 1,26 1,14

Reusabilidade 1,00 1,13 1,43 1,75


Os atributos de qualidade Flexibilidade, Funcionalidade, Extensibilidade e

Reusabilidade estão agrupados no GRAF. 4 para uma melhor análise temporal. O atributo de

qualidade Facilidade de Compreensão foi separado no GRAF. 5 para ter uma melhor

visualização pelo fato dele conter valores negativos.

81

GRÁFICO 4 - Resultado dos atributos de qualidade Flexibilidade, Funcionalidade, Extensibilidade e Reusabilidade Fonte: Dados da pesquisa

Os atributos de qualidade Reusabilidade e Flexibilidade aumentaram da versão

anterior para a próxima versão. Como as novas versões do Modelo de Objetos do openEHR

incorporaram novos recursos, então, esperava-se que fossem incrementados os valores desses

atributos. Além disso, problemas de projeto da versão anterior são corrigidos na versão

seguinte. De acordo com Bansiya e Davis (2002) existem duas razões principais para novas

versões: implementação de novos recursos e correção de bugs que foram descobertos em

versões anteriores.

O atributo de qualidade Flexibilidade e Extensibilidade tiveram uma tendência de

queda, com exceção da versão 1.0.1. Os principais fatores foram as propriedades de projeto

Acoplamento e Polimorfismo. Primeiramente, o Acoplamento aumentou, o que significa que

existe uma maior interdependência entre os objetos. Já a propriedade de polimorfismo

diminuiu, indicando que existem métodos que não utilizam recursos já implementados pela

classe pai. Além disso, a propriedade de projeto Encapsulamento impactou, exclusivamente,

no atributo de qualidade Flexibilidade, visto que os dados e métodos ficaram mais expostos e

são utilizados por outras classes. Nesse sentido, afeta a capacidade do projeto ser adaptado

para novos recursos em uma grande reestruturação.

0,70

0,90

1,10

1,30

1,50

1,70

0.95 1.0 1.0.1 1.0.5

Flexibilidade Funcionalidade Extensibilidade Reusabilidade

82

GRÁFICO 5 - Resultado do atributo de qualidade Facilidade de Compreensão Fonte: Dados da pesquisa.

Já com relação ao atributo Facilidade de Compreensão, os valores diminuíram da

versão anterior para a versão seguinte, conforme exibido no GRAF. 5. A adição de novos

recursos no Modelo de Objetos do openEHR, fez com que esSe atributo tivesse tal

comportamento, pois foram adicionadas muitas classes e métodos nas novas versões, o que

fez com que elas sejam mais difíceis de entender e aprender. Entretanto, conforme citado por

Bansiya e Davis (2002), é esperado que uma versão madura reverta a tendência de queda

desse atributo após várias versões iniciais.

-1,90

-1,70

-1,50

-1,30

-1,10

-0,90

-0,700.95 1.0 1.0.1 1.0.5


83

4 CONSIDERAÇÕES FINAIS

Este trabalho avaliou a qualidade de Projeto Orientado a Objeto do Modelo de

Objetos do openEHR, utilizando o framework Java Reference Implementation (JRI)

disponibilizado pela própria Fundação openEHR. Para atingir esse objetivo geral, dois

objetivos específicos foram definidos e alcançados. Foi identificado um conjunto de métricas

de OO para avaliação da qualidade de POO do Modelo de Objetos do openEHR por meio de

pesquisa bibliográfica e observação direta. Nas seções 2.2.2 e 2.2.3 são apresentados esses

resultados. Depois foram identificadas e avaliadas as ferramentas para aplicação de métricas

de OO, por intermédio de uma revisão sistemática da literatura e observação direta. As

ferramentas escolhidas foram InFusion (INFUSION, 2013) para a avaliação das estratégias de

detecção de problemas de POO e CKJM (CKJM, 2011) para avaliação dos atributos de

qualidade de POO.

A avaliação da qualidade de POO foi dividida em duas partes: primeiro foram

aplicadas as estratégias de detecção de problemas de POO definidas na seção 2.2.3 em quatro

versões do JRI. Posteriormente, foi feita uma avaliação dos atributos de qualidade de POO

com base no modelo de qualidade QMOOD.

Na parte relativa à aplicação das estratégias de detecção de problemas de POO,

foram identificados seis problemas de projetos do total de dez propostos nesta avaliação. Os

problemas de POO encontrados foram Classe Deus, Inveja de Funcionalidade, Classe de

Dados, Classe Cérebro e Método Cérebro. Na análise dos resultados foram citadas algumas

técnicas de correção (refactoring) dos problemas de POO com base na literatura. Não foram

encontrados problemas de POO Acoplamento Intensivo, Cirurgia de Espingarda, Herança do

Pai Recusada e Quebrador de Tradição. O que permite concluir que, de uma maneira geral, os

problemas de POO aumentaram de acordo com o aumento da complexidade do Modelo de

Objetos do openEHR.

Na segunda parte, foram avaliados os atributos de qualidade Facilidade de

Compreensão, Flexibilidade, Funcionalidade, Extensabilidade e Reusabilidade com base no

modelo de qualidade QMOOD, proposto por Bansiya e Davis (2002). No modelo de

qualidade QMOOD é esperado que os atributos de qualidade aumentem ao longo das versões.

Nesse sentido, os atributos de qualidade Reusabilidade e Funcionalidade satisfizeram as

expectativas. Já os atributos de qualidade Extensabilidade e Flexibilidade mostraram-se

instáveis, ou seja, aumentaram e diminuíram ao longo das versões, sendo que na última versão

84

os valores diminuíram. Por fim, o atributo de qualidade Facilidade de Compreensão teve

queda em todas as versões. Entretanto, Bansiya e Davis (2002) ressaltam que essa situação é

normal até que uma versão madura reverta a tendência de queda desse atributo. Portanto,

conclui-se que o Modelo de Objetos do openEHR tem ganho de novos recursos e tem a

capacidade de reutilizar módulos já existentes para resolver um novo problema com pouco

esforço. Entretanto, novos requisitos em recursos já existentes podem ser mais trabalhosos,

assim como a adaptação do projeto como um todo para novos recursos. Além disso, o projeto

apresenta uma dificuldade de ser aprendido e compreendido devido ao aumento constante de

sua complexidade.

4.1 Limitações da pesquisa

Uma das limitações encontradas neste trabalho foi a falta de implementação de

código em alguns métodos de algumas classes do projeto Java Reference Implementation do

openEHR. Essa limitação impacta somente em métricas que envolvem métodos, ou seja,

métricas que envolvem classes e pacotes não tiveram o impacto dessa limitação. De qualquer

forma, a amostra de classes que continham métodos sem implementação foi bastante pequena,

em torno de 8% em relação ao universo total de classes com métodos implementados.

A segunda delas foi a inexistência da estratégia de detecção de problema de POO

Acoplamento Dispersado em todas as ferramentas avaliadas. Por fim, outra limitação foi a

retirada da estratégia de detecção de problema de POO Duplicação Signiticativa por não

apresentar os resultados isolados das métricas utilizadas na ferramenta escolhida.

4.2 Trabalhos Futuros

Uma sugestão de trabalho futuro seria a aplicação do modelo proposto neste

trabalho no modelo de referência da norma ISO 13606, que trata da interoperabilidade de

sistemas RES semelhante à abordagem da Fundação openEHR.

85

A norma ISO 13606 foi baseada na implementação do pré-padrão europeu ENV

13606 e foi especificada pelo comitê técnico ISO/TC 215 de informática em saúde (SANTOS,

2011).

86

REFERÊNCIAS

AHMED, S. H.; SOLIMAN, T. H. A.; SEWISY, A. A. A Hybrid Metrics Suite for Evaluating Object-Oriented Design. v. 6, n. 1, 1 jan. 2013. Disponível em: <http://www.researchgate.net/publication/235608274_Utilizing_CK_metrics_suite_to_UML_models_A_case_study_of_Microarray_MIDAS_software/file/d912f51446d42e9c73.pdf>.Acesso em: 29 nov. 2013.

AHN, S. et al. Quality metrics for detailed clinical models. International journal of medical informatics, 2012. Disponível em: <http://www.sciencedirect.com/science/article/pii/S1386505612001906>. Acesso em: 4 abr. 2013.

ALLONES, J. L. et al. SNOMED CT module-driven clinical archetype management. Journal of Biomedical Informatics, v. 46, n. 3, p. 388-400, jun. 2013. Disponível em: <http://www.sciencedirect.com/science/article/pii/S1532046413000051>. Acesso em: 27 out. 2013.

ALSHAMMARI, B.; FIDGE, C.; CORNEY, D. Security metrics for object-oriented class designs. [S.l: s.n.], 2009. p. 11-20. Disponível em: <http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5381538>. Acesso em: 11 jun. 2013.

ALVERNAZ, C.; COOK, T. W.; CAVALINI, L. T. Migration of a Pre-hospital Cardiology Emergency System from Data Model to Multilevel Modeling. SIGHIT Rec., v. 2, n. 1, p. 9-9, mar. 2012. Disponível em: <http://doi.acm.org.ez27.periodicos.capes.gov.br/10.1145/2180796.2180801>. Acesso em: 27 set. 2013.

ATALAG, K.; YANG, H. Y.; WARREN, J. Assessment of Software Maintainability of openEHR Based Health Information Systems–A Case Study In Endoscopy. Electronic Journal of Health Informatics, v. 7, n. 1, p. 3, 2011. Disponível em: <http://www.ejhi.net/ojs/index.php/ejhi/article/view/156 >. Acesso em: 4 mar. 2013.

BANSIYA, J.; DAVIS, C. G. A hierarchical model for object-oriented design quality assessment. IEEE Transactions on Software Engineering, v. 28, n. 1, p. 4-17, jan. 2002.

87

BEALE, T. Archetype Object Model. London: The OpenEHR Foundation, 2008. Disponível em: <http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/aom1.4.pdf>. Acesso em: 22 jul. 2012.

BEALE, T. EHR versus Messages - Resources - openEHR Wiki, 2013. Disponível em: <http://www.openehr.org/wiki/display/resources/EHR+versus+Messages>. Acesso em: 30 jan. 2013.

BEALE, T. The openEHR Modelling Guide. London: The OpenEHR Foundation, 2007. Disponível em: <http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/modelling_guide.pdf>. Acesso em: 17 nov. 2012.

BEALE, T.; HEARD, S. Architecture Overview. London: The OpenEHR Foundation, 2007. Disponível em: <http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/overview.pdf>. Acesso em: 21 jul. 2012.

BERTRÁN, I. M. Avaliação da qualidade de software com base em modelos UML. 2009. 118 f. Dissertação (Mestrado em Informática) – Pontifícia Universidade Católica do Rio de Janeiro, Rio de Janeiro, 2009. Disponível em: <http://www2.dbd.puc-rio.br/pergamum/biblioteca/php/mostrateses.php?open=1&arqtese=0711290_09_Indice.html>. Acesso em: 26 mar. 2013.

BLAHA, M.; RUMBAUGH, J. Modelagem e projetos baseados em objetos com UML 2. 2ª. ed. Rio de Janeiro: Elsevier, 2006.

BOOCH, G. et al. Object-Oriented Analysis and Design with Applications. 3. ed. Boston: Pearson, 2007.

BUCK, J. et al. Towards a comprehensive electronic patient record to support an innovative individual care concept for premature infants using the openEHR approach. International Journal of Medical Informatics, v. 78, n. 8, p. 521-531, ago. 2009. Disponível em: < http://www.sciencedirect.com/science/article/pii/S1386505609000380 >. Acesso em: 17 out. 2013.

88

CAVALINI, L. T.; COOK, T. W. Sistemas de informacão em saúde: a importância do software livre e da modelagem multinível. J Bras TelesSaúde, v. 1, p. 16-23, 2012. Disponível em: <http://www.telessaude.uerj.br/resource/jornal/pdf/446.pdf>. Acesso em: 30 mar. 2013.

CHEN, R. et al. An archetype-based testing framework. Studies in Health Technology and Informatics, v. 136, p. 401, 2008. Disponível em: <http://books.google.com.br/books?hl=pt-BR&lr=&id=krj78Gs4njkC&oi=fnd&pg=PA401&dq=%22An+archetype-based+testing+framework%22&ots=Dwht8bE5fw&sig=bkbsr72qV4aw5KefmYJupsYgsQ8 >. Acesso em: 20 mar. 2013.

CHEN, R. et al. Archetype-based conversion of EHR content models: pilot experience with a regional EHR system. BMC Medical Informatics and Decision Making, PMID: 19570196, v. 9, n. 1, p. 33, 1 jul. 2009. Disponível em: < http://www.biomedcentral.com/1472-6947/9/33/abstract>. Acesso em: 28 abr. 2014.

CHEN, R. OpenEHR Reference Model Java ITS. [S.l: s.n.], 2006. Disponível em: <http://research.behdasht.gov.ir/uploads/256_1197_openEHR-JavaITS.pdf>. Acesso em: 20 mar. 2013.

CHEN, R.; KLEIN, G. The openEHR Java reference implementation project. Studies in health technology and informatics, v. 129, n. 1, p. 58, 2007. Disponível em: <http://books.google.com.br/books?hl=pt-BR&lr=&id=dEXxG4XyvKwC&oi=fnd&pg=PA58&dq=%22ARCHETYPE+OBJECT+MODEL%22&ots=AwzHqgKCGn&sig=P-iVgl8vF6zX8D3-rY2YJr-i5GI>. Acesso em: 20 mar. 2013.

CHIDAMBER, S. R.; DARCY, D. P.; KEMERER, C. F. Managerial use of metrics for object-oriented software: An exploratory analysis. Software Engineering, IEEE Transactions on, v. 24, n. 8, p. 629-639, 1998. Disponível em: <http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=707698 >. Acesso em: 27 mar. 2013.

CHIDAMBER, S. R.; KEMERER, C. F. A metrics suite for object oriented design. Software Engineering, IEEE Transactions on, v. 20, n. 6, p. 476-493, 1994. Disponível em: <http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=295895>. Acesso em: 27 mar. 2013.

89

CHOTJARATWANICH, U.; ARPNIKANONDT, C. A Visualization Technique for Metrics-Based Hierarchical Quality Models. In: SOFTWARE ENGINEERING CONFERENCE (APSEC), 2012 19TH ASIA-PACIFIC, dez. 2012, [S.l: s.n.], dez. 2012. p. 733-736.

CKJM extended. [S.l: s.n.], 2011. Disponível em: <http://gromit.iiar.pwr.wroc.pl/p_inf/ckjm/>. Acesso em: 21 set. 2013.

COSTA, C. M.; TORTOSA, M. M.; MALDONADO, J. T. F. B. Semantic Web technologies for managing EHR - related clinical knowledge. n. Semantic Web, 2009. Disponível em: <http://cdn.intechopen.com/pdfs/9396/InTech-Semantic_web_technologies_for_managing_ehr_related_clinical_knowledge.pdf>. Acesso em: 20 mar. 2013.

COSTA, C. M.; TORTOSA, M. M.; FERNÁNDEZ-BREIS, J. T. Clinical data interoperability based on archetype transformation. Journal of Biomedical Informatics, v. 44, n. 5, p. 869-880, out. 2011. Disponível em: < http://www.j-biomed-inform.com/article/S1532-0464(11)00097-9/abstract >.Acesso em: 28 nov. 2013.

COSTA, C. M.; TORTOSA, M. M.; FERNÁNDEZ-BREIS, J. T. An approach for the semantic interoperability of ISO EN 13606 and OpenEHR archetypes. Journal of Biomedical Informatics, v. 43, n. 5, p. 736-746, out. 2010. Disponível em: < http://www-sciencedirect-com.ez27.periodicos.capes.gov.br/science/article/pii/S1532046410000821 >. Acesso em: 30 nov. 2013.

DIAS, R. D. M. Modelagem do padrão TISS por meio do enfoque dual da Fundação openEHR. 2011. Universidade do Estado do Rio de Janeiro. Faculdade de Ciências Médicas, 2011. Disponível em: <http://bases.bireme.br/cgi-bin/wxislind.exe/iah/online/?IsisScript=iah/iah.xis&src=google&base=LILACS&lang=p&nextAction=lnk&exprSearch=691823&indexSearch=ID>. Acesso em: 18 out. 2013.

DUFTSCHMID, G. et al. The EHR-ARCHE project: Satisfying clinical information needs in a Shared Electronic Health Record System based on IHE XDS and Archetypes. International Journal of Medical Informatics, v. 82, n. 12, p. 1195-1207, dez. 2013. Disponível em: <http://www.ijmijournal.com/article/S1386-5056(13)00173-1/abstract >. Acesso em: 5 nov. 2013.

FERREIRA, K. A. M. Um modelo de predição de amplitude da propagação de modificações contratuais em software orientado por objetos. 2011. Universidade Federal de Minas Gerais,

90

Belo Horizonte, 2011. Disponível em: <http://www.bibliotecadigital.ufmg.br/dspace/bitstream/handle/1843/SLSS-8GYFSX/keciaalinemarquesferreira.pdf?sequence=1>. Acesso em: 25 jul. 2013.

FONTANA, F. A.; BRAIONE, P.; ZANONI, M. Automatic detection of bad smells in code: An experimental assessment. The Journal of Object Technology, v. 11, n. 2, p. 51, 2012. Disponível em: <http://www.jot.fm/contents/issue_2012_08/article5.html>. Acesso em: 6 nov. 2013.

FREITAS, T. A. V. Métricas para avaliação de sistemas middleware orientado a aspectos e aplicação em um sistema de monitoramento de poços de petróleo. 2009. 149 f. Dissertação (Sistemas e Computação) Universidade Federal do Rio Grande do Norte, Natal, 2009. Disponível em: <http://repositorio.ufrn.br:8080/jspui/bitstream/1/7183/1/TassiaAVF.pdf>. Acesso em: 23 jul. 2013.

GARDE, S. et al. Ubiquitous information for ubiquitous computing: expressing clinical data sets with openEHR archetypes. Studies in Health Technology And Informatics, v. 124, p. 215-220, 2006. Disponível em: <http://search.ebscohost.com/login.aspx?direct=true&db=mdc&AN=17108528&lang=pt-br&site=ehost-live&authtype=ip,cookie,uid>. Acesso em: 15 nov. 2013.

GARZAS, J.; PIATTINI, M. Object-Oriented Design - knowledge_ principles, heuristics, and best practices. London: Idea Group Publishing, 2007.

GILL, N. S.; SIKKA, S. Inheritance Hierarchy Based Reuse & Reusability Metrics. In: OOSD. International Journal on Computer Science & Engineering, v. 3, n. 6, p. 2300-2309, jun. 2011.

HADERER, N.; KHOMH, F.; ANTONIOL, G. SQUANER: A framework for monitoring the quality of software systems. , [S.l: s.n.], 2010. p. 1-4. Disponível em: <http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5609684>. Acesso em: 11 jun. 2013.

HEDAYAT, R. Semantic web technologies in the quest for compatible distributed health records. 2010. 65 f. Dissertação (Degree of Master Mathematics and Computer Science) – Uppsala University, Uppsala, 2010. Disponível em: <http://uu.diva-portal.org/smash/record.jsf?pid=diva2:310787>. Acesso em: 2 abr. 2013.

91

HU, W.-C. et al. Vesta: A view-based software quality assessmentmodel for software evolution management. 2010, [S.l: s.n.], 2010. p. 345-348. Disponível em: <http://140.116.240.3/conference/ISAD/files/Q38951043-a.pdf>. Acesso em: 11 jun. 2013.

INFUSION. [S.l: s.n.], 2013. Disponível em: <http://www.intooitus.com/products/infusion>. Acesso em: 14 ago. 2013.

IPLASMA. [S.l: s.n.], 2009. Disponível em: <http://loose.upt.ro/reengineering/research/iplasma?_s=js15YOoptg-IaJbU&_k=diQZmMR4&_n&14>. Acesso em: 16 mar. 2013.

JHAWK. [S.l: s.n.], 2013. Disponível em: <http://www.virtualmachinery.com/jhawkprod.htm>. Acesso em: 23 nov. 2013.

KALRA, D. Electronic health record standards. Yearb Med Inform, p. 136-144, 2006. Disponível em: <http://www.schattauer.de/de/magazine/uebersicht/zeitschriften-a-z/imia-yearbook/imia-yearbook-2006/issue/special/manuscript/6382/download.html>. Acesso em: 2 abr. 2013.

KALRA, D.; BEALE, T.; HEARD, S. The openEHR Foundation. Studies in Health Technology and Informatics, v. 115, p. 153-173, 2005. Disponível em: <http://search.ebscohost.com/login.aspx?direct=true&db=mdc&AN=16160223&lang=pt-br&site=ehost-live&authtype=ip,cookie,uid>. Acesso em: 28 abr. 2014.

KITCHENHAM, B.; CHARTERS, S. Guidelines for Performing Systematic Literature Reviews in Software Engineering, Keele University. [S.l.]: UK EBSE-2007-1, 2007.

KOPANITSA, G.; TSVETKOVA, Z.; VESELI, H. Analysis of metrics for the usability evaluation of electronic health record systems. Studies In Health Technology And Informatics, v. 174, p. 129–133, 2012. Acesso em: 6 out. 2013.

KOSTINGER, H. et al. Developing a NFC based patient identification and ward round system for mobile devices using the android platform. In: 2013 IEEE POINT-OF-CARE HEALTHCARE TECHNOLOGIES (PHT), [S.l: s.n.], jan. 2013. p. 176-179.

92

LANZA, M.; MARINESCU, R. Object-Oriented Metrics in Practice: Using Software Metrics to Characterize, Evaluate, and Improve the Design of Object-Oriented Systems. [S.l.]: Springer, 2006. Disponível em: <http://books.google.com.br/books?hl=pt-BR&lr=&id=gdLbgnaMaa0C&oi=fnd&pg=PA1&dq=Object-Oriented+Metrics+in+Practice+autor:LANZA&ots=s_vMtJElsQ&sig=wqqIV07_68oqUDtQOGHo8n1c6uU>. Acesso em: 11 jun. 2013.

LEZCANO, L.; SICILIA, M.-A.; RODRÍGUEZ-SOLANO, C. Integrating reasoning and clinical archetypes using OWL ontologies and SWRL rules. Journal of Biomedical Informatics, v. 44, n. 2, p. 343-353, abr. 2011. Disponível em: <http://www.j-biomed-inform.com/article/S1532-0464(10)00171-1/abstract>. Acesso em: 30 nov. 2013.

LOPES, V. P. Repositório de Conhecimento de um Ambiente de Apoio à Experimentação em Engenharia de Software. 2010. Dissertação (Engenharia de Sistemas e Computação) – Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2010. Disponível em: <http://fenix3.ufrj.br/60/teses/coppe_m/VitorPiresLopes.pdf>. Acesso em: 12 abr. 2013.

LORENZ, M.; KIDD, J. Object-oriented software metrics. [S.l.]: Prentice-Hall, 1994. Disponível em: <http://www.weibnc.com/wp-content/uploads/brkpdfs/Object-Oriented-Software-Metrics-by-Jeff-Kidd-Relates-Metrics-To-Quality.pdf>. Acesso em: 16 mar. 2013.

MACDONELL, S. et al. How reliable are systematic reviews in empirical software engineering? Software Engineering, IEEE Transactions on, v. 36, n. 5, p. 676-687, 2010. Disponível em: <http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5416726>. Acesso em: 5 nov. 2013.

MALDONADO, J. A. et al. LinkEHR-Ed: A multi-reference model archetype editor based on formal semantics. International Journal of Medical Informatics, v. 78, n. 8, p. 559-570, 2009. Disponível em: < http://www.sciencedirect.com/science/article/pii/S1386505609000513>. Acesso em: 20 mar. 2013.

MALDONADO, J. A. et al. Using the ResearchEHR platform to facilitate the practical application of the EHR standards. Journal of Biomedical Informatics, v. 45, n. 4, p. 746-762, ago. 2012. Disponível em: <http://www.j-biomed-inform.com/article/S1532-0464(11)00192-4/abstract>. Acesso em: 30 nov. 2013.

93

MALVIYA, A. K.; SINGH, V. The Role and Issues of Clustering Technique in Designing Maintainable Object Oriented System. International Journal on Computer Science & Engineering, v. 3, n. 2, p. 784-788, fev. 2011.

MEI, H.; XIE, T.; YANG, F. A model-based approach to object-oriented software metrics. Journal of Computer Science and Technology, v. 17, n. 6, p. 757-769, nov. 2002. Disponível em: <http://link-springer-com.ez27.periodicos.capes.gov.br/article/10.1007/BF02960766>. Acesso em: 7 set. 2013.

MEIZOSO GARCÍA, M. et al. Semantic similarity-based alignment between clinical archetypes and SNOMED CT: An application to observations. International Journal of Medical Informatics, v. 81, n. 8, p. 566-578, ago. 2012. Disponível em: <http://www.ijmijournal.com/article/S1386-5056(12)00039-1/abstract>. Acesso em: 30 out. 2013.

MORAES, J. L. C. et al. A novel architecture for message exchange in Pervasive Healthcare based on the use of Intelligent Agents. In: 2013 ACS INTERNATIONAL CONFERENCE ON COMPUTER SYSTEMS AND APPLICATIONS (AICCSA), maio 2013, [S.l: s.n.], maio 2013. p. 1-8.

OBJECT MANAGEMENT GROUP (OMG). OMG Unified Modeling Language (OMG UML) - Infrastructure. Needham: Object Management Group, 2011. Disponível em: <http://www.omg.org/spec/UML/2.4.1/Infrastructure/PDF>.

OPENEHR. openEHR - Academic Research, 2013a. Disponível em: <http://www.openehr.org/who_is_using_openehr/academic_research>. Acesso em: 16 out. 2013.

OPENEHR. openEHR - Foundation, 2013b. Disponível em: <http://www.openehr.org/about/foundation>. Acesso em: 4 abr. 2013.

OSORIO, E. et al. Interoperability in Ambient Assisted Living using OpenEHR. In: 2013 IEEE 15TH INTERNATIONAL CONFERENCE ON E-HEALTH NETWORKING, APPLICATIONS SERVICES (HEALTHCOM), [S.l: s.n.], out. 2013. p. 394-398.

PETERS, J. F.; PEDRYCZ, W. Engenharia de Software - Teoria e Prática. Rio de Janeiro: Campus, 2001.

94

PETTICREW, M.; ROBERTS, H. Systematic reviews in the social sciences: A practical guide. [S.l.]: Wiley. com, 2008. Disponível em: <http://books.google.com.br/books?hl=pt-BR&lr=&id=ZwZ1_xU3E80C&oi=fnd&pg=PR5&dq=%22Systematic+Reviews+in+the+Social+Sciences%22&ots=wWW0xUNTMw&sig=sTXvGKnxP0c1q1LUnp7HIMHTNHs>. Acesso em: 5 nov. 2013.

PFLEEGER, S. L. Engenharia de software: teoria e prática. 2ª. ed. São Paulo: Prentice Hall, 2004.

PRESSMAN, R. S. Software Engineering. 7. ed. New York: McGraw-Hill, 2010.

RAMNATH,, S.; DATHAN, B. Object-Oriented Analysis and Design. New York: Springer, 2011.

REDDY, K. R.; RAO, A. A. Dependency Oriented Complexity Metrics to Detect Rippling Related Design Defects. SIGSOFT Softw. Eng. Notes, v. 34, n. 4, p. 1–7, jul. 2009. Disponível em: < http://doi.acm.org.ez27.periodicos.capes.gov.br/10.1145/1543405.1543421 >. Acesso em: 6 ago. 2013.

SACHDEVA, S.; BHALLA, S. Implementing high-level query language interfaces for archetype-based electronic health records database. 2009, [S.l: s.n.], 2009. p. 235-238. Disponível em: <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.175.9962&rep=rep1&type=pdf>. Acesso em: 20 mar. 2013.

SANTOS, M. R. Sistema de registro eletrônico de saúde baseado na norma ISO 13606: aplicacões na Secretaria de Estado de Saúde de Minas Gerais. 2011. 175 f. Tese (Doutorado em Ciência da Informação) – Escola de Ciência da Informação, Universidade Federal de Minas Gerais, Belo Horizonte, 2011. Disponível em: <http://dspace.lcc.ufmg.br/dspace/bitstream/1843/ECIC-8L8HFJ/1/tese_eci_ufmg____marcelo_rodrigues_dos_santos___2011.pdf>. Acesso em: 30 mar. 2013.

SANTOS, M. R.; BAX, M. P.; PESSANHA, C. Uma leitura ontológica da norma ISO 13606 para o Registro Eletrônico de Saúde. In: CONGRESSO BRASILEIRO DE INFORMÁTICA NA SAÚDE, Porto de Galinhas. Anais... Porto de Galinhas: [s.n.], 2010a. Disponível em: <http://sres.saude.mg.gov.br/upload/manual/PaperArquetiposeontologias-SESMG.pdf>. Acesso em: 30 mar. 2013.

95

SANTOS, M. R.; BAX, M. P.; PEÇANHA, C. Codificando Arquétipos em linguagem ADL com base no modelo de referência da norma ISO 13606. [S.l: s.n.], 2010b. Disponível em: <http://143.107.58.177/cecas/sites/default/files/wim%202010/st08_02.pdf>. Acesso em: 20 mar. 2013.

SOCIEDADE BRASILEIRA DE INFORMÁTICA EM SAÚDE; CONSELHO FEDERAL DE MEDICINA. Cartilha sobre Prontuário Eletrônico – a Certificação de Sistemas de Registro Eletrônico de Saúde. [S.l: s.n.]. Disponível em: <http://www.sbis.org.br/site/site.dll/noticia?pagina=18&item=1>. , Acesso em: 8 abr. 2014.

SHATNAWI, R.; ALZU’BI, A. A Verification of the Correspondence between Design and Implementation Quality Attributes Using a Hierarchal Quality Model. IAENG International Journal of Computer Science, v. 38, n. 3, p. 225-233, set. 2011. Disponível em: <http://search.ebscohost.com/login.aspx?direct=true&db=iih&AN=65482339&lang=pt-br&site=ehost-live&authtype=ip,cookie,uid>. Acesso em: 8 abr. 2014.

SHATNAWI, R.; LI, W. An Empirical Assessment of Refactoring Impact on Software Quality using a Hierarchical Quality Model. International Journal of Software Engineering and Its Applications, v. 5, n. 4, 2011.

SILVA, G. M. B. et al. OpenEHR-based pervasive health information system for primary care: First Brazilian experience for public care. In: 2013 IEEE 26TH INTERNATIONAL SYMPOSIUM ON COMPUTER-BASED MEDICAL SYSTEMS (CBMS), jun. 2013, [S.l: s.n.], jun. 2013. p. 572-873.

SILVA, G. M. B.; SANTOS, R. F. S.; CORREIA, R. J. C. Creating openEHR content to different moments of care: Obstetrics emergency scenario. In: 2013 IEEE 26TH INTERNATIONAL SYMPOSIUM ON COMPUTER-BASED MEDICAL SYSTEMS (CBMS), jun. 2013, [S.l: s.n.], jun. 2013. p. 361-364.

SILVA, M. L. Manual de Certificacão para Sistemas de Registro Eletrônico em Saúde (S-RES). . [S.l: s.n.], 2011. Disponível em: <http://www.sbis.org.br/certificacao/Manual_Certificacao_SBIS_CFM_2011_v4_Consulta_Publica.pdf>. Acesso em: 30 mar. 2013.

96

THURSTON, L. M. Flexible and extensible display of archetyped data: The openEHR presentation challenge. In: HIC 2006 BRIDGING THE DIGITAL DIVIDE: CLINICIAN, CONSUMER AND COMPUTER, 2006, Adelaide. Anais... Adelaide: Health Informatics Society of Australia Ltd, 2006. p. 28-36. Disponível em: <http://my.openehr.org/wiki/download/attachments/2949261/006_Thurston.pdf>. Acesso em: 20 mar. 2013.

TRAVASSOS, G. H.; GUROV, D.; AMARAL, E. Introdução à Engenharia de Software Experimental. [S.l.]: UFRJ, 2002. Disponível em: <http://www2.ufpa.br/cdesouza/teaching/topes/4-ES-Experimental.pdf>. Acesso em: 12 abr. 2013.

VAVASSORI, F. B. Metodologia para o gerenciamento distribuído de projetos e métrica de software. 2002. Tese (Doutorado em Engenharia de Produção) – Universidade Federal de Santa Catarina, 2002. Disponível em: <http://tcciguilhermeselias.googlecode.com/svn/trunk/%20tcciguilhermeselias%20--username%20deixapramim/Estado_da_Arte/GerenciamentoDistribuido_MetricasSoftware.pdf>. Acesso em: 4 abr. 2013.

VELTE, L. M. Electronic health record repository based on the openEHR standard. 2011. 70 f. Dissertação (Mestrado em Engenharia de Computadores e Telemática) – Universidade de Aveiro, Aveiro, 2011. Disponível em: <http://ria.ua.pt/handle/10773/7479>. Acesso em: 2 abr. 2013.

VERGARA, S.C. Projetos e relatórios de pesquisa em administração. 6. ed. São Paulo: Atlas, 2005.

WAZLAWICK, R. S. W. Metodologia de pesquisa para ciência da computação. 6. ed. Rio de Janeiro: Elsevier, 2008.

WOHLIN, C.; RUNESON, P.; HÖST, M.; OHLSSON, M.C.; REGNELL, B.;WESSLÉN, A. Experimentation in Software Engineering: an Introduction. Norwell: Kluwer Academic Publishers, 2012?

97

APÊNDICE A

Lista completa das estratégias de detecção de problemas de POO

Versão 1.0.5

Estratégia de Detecção Objeto detectado

Classe Cérebro Flattener

Classe de Dados

Archetyped

Attestation

AuditDetails

Contribution

EHR

EHRExtract

Entry

EventContext

FeederAudit

FeederAuditDetails

ISMTransition

InstructionDetails

Link

Message

Participation

PrimitiveObjectBlock

Role

Transition

TranslationDetails

Version

Classe Deus

Archetype

ArchetypeValidator

DADLBinding

DvDuration

Flattener

SpecialisedArchetypeValidator

XMLSerializer

Inveja de Funcionalidade

DADLBinding.methodbindPrimitiveBlock

XMLSerializer.methodprintHeader

XMLSerializer.methodprintDescriptionItem

XMLSerializer.methodprintDescription

XMLSerializer.methodprintAssertion

ADLSerializer.methodprintArchetypeSlot

ADLSerializer.methodoutput

98

APÊNDICE B

Resultado das métricas de classes com problemas de POO

Versão 1.0.5

Classe

AM

WA

TF

DB

OV

RB

UR

CC

LA

AL

OC

NA

SN

OA

MN

OM

NP

rotM

P

NA

ST

CC

WM

C

Archetype

2,485

01

70,71

45316

827

01

0,1267

ArchetypeV

alidator6,23

470

11

0,191452

01

444

00,03

274

Archetyped

1,360

01

21

1452

511

01

0,515

Attestation

1,421

01

00,88

1362

812

01

017

AuditD

etails1,57

10

14

0,94171

210

141

10,5

22

Contribution

1,71

01

00,9

1222

610

01

0,517

DA

DL

Binding

416

01

00,11

3300

014

00

056

DvD

uration1,47

50,1

0,678

0,38560

140

361

0,560,06

53

EH

R1,61

11

10

0,88190

016

180

00

29

EH

RE

xtract1

00

10

1101

010

120

01

12

Entry

1,870

01

21

1892

1115

21

028

EventC

ontext1,63

10

10

0,95234

313

190

10,5

31

FeederA

udit1,54

00

10

1157

29

130

10,5

20

FeederA

uditDetails

1,190

01

01

1642

1216

01

0,519

Flattener

4,9116

01

00,36

16540

153

180

0260

ISM

Transition

1,622

11

00,6

1010

68

00

013

InstructionDetails

1,250

11

01

870

68

00

010

Link

1,50

01

11

1312

610

01

0,515

Message

1,920

11

01

1990

1112

00

023

Participation

1,751

01

00,92

1612

812

01

0,521

Prim

itiveObjectB

lock1

01

11

140

05

60

00

6

Role

1,60

10,14

01

1320

610

40

0,516

SpecialisedA

rchetypeValidator

7,424

00,8

00

7413

020

01

0148

Term

Map

2,642

01

20,75

2940

114

00

0,537

Transition

20

11

01

890

46

00

012

TranslationD

etails1,42

00

12

1134

28

120

10,5

17

Version

1,31

01

40,9

1973

1420

11

0,1726

XM

LS

erializer3,71

870

10

0,03990

00

4836

00

178

99

APÊNDICE C

Resultado das métricas de métodos com problemas de POO

Versão 1.0.5

Método CDISP CINT CM CYCLO FDPMAXNE

STINGNOAV

ArchetypeValidator.methodcheckArchetypeTermValidity 1 1 0 13 6 4 12

ArchetypeValidator.methodcheckCodeConstraintValidity 1 1 0 13 6 4 12

ArchetypeValidator.methodvalidateCAttribute 0,67 6 0 54 6 9 22

SpecialisedArchetypeValidator.methodcheckSpecialisedRMType

CompatiblityOfValueChildren 0,88 8 0 24 2 7 21

RMInspector.methodloadTypeMap 0 0 0 2 0 2 4

RMInspector.methodfindMatchingRMClass 0 0 0 22 0 7 14

ADLSerializer.methodprintOntology 1 1 0 14 5 6 15

ADLSerializer.methodprintLanguage 0 0 0 5 4 4 4

ADLSerializer.methodprintDescriptionItem 0 0 0 1 3 1 3

ADLSerializer.methodoutput 0 0 0 2 2 2 2

ADLSerializer.methodprintArchetypeSlot 1 1 0 5 2 3 3

XMLSerializer.methodprintOntology 1 1 0 15 7 5 9

XMLSerializer.methodprintHeader 1 2 0 4 2 2 2

XMLSerializer.methodprintAssertion 0 0 0 4 2 3 2

XMLSerializer.Description 0 0 0 5 1 2 1

XMLSerializer.methodprintDescriptionItem 0 0 0 1 1 1 1

SkeletonGenerator.methodcreateComplexObject 0,88 17 0 81 7 27 37

Flattener.methodapplyOccurrencesConstraint 0,75 4 0 35 4 4 11

Flattener.methodapplyDefaultValueConstraint 0,69 13 0 11 2 5 16

Flattener.methodapplyQuantityConstraint 0,57 14 0 20 1 5 13

Party.methodParty 0,67 3 2 12 2 4 17

Actor.methodActor 1 2 4 8 1 3 16

Address.methodAddress 1 1 0 2 0 2 9

PartyRelationship.methodPartyRelationship 1 1 0 4 0 2 15

Capability.methodCapability 1 1 0 2 0 2 11

Agent.methodAgent 1 1 0 1 0 1 13

PartyIdentity.methodPartyIdentity 1 1 0 2 0 2 9

Role.methodRole 1 1 0 4 0 2 17

Organisation.methodOrganisation 1 1 0 1 0 1 13

Group.methodGroup 1 1 0 1 0 1 13

Person.methodPerson 1 1 0 1 0 1 13

Contact.methodContact 1 1 0 3 0 2 11

VersionedParty.methodVersionedParty(A) 1 1 0 1 0 1 10

VersionedParty.methodVersionedParty(B) 1 1 0 1 0 1 7

VersionedParty.methodVersionedParty(C) 1 1 0 1 0 1 12

DADLBinding.methodbindPrimitiveBlock 1 1 0 7 2 6 3

RMInspector.methodloadTypeMap 0 0 0 2 0 2 4

RMInspector.methodfindMatchingRMClass 0 0 0 22 0 7 14

packageorg.openehr.rm.common.changecontrol

Version.methodVersion 1 4 1 7 1 2 8

VersionedObject.methodVersionedObject(A) 0 0 5 1 0 1 10

VersionedObject.methodVersionedObject(B) 0 0 5 1 0 1 7

VersionedObject.methodVersionedObject(C) 0 0 5 1 0 1 12

VersionedObject.methodcommitOriginalVersion 1 1 1 1 0 1 9

VersionedObject.methodcommitOriginalMergedVersion 1 1 1 1 0 1 10

OriginalVersion.methodOriginalVersion 1 1 2 5 0 2 12

100

APÊNDICE D

Métrica DCC customizada

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

package gr.spinellis.ckjm; import java.util.*; import org.apache.bcel.classfile.*; public class DccClass extends EmptyVisitor { public DccClass(IClassMetricsContainer classMap) { mMetricsContainer = classMap; mClasses = new LinkedList(); } public void end() { JavaClass jc; for(Iterator itrClass = mClasses.iterator(); itrClass.hasNext(); countDccInClass(jc)) jc = (JavaClass)itrClass.next(); } protected ClassMetrics getClassMetrics(String className) { return mMetricsContainer.getMetrics(className); } private void countDccInClass(JavaClass currentClass) { Field fields[] = currentClass.getFields(); int Dcc = 0; Field arr$[] = fields; int len$ = arr$.length; label1: for(int i$ = 0; i$ < len$; i$++) { Field f = arr$[i$]; Iterator itr = mClasses.iterator(); do { if(!itr.hasNext()) continue label1; String userClass = ((JavaClass)itr.next()).getClassName(); String fieldClass = Class.className(f.getType()); if(fieldClass.compareTo(userClass) == 0) Dcc++; } while(true); }

Parte 1 de 2

101

42 43 44 45 46 47 48 49 50

getClassMetrics(currentClass.getClassName()).setDcc(Dcc); } public void visitJavaClass(JavaClass jc) { mClasses.add(jc); } protected IClassMetricsContainer mMetricsContainer; private List mClasses; }

Parte 2 de 2

Documents

MODELO DE OBJETOS DO OPENEHR: UMA …DOAJ – Directory of Open AccesS Journals EHR – Electronic Health Record FDP – Foreign Data Providers FOL – First-Order predicate Logic