Métricas de calidad para esquemas conceptuales. Una revisión crítica1

Quality metrics for conceptual schemes. A critical review

Paula Andrea Tamayo Osorio2

Fecha de recepción: 31/07/2012 Fecha de envío a evaluación: 01/08/2012 Fecha respuesta de evaluación: 28/08/2012

1

En el presente artículo se presentan los resultados parciales del proyecto de investigación “Métricas de calidad para esquemas conceptuales de UML 2.2”, financiado por la Institución Universitaria de Envigado.

2

Estudiante de Doctorado en Ingeniería. Magíster en Ingeniería de Sistemas. Ingeniera de Sistemas e Informática. Docente de tiempo completo. Grupo de investigación en sistemas e informática de la Institución Universitaria de Envigado, Envigado, Colombia. Correo electrónico: patamayo@correo. iue.edu.co.

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

Resumen El Proceso Unificado de Desarrollo es la metodología que más se utiliza en el desarrollo de proyectos software de largo plazo, y utiliza el Lenguaje Unificado de Modelado (UML) para la elaboración de los esquemas conceptuales del sistema informático. Para evaluar la calidad de los esquemas conceptuales de UML que especifican los requisitos de los interesados, se utilizan las métricas de calidad. Estas métricas definen las propiedades que deben poseer los esquemas, pero no definen cómo se deben evaluar. Por consiguiente, no existen reglas claras que permitan a los analistas verificar la validez de los diagramas realizados. En este artículo se presenta una revisión crítica de los trabajos concernientes a la formulación de métricas de calidad para los esquemas conceptuales empleados en el desarrollo de software, en especial de los diagramas definidos en la superestructura UML. De esta revisión, se concluye que las principales métricas encontradas evalúan solo algunas de las características de los diagrama de UML, como es la mantenibilidad y la complejidad, dejando de un lado características como correctitud, consistencia y completitud. Por otra parte, las métricas definidas se centran en el principal esquema conceptual de UML: el diagrama de Clases, restándole importancia a los demás diagramas. Palabras claves: Esquemas conceptuales, Lenguaje Unificado de Modelado, métricas de calidad.

Abstract The Rational Unified Process is the most widely used methodology in the development of long-term software projects and uses the Unified Modeling Language (UML) for the development of the conceptual schemes of computer system. To assess the quality of UML conceptual schemas that specify the requirements of stakeholders are used quality metrics. These metrics define the properties that must have the schematics, but do not define how they should be assessed. Consequently, there are no clear rules that allow analysts to verify the validity of the diagrams made. This article presents a critical review of the work concerning the development of quality metrics for conceptual schemes employed in software development, especially the diagrams defined in UML superstructure. In this review, we conclude that the key metrics evaluated only found some of the features of the UML diagram as maintainability and complexity, leaving aside features such as correctness, consistency and completeness. Moreover, the metrics defined focus on the main conceptual framework of UML Class Diagram, downplaying other diagrams. Key words: conceptual diagrams, Unified Modeling Language, quality metrics.

1. Introducción El Proceso Unificado de Desarrollo es la metodología que más se utiliza en el desarrollo de proyectos de software y utiliza el Lenguaje Unificado de Modelado (UML) para la elaboración de los esquemas conceptuales del sistema informático (Jacobson, Booch & Rumbaugh, 2001). UML contiene un conjunto de primitivas o elementos conceptuales que permiten describir, de forma abstracta, todos los aspectos funcionales de una aplicación y especificar los requisitos de los interesados a través de las diferentes fases del desarrollo de software. UML es un lenguaje semiformal y proporciona un

36

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

conjunto de gráficas y técnicas de descripción textual “intuitivas”, que no se definen claramente. Como consecuencia, el uso de estas técnicas y la interpretación de los modelos desarrollados pueden diferir considerablemente entre los analistas (Breu et al., 1997). Para evaluar la calidad de los esquemas conceptuales de UML, existe un conjunto de atributos a tener en cuenta: complejidad, mantenibilidad, acoplamiento, complejidad, consistencia, correctitud, completitud, entre otros (Zowghi & Gervasi, 2002). Una métrica de software es una correspondencia entre uno o más atributos del entorno de desarrollo del software, y cualquier otro atributo, es decir, las métricas, definen las propiedades que deben poseer los esquemas conceptuales, pero no definen cómo se deben evaluar. Por consiguiente, no existen reglas claras que permitan a los analistas verificar la validez de los diagramas realizados (Fenton & Pfleeger, 1997). Algunos autores (Chidamber & Kemerer, 1991; Genero, 2002; Genero, Cruz-Lemus & Piattini, 2002) abordan el tema de aseguramiento de la calidad de los modelos conceptuales de UML, evitando la propagación de errores y el alto coste de su corrección (Marín, Condori-Fernández & Pastor 2007). Esta área de trabajo es de gran importancia en la Ingeniería de Software, puesto que, al dotar a los esquemas conceptuales de UML de métricas que evalúen estos esquemas, se establecerían medios de comunicación acertados entre los analistas y se podrían ejecutar tareas del proceso de desarrollo de software automáticamente. Algunos proyectos en este tópico de investigación se caracterizan por su enfoque en el diagrama principal de UML, el diagrama de Clases, haciendo énfasis en conceptos como el encapsulamiento, la herencia, el polimorfismo y la complejidad de las clases, dejando a un lado los otros 12 diagramas de este lenguaje de modelado y otras de las características que deben cumplir los esquemas conceptuales, como son la consistencia, completitud y correctitud. En este artículo se presenta una revisión crítica de métricas de calidad para los esquemas conceptuales de UML, empleando para ello la siguiente estructura: en la sección 2 se realiza la presentación de los conceptos fundamentales relacionados con UML y métricas de calidad; en la sección 3 se hace un análisis crítico de los trabajos en la formulación de métricas. Los diferentes problemas que aún subsisten en la definición y formalización de las métricas para los esquemas conceptuales de UML, se presentan en la sección 4. Por último, en la sección 5 se presentan las principales conclusiones.

37

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

2. Marco teórico 2.1 UML UML es, ante todo, un lenguaje que proporciona un vocabulario y unas reglas para permitir la comunicación entre los actores del proceso de desarrollo de software (Genero, Cruz-Lemus & Piattini, 2002). UML reúne un conjunto de diagramas o esquemas conceptuales que tienen como objetivos principales: • Visualizar: UML permite expresar, de una forma gráfica, un sistema de forma que otro analista pueda entender. • Especificar: UML permite especificar cuáles son las características de un sistema antes de su construcción. • Construir: A partir de los modelos especificados se pueden construir los sistemas diseñados. • Documentar: Los propios elementos gráficos sirven como documentación del sistema desarrollado y, en un futuro, se pueden utilizar para la revisión del mismo. UML ofrece una amplia variedad de diagramas para visualizar el sistema desde varias perspectivas. En la última especificación de UML se presentan trece diagramas. Su taxonomía se presenta en la Figura 1 (OMG, Object Management Group, 2007). Diagrama

Diagrama de Estructura

Diagrama de Clases

Diagrama de Componentes

Diagrama de Estructura Compuesta

Diagrama de Comportamiento

Diagrama de Objetos

Diagrama de Desplegue

Diagrama de Actividad

Diagrama de Paquetes

Diagrama de Casos de Uso

Diagrama de Máquina de Estado

Diagrama de Interacción

Diagrama de Secuencia

Diagrama Global de Interacción

Diagrama de Comunicación

Diagrama de Tiempos

Figura 1. Taxonomía de los Diagramas de UML 2.2. Tomado de (OMG, 2009)

38

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

2.2 Métricas de calidad Pressman (1998) define las métricas de software como “una medida cuantitativa que permite a la gente del software tener una visión profunda de la eficacia del proceso del software” (p. 53). Las métricas de software proveen la información necesaria para la toma de decisiones técnicas. Las métricas son la maduración de una disciplina, que, según Pressman (1998), van a ayudar a: (1) la evaluación de los modelos de análisis y de diseño, (2) proporcionar una indicación de la complejidad de diseños procedimentales y del código fuente, y (3) el diseño de pruebas más efectivas. Es por eso que propone un proceso de medición, el cual se puede caracterizar por cinco actividades: • Formulación: la obtención de medidas y métricas del software apropiadas para la representación de software en cuestión. • Colección: el mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas. • Análisis: el cálculo de las métricas y la aplicación de herramientas matemáticas. • Interpretación: la evaluación de los resultados de las métricas en un esfuerzo por conseguir una visión interna de la calidad de la representación. • Realimentación: recomendaciones obtenidas de la interpretación de métricas técnicas transmitidas al equipo de software. Las métricas del software son las que están relacionadas con el desarrollo del software, como funcionalidad, complejidad y eficiencia. Estas métricas se pueden clasificar en: • Métricas técnicas: se centran en las características de software, por ejemplo: la complejidad lógica y el grado de modularidad. Mide la estructura del sistema, el cómo está hecho. • Métricas de calidad: proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y explícitos del cliente. Es decir, cómo medir la adaptación del sistema a los requisitos del cliente. • Métricas de productividad: se centran en el rendimiento del proceso de la ingeniería del software. Es decir, qué tan productivo es el software. • Métricas orientadas a la persona: proporcionan medidas e información sobre la forma en que la gente desarrolla el software y, sobre todo, el punto de vista humano de la efectividad de las herramientas y métodos.

39

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

• Métricas orientadas al tamaño: permiten estimar el tiempo para terminar el software y las personas necesarias Son medidas directas al software y el proceso por el cual se desarrolla, si una organización de software mantiene registros sencillos. • Métricas orientadas a la función: son medidas indirectas del software y del proceso por el cual se desarrolla. En lugar de calcular las líneas de código, las métricas orientadas a la función se centran en la funcionalidad o utilidad del programa.

3. Métricas para los esquemas conceptuales de UML Actualmente, existen diversos trabajos que buscan proporcionar a los esquemas conceptuales utilizados en el desarrollo de software, en especial a UML, de un conjunto de métricas que permitan validar sus características, para evitar la propagación de errores y el alto coste de su corrección. Estos trabajos se enuncian a continuación, clasificados según el diagrama que evalúan.

3.1 Diagrama de Clases Li y Henry (1993) definen una serie de métricas que se focalizan en mediciones de primitivas del diseño del software. Las métricas trabajadas por este autor son: número de métodos invocados en una clase, número de atributos en una clase que tienen como tipo otra clase, número de atributos y métodos locales. Este conjunto de métricas son realizadas para el diagrama de Clases y evalúan los atributos de acoplamiento y tamaño. Chidamber y Kemerer (1991, 1994) y Genero (2002) definen un conjunto de métricas para medir la complejidad, el acoplamiento, la cohesión, la herencia y la comunicación interclases del diseño orientado a objetos. Estas métricas permiten predecir si el modelo y su posterior implementación serán fáciles de corregir, mejorar o adaptar a nuevos requisitos. Las métricas definidas por los autores son: método ponderado por clase (WMC), profundidad del árbol de herencia (DIT), número de hijos (NOC), acoplamiento entre los objetos de la clase (CBO), respuesta para una clase (RFC) y falta de cohesión en los métodos (LCOM). Lorenz y Kidd (1994) definen métricas para medir las características estáticas del diseño de software, tales como el tamaño, el uso de herencia y el número de responsabilidades de una clase. Las métricas definidas son: número total de métodos públicos de una clase que están disponibles como servicios para otras clases, número total de métodos de las instancias de una clase, ya sean públicos,

40

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

privados o protegidos, número total de variables (privadas y protegidas) a nivel de instancia que tiene una clase, número total de métodos globales de una clase y número total de variables globales de una clase, ambos visibles por todas las instancias de la clase, número de métodos sobrecargados en una subclase, número de métodos que hereda una clase, número total de métodos que se definen en una subclase, número medio de parámetros por operación, índice de especialización de una clase, número de líneas de código por método y número de mensajes enviados por un método. Por otra parte, Abreu (1993) y Abreu y Melo (1996) definen métricas para medir el uso de los mecanismos de diseño orientado a objetos a nivel de sistema, tales como la encapsulación, la herencia, el polimorfismo y el paso de mensajes. Las métricas son: método de factor oculto, el factor de ocultamiento de un atributo, el factor de métodos heredados, el factor de atributos heredados y el factor de polimorfismo. En la Tabla 1 se puede observar la definición de las métricas definidas por Brito e Abreu y Melo (1996), así como la propiedad que satisface. Tabla 1. Métricas definidas por Brito e Abreu y Melo (1996). Métrica

MHF

AHF

MIF

AIF

PF

Definición Método de factor oculto, se define como el cociente entre la suma de las invisibilidades de todos los métodos definidos en todas las clases y el número total de métodos definidos en el sistema bajo consideración. La invisibilidad de un método es el porcentaje de las clases para las cuales el método no es visible El factor de ocultamiento de un atributo se define como el cociente entre la suma de todos los atributos invisibles definidos en todas las clases y el número total de atributos definidos en el sistema en consideración. La invisibilidad de un atributo es el porcentaje de clases para los que el atributo no es visible El factor de métodos heredados se define como el cociente entre la suma de los métodos heredados en todas las clases y el número total de métodos disponibles para todas las clases El factor de atributos heredados se define como el cociente entre la suma de los atributos heredados en todas las clases del sistema y el número total de atributos disponibles para todas las clases

Propiedad

Tamaño

Tamaño

Herencia

Herencia

El factor de polimorfismo se define como el cociente entre el número real de situaciones polimórficas posibles y el número máximo de situaciones Polimorfismo distintas polimórficos para clase

Bansiya, Etzkorn, Davis y Li (1999) y Bansiya y Davis (2002) definen un conjunto de métricas para evaluar las propiedades de diseño, en especial el encapsulamiento,

41

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

acoplamiento, cohesión, composición y herencia. Algunas de las métricas definidas por estos autores son: número total de clases en el diseño, número de jerarquías de clases, número medio de ancestros, relación entre el número de atributos privados y el total de atributos de una clase, número de clases diferentes con las que una clase está relacionada, entre otras. En la Tabla 2 se presenta el conjunto de métricas definidas por Bansiya y Davis (2002), su definición y la propiedad del sistema que evalúan. Tabla 2. Métricas definidas por Bansiya y Davis (2002). Métrica

Definición

Propiedad

Design size of class (DSC)

Número total de clases en el diseño

Tamaño

Number of Hierarchies (NOH)

Número de jerarquías de clase

Herencia

Average number of ancestors (ANA)

Número medio de ancestros

Abstracción

Data access metric (DAM)

Relación entre el número de atributos privados Encapsulamiento (protegidos) y el número total de atributos de una clase

Direct class coupling (DCC)

Número de clase diferente con las que una clase está Acoplamiento relacionada

Cohesion among methods of class (CAM)

Calcula la relación entre métodos de una clase, Cohesión basándose en la lista de parámetros de los métodos

Measure of aggregation Mide la extensión de la relación parte/todo, mediante Composición (MOA) el uso de atributos Relación del número de métodos heredados por una Measure of functional clase y el número total de métodos accesibles por un Herencia abstraction (MFA) método miembro Number of polymorphic Número de métodos que pueden mostrar Polimorfismo methods (NPM) comportamiento polimórfico Class interface size (CIS) Número de métodos públicos de una clase

Comunicación

Number of methods (NOM)

Complejidad

Número de métodos definidos en una clase

Genero (2002) y Genero, Piattini y Jiménez (2001) definen un conjunto de métricas para medir la complejidad de los diagramas de clases, según los diferentes tipos de relaciones: asociaciones, agregaciones, dependencias y generalizaciones. Las métricas definidas por estos autores son: número total de asociaciones dentro de un modelo de clases, número total de relaciones de agregación dentro de un modelo de clases, número total de relaciones de dependencia dentro de un modelo de clases, número total de relaciones de generalización de un modelo de clases, número de jerarquías

42

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

de generalización en un modelo de clases, número de jerarquías de agregación en un modelo de clases, número de asociaciones por clase, longitud de la ruta más larga desde la clase a las hojas dentro de una jerarquía de agregación, número de partes directas que contiene una clase que pertenece a una jerarquía de agregación, número de partes de una clase, ya sean directas o indirectas, y número de clases que dependen de una clase. Por su parte, Manso, Crespo y Dolado (2002) realizan la extracción de un conjunto de 20 métricas no redundantes, interrelacionadas a través del estudio de 72 diagramas de clases. Estas métricas miden las propiedades de complejidad, reusabilidad, modificabilidad y tamaño. En la Tabla 3 se puede observar el conjunto completo de métricas extraídas por Manso, Crespo y Dolado (2002) y la propiedad evaluada. Tabla 3. Métricas extraídas por Manso, Crespo y Dolado (2002). Métrica

Definición

Propiedad

CBO

Acoplamiento entre objetos

Reusabilidad

DAC

Acoplamiento por abstracción de datos

Acoplamiento

DOI

Profundidad de herencia

Modificabilidad

LOCOM1

Falta de cohesión de los métodos

Reusabilidad

LOCOM2

Falta de cohesión de los métodos

Complejidad

LOCOM3

Falta de cohesión de los métodos

Reusabilidad

MNOP

Número máximo de parámetros entre las operaciones de una clase Reusabilidad

NOA

Número de atributos heredados

Diseño

NOAM

Número de métodos añadidos

Diseño

NOC

Número de clases

Tamaño, complejidad

NOCC

Número de hijos de una clase

Tamaño

NOM

Número de miembros

Diseño

NOO

Número de operaciones

Diseño, tamaño

NOOM

Número de métodos heredados

Diseño, tamaño

NORM

Número de métodos remotos

Diseño, tamaño

PPKGM

Porcentaje de miembros del paquete

Tamaño

PPRIVM

Porcentaje de miembros privados

Diseño, tamaño

PPROTM

Porcentaje de miembros protegidos

Diseño, tamaño

PPUBM

Porcentaje de miembros públicos

Diseño

RFC

Respuesta de una clase

Complejidad

WNPC2

Número de métodos y parámetros de los mismos

Complejidad

Por último, Reynoso, Genero y Piattini (2004) proponen un conjunto de métricas para las expresiones OCL (Object Constraint Language – Lenguaje de Especificación de

43

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

Objetos), teniendo en cuenta los conceptos relacionados con las técnicas cognitivas de fragmentación y localización. En la Tabla 4 se puede visualizar el conjunto de métricas definidas por Reynoso, Genero y Piattini (2004), así como la propiedad del sistema que evalúan. Las expresiones OCL son utilizadas para definir restricciones sobre los diagramas UML, en especial el diagrama de Clases, por lo que estas métricas solo se aplican sobre dicho diagrama. Estas métricas son validadas mediante un experimento controlado presentado por Reynoso, Genero y Piattini (2004a). Tabla 4. Métricas propuestas por Reynoso, Genero y Piattini (2004). Métrica

Definición

Propiedad

NKS

Número de palabras claves OCL

Complejidad

NES

Número de Self explícitos

Complejidad

NIS

Número de Self implícitos

Complejidad

NVL

Número de variables definidas por expresiones Let

Complejidad

NIE

Número de expresiones IF

Complejidad

NSL, NOSL, NBL, NSQL, NTL NBO

Número de literales de conjunto, conjuntos ordenados, bags, Complejidad secuencia o tuplas Número de operadores booleanos

Complejidad

NCO

Número de operadores de comparación

Complejidad

NEI, NII

Número de variables explícitas e implícitas

Complejidad

NAS

Número de atributos que representa el clasificador Self

Complejidad

NOS

Número de operaciones que representa el clasificador Self

Complejidad

NVD NIO

Número de variables definidas a través de la definición de las Complejidad restricciones Número de operaciones oclIsTypeOf, oclIs KindOf o oclAsType Complejidad

N@P

Número de propiedades fijadas por @Pre

Complejidad

NNR

Número de relaciones de navegación

Complejidad

NAN

Número de atributos referenciados a través de navegaciones

Complejidad

WNON NNC

Número ponderado de operaciones referidas a través de Complejidad navegaciones Número de clases navegables Complejidad

WNM

Número ponderado de mensajes

NPT NUDTA

Número de parámetros cuyo tipo son clases definidos en el diagrama Complejidad de Clases Número de tipo de atributos definidos por el usuario Complejidad

NUDTO

Número de tipo de operaciones definidos por el usuario

Complejidad

WNN

Número ponderado de navegaciones

Complejidad

DN

Profundidad de las navegaciones

Complejidad

WNCO

Número ponderado de la colección de operaciones

Complejidad

Complejidad

44

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

3.2 Diagrama de casos de uso Marchesi (1998, 2003) propone un conjunto de cuatro métricas para el diagrama de casos de uso: número de casos de uso, número de comunicaciones entre actores y casos de uso, número total de comunicaciones entre los casos de uso y actores (sin las redundancias introducidas por ampliar y utilizar las relaciones uses y extend), y estimación de la complejidad total del sistema. Un conjunto de indicadores para el diagrama de casos de uso, en especial para el atributo de modificabilidad, mediante el número de relaciones extend y uses es propuesto por Saeki (2003). Las métricas definidas son: número de dependencias y el número de tipos de casos de uso. Por último, Debnath et al. (2005) establecen una serie de pasos para definir, de manera uniforme, las métricas, usando la especificación estándar de OMG. Los pasos definidos son: (i) describir la métrica (ii) identificar el modelo (iii) identificar el metamodelo (vi) identificar las metaclases utilizadas en el modelo (v) definir la especificación de la métrica formalmente con OCL Por otra parte, definen un conjunto de métricas orientadas a clases (acoplamiento entre objetos, tamaño de la clase, número de hijos, número de operaciones), orientadas a operaciones y orientadas a proyectos (número de scripts de escenarios, número de casos de uso).

3.3 Diagrama de estados La complejidad estructural y el tamaño de un diagrama de estado se determinan por los diferentes elementos que lo componen, tales como estados, transiciones, actividades, etc. Por lo tanto, para capturar todos los aspectos de complejidad y tamaño no se puede definir una única métrica (Fenton, 1994). Cruz-Lemus, Genero y Piattini (2005) definen un conjunto de métricas que están enfocadas a medir los aspectos dinámicos de los modelos, teniendo en cuenta algunos de los elementos del diagrama de estados. Las métricas definidas por estos autores y la propiedad que evalúan, se encuentran en la Tabla 5.

45

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

Tabla 5. Métricas definidas por Cruz-Lemus, Genero y Piattini (2005). Métrica

Definición

Propiedad

NEntryA

El número total de acciones de entrada, es decir, el número total de Tamaño acciones que se realizan una vez se entra en un estado

NExitA

El número total de acciones de salida, es decir, el número total de acciones Tamaño que se realiza cuando se sale de un estado

NA

Número total de actividades en el diagrama de estados

NSS

Número total de estados simples, considerando los estados simples que Tamaño están incluidos en los estados compuestos

NCS

Número de estados compuestos

Tamaño

NE

Número de eventos

Tamaño

NG

Número total de condiciones de guarda

Tamaño

McCabe

Número ciclomático de McCabe. Es definido como |NSS – NT + 2|

Complejidad

NT

El número total de transiciones, incluyendo transacciones comunes, las Complejidad transacciones iniciales y finales, y transiciones internas.

Tamaño

Genero, Miranda y Piattini (2002) definen un conjunto de métricas para el diagrama de estados, teniendo en cuenta la complejidad de dicho diagrama en términos de los elementos que lo componen: estados, transiciones, actividades, entre otros. Las métricas definidas son: el número total de acciones de entrada, de acciones de salida, de actividades, de estados simples, de transiciones. Por otra parte, Miranda, Genero y Piattini (2003) realizan la validación de dichas métricas mediante una serie de experimentos, permitiendo concluir que las métricas Número total de actividades, Número total de estados simples y Número total de transacciones están altamente correlacionadas con la comprensibilidad de los diagramas de estados de UML.

3.4 Otros modelos conceptuales Calero, Piattini, Polo y Ruiz (2000) presentan diferentes métricas para medir la complejidad de esquemas de bases de datos relacionales: número de atributos (NA), grado de referenciabilidad (RD), profundidad del árbol referencial (DRT) y ratio de normalidad (NR), describiéndolas formalmente siguiendo la teoría de la medida. Por otra parte, Calero y Piattini (1999) analizan a fondo las características formales de la métrica RD, demostrando que no asume una estructura extensiva ni cumple las condiciones de independencia, pero que sí cumple la estructura de creencia. Las características que un esquema conceptual de bases de datos debe tener para ser considerado de calidad, son presentadas por Varas y Pradenas (2000). Los autores definen métricas para evaluar la autoexplicación, correctitud semántica, compleción

46

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

y expresividad, teniendo en cuenta las siguientes variables: legibilidad, compleción, corrección, minimalidad, expresividad, autoexplicación, extensibilidad y consistencia. Cada una de estas variables es medida de forma independiente, para luego obtener una evaluación global de todas ellas. Piattini, Calero y Genero (2001) proponen un conjunto de métricas de calidad para el modelo entidad relación, que permita a los diseñadores evaluar de manera sistemática la calidad de los esquemas conceptuales a lo largo del proceso de modelado. Las métricas propuestas por los autores son: compleción, corrección, minimalidad, expresividad, legibilidad y auto explicación, extensibilidad y normalidad, cohesión del esquema, complejidad del esquema, complejidad intra-entidad, longitud interrelacional y tamaño. Por su parte, San Juan (2002) realiza una crítica a las métricas de calidad de los esquemas conceptuales de bases de datos, y propone una nueva técnica de medición a partir de la comunicación, que se realiza entre los diferentes actores que intervienen en el desarrollo de software: usuario, analista, desarrollador y programador. Canfora García, Piattini, Ruiz y Vissagio (2004) y García, Ruiz y Piattini (2004a) presentan un conjunto representativo de métricas para los modelos de procesos de software, con el fin de evaluar la influencia de la complejidad en los modelos de procesos de software en su calidad. Estas medidas se centran en los principales elementos incluidos en un modelo de procesos de software (Véase Tabla 6), y puede proporcionar la base cuantitativa necesaria para evaluar los cambios en los procesos de software en las empresas con altos niveles de madurez. La validación de estas métricas es realizada por García, Ruiz y Piattini (2004b), mediante la realización de una réplica de un experimento descrito por García, Ruiz y Piattini (2004a); y García, Ruiz y Visaggio (2006) realizan una familia de experimentos de los que se obtuvieron conclusiones significativas. Como resultado de estos estudios, se puede concluir que las métricas de NA (Número de actividades del modelo de proceso de software), NWP (Número de productos de trabajo), NDWPIn (Número de dependencias de entrada de los productos de trabajo de las actividades en el proceso), NDWPOut (Número de dependencias de salida de los productos de trabajo de las actividades en el proceso), NDWP (Número de dependencias entre los productos de trabajo y las actividades en el proceso) y NDA (Número de dependencias de precedencia entre actividades) son buenos indicadores de mantenimiento.

47

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

Tabla 6. Métricas definidas por Canfora García, Piattini, Ruiz y Vissagio (2004) y García, Ruiz y Piattini (2004a) Métrica

Definición

Propiedad

NA

Número de actividades del modelo de proceso de software

Modificabilidad

NWP

Número de productos de trabajo del modelo de proceso de software Modificabilidad

NPR

Número de roles que participan en el proceso

NDWPIn

Número de dependencias de entrada de los productos de trabajo de Modificabilidad las actividades en el proceso

NDWPOut

Número de dependencias de salida de los productos de trabajo de las Modificabilidad actividades en el proceso

NDWP

Número de dependencias entre los productos de trabajo y las Modificabilidad actividades en el proceso

NDA

Número de dependencias de precedencia entre actividades

Modificabilidad

NCA

Acoplamiento de las actividades en el modelo de procesos

Modificabilidad

RDWPIn

Proporción entre dependencias de entrada de productos de trabajo, y Modificabilidad el número total de dependencias de productos de trabajo

RDWPOut

Proporción entre dependencias de salida de productos de trabajo, y el Modificabilidad número total de dependencias de productos de trabajo

RWPA

Proporción de productos de trabajo y actividades

Modificabilidad

RRPA

Proporción de roles de proceso y actividades

Modificabilidad

Modificabilidad

Un conjunto de métricas para la evaluación de modelos conceptuales de procesos de negocio es propuesto por Rolón, Ruiz, García y Piattini (2005). Estas métricas están basadas en el modelo de evaluación de procesos de software, debido a las similitudes existentes entre ambos procesos. Las métricas definidas tienen en cuenta los siguientes elementos: eventos de inicio, eventos intermedios, eventos finales, tareas y subprocesos colapsados. En la Tabla 7 se presenta el compendio de métricas definidas por Rolón, Ruiz, García y Piattini (2005). Tabla 7. Métricas extraídas por García, Ruiz y Visaggio (2006). Métrica

Definición

Propiedad

NSNE

Número total de eventos de inicio simple en el modelo

Complejidad

NSTE

Número total de eventos de inicio de tiempo en el modelo

Complejidad

NSMsE

Número total de eventos de inicio de mensaje en el modelo

Complejidad

NSRE

Número total de eventos de inicio de regla en el modelo

Complejidad

NSLE

El número total de eventos de inicio de vínculo en el modelo

Complejidad

NSMuE

Número total de eventos de inicio múltiple en el modelo

Complejidad

48

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

Métrica

Definición

Propiedad

NINE

Número total de eventos intermedios simples en el modelo

Complejidad

NITE

Número total de eventos intermedios de tiempo en el modelo

Complejidad

NIMsE

Número total de eventos intermedios de mensaje en el modelo

Complejidad

NIEE

Número total de eventos intermedios de error en el modelo

Complejidad

NICaE

Número total de eventos intermedios de cancelaciones en el modelo

Complejidad

NICoE

Número total de eventos intermedios de compensación en el modelo Complejidad

NIRE

Número total de eventos intermedios de regla en el modelo

Complejidad

NILE

Número total de eventos intermedios de vínculo en el modelo

Complejidad

NIMuE

Número total de eventos intermedios múltiples en el modelo

Complejidad

NENE

Número total de eventos finales simples en el modelo

Complejidad

NEMsE

Número total de eventos finales de mensaje en el modelo

Complejidad

NEEE

Número total de eventos finales de error en el modelo

Complejidad

NECaE

Número total de eventos finales de cancelación en el modelo

Complejidad

NECoE

Número total de eventos finales de compensación en el modelo

Complejidad

NELE

Número total de eventos finales de vínculo en el modelo

Complejidad

NEMuE Número total de eventos finales múltiples en el modelo

Complejidad

NETE

Complejidad

Número total de eventos finales de terminación en el modelo

Berenguer, Romero, Trujillo, Serrano y Piattini (2005) presentan un marco para diseñar métricas como parte de un indicador de calidad. Este método permite definir las métricas para modelos, diagramas y paquetes. Por otra parte, Serrano, Trujillo, Calero y Piattini (2007) definen un conjunto de métricas para medir la comprensibilidad de los modelos conceptuales de los almacenes de datos. Además, se presenta una validación teórica mediante una familia de experimentos (Serrano, Calero, Trujillo, Lujan y Piattini, 2004). Entre las métricas definidas se tiene: Número de dimensiones, de clases bases, total de clases, relación de las clases bases, número de atributos de la clase de hechos, número de relaciones de herencia, entre otras. Baroni, Calero, Brito e Abreu y Piattini (2006) y Baroni, Calero, Ruiz y Brito e Abreu (2004) realizan la definición y formalización de métricas para bases de datos objeto relacionales. Entre las métricas definidas se tienen: el tamaño de la tabla, el tamaño de las columnas complejas, el tamaño de la clase, el número de clases involucradas, el número de clases compartidas, el porcentaje de columnas complejas, el número de claves foráneas. Genero, Poels y Piattini (2008) definen un conjunto de métricas para el modelo Entidad - Relación. Además, realizan una metodología para validar teóricamente los

49

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

indicadores propuestos. Las métricas definidas para el modelo Entidad - Relación son: el número de entidades, el número de atributos, el número de atributos derivados, el número de atributos compuestos, el número de atributos multivaluados, el número de relaciones, el número de relaciones n-anarias y el número de relaciones reflexivas. Tort y Olivé (2009) definen cinco tipos de prueba que se pueden aplicar sobre esquemas conceptuales, independientemente del modelo conceptual empleado: actualización de la información base, la inconsistencia de la información base, la ocurrencia de un evento del dominio, la no ocurrencia de un evento del dominio y el contenido del estado de la información base. Además, los autores presentan un lenguaje para escribir pruebas automatizadas de esquemas ejecutables escritos en UML / OCL. Por otra parte, Tort, Olivé y Sancho (2011) desarrollan una herramienta que permite realizar las pruebas sobre los esquemas conceptuales. Bisgaard y Aalast (2009) definen tres métricas de complejidad para redes de flujo de trabajo. La primera métrica es una extensión de la métrica definida por Cardoso (2005), y se basa en la presencia de divisiones y uniones del proceso sintáctico. La segunda métrica es una extensión de la métrica ciclomática definida por McCabe (1976). La tercera métrica definida por los autores analiza iterativamente la estructura del modelo. Por último, Al-Ghamdi, Elish y Ahmed (2002) describen tres herramientas para la recopilación, análisis y evaluación de métricas orientadas a objetos. Las herramientas son: • Brooks y Buell: un analizador de métricas • Un motor de consulta para el análisis de C++ • Una jerarquía de modelos de clases para recopilar las métricas orientadas a objetos Además, construyeron su propia herramienta que recoge y mide la herencia de acoplamiento en los sistemas orientados a objetos.

4. Problemas en la formalización de UML A pesar de que se ha encontrado un conjunto amplio y representativo de propuestas que definen modelos de calidad y métricas, para que sean aplicados en modelos conceptuales, estos se enfocan en el paradigma orientado a objetos, es decir, su principal línea de acción es el diagrama de Clases, dejando de lado los demás

50

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

modelos conceptuales que hacen parte de la taxonomía de UML, como el Diagrama de Secuencias, el Diagrama de Máquina de Estados y el Diagrama de Actividades, utilizados en las diversas metodologías de desarrollo de software. Por otra parte, aunque existe un conjunto importante de atributos de calidad para medir las diferentes características de los esquemas conceptuales, las propuestas analizadas se enfocan en las propiedades de complejidad y mantenibilidad, dejando de lado la completitud, correctitud y consistencia. En algunos casos las métricas definidas están enfocadas a solo uno de estos atributos. En la Tabla 8 se realiza un compendio de los esquemas conceptuales que trabaja cada uno de los investigadores, mientras que en la Tabla 9 se realiza un compendio de los atributos de calidad que miden las métricas propuestas en la investigación.

Li y Henry (1993)

X

Chidamber y Kemerer (1994)

X

Genero (2002)

X

Lorenz y Kidd (1994)

X

Brito e Abreu y Melo (1996), Brito (1998)

X

Marchesi (1998, 2003)

X

Bansiya et al. (1999), Bansiya y Davis (2002)

X

Genero et al. (2001, 2002a)

X

Manso et al. (2002)

X

Reynoso et al. (2004a, 2004b)

X

Saeki (2003) Debnath et al. (2005)

X

X X

X

Cruz Lemus et al. (2005)

X

Genero et al. (2002b)

X

Calero et al. (2000)

X

Varas y Praderas (2000)

X

51

Redes de Petri

BD objeto relacional

Data Warehouse

Modelo de procesos

Esquema relacional

D. de Estados

Autor

D. Casos de uso

Esquema conceptual

D. de Clases

Tabla 8. Compendio de los trabajos en la definición de métricas para esquemas conceptuales. Elaboración propia con base en la literatura revisada.

Piattini et al. (2001)

X

San Juan (2002)

X

Canfora et al. (2004) y García et al. (2004a)

X

Rolón et al. (2005)

X

Serrano et al. (2007)

X

Redes de Petri

BD objeto relacional

Data Warehouse

Modelo de procesos

Esquema relacional

D. de Estados

Autor

D. de Clases

Esquema conceptual

D. Casos de uso

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

X

Baroni et al. (2006)

X

Genero et al. (2008)

X

Tort y Olivé (2009)

X

Bisgaard y Aalast (2009)

X X

X X

X X X X

X

X X

X

X

X X

X

X

X X X X

52

X

Comprensibilidad

Completitud

Correctitud

Encapsulamiento

X X X X

Tamaño

X X

Modificabilidad

X X X

Reusabilidad

Herencia

X X

Cohesión

Li y Henry (1993) Chidamber y Kemerer (1994) Genero (2002) Lorenz y Kidd (1994) Brito e Abreu y Melo (1996) Marchesi (1998) Bansiya et al. (1999), Bansiya y Davis (2002) Genero et al. (2001, 2002a) Manso et al. (2002) Reynoso et al. (2004a y 2004b) Marchensi (2003) Saeki (2003) Debnath et al. (2005) Cruz Lemus et al. (2005) Genero et al. (2002b)

Acoplamiento

Autor

Composición

Atributo de calidad

Complejidad

Tabla 13. Compendio de los trabajos en la definición de métricas por atributo de calidad. Elaboración propia con base en la literatura revisada.

X X

X X

Comprensibilidad

Completitud

Encapsulamiento

Tamaño

Modificabilidad

Reusabilidad

Herencia

Cohesión

Correctitud

Calero et al. (2000) Varas y Praderas (2000) Piattini et al. (2001) Canfora et al. (2004) y García et al. (2004a) Rolón et al. (2005) Serrano et al. (2007) Baroni et al. (2006) Genero et al. (2008) Tort y Olivé (2009) Bisgaard and Aalast (2009)

Acoplamiento

Autor

Composición

Atributo de calidad

Complejidad

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

X X

X X

X X X X X X

De lo anterior se puede concluir que la mayoría de los esquemas conceptuales de UML no cuentan con métricas que permitan medir sus características, en especial, la completitud y correctitud de un diagrama y la consistencia entre estos. De la Figura 2 se puede concluir que el 26.6% de los esquemas utilizados en la definición de métricas pertenece a UML, lo que representa que tan solo el 23% de los diagramas del lenguaje de modelado tiene alguna métrica que permita evaluar alguna de sus propiedades. Por otra parte, los dos esquemas conceptuales que tienen mayor número de investigaciones asociadas, referente a la definición de métricas de calidad, son el diagrama de Clases y el esquema relacional. Nro de investigadores que trabajan cada esquema conceptual D. de Clases D. Casos de Uso D. de Estados Esquema relacional Mod. de procesos Data Warehouse BD objeto - relacional Redes de Petri

Figura 2. Número de investigadores que definen métricas para los esquemas conceptuales.

53

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

En la Figura 3 se muestran los criterios de calidad que son tenidos en cuenta para la definición de métricas en los diversos esquemas conceptuales.

Figura 3. Criterios de calidad empleados en la definición de métricas para esquemas conceptuales.

De los diagramas que hacen parte de la taxonomía de UML, el diagrama de Clases es el esquema conceptual que cuenta con una mayor cantidad de métricas definidas por varios investigadores (Li y Henry, 1993; Chidamber y Kemerer, 1994; Genero, 2002; Lorenz y Kidd, 1994; Brito e Abreu y Melo, 1996; Abreu, 1998; Marchesi, 1998, 2003; Serrano, Trujillo, Calero y Piattini, 2007). Por otra parte, las métricas que se han definido para este diagrama tienen en cuenta los criterios de complejidad y acoplamiento. En segundo lugar, se encuentra el diagrama de casos de uso, para el que se definen métricas que evalúan los criterios de modificabilidad y tamaño.

Conclusiones y trabajo futuro En el proceso de desarrollo de software cobran fuerza los intentos por definir y formalizar métricas para los diferentes esquemas conceptuales, que buscan evitar la propagación de errores y el alto coste de su corrección. Además, se establecen medios de comunicación acertados entre los analistas que facilitan ejecutar tareas del proceso de desarrollo de software automáticamente.

54

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

En este artículo se evaluó la problemática de la definición de métricas de calidad para los esquemas conceptuales utilizados en el desarrollo de software, en especial los diagramas de UML. Esta evaluación permite identificar tres problemas: • Las métricas de calidad definidas para los diagramas UML se centran en el diagrama de Clases. Para dicho diagrama, se mide la complejidad teniendo en cuenta la cantidad de clases, operaciones y relaciones que se presentan entre las clases. • La definición de las métricas se centran en el diagrama como tal, sin tener en cuenta el dominio del problema y los requisitos de los interesados. Estos dos aspectos son de vital importancia al momento de medir características, como completitud y consistencia. • Algunos de los diagramas que componen la taxonomía de UML no cuentan con métricas de calidad que permitan a los analistas, desarrolladores y/o programadores evaluar los modelos realizados. Por lo tanto, la evaluación de estos es realizada de manera subjetiva por las personas que intervienen en el desarrollo del software. Tomando como base la evaluación realizada, se pueden sugerir varios aspectos susceptibles de iniciar trabajos de investigación, tales como: • Establecer métricas de calidad para diagramas de UML, adicionales a las que están definidas para el diagrama de Clases y Diagrama de casos de uso. • Definir un conjunto de reglas para evaluar otros atributos de calidad sobre los esquemas conceptuales de UML, como son la completitud y la consistencia. • Integrar las métricas de los esquemas conceptuales a las herramientas CASE, que permiten automatizar el proceso, previniendo la ocurrencia de errores humanos. • Integrar las métricas de los esquemas conceptuales en el desarrollo de software a nivel empresarial y académico.

Referencias Abreu, F. B. (1993). Metrics for object oriented software development. In 3rd International Conference on Software Quality, Octuber, Lake Tahoe, Nevada, EUA. Al-Ghamdi, J., Elish, M. & Ahmed, M. (2002). A tool for measuring inheritance coupling in object-oriented systems, Information Sciences-Informatics and Computer Science. An International Journal, 140(3), 217-227.

55

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

Bansiya, J., Etzkorn, L., David, C. & Li, W. (1999). A Class Cohesion Metric For ObjectOriented Designs. The Journal of Object-Oriented Programming, 11(8), 47-52. Bansiya, J. & Davis, C. (2002). A Hierarchical Model for Object-Oriented Design Quality Assessment. IEEE Transactions on Software Engineering, 28(1), 4-17. Baroni, A., Calero, C., Brito e Abreu, F., Piattini, M. (2006). Object-Relational Database Metrics Formalization. QSIC 2006: Sixth International Conference on Quality Software. October 26-28, Beijing, China. Baroni, A. L., Calero, C., Ruiz, F., & e Abreu, F. B. (2004). Formalizing objectrelational structural metrics. In Conf. of APSI, November 10-12, Lisbon, Portugal . Berenguer, G., Romero, R., Trujillo, J., Serrano, M., Piattini, M. (2005). A Set of Quality Indicators and Their Corresponding Metrics for Conceptual Models of Data Warehouses. In Lecture Notes in Computer Science 3589 (DaWaK 2005) (95-104). Berlin: Springer. Bisgaard, K. & Aalast, W. (2009). Complexity metrics for Workflow nets. Information and Software Technology, 51(Issue 3), 610 - 626. Breu, R., Hinkel, U., Hofmann, C., Klein, C., Paech, B., Rumpe, B., & Thurner, V. (1997). Towards a formalization of the unified modeling language (pp. 344-366). Springer Berlin Heidelberg. Brito e Abreu, F. & Melo, W. (1996). Evaluating the Impact of Object-Oriented Design on Software Quality. 3rd International Metric Symposium. March 25-26, Berlin, Germany. Calero, C., Piattini, M., Polo, M. Y Ruiz, F. (2000). Métricas para la evaluación de la complejidad de bases de datos relacionales. Computación y sistemas, 3(4), 264-273. Calero, C. & Piattini, M. (1999). Caracterización formal de métricas para bases de datos relacionales. IV Jornadas de Ingeniería de Software y Bases de Datos. (JISBD99). Noviembre 24-26, Cáceres, España. Canfora, G., García F., Piattini, M., Ruiz F. & Visaggio C. (2004). A family of experiments to validate metrics for software process models. Journal of Systems and Software archive, 77(Issue 2), 113-129. Cardoso, J. (2005). Control-flow complexity measurement of processes and Weyuker’s properties. In Transactions on Enformatika, Systems Sciences and Engineering, sixth ed., vol. 8, (213-218). Berlin, Budapest, Hungary: Springer-Verlag.

56

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

Cruz-Lemus, J., Genero, M. & Piattini, M. (2005). Metrics for Software Conceptual Models. Capítulo 7: Metrics for UML Statechart Diagrams. London: Imperial College Press. Chidamber, S. R., & Kemerer, C. F. (1991). Towards a metrics suite for object oriented design (Vol. 26, No. 11, pp. 197-211). ACM. Chidamber, S. & Kemerer, C. (1994). A Metrics Suite for Object Oriented Design. IEEE Transactions on Software Engineering, 20(6), 476-493. Debnath, N., Riesco, D., Montejano, G., Uzal, R., Baigorria, L., Dasso, A. & Funes, A. (2005). A technique based on the OMG metamodel and OCL for the definition of objectoriented metrics applied to UML models. Proceedings of the ACS/IEEE 2005 International Conference on Computer Systems and Applications. January 3-6, Cairo, Egypt. Fenton, N. (1994). Software Measurement: A Necessary Scientific Basis. IEEE Transactions on Software Engineering, 20(3), 199 - 206. Fenton, N. & Pfleeger, S. (1997). Software Metrics: A Rigorous and Practical Approach. Second Edition. London: International Thomson Computer Press. García, F., Ruiz, F. & Piattini, M. (2004a). Definition and Empirical Validation of Metrics PROFES 2004. In 5th International Conference on Product Focused Software Process Improvement (LNCS 2004), (146-158). Berlin: Springer-Verlag. ________. (2004b). An Experimental Replica to Validate a set of Metrics for Software Process Models. In Dingsøyr, T. (Ed.), Lecture Notes in Computer Science 3281, (7990). Berlin: Springer - Heidelberg. García, F., Ruiz, F. &Visaggio, C. (2006). A Proposal and Empirical Validation of Metrics to Evaluate the Maintainability of Software Process. 23rd IEEE Instrumentation and Measurement Technology Conference. April 24-27, Sorrento, Italy. Genero, M., Piattini, M., & Jiménez, L. (2001). Empirical validation of class diagram complexity metrics. In Computer Science Society, Proceedings. XXI Internatinal Conference of the Chilean, November 9, Santiago, Chile. Genero, M. (2002). Defining and Validating Metrics for Conceptual Models. (Tesis doctoral). Universidad de Castilla-La Mancha, Madrid, España. Genero, M., Cruz-Lemus, J. & Piattini, M. (2002). Construcción de un modelo de predicción para el entendimiento de los diagramas de estados en UML. Ciudad Real, España: Universidad de Castilla- La Mancha.

57

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

Genero, M., Miranda, D. & Piattini, M. (2002). Defining and validating metrics for UML Statechart Diagrams. 6th International ECOOP Workshop on quantitative approaches in Object-oriented software Engineering. June 10-14, Málaga, Spain. Genero, M., Poels, G. & Piattini, M. (2008). Defining and validating metrics for assesing the understandabiity of entity-relationship diagrams. Data & knowedge Engineering, 64(3), 534-557. Jacobson, I., Booch, G. & Rumbaugh J. (2001). El Proceso Unificado de Desarrollo de Software. Massachusetts: Addison Wesley. Li, W. & Henry, S. (1993). Maintenance Metrics for the Object Oriented Paradigm. 1st International Software Metrics Symposium. May 21-22, Baltimore, Maryland, EEUU. Lorenz, M. & Kidd, J. (1994). Object-Oriented Software Metrics: A Practical Guide. New Jersey: Prentice Hall, Englewood Cliffs. McCabe, T. (1976). A complexity measure. IEEE Transactions on Software Engineering, 2(Issue 4), 308-320. Manso, E., Crespo, Y. & Dolado, J. (2002). Caracterización de productos de software con métricas no redundantes. VII Jornadas de Ingeniería del Software y Bases de Datos (JISBD 2002). Noviembre 19-21, El Escorial, Madrid, España. Marchesi, M. (1998). OOA Metrics for the Unified Modeling Language. 2nd Euromicro Conference on Software Maintenance and Reengineering. March 8-11, Florence, Italy. __________. (2003). OOA Metrics for the unified modeling language. 2nd Euromicro Conference on Software Maintenance and Reengineering. March 8-11, Florence, Italy Marín, B., Condori-Fernández, N. & Pastor, O. (2007). Calidad en modelos conceptuales: un análisis multidimensional de modelos cuantitativos basados en la ISO 9126. RPM-AEMES, 4 (Nº Especial), 153-167. Miranda, D., Genero, M. & Piattini, M. (2003). Empirical validation of metrics for UML statechart diagrams. In: Proceedings of the 5th International Conference on Enterprise Information Systems (ICEIS 03), vol. 1. (87 – 95). Estados Unidos. Kluwer Academic Publishers. OMG (Object Management Group). (2007). Unified Modeling Language (OMG UML) Superstructure, V2.1.2, OMG Available Specification without Change Bars (formal/2007-11-02). Recuperado de: http://www.omg.org.

58

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

OMG (Object Management Group). (2009). OMG Unified Modeling Language (OMG UML), Superstructure, Version 2.2. Recuperado de: http://www.omg.org. Piattini, M., Calero, C. & Genero, M. (2001). Table oriented metrics for relational databases. Software Quality Journal. Kluwer Academic Publishers, 9(2), 79-97. Pressman, R. (1998). Ingeniería del software. Un enfoque práctico. 4ª Edición. Madrid: McGrawHill. Reynoso, L., Genero, M. & Piattini, M. (2004). Towards a metric suite for OCL Expressions expressed within UML/OCL models. Journal of Comptuer Science and Technology, 4(1), 38-44. _________. (2004a). A Controlled Experiment for Validating Metrics for OCL Expressions. International Symposium on Empirical Software Engineering, Redondo Beach, EEUU. Rolón, E., Ruiz, F., García, F. & Piattini, M. (2005). Aplicación de métricas software en la evaluación de modelos de procesos de negocio. Revista Sociedad Chilena de Ciencia de la Computación, Vol 6. Saeki, M. (2003). Embedding metrics into information system development methods: an application of method engineering technique. 15th International Conference on Advanced Information Systems Engineering. Lectures Notes in Computer Science, vol 2681. June 16-18, Klagenfurt, Austria. San Juan, V. (2002). Análisis de métricas de calidad para esquemas conceptuales de bases de datos. Revista Ingeniería Informática, Vol 8. Serrano, M., Trujillo, J., Calero, C. & Piattini, M. (2007). Metrics for data warehouse conceptual models understandability. Information and Software Technology, 49(8), 851-870. Serrano, M., Calero, C., Trujillo, J., Lujan, S., Piattini, M. (2004). Empirical Validation of Metrics for Conceptual Models of Data Warehouses. In Person, A. & Stirna, J. (Eds.), Lecture Notes in Computer Science 3084 (CAiSE 2004), (506-520). Berlin: Springer. Tort, A. & Olivé, A. (2009). An approach to testing conceptual schemas. Data & Knowledge Engineering, 69(Issue 6), 598–618. Tort, A., Olivé, A. & Sancho, M. (2011). The CSTL Processor: A Tool for Automated Conceptual Schema Testing. ER Workshops. Presented in Conference: Advances in Conceptual Modeling. Recent Developments and New Directions - ER 2011

59

P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016

Workshops FP-UML, MoRE-BI, Onto-CoM, SeCoGIS, Variability@ER, WISM. October 31 - november 3, Brussels, Belgium. Varas, M. & Pradenas, J. (2000). Hacia la definición de métricas de calidad para esquemas conceptuales de bases de datos. Revista Electrónica del DIICC, Año 3(6), Zowghi, D., Gervasi, V. (2002). The Three Cs of Requirements: Consistency, Completeness, and Correctness. Proceedings: 8th International Workshop on Requirements Engineering: Foundations for Software Quality. September 9-10, Essen, Germany.

60