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.6.2 Questão de pesquisa Q2 ........................................................................................... 63
2.3.6.3 Questão de pesquisa Q3 ........................................................................................... 64
2.3.6.4 Questão de pesquisa Q4 ........................................................................................... 64
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
Facilidade de Compreensão
-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
Fonte: Adaptado de BANSIYA; DAVIS, 2002, p. 11.
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
Fonte: Adaptado de BANSIYA; DAVIS, 2002, p. 10.
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.
Características da estratégia de detecção:
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.
Características da estratégia de detecção:
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.
Características da estratégia de detecção:
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.
Características da estratégia de detecção:
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.
Características da estratégia de detecção:
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
Passo 2 279 publicações
Aplicação dos critérios de exclusão CE1, CE2, CE3 e CE4
na publicação inteira
Passo 3 224 publicações
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
Passo 3 138 publicações
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
2.3.6.2 Questão de pesquisa Q2
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
2.3.6.3 Questão de pesquisa Q3
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.
2.3.6.4 Questão de pesquisa Q4
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
Fonte: Dados da pesquisa.
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
Fonte: Dados da pesquisa.
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
Fonte: Dados da pesquisa.
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
Facilidade de Compreensão
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
Top Related