Métricas de calidad para esquemas conceptuales. Una ...€¦ · como el encapsulamiento, la...

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


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


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


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


• 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


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


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


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


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


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


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


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


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


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


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


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


Tabla 6. Métricas definidas por Canfora García, Piattini, Ruiz

y Vissagio (2004) y García, Ruiz y Piattini (2004a)


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


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



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


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


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


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


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


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


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


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


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


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


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


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.

Métricas de calidad para esquemas conceptuales. Una ...€¦ · como el encapsulamiento, la...

Documents

Transcript of Métricas de calidad para esquemas conceptuales. Una ...€¦ · como el encapsulamiento, la...