Métricas de calidad para esquemas conceptuales.
Una revisión crítica1
Quality metrics for conceptual
schemes. A critical review
Paula Andrea Tamayo Osorio2
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: [email protected].
Fecha de recepción: 31/07/2012Fecha de envío a evaluación: 01/08/2012
Fecha respuesta de evaluación: 28/08/2012
36
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
37
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.
38
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 deEstructura
Diagrama deClases
Diagrama deDesplegue
Diagrama dePaquetes
Diagrama deInteracción
Diagrama Globalde Interacción
Diagrama deSecuencia
Diagrama deComunicación
Diagrama deTiempos
Diagrama deEstructuraCompuesta
Diagrama deComponentes
Diagrama deObjetos
Diagrama deActividad
Diagrama deCasos de Uso
Diagrama deMáquina de Estado
Diagrama deComportamiento
Figura 1. Taxonomía de los Diagramas de UML 2.2. Tomado de (OMG, 2009)
39
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.
40
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,
41
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 Definición Propiedad
MHF
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
Tamaño
AHF
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
Tamaño
MIFEl 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
Herencia
AIFEl 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
Herencia
PFEl 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 distintas polimórficos para clase
Polimorfismo
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,
42
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 (protegidos) y el número total de atributos de una clase
Encapsulamiento
Direct class coupling (DCC)
Número de clase diferente con las que una clase está relacionada
Acoplamiento
Cohesion among methods of class (CAM)
Calcula la relación entre métodos de una clase, basándose en la lista de parámetros de los métodos
Cohesión
Measure of aggregation (MOA)
Mide la extensión de la relación parte/todo, mediante el uso de atributos
Composición
Measure of functional abstraction (MFA)
Relación del número de métodos heredados por una clase y el número total de métodos accesibles por un método miembro
Herencia
Number of polymorphic methods (NPM)
Número de métodos que pueden mostrar comportamiento polimórfico
Polimorfismo
Class interface size (CIS) Número de métodos públicos de una clase Comunicación
Number of methods (NOM)
Número de métodos definidos en una clase Complejidad
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
43
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
44
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
Número de literales de conjunto, conjuntos ordenados, bags, secuencia o tuplas
Complejidad
NBO 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 Número de variables definidas a través de la definición de las restricciones
Complejidad
NIO 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 Número ponderado de operaciones referidas a través de navegaciones
Complejidad
NNC Número de clases navegables Complejidad
WNM Número ponderado de mensajes Complejidad
NPT Número de parámetros cuyo tipo son clases definidos en el diagrama de Clases
Complejidad
NUDTA 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
45
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.
46
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
NEntryAEl número total de acciones de entrada, es decir, el número total de acciones que se realizan una vez se entra en un estado
Tamaño
NExitAEl número total de acciones de salida, es decir, el número total de acciones que se realiza cuando se sale de un estado
Tamaño
NA Número total de actividades en el diagrama de estados Tamaño
NSSNúmero total de estados simples, considerando los estados simples que están incluidos en los estados compuestos
Tamaño
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
NTEl número total de transiciones, incluyendo transacciones comunes, las transacciones iniciales y finales, y transiciones internas.
Complejidad
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
47
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.
48
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 Modificabilidad
NDWPInNúmero de dependencias de entrada de los productos de trabajo de las actividades en el proceso
Modificabilidad
NDWPOutNúmero de dependencias de salida de los productos de trabajo de las actividades en el proceso
Modificabilidad
NDWPNúmero de dependencias entre los productos de trabajo y las actividades en el proceso
Modificabilidad
NDA Número de dependencias de precedencia entre actividades Modificabilidad
NCA Acoplamiento de las actividades en el modelo de procesos Modificabilidad
RDWPInProporción entre dependencias de entrada de productos de trabajo, y el número total de dependencias de productos de trabajo
Modificabilidad
RDWPOutProporción entre dependencias de salida de productos de trabajo, y el número total de dependencias de productos de trabajo
Modificabilidad
RWPA Proporción de productos de trabajo y actividades Modificabilidad
RRPA Proporción de roles de proceso y actividades 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
49
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 Número total de eventos finales de terminación en el modelo Complejidad
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
50
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
51
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.
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.
Esquema conceptual
Autor
D. d
e C
lase
s
D. C
aso
s d
e u
so
D. d
e E
stad
os
Esq
uem
a re
laci
on
al
Mo
del
o d
e p
roce
sos
Dat
a W
areh
ou
se
BD
ob
jeto
rel
acio
nal
Red
es d
e P
etri
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 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) X
Debnath et al. (2005) X X
Cruz Lemus et al. (2005) X
Genero et al. (2002b) X
Calero et al. (2000) X
Varas y Praderas (2000) X
52
P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016
Esquema conceptual
Autor
D. d
e C
lase
s
D. C
aso
s d
e u
so
D. d
e E
stad
os
Esq
uem
a re
laci
on
al
Mo
del
o d
e p
roce
sos
Dat
a W
areh
ou
se
BD
ob
jeto
rel
acio
nal
Red
es d
e P
etri
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 X
Baroni et al. (2006) X
Genero et al. (2008) X
Tort y Olivé (2009) X
Bisgaard y Aalast (2009)
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.
Atributo decalidad
Autor
Co
mp
lejid
ad
Co
mp
osi
ció
n
Aco
pla
mie
nto
Co
hes
ión
Her
enci
a
Reu
sab
ilid
ad
Mo
difi
cab
ilid
ad
Tam
año
En
cap
sula
mie
nto
Co
rrec
titu
d
Co
mp
leti
tud
Co
mp
ren
sib
ilid
adLi y Henry (1993) X X
Chidamber y Kemerer (1994) X X X X
Genero (2002) X X X X
Lorenz y Kidd (1994) X X
Brito e Abreu y Melo (1996) X
Marchesi (1998) X X X
Bansiya et al. (1999), Bansiya y Davis (2002) X X X X X
Genero et al. (2001, 2002a) X
Manso et al. (2002) X X X X
Reynoso et al. (2004a y 2004b) X
Marchensi (2003) X
Saeki (2003) X
Debnath et al. (2005) X X
Cruz Lemus et al. (2005) X
Genero et al. (2002b) X
53
P. A. Tamayo Osorio - Revista Reune No. 1 pp. 35-60, 2016
Atributo decalidad
Autor
Co
mp
lejid
ad
Co
mp
osi
ció
n
Aco
pla
mie
nto
Co
hes
ión
Her
enci
a
Reu
sab
ilid
ad
Mo
difi
cab
ilid
ad
Tam
año
En
cap
sula
mie
nto
Co
rrec
titu
d
Co
mp
leti
tud
Co
mp
ren
sib
ilid
ad
Calero et al. (2000) X
Varas y Praderas (2000) X X
Piattini et al. (2001) X X X X
Canfora et al. (2004) y García et al. (2004a) X
Rolón et al. (2005) X
Serrano et al. (2007) X
Baroni et al. (2006) X
Genero et al. (2008) X
Tort y Olivé (2009) X
Bisgaard and Aalast (2009) 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.
54
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.
55
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.
56
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 Object-Oriented 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 object-relational 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.
57
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 object-oriented 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, (79-90). 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.
58
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.
59
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
60
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.