Embed Size (px)
Citation preview
UNIVERSIDAD NACIONAL DE SAN LUIS
FACULTAD CIENCIAS FÍSICO MATEMÁTICAS Y NATURALES
Tesis
para optar a la titulación de posgrado correspondiente a la
Maestría en Ingeniería de Software
Definición de Métricas en OCL según el
Metamodelo de la OMG aplicadas al Diseño Orientado a Aspectos
Lorena Soledad Baigorria Fernández
Director: Dr. Daniel Riesco Co director: Mg. Ing. Germán Montejano
San Luis 2010
Agradecimientos
A mi esposo e hijos por su apoyo incondicional. A mis directores por su dedicación. A mis compañeros de trabajo, en especial a Mg. Ana Garis, Esp. Mario Peralta y Esp. Carlos Salgado por su apoyo y amistad.
Nada te turbe, Nada te espante
todo se pasa Dios no se muda
La paciencia todo lo alcanza
quien a Dios tiene nada le falta
Sólo Dios basta.
Santa Teresa
A.M.D.G.
I
Índice de Contenidos
Índice de Figuras IV Índice de Tablas V Capítulo 1 Introducción 1 1.1. Introducción 11.2 Motivación 3 1.2.1 Modelado de Sistemas Orientados a Aspectos (OA) 3 1.2.2 Realización de Prueba 4 1.2.3 Comparación de OA con OO 5 1.2.4 Reingeniería OA 6 1.2.5 Verificación de modelos OA 61.3 Objetivos 81.4 Publicaciones derivadas del presente trabajo de tesis 81.5 Estructura de Informe 9 Capítulo 2 Desarrollo de Software Orientado a Aspectos 11 2.1 Introducción 112.2 Separación de concerns 122.3 Aspectos, puntos de enlace y puntos de corte 182.4 Ingeniería de software con aspectos 23 2.4.1 Ingeniería de requerimientos orientada por concerns 25 2.4.2 Análisis orientado a aspectos 27 2.4.3 Diseño orientado a aspectos 28 2.4.4 Implementación orientada a aspectos 32 2.4.5 Prueba orientada a aspectos 32 Capítulo 3 Métricas de Software 36 3.1 Introducción 363.2 Conceptos básicos de métricas 363.3 Proceso de creación de métricas 37 3.3.1 Modelo Alarcos para la obtención de métricas 383.4 Objetivos de las Métricas de Software 403.5 Métricas de software 41 3.5.1 Medición del Proceso 42 3.5.2 Medición del Proyecto 43 3.5.3. Medición del Producto 45 3.5.3.1 Métricas de Código fuente 45 3.5.3.2 Métricas de Complejidad 47 3.5.3.3 Métricas para sistemas OO 483.6 Herramientas de medición de software 533.7 Importancia de las métricas en el proceso 54
II
Capítulo 4 Metamodelo de UML 2.3 56 4.1 Introducción 564.2 Arquitectura del lenguaje 56 4.2.1 Niveles de Modelado 56 4.2.2 Infraestructura 58 4.2.3 Modelos Estáticos 61 4.2.4 Mecanismo de extensión de UML 65 4.2.4.1 Ventajas 66 4.2.4.2 Elementos 66 4.2.5 OCL: Descripción y ventajas de su uso 68 4.2.5.1 Tipos básicos 71 4.2.5.2 Objetos y propiedades 71 4.2.5.3 OCL y el metamodelo UML 74 4.2.6 Sintaxis Abstracta de Perfil UML 74 4.2.6.1 Notación gráfica 79 4.2.6.2 Relación entre paquetes y perfiles 80 Capítulo 5 Definición de Métricas para el Diseño Orientado a Aspectos
82
5.1 Introducción 825.2 Extensión de UML 2.3 para sistemas OA 82 5.2.1 Participantes 84 5.2.3 Restricciones 86 5.2.4 Definición del perfil OA en la herramienta Papyrus 90 5.2.5 Generación automática de código AspectJ a partir del Perfil OA 935.3 Definición de Métricas Orientadas a Aspectos en OCL 95 5.3.1 Peso de método por Aspecto (PMA) 96 5.3.2 Profundidad del árbol de herencia (PAH) 96 5.3.3. Número de Hijos (NH) 97 5.3.4. Acoplamiento entre Aspectos (AA) 97 5.3.5. Dependencia entre Aspectos (DA) 98 5.3.6 Dependencia entre Clase-Aspectos (DCA) 99 5.3.7 Respuestas por Aspecto (RA) 99
5.3.8 Numero de Aspectos (NA) 99 5.3.9 Cantidad de operaciones de un aspecto (COA) 100 5.3.10 Cantidad de atributos de un aspecto (CAA) 101 5.3.11 Cantidad total de operaciones de un aspecto (CTO) 101 5.3.12 Cantidad total de atributos de un aspecto (CTA) 101 5.3.13 Tamaño de un aspecto (TA) 102 5.3.14 Indicación de herencia múltiple (HM) 102
5.3.15 Clases Tejidas 1025.4 Aplicación empírica de métricas en un diseño orientado a aspectos 103 5.4.1 Pool de conexiones de base de datos OA 104 5.4.2 Resultados y análisis de métricas 105 Capitulo 6 Conclusiones y Trabajos Futuros 110
III
Referencias 113
Anexo A Restricciones del Perfil OA 118
Anexo B Métricas OA en Papyrus 121
IV
Índice de Figuras Figura 2.1 Crosscutting Concerns 15Figura 2.2 Código mezclado de la administración de un buffer compartido 16Figura 2.3 Código diseminado en los métodos para implementar concerns secundarios
17
Figura 2.4 Aspecto autenticación de usuario 20Figura 2.5 Tejido de aspectos 22Figura 2.6 Núcleo del sistema con extensiones 24Figura 2.7 Enfoque orientado por punto de vista 26Figura 2.8 Casos de uso del sistema de administración de ambulancias 28Figura 2.9 Extensión de un Caso de Uso 28Figura 2.10 Proceso genérico de diseño orientado a aspectos 30Figura 2.11 Modelo de Diseño Orientado a Aspectos 31Figura 2.12 Modelo parcial de un aspecto 31Figura 3.1: Método Alarcos para la Definición de Métricas de Software 39Figura 3.2: Tipos de Entidades de Medición del Software 42Figura 4.1- Ejemplo de la jerarquía de metamodelos 58Figura 4.2 - Infraestructura UML 59Figura 4.3 Reutilización de “Core” 59Figura 4.4 Núcleo 60Figura 4.5 Class Diagrams 63Figura 4.6 Dependencies 65Figura 4.7 Perfil EJB 68Figura 4.8 Uso de operador “oclAsType()” 73Figura 4.9 Elementos definidos en el paquete Profile 75Figura 4.10 Ejemplo de aplicación de perfiles a un paquete 78Figura 4.11 Ejemplo de definición de un estereotipo 79Figura 4.12 Instancia de especificación de un estereotipo 79Figura 4.13 Ejemplo de relación de perfiles con paquetes 81Figura 5.1 Paquete Profiles de UML 2.3 83Figura 5.2 Definición de Perfil para Orientación de Aspectos 85Figura 5.3 (a) Metamodelo UML 2.3 (Class Diagrams) 89Figura 5.3 (b) Metamodelo UML 2.3 (Dependencies) 89Figura 5.4 Perfil OA en la Herramienta Papyrus 91Figura 5.5. Modelado de sistema 92Figura 5.6. Modelo que contiene un aspecto aislado (SaludoJapones) 93Figura 5.7 Transformaciones desde Perfil OA hasta código AspectJ 94Figura 5.8 Pool de conexiones de BD utilizando OA 104Figura 5.9 RA 105Figura 5.10 CAA 106Figura 5.11 DA 108Figura 5.12 ECT 109
V
Índice de Tablas Tabla 3.1 Métricas MOOD aplicables a la fase de diseño 49Tabla 3.2 Métricas de Lorenz y Kidd 51Tabla 3.3 Métricas para complejidad estructural de diagramas de clase UML 52Tabla 4.1 Tipos básicos 71Tabla 4.2 Operaciones predefinidas 71Tabla 4.3 Notación gráfica de vínculos 80Tabla 4.4 Notación gráfica de estereotipos, metaclases y perfiles 80
1
Capítulo 1
Introducción
1.1. Introducción
El desarrollo de grandes sistemas de software es una actividad que es abordada por la
ingeniería de software desde diferentes puntos de vista y en cada una de las fases de
desarrollo. Cada día surgen nuevas técnicas y metodologías que intentan mejorar la
calidad y la eficiencia del software.
El objetivo de la Ingeniería de Software es construir un producto de software o mejorar
alguno existente. Un proceso de desarrollo de software efectivo proporciona normas
para la construcción eficiente de software de calidad. Este proceso está compuesto, a
grandes rasgos, por cinco etapas: Requisitos, Análisis, Diseño, Implementación y
Prueba. La etapa de diseño tiene como propósito crear una abstracción de la
implementación, en el sentido de que la implementación es un refinamiento directo del
diseño. Esto permite la utilización de tecnologías como la generación de código y la re-
ingeniería entre el diseño y la implementación, entre otros. Es por esto que el diseño
detallado está directamente relacionado con los lenguajes de programación y en esta
etapa, se construyen modelos que dependen de ellos.
Por otro lado, uno de los principales problemas en el proceso de desarrollo de software
es el uso de grandes cantidades de tiempo y recursos. Aún con el incremento de la
automatización de diferentes actividades del desarrollo de software, los recursos son
escasos y costosos. Como consecuencia de esto y en la constante búsqueda de mejoras
en el desarrollo de sistemas de software, los investigadores y desarrolladores están
utilizando la orientación a aspectos (OA) en el proceso de desarrollo.
La orientación a aspectos surge a partir de la orientación a objetos (OO) tratando de
solucionar una de sus principales falencias. Si bien la OO es uno de los avances más
importantes en la ingeniería de software para la construcción de sistemas complejos
utilizando el principio de descomposición, y la reutilización, entre otros. Las
descomposiciones poseen el inconveniente de que muchas veces se tienen ejecuciones
ineficientes. Éstas surgen debido a que las unidades de descomposición no siempre van
acompañadas de un buen tratamiento de los aspectos tales como: sincronización, manejo
de errores y manejo de excepciones, administración de memoria y gestión de seguridad.
2
Estos aspectos que entrecruzan y atraviesan todo el sistema no pueden ser totalmente
separados con las técnicas de OO.
Surge entonces la OA, la cual tiene como unidad principal el aspecto. Los aspectos
encapsulan los crosscutting concerns1 que afectan a distintos componentes del sistema,
es decir se encuentran en varias partes de un programa (por ej. manejo de excepciones)
de manera tal que se reduzca la dependencia, y aumente su reutilización.
La industria del software ha atravesado una serie de etapas a lo largo del tiempo, desde
el interés de seguir la moda, hasta el desarrollo rápido de calidad requerido en los
noventa. La calidad de software es un punto crucial en cualquier desarrollo serio. Para
determinar si un software es de calidad o no, se utilizan métricas de software las cuales
son también aplicables a otras áreas como prueba, administración y mantenimiento del
software.
En los últimos años existe un gran interés en las métricas de software debido a su
potencial para predecir el uso más eficiente de los recursos y mejorar la calidad. Se han
realizado una gran cantidad de trabajos relacionados a las métricas, en especial
aplicadas a la orientación a objetos y procedimentales [1,2], pero no para software
orientado a aspectos.
Las métricas de software son formas de calificar, entre otros, el diseño de software. Se
puede decir entonces que las métricas aplicadas a la OA son cruciales para determinar la
efectividad de su uso.
En un desarrollo de software de calidad se utilizan herramientas que permitan modelar y
documentar el mismo, siendo en la actualidad UML (Unified Modeling Language) un
estándar.
UML es un lenguaje que sirve para modelar la mayoría de los dominios, pero no todos
los dominios son factibles de ser modelados en este lenguaje. Es por esto que UML
provee mecanismos de extensión. Uno de las formas de extender dicho lenguaje es a
través de estereotipos. Un estereotipo amplía el vocabulario del UML, permitiendo crear
nuevos tipos de bloques de construcción parecidos a los existentes, pero específicos a
un problema. El uso de definición de estereotipos en la arquitectura de Perfiles del
estándar UML permite extender los modelos para diseños orientado a aspectos. Además
UML utiliza OCL (Object Constraint Language) para especificar las restricciones del
1 Crosscutting concerns: son los distintos requerimientos funcionales, necesidades, restricciones que debe cumplir un sistema. Además éstos se encuentran dispersos en el sistema atravesándolo. En el campo de la orientación a aspectos se utiliza la palabra en inglés ya que no hay una traducción concensuada.
3
metamodelo UML en sus diferentes capas. OCL es un lenguaje que utiliza lógica de
primer orden y permite definir operaciones y restricciones de forma precisa.
Tanto el diseño como el modelado de sistemas ocupan un lugar importante en la
Ingeniería de Software. Los modelos brindan la posibilidad de abstraer sistemas y
facilitar la implementación. La construcción de buenos modelos asegura un correcto
desarrollo de la arquitectura del sistema.
Es imprescindible entonces contar con herramientas para evaluar la calidad del diseño,
es por esto que la definición de métricas específicas a la OA es indispensable. La
utilización para esto de estándares de la OMG (Object Management Group) como lo son
UML y OCL, las cuales son actualmente utilizadas por la mayoría de los
desarrolladores de software, provee las ventajas propias de los mismos. La definición de
métricas OA permitirá evaluar objetivamente el desarrollo de un producto de software
de manera tal que se logre aprovechar al máximo las ventajas de la OA.
1.2 Motivación
Este trabajo se enfoca en ayudar al ingeniero de software en el modelado de sistemas
orientados a aspectos, en particular en la etapa del diseño. Dado que esta etapa es la
más significativa en cuanto a estimaciones de recursos, la aplicación de métricas sería
muy provechosa [1, 2].
Como se dijo anteriormente la evolución continua del campo de la ingeniería de
software en pos de mejorar la calidad y el aprovechamiento de recursos, han surgido
nuevas tecnologías y metodologías para el desarrollo de software, como la Orientación a
Aspectos [3,4]. La OA es ampliamente utilizada para desarrollar software de alta
calidad, sin embargo la investigación de métricas aplicables a la misma es en la
actualidad muy escasa, la mayoría de los trabajos están enfocados hacia la
programación orientada a aspectos y no al Desarrollo de Sistemas Orientado a Aspectos
(DSOA).
En cuanto a la investigación existente acerca de la Orientación a Aspectos se pueden
distinguir algunas ramas principales. A continuación se presentan algunos de los
trabajos que las muestran.
1.2.1 Modelado de sistemas Orientados a Aspectos (OA)
El modelado se realiza usando una extensión de UML a través de diferentes técnicas, la
mayoría basadas en versiones anteriores a la actual versión de UML 2.3. Otros han
4
definido perfiles para sistemas OA enfocados en la Programación Orientada a Aspectos
o en lenguajes de propósito específico.
a. Zakaira, en [5], realiza una extensión de UML para el desarrollo
orientado a aspectos, considerando que la temprana detección de los
aspectos minimiza la interdependencia de las clases y permite una
generación automática de código. En este trabajo, la extensión realizada
se basa en versiones anteriores de UML y no utiliza perfiles, como está
especificado a partir de UML 2.0, sino que realiza la extensión a través
del uso de metaclases. Es claro, en este trabajo, la ventaja de la extensión
de UML y la generación automática de código AspectJ a través de una
herramienta (CASE). Pero se debe considerar que la extensión se realizó
sin usar perfiles a pesar que ya existían como mecanismo de extensión de
UML.
b. Aldawud, en [6], aborda el problema de la definición de perfiles para
extender UML y modelar sistemas que utilizan lenguajes orientados a
aspectos como AspectJ, sin definirlo en forma clara o estructural. Trata
el problema a modo de discusión y considera los puntos a tener en cuenta
y la importancia de la detección temprana de los aspectos en sistemas
orientados a aspectos.
c. Zambrano, en [7], hace hincapié en la detección temprana de los aspectos
para encapsular los crosscutting concerns en etapas tempranas del
desarrollo de software. Propone una herramienta que permita de forma
automática detectar aspectos candidatos a través de un patrón de colores
para poder diferenciar los crosscutting concerns en los requerimientos
del sistema.
1.2.2 Realización de Pruebas
En estos trabajos realiza la definición de lotes de prueba de los puntos más débiles de la
OA, es decir una vez ya desarrollado el sistema no en etapas anteriores.
a. Xu, en [8] y Bradi, en [9] consideran las distintas debilidades de la
programación OA. Teniendo en cuenta que los aspectos afectan a una o
más clases, que participan en el desarrollo, surgen otro tipo de errores
además de los habituales. Por ejemplo la interacción y sincronización
entre la clase base y él o los aspectos que utiliza. Es por este motivo que
5
se presentan en estos trabajos diferentes técnicas de prueba basadas en
los diagramas de estados de UML para comprobar que la interacción se
realice en tiempo y forma correcta.
b. Groher y Schuzle, en [10], presentan tres técnicas de prueba de
metamodelos (extensiones de UML). Una de ellas está basada en la
orientación a aspectos, detectando que si el modelado es realizado con
aspectos los errores se encuentran centralizados y las posibles soluciones
son más rápidas que en otras metodologías.
c. Quintero, en [11], muestra las ventajas del uso de la orientación a
aspectos con respecto a la reutilización de las clases base y de los
aspectos. Debido a esto la cantidad de pruebas disminuye notoriamente y
además las pruebas realizadas sobre un aspecto pueden reutilizarse para
probar otros, debido a sus similitudes.
1.2.3 Comparación de OA con OO
Se comparan las ventajas de OA con respecto al paradigma OO, mencionando cuáles
son las mejoras introducidas. Se consideran además algunas métricas, sin definirlas sólo
como comparación subjetiva.
a. Zhao, en [12], considera la medición del acoplamiento entre clases y
aspectos, el cuál debería disminuir. Afirmando que ésta métrica es la más
importante y propone diferentes estrategias o puntos a tener en cuenta
para disminuir el acoplamiento, sin medirlo, sólo sugiriendo que hacer
para disminuirlo. En este trabajo no se considera el modelado de
sistemas orientados a aspectos.
b. Baniassad, en [4], propone modelar los aspectos de un sistema en forma
separada e identificar los puntos de unión entre las clases base y los
aspectos. De esta manera se modela las clases bases por un lado y los
aspectos por otro. Aplica así las métricas OO a las clases base, sin
estimar los aspectos.
c. Shiu, Clarke y Baniassad, en [13], comparan la OO con la OA.
Consideran las similitudes y diferencias entre ambas y cómo el uso de
Aspectos disminuye distintas métricas. Se compara un sistema OO con el
mismo sistema desarrollado usando la OA. Se determina que distintas
métricas se favorecen con el uso de la OA, sin definir métricas
6
específicas para la OA pero sí indicando las posibles mejoras de las
métricas OO en el sistema OA debido al uso de ésta.
1.2.4 Reingeniería OA
En estos trabajos se proponen técnicas o herramientas que ayudan al ingeniero de
software a realizar el paso de sistemas OO a sistemas OA. Se realiza ingeniería inversa
de los sistemas y se detectan los aspectos candidatos. Una vez identificados los posibles
aspectos se convierte el sistema OO a OA.
a. Abait, en [14], realiza la identificación de crosscutting concerns
candidatos a través de una herramienta que utiliza técnicas de
inteligencia artificial. Esta herramienta usa técnicas de entrenamiento de
redes neuronales. Se identifican los crosscutting concerns en el código
OO para de esta manera entrenar las redes neuronales y que ésta pueda
identificar posteriormente de forma automatizada otros en el código.
b. Marcos, en [15], propone un proceso de refactoring de sistemas OO a
OA. Utiliza redes neuronales para verificar si los crosscuting concerns
identificados son efectivamente aspectos. Se realizan diferentes
observaciones para obtener evidencias de que los concerns detectados
son aspectos. Una vez confirmado el aspecto se realiza el refactoring del
sistema.
c. Martín, en [16], propone un enfoque de OA para el desarrollo de sitios
Web. Este trabajo hace hincapié en que el desarrollo de aplicaciones
Web para mejorar la accesibilidad de los mismos. Propone un enfoque
orientado a aspectos para realizar la reingeniería de aplicaciones Web y
mejorar la accesibilidad para personas con discapacidad. Muestra una
comparación entre las reingeniería OA con otras técnicas de reingeniería
utilizadas en aplicaciones Web y las ventajas que surgen de la aplicación
de esta nueva metodología.
1.2.5 Verificación de modelos OA
Otra rama que ha empezado a investigarse es la verificación formal de modelos OA.
a. Mostefaoui, en [17,18], propone una verificación formal de modelos
UML OA utilizando Alloy, un lenguaje de modelado estructural basado
en lógica relacional. Esta tarea se realiza debido a que es difícil predecir
7
el comportamiento de los aspectos una vez que éstos son tejidos en las
clases base. Muchas veces los aspectos tejidos no cumplen con el
propósito para el que fueron definidos. Es por esto que a partir de un
modelo OA realiza una traducción a Alloy para verificar el SOA. El
autor presenta una herramienta que permite realizar en forma automática
la verificación.
b. Ubayashi, en [19], provee un enfoque de verificación lightweight para
arquitecturas OA utilizando Alloy. Propone un método de verificación
para el chequeo de corectitud del tejido de un programa orientado a
aspectos. A través del analizador Alloy automatiza el chequeo una vez
realizado el modelo OA.
Luego del análisis de los diferentes trabajos encontrados, es llamativa la carencia de
definiciones formales o semi formales de métricas aplicables al diseño orientado a
aspectos. Considerando que las métricas son herramientas objetivas que permiten
calificar el desarrollo de software y ayudan a los diseñadores a decidir la viabilidad del
proyecto es importante su utilización.
Se puede observar que el mayor esfuerzo de investigación está en destacar las ventajas
que provee la OA sin realizar una valoración objetiva de los desarrollos que la
implementan.
En este trabajo se propone una serie de métricas precisas para sistemas OA las cuales
permitirán al ingeniero de software evaluar objetivamente el diseño realizado. Además
se utiliza para la definición de estas métricas estándares de la OMG. Considerando
también la tendencia actual de utilizar el enfoque MDA (Model Driven Architecture) el
cual se utiliza para el desarrollo de software dirigido por modelos propuesto también
por la OMG, la utilización de perfiles permite enmarcarse en el mismo. Esto se debe a
que MDA sostiene que a partir de un modelo de alto nivel de abstracción se llegue a
código ejecutable a través de transformaciones. MDA consta principalmente de tres
vistas [20]:
- CIM (Computation Independent Model): descripción de la lógica del negocio
desde una perspectiva independiente de la computación
- PIM (Platform Independent Model) descripción de la funcionalidad del sistema
en forma independiente de las características de plataformas.
8
- PSM (Platform Specific Model) descripción del sistema en términos de una
plataforma. A partir del cual debería ser posible la generación automática de
código fuente.
Si se tiene en cuenta que en este trabajo se enfoca en la orientación a aspectos se puede
situar el mismo en la vista PIM.
1.3 Objetivo
Esta tesis tiene varios objetivos basados en la situación actual de la OA en la ingeniería
de software.
1) Definir una extensión precisa de UML para el modelado de sistemas orientados
a aspectos.
Las extensiones existentes de UML para OA no proveen una definición precisa de las
restricciones que debe cumplir un modelo OA. Es por esto que como parte de este
trabajo se define una extensión de UML a través de perfiles y especificando la
semántica de los elementos que lo componen con OCL.
2) Definir métricas aplicables al desarrollo de software en la fase de diseño para
sistemas Orientados a Aspectos (OA), utilizando el lenguaje Object Constraint
Language (OCL), basándose en la extensión de UML para OA.
Definir métricas específicas para sistemas OA utilizando lenguajes estándares como lo
son UML y OCL. Se definen métricas a partir de la extensión del metamodelo de UML.
Esta definición se realiza utilizando la lógica de primer orden provista por OCL.
3) Aplicar el perfil y las métricas propuestas en este trabajo.
Realizar una aplicación práctica del perfil OA, en alguna herramienta actual. Calcular
las métricas OA sobre modelos OA. Describiendo en particular un caso de estudio.
1.4 Publicaciones derivadas del presente trabajo de tesis
Es importante destacar que se han realizado y publicado diferentes trabajos relacionados
a la temática abordada en esta tesis de maestría como así también la aplicación de la
extensión de UML para sistemas orientados a aspectos.
A continuación se listan los trabajos relacionados publicados por el autor de este trabajo
de tesis:
9
- Baigorria L. - Montejano G. - Riesco D.; “Definición y Aplicación de Perfil UML para
AspectJ”; ASSE; 39 Jornadas Argentinas de Informática; 2010.[21]
- L. Baigorria, G. Montejano, D. Riesco, C. Abdelahad, N. Perez, "Definición del
Diseño Orientado a Aspectos según el Metamodelo de la OMG", XV Congreso
Argentino de Ciencias de la Computación, 2009. [22]
- N. Debnath, L. Baigorria, D. Riesco, G. Montejano, “Metrics Applied to Aspect
Oriented Design using UML Profiles”, IEEE 13TH Symposium on Computers and
Communications 2008. [23]
- L. Baigorria, G. Montejano, D. Riesco, “Metricas C&K Aplicadas al Diseño Orientado
a Aspectos”, XII Congreso Argentino de Ciencias de la Computación, 2006. [24]
- L. Baigorria, D. Riesco, G. Montejano, “Métricas Aplicadas a la Programación
Orientada a Aspectos" WICC2006 en Morón (Argentina), Anales del VIII Workshop de
Investigadores en Ciencias de la Computación. [25]
- N. Debnath, D. Riesco, G. Montejano, R. Uzal, L. Baigorria, A. Dasso, A. Funes, "A
Technique Based on the OMG Metamodel: A Definition of Object Oriented Metrics
applied to UML Models", The 3rd ACS/IEEE International Conference on Computer
Systems and Applications, 2005.[26]
1.5 Estructura de Informe
El informe se ha estructurado en seis capítulos, el contenido de cada uno de ellos se
describe brevemente en los siguientes párrafos.
En el capítulo 1 se explican las motivaciones, objetivos y marco en el cual se realiza el
presente trabajo de tesis de maestría.
En el capítulo 2 se explica la Orientación a Aspectos desde Programación Orientada a
Aspectos (POA) hasta el desarrollo de sistemas siguiendo la metodología OA. Además
se explican los conceptos claves de la misma.
En el capítulo 3 se explican las métricas de software. La utilidad de las mismas y cuales
son los posibles usos. Cómo se definen y cuál es su importancia en el desarrollo de
10
software con calidad. También se detallan los diferentes tipos de métricas (producto,
proceso, proyecto) existentes.
En el capítulo 4 se explica el Metamodelo de UML 2.3 publicado en mayo de 2010.
Muestra sus componentes básicos, modelos, arquitecturas. Se describe también Object
Constraint Language (OCL 2.2) el cual es parte de UML desde la versión 2.1.
En el capítulo 5 se presentan las métricas definidas en OCL a partir de la extensión de
UML con un Perfil OA. Se analiza y compara la importancia de las mismas con
respecto a la OA. Se muestra además las diferencias esperables en los valores de las
métricas con respecto a los sistemas desarrollado siguiendo la OO.
En el capítulo 6 se muestran las conclusiones alcanzadas en el estudio de la orientación
a aspectos así como la importancia del uso de métricas para su evaluación. Además se
proponen trabajos futuros relacionados a la tesis presentada. Considerando que la
orientación a aspecto es un tema de investigación nuevo en comparación con otras
metodologías de desarrollo surgen una gran variedad de trabajos. Estos posibles trabajos
están enfocados en ayudar al ingeniero de software en el desarrollo de sistemas OA.
11
Capítulo 2
Desarrollo de Software Orientado a Aspectos
2.1 Introducción
En la mayoría de los grandes sistemas, la relación entre los requerimientos y los
componentes es compleja. Un requerimiento puede implementarse por varios
componentes y cada componente puede incluir elementos de muchos requerimientos.
Esto significa que implementar un cambio en un requerimiento puede involucrar
conocer y modificar varios componentes. Por este motivo la reutilización de
componentes puede resultar difícil ya que éstos no implementan una sola abstracción
del sistema sino que incluyen fragmentos de código de otros requerimientos.
El desarrollo de software orientado a aspectos, es un nuevo enfoque para el desarrollo
de software que intenta manejar éstos problemas y así hacer programas más fáciles de
mantener y reutilizar. El desarrollo de software orientado a aspectos (DSOA) se basa en
un nuevo tipo de abstracción llamado aspecto. Los aspectos se utilizan a lo largo de
otras abstracciones como objetos y métodos. Éstos encapsulan funcionalidades que
atraviesan y co-existen con otras funcionalidades que están incluidas en el sistema. Un
programa ejecutable orientado a aspectos se crea por la combinación automática (tejido)
de objetos, métodos y aspectos, de acuerdo a una especificación que es incluida en el
código del programa.
El beneficio clave del enfoque orientado a aspectos es que soporta la separación de
concerns. La separación de concerns, en elementos independientes, es una buena
práctica en la ingeniería de software porque evita incluir diferentes concerns en la
misma abstracción lógica. Si se representan los crosscutting concerns como aspectos,
estos conceptos pueden ser entendidos, reutilizados y modificados independientemente.
Por ejemplo, suponga que la autenticación de usuario se represente como un aspecto que
requiere un nombre de usuario y una contraseña. La autenticación de usuario es tejida
automáticamente en el programa cuando sea necesaria.
Una característica importante de los aspectos es que incluyen una definición de dónde
deben ser incluidos en el programa, así como el código que implementa los crosscutting
concerns. Se puede especificar entonces dónde el código que atraviesa el programa
debería ser incluido, si antes o después de la llamada al método o cuando un atributo es
12
accedido. Los aspectos son tejidos en el núcleo del programa para crear un sistema
enriquecido.
Por ejemplo, suponga que, en los requerimientos, la autenticación de usuario es
necesaria antes de cualquier cambio en los datos personales de la base de datos. Se
podría especificar esto como un aspecto, diciendo que el código de autenticación debe
incluirse antes de cada llamada a los métodos que actualizan los datos personales. De
ser necesario, se puede extender este requerimiento a todas las actualizaciones de la
base de datos. Esto puede ser implementado fácilmente modificando el aspecto,
cambiando la definición de dónde el código de autenticación es tejido en el sistema. De
esta manera no es necesario buscar en el código todas las ocurrencias de estos métodos,
lo que puede llevar a cometer errores o introducir vulnerabilidades en la seguridad del
sistema.
El desarrollo e investigación de la orientación a aspectos se enfocó en una primera etapa
en la programación orientada a aspectos (POA). Lenguajes de programación orientados
a aspectos (LOAs) como AspectJ [27, 28, 29] se han desarrollado para extender la
programación orientada a objetos de manera tal que incluyan aspectos. Algunas
compañías como IBM, están utilizando la POA en el proceso de desarrollo de software
[30]. Sin embargo, no se reconoce que los crosscutting concerns sean igualmente
problemáticos en otras etapas del proceso de desarrollo de software. Los investigadores
trabajan ahora en cómo utilizar la orientación a aspectos en los requerimientos del
sistema, en el diseño del sistema y en como probar y verificar los programas orientados
a aspectos.
El desarrollo de software orientado a aspectos (DSOA) no es aún parte principal de la
ingeniería del software. Aún no existen prácticas o convenciones para el DSOA y
tomará varios años de experiencia práctica para que éstos surjan. Actualmente las
tecnologías se enfocan en los beneficios y en intentar solucionar algunos de los
problemas o costos.
En este capítulo se mostrarán los conceptos claves de la OA y los problemas que surgen
al aplicar esta metodología de desarrollo. Se explicará también cómo la OA influye en
las distintas etapas de desarrollo de software.
2.2 Separación de concerns
La clave principal del diseño y la implementación de sistemas de software es la
separación de concerns.
13
Básicamente esto significa organizar el software de manera tal que cada elemento del
programa (clase, método, procedimiento, etc.) pueda realizar una y sólo una tarea. De
esta manera es posible enfocarse en este elemento sin considerar los demás elementos
del programa. Se pueden entender los concerns de un elemento sin la necesidad de
entender los demás elementos del programa. Cuando se requiere un cambio las
modificaciones se encuentran localizadas en pocos elementos.
La importancia de la separación de concerns fue detectada en etapas muy tempranas de
la historia de la ciencia de la computación. Las subrutinas, que encapsulaban una unidad
de funcionalidad y la estructuración de programas a través de procedimientos y objetos,
se inventaron en los 50’s, desde entonces se ha diseñado mecanismos para obtener una
mejor separación de concerns. Sin embargo, todos estos mecanismos tienen problemas
con cierto tipo de concerns que están dispersos en otros conceptos. Los aspectos se han
inventado para ayudar a manejar estos crosscutting concerns.
La separación de concerns es una buena práctica en el desarrollo de software pero es
difícil establecer a qué se refiere cuando se habla de un concern. A veces se lo define
como una noción funcional donde el concern es algún elemento funcional del sistema;
también se lo puede definir de manera muy amplia diciendo que es cualquier pieza o
punto de interés en un programa. Pero ninguna de estas definiciones es realmente útil.
Los concerns son más que simples elementos funcionales y la definición general es
realmente inútil.
Además estas definiciones de concerns intentan unir los aspectos con el programa. Pero
los aspectos son el reflejo de los requerimientos del sistema y las prioridades de los
stakeholders1 del sistema [31]. La performance del sistema puede ser un concern porque
los usuarios quieren una rápida respuesta del sistema; algunos stakeholders pueden
requerir alguna funcionalidad particular del sistema; las compañías que tienen el sistema
pueden requerir que sea fácil de mantener. Un concern es algo que es de significancia
para un stakeholder o para un grupo de stakeholders.
Con esta visión de aspectos, se puede observar porque el enfoque de separación de
concerns, en diferentes elementos del programa, es una buena práctica. Es más fácil
seguir los concerns, que se expresan como un requerimiento o un conjunto de
requerimientos, y los componentes del programa que implementan estos concerns. Si
los requerimientos cambian la parte del programa que se debe modificar es obvia.
1 Stakeholder: es cualquier persona que tenga algún interés y/o participación en el desarrollo del sistema. Por ejemplo: diseñadores, arquitectos, usuario final, cliente, organización, etc.
14
Hay diferentes tipos de concerns [32]:
1- Concerns funcionales: los que están relacionados a funcionalidades específicas
que deben incluirse en un sistema. Por ejemplo, en un sistema de control de
vuelo, un interés funcional es aterrizar el avión.
2- Concerns de calidad de servicio: los que se relacionan al comportamiento no
funcional del sistema. Esto incluye características como performance,
confiabilidad y disponibilidad.
3- Concerns de reglamentación o políticas organizacionales: los que se relacionan a
todas las reglas que gobiernan el uso del sistema. La regulación incluye
seguridad e intereses relacionados a las reglas de negocio.
4- Concerns del sistema: los que se relacionan a atributos del sistema como un
todo, como su mantenimiento y configuración.
5- Concerns organizacionales los que se relacionan a las metas y prioridades de la
organización como producir un sistema sin errores, reusar software existente o
mantener la reputación de la empresa.
Los concerns básicos del sistema son aquellos concerns funcionales que están
relacionados a su propósito principal. Por esto, para un sistema de información de
pacientes de un hospital, los concerns básicos son la creación, edición, devolución y
manejo de los registros de los pacientes. Además de los concerns básicos, la mayoría de
los grandes sistemas tienen funcionalidades secundarias. Éstas pueden ser
funcionalidades que comparten información con los concerns básicos o requerimientos
no funcionales del sistema.
Como un ejemplo de un requerimiento no funcional, considere un sistema que tenga el
requerimiento de proveer acceso concurrente a un buffer compartido. Éste es el caso de
procesos productores-consumidores, donde el productor coloca datos en el buffer y el
consumidor saca los datos del buffer. Sin embargo, para evitar que los procesos
interfieran entre si, hay un concern secundario esencial de sincronización. El sistema
debe diseñarse de manera tal que el proceso productor no sobre escriba los datos que
aún no han sido consumidos. Y que el proceso consumidor no pueda acceder a un buffer
vacío.
Además de la sincronización, otros concerns relacionados a la calidad de servicio y
políticas organizacionales reflejan requerimientos esenciales del sistema. En general,
estos concerns son intereses del sistema (se aplican al sistema como un todo y no como
15
si fueran requerimientos individuales o la realización de estos requerimientos en un
programa).
Se llamará a los concerns que son transversales al sistema, crosscutting concerns, para
distinguirlos de los concerns básicos. Los concerns funcionales secundarios pueden ser
también concerns transversales aunque no atraviesen todo el sistema; están asociados
con un grupo de concerns básicos que proveen la funcionalidad correspondiente.
En la figura 2.1 se muestra un ejemplo de un sistema de Homebanking. Este sistema
tiene requerimientos relacionados a los usuarios como consulta de saldo y verificación
de domicilio. También tiene requerimientos relacionados al manejo de usuarios
existentes y al manejo de las cuentas de los mismos. Todos estos son concerns básicos
que están asociados con el propósito principal del sistema. Sin embargo, el sistema tiene
también requerimientos de seguridad basados en las reglas de seguridad del banco y
requerimientos de recuperación, para asegurar que no se pierden datos en el caso de
falla del sistema. Estos crosscutting concerns pueden influenciar la implementación de
todos los demás requerimientos del sistema.
Las abstracciones de los lenguajes de programación como los procedimientos y las
clases son mecanismos que se utilizan para organizar y estructurar los concerns básicos
de un sistema. Sin embargo, la implementación de los concerns básicos en lenguajes
Figura 2.1 Crosscutting Concerns
convencionales de programación, generalmente incluyen código adicional que
implementan estos crosscutting concerns funcionales, de calidad de servicio y políticas
Requerimientos de Seguridad
Requerimientos de Recuperación
Req. de Nuevo Usuario
Req. de Cuenta Req. de Administración Usuario
Crosscutting Concerns
Intereses básicos
16
organizacionales. Esta solución lleva a dos fenómenos indeseables: código mezclado o
código diseminado.
El código mezclado ocurre cuando un módulo del sistema incluye código que
implementa diferentes requerimientos del sistema. Por ejemplo, la figura 2.2, muestra el
código mezclado que implementa la sincronización de un buffer. El código que
implementa el concern básico (en este caso colocar un registro en el buffer), está
mezclado con el código que implementa la sincronización. El código de sincronización
que está asociado con el concern secundario de asegurar la exclusión mutua debe
incluirse en todos los métodos que acceden al buffer compartido. El código asociado
con el interés de sincronización se muestra sombreado en la figura 2.2.
Figura 2.2 Código mezclado de la administración de un buffer compartido
El fenómeno de código diseminado ocurre cuando la implementación de un único
concern (un requerimiento lógico o un conjunto de requerimientos) es diseminado en
muchas componentes de un programa. Ésto puede ocurrir cuando se implementan los
requerimientos relacionados a los concerns secundarios funcionales o de política
organizacional.
Por ejemplo, la administración de un sistema de registros de hospitales tiene un número
de componentes que tienen que ver con la administración de la información personal,
medicación, consultas, imágenes médicas, diagnósticos y tratamientos. Ésto puede
configurarse de diferentes formas para diferentes tipos de clínicas e implementar los
conceptos básicos del sistema (mantener los registros de los pacientes).
synchoronized void put (SensorRecord rec) throws InterruptedException {
If (cantelem==tambuf) wait(); store[cant]=new Sensorrecord(recsensorid, recsensorVal); cant=cant+1; if (cant==tambuf) cant=0; cantelem= cantelem +1; notify(); }//put
17
Sin embargo, asuma que también hay un concern secundario importante que es la
generación de información estadística (el hospital desea registrar los detalles de cómo
los pacientes son admitidos y dados de alta cada mes, cuántos pacientes mueren, qué
medicamentos fueron utilizados, las razones de consulta, etc.). Estos requerimientos
deben implementarse de manera tal que se agregue código para que la información se
vuelva anónima (asegurar la privacidad del paciente) y escriba los datos en una base de
datos estadística. Componentes estadísticos procesan la información estadística y
generan los reportes estadísticos que se requieren.
En la figura 2.3 se muestra un diagrama que ejemplifica las tres clases que podrían ser
incluidas en el sistema de registros de pacientes en algunos de los métodos de
administración de información del paciente. El área sombreada muestra los métodos
necesarios para implementar los concerns secundarios (estadísticas). Se puede observar
que estos concerns estadísticos están diseminados a través de los otros concerns básicos.
Figura 2.3 Código diseminado en los métodos para implementar concerns secundarios
Los problemas de código mezclado y diseminado aparecen cuando los requerimientos
iniciales del sistema cambian. Por ejemplo, si nuevos datos estadísticos deben
recolectarse en el sistema de registro de un paciente. Los cambios al sistema no están
todos en un sólo lugar y por esto hay que ocupar tiempo buscando en el sistema los
componentes que deben cambiarse. Después hay que modificar cada uno de estos
componentes para incorporar los cambios requeridos. Debido al tiempo consumido en
esta tarea el proceso es costoso. Además siempre está la posibilidad de olvidarse de
modificar algún código y por esto las estadísticas serían incorrectas. Otro punto a
Paciente
<decl atrib>
getnomb(); editnomb(); getdom(); editdom(); . . p_anonimo()
Estudio
<decl atrib>
modalidad(); archivar(); getfecha(); editfecha(); . . guardardiag(); guardartipo();
Consulta
<decl atrib>
dartuno(); cancelturno( enfermera(); equipo(); . . p_anonimo(); guardarcons();
18
considerar es que cuanto más sean los cambios a realizar más posibilidades de cometer
errores e introducir errores en el software.
2.3 Aspectos, puntos de enlace y puntos de corte
En esta sección, se introducen los conceptos más importantes asociados al DSOA y se
darán ejemplos de los mismos basándose en el sistema de pacientes de un hospital. La
termología utilizada fue introducida por los desarrolladores de AspetcJ en los 90’s [33].
Sin embargo, los conceptos son genéricos y aplicables no sólo a la programación
orientada a aspectos sino también al desarrollo orientado a aspectos.
Los conceptos principales de la OA son:
Advice (Consejo): El código que implementa un interés.
Aspectos: Una abstracción que define un crosscutting concern del sistema. Éste incluye
la definición de un punto de corte y el advice asociado con ese interés.
Join-Point (Punto de enlace): Un evento de un programa en ejecución que causa que el
advice asociado con un aspecto se ejecute.
Modelo de punto de enlace: El conjunto de eventos que se referencia en un punto de
corte.
Point cut (Punto de corte): Una sentencia, incluida en un aspecto, que define el punto
de unión donde los aspectos asociados al advice deben ejecutarse.
Tejedor (Weaver): La incorporación del código de un advice en un punto de unión
específico es realizada por un tejedor de aspectos. Este tejedor es parte del lenguaje
orientado a aspectos.
El sistema de información de pacientes de hospitales, introducido en la sección 2.2,
incluye un número de diferentes componentes que manejan la lógica relacionada a la
información del paciente. La clase paciente contiene la información personal del
paciente; medicamento es la clase que tiene la información acerca de los medicamentos
que se pueden recetar, etc. Si se diseña el sistema usando un enfoque orientado a
objetos, diferentes instanciaciones del sistema se pueden configurar. Por ejemplo, una
configuración de versión para cada clínica, habilitando a los doctores sólo para que
receten medicamentos correspondientes a la especialidad. Esto simplifica el trabajo del
personal de la clínica y reduce las posibilidades de que el doctor recete por error un
medicamento no autorizado.
Sin embargo, esta organización implica que la base de datos sea actualizada desde
diferentes partes del sistema. Por ejemplo, cuando los datos personales del paciente
19
cambian, cuando la medicación cambie, cuando se los deriva a un nuevo especialista,
etc. Considere que todas las clases tienen los métodos que actualizan los datos y que los
nombres de estos métodos empiezan con “update”. Como por ejemplo:
updateInfo_Personal(id_paciente, infoupdate)
updateMedicamento(id_paciente, medicaciónupdate)
El paciente es identificado con id_paciente y los cambios a realizar están en el segundo
parámetro (los detalles no son necesarios para continuar con el ejemplo). Las
actualizaciones (updates) son realizadas por personal de la clínica que se encuentra
habilitado en el sistema.
Suponga ahora que surge un problema de seguridad, la información del paciente ha sido
modificada maliciosamente. Alguien dejó la computadora conectada al sistema y una
persona, no autorizada a ingresar, accedió a modificar la información del paciente
maliciosamente.
Para reducir la probabilidad de que esta violación de seguridad ocurra nuevamente, se
establece una nueva regla. Antes de realizar cualquier cambio en la base de datos de los
pacientes, el sistema solicita que el usuario se autentifique nuevamente en el sistema.
Los detalles de quién realizó los cambios se almacenan en un archivo separado. Esto
ayuda a resolver problemas de seguimiento de usuario.
Una manera de implementar esta nueva regla de seguridad es modificar el método
update, en cada clase, para llamar a otros métodos que realizan el seguimiento y la
autenticación de usuario. Otra solución es que cada vez que el método update es
invocado, se agreguen invocaciones a métodos para hacer el seguimiento y la
autenticación de usuario y después de la autenticación realizar los cambios. Pero
ninguna de éstas es una buena solución al problema:
1- El primer enfoque lleva a la implementación de código mezclado. Lógicamente,
la actualización de la base de datos, identificar quien realiza la actualización
(seguimiento de usuario) y la autenticación de usuario están separadas, son
concerns que no están relacionados. El seguimiento y autenticación de usuario
deben agregarse en muchos métodos.
2- La otra alternativa lleva a la implementación de código diseminado. Si se
agregan explícitamente invocaciones a métodos que realizan el seguimiento y
20
autenticación de usuario, antes y después de cada invocación a update, este
código se debe incluir en diferentes partes del sistema.
El seguimiento y autenticación de usuario atraviesan los concerns básicos del sistema y
es posible que se los incluya en diferentes partes. En un sistema orientado a aspectos, se
pueden representar estos crosscutting concerns del sistema, como aspectos separados.
Un aspecto incluye una especificación de dónde el crosscutting concern debe tejerse en
el programa y el código para implementar éstos. En la figura 2.4, se define el aspecto
autenticación de usuario. La notación utilizada sigue el estilo de AspectJ pero con una
sintaxis simplificada, para que se entienda sin necesidad de conocer Java o AspectJ.
Figura 2.4 Aspecto autenticación de usuario
Los aspectos son completamente diferentes de otras abstracciones del programa, ya que
en ellos se incluye la especificación de dónde debe ejecutarse. En las demás
abstracciones hay una clara separación entre la definición de la abstracción y su
utilización. Se puede invocar a un método mientras sea alcanzable y no se puede decir,
mirando el código del método, de dónde puede invocarse. Los aspectos en cambio
incluyen un punto de corte (una sentencia que define cuándo el aspecto debe ser tejido
en el programa).
En este ejemplo el punto de corte es:
before: call (public void update*(..))
aspect auten_usuario { before: call (public void update*(..)) // punto de corte { //un consejo que debe ejecutarse cuando se teja el aspecto en
//ejecución en el sistema int intento=0; string clave_us=Clave.Get(intento);
while ((intento<3) && (clave_us!= this.Usuario.clave())) { intento=intento+1;
clave_us=Clave.Get(intento); } if ((clave_us!=this.Usuario.clave())then // si la clave es incorrecta salir del sistema System.Logout(thisUsuario.uid); } }
21
El significado de esto es que antes de la ejecución de cualquier método que comience
con la cadena update (el carácter * es un comodín que reemplaza cualquier
identificador), se ejecuta el código que está a continuación del punto de corte. Este
código se llama advice y es la implementación del crosscutting concern. En este caso, el
advice obtiene la contraseña de la persona que solicita el cambio y chequea que coincida
con la contraseña del usuario que se encuentra en el sistema. Si no coincide, el usuario
es desconectado del sistema y la actualización no continúa.
La habilidad de especificar, usando puntos de cortes, dónde se deben ejecutar es una
característica distintiva de los aspectos. Sin embargo, para entender que significan los
puntos de corte, es necesario entender otro interés básico, el punto de enlace. Un punto
de enlace es un evento que ocurre durante la ejecución del programa (como la
invocación a métodos, la inicialización de variables, etc.). Hay una gran cantidad de
eventos que ocurren en un programa en ejecución. Un modelo de puntos de enlace
define aquellos eventos que pueden ser referenciados por un programador orientado a
aspectos. Por ejemplo en AspectJ, los eventos que son parte del modelo de puntos de
enlace incluyen. [34]
- eventos de invocación – invocaciones a métodos o constructores;
- eventos de ejecución – la ejecución de un método o un constructor;
- eventos de inicialización – inicializaciones de clases u objetos;
- eventos de datos – acceso o actualización de un dato;
- eventos de excepciones – el manejo de excepciones.
Un punto de corte identifica los eventos específicos (ej. la invocación a un
procedimiento determinado) con el cual el advice debe asociarse. Esto significa que se
puede tejer el advice en el programa en diferentes contextos. Por ejemplo:
1. Antes de la ejecución de un método específico, de una lista de métodos o de una
lista de métodos cuyos nombres empiecen con un patrón específico (como el
update*).
2. Luego de la finalización de la ejecución del método sea exitosa o no. En el ejemplo
de la figura 2.4, se puede definir un punto de corte que ejecute el código de
autenticación de usuario, luego de las invocaciones a los métodos update.
3. Cuando un campo en un objeto es modificado, se puede incluir un advice para
seguir las modificaciones del campo.
La inclusión de un advice en el punto de enlace especificado en el punto de corte es
responsabilidad de un tejedor de aspectos. Los tejedores de aspectos son extensiones de
22
compiladores que procesan la definición de los aspectos y de los objetos y métodos de
clase del sistema. El tejedor genera después un nuevo programa con los aspectos
incluidos en los puntos de enlace especificados. Los aspectos son integrados de manera
tal que los crosscutting concerns se ejecuten en los lugares que correspondan en el
sistema final.
La figura 2.5 muestra el tejido del aspecto para el seguimiento y autenticación del
usuario que deben incluirse en el sistema de administración de pacientes.
Hay tres enfoques diferentes para el tejido de aspectos:
1. Pre-procesamiento de código fuente donde un tejedor toma como entrada código
fuente y genera un nuevo código en un lenguaje como Java o C++ el cual luego
puede ser compilado usando un compilador estándar. Este enfoque es el utilizado
por el lenguaje AspectX con XWeaver [35]
2. Tejido en tiempo de enlace (Link time weaving) donde el compilador es modificado
para incluir un tejedor de aspectos. Un lenguaje orientado a aspectos como AspectJ
es procesado y se genera bytecode Java. Éste puede ser ejecutado directamente por
un intérprete Java o ser procesado aún más para generar código de máquina. Este es
el enfoque más utilizado
3. Tejido dinámico en tiempo de ejecución. Este es el enfoque más general pero
también el que tiene mayor overhead. En este caso, los puntos de enlace son
monitoreados y cuando un evento que es referenciado desde un punto de corte
ocurre, se integra el advice correspondiente al programa en ejecución.
Figura 2.5 Tejido de aspectos
Aspecto autenticación de usuario
Aspecto logging
…. updateInfo(..) …
Paciente
Tejedor de aspectos
…. código de autentic updateInfo(..) código de logging ....
Paciente
23
2.4 Ingeniería de software con aspectos
Los aspectos se introdujeron originalmente como una construcción de los lenguajes de
programación pero, la noción de concern proviene de los requerimientos del sistema.
Por esto es posible adoptar el enfoque orientado a aspectos en todas las etapas del
proceso de desarrollo de software. En etapas tempranas de la ingeniería de software,
adoptar el enfoque orientado a aspectos implica utilizar la noción de separación de
concerns como base para pensar en los requerimientos y en el diseño del sistema.
Identificar y modelar los concerns debe ser parte de la ingeniería de requerimientos y
análisis. Los lenguajes orientados a aspectos proveen el soporte tecnológico para
mantener la separación de concerns en la implementación del sistema.
Jacobsen en [31] sugiere que se debe pensar en un sistema que soporte los concerns de
los diferentes stakeholders como una extensión del núcleo del sistema. En la figura 2.6
se muestra el núcleo y las extensiones del sistema utilizando paquetes UML [36] para
representarlos. El núcleo del sistema es un conjunto de características del mismo, que
soporta el propósito esencial del sistema. En el caso del sistema que se ha visto en las
secciones anteriores, el propósito del sistema es mantener la información de los
pacientes de un hospital. Entonces el sistema provee básicamente la creación, edición,
administración y acceso a la base de datos de los registros de los pacientes. Las
extensiones al núcleo del sistema reflejan concerns adicionales de los stakeholders del
sistema, los cuales deben integrarse con los concerns básicos del sistema. Por ejemplo,
es importante que la información de los pacientes del hospital sea confidencial, por esto
algunas extensiones pueden estar relacionados con el acceso de datos, otra con
encriptación, etc..
24
Figura 2.6 Núcleo del sistema con extensiones
Existen un número de extensiones que son derivadas de los diferentes tipos de concerns
[32], que se explicaron en la sección 2.2.
1. Extensiones secundarias funcionales: agregan funcionalidades adicionales a la
funcionalidad provista por el núcleo del sistema. Por ejemplo, la generación de
reportes de las drogas prescriptas en los meses anteriores.
2. Extensión de reglas: agregan funcionalidades que soportan las reglas de la
organización. Ejemplos de estas extensiones son la incorporación de
características de seguridad de la organización.
3. Extensiones QoS: agregan funcionalidades que ayudan a alcanzar los
requerimientos de calidad de servicio que han sido especificados para el sistema.
Por ejemplo, una extensión para reducir el número de accesos a la base de datos
a través de una cache o recuperaciones automáticas ante una falla del sistema.
4. Extensiones de infraestructura: agregan funcionalidades que soportan la
implementación de un sistema sobre una plataforma específica. Por ejemplo, en
un sistema de información de pacientes, las extensiones de infraestructura se
pueden utilizar para la implementación de una interfaz para el sistema de
administración de base de datos existente.
Las extensiones siempre agregan alguna clase de funcionalidad o característica
adicional al núcleo del sistema. Los aspectos son una manera de implementar
Extension 1
Extension 6 Extension 5 Extension 4
Extension 3 Extension 2
Núcleo del sistema
25
estas extensiones, las que pueden componerse con las funcionalidades básicas
del sistema utilizando el tejido en el ámbito de los programas orientados a
aspectos.
2.4.1 Ingeniería de requerimientos orientada por concerns
Los concerns reflejan los requerimientos de los stakeholders. Éstos pueden reflejar una
funcionalidad requerida por un stakeholder, la calidad del sistema, políticas
organizacionales o de uso que están relacionados con los atributos del sistema como un
todo. Entonces tiene sentido adoptar un enfoque para la ingeniería de requerimientos
que identifique y especifique los concerns de los distintos stakeholders. El término
aspectos tempranos (early aspects) se usa a veces para referirse al uso de aspectos en
etapas tempranas del ciclo de vida del software donde se enfatiza la separación de
concerns.
La importancia de la separación de concerns durante la ingeniería de requerimientos es
reconocida desde hace muchos años. Los puntos de vista [37, 38] que se han
incorporado a algunos métodos de la ingeniería de requerimientos, son una manera de
separar los concerns de diferentes stakeholders. Éstos reflejan las distintas
funcionalidades que se requieren por distintos grupos de stakeholders. Sin embargo, hay
requerimientos que atraviesan todos los puntos de vista como se muestra en la figura
2.7. Este diagrama muestra que los puntos de vista pueden ser de diferentes tipos pero
los crosscutting concerns (como disponibilidad, seguridad y políticas o reglas de
negocio) generan requerimientos que impactan en todos los puntos de vista del sistema.
Para desarrollar un sistema que está organizado como se muestra en la figura 2.6, es
necesario identificar los requerimientos básicos del sistema más los requerimientos de
extensión del sistema. Un enfoque orientado por los puntos de vista para la ingeniería de
requerimientos, donde cada punto de vista representa un requerimiento de los grupos de
stakeholders relacionados, es una forma de separar los requerimientos básicos de los
secundarios. Si se organizan los requerimientos de acuerdo a los requerimientos de los
stakeholders, se pueden encontrar los requerimientos relacionados que aparecen en la
mayoría de los puntos de vista. Éstos representan las funcionalidades básicas del
sistema. Otros requerimientos pueden ser requisitos para la separación de concerns que
pueden implementarse como extensiones de las funcionalidades básicas.
26
Figura 2.7 Enfoque orientado por punto de vista
El sistema de la figura 2.7 se utiliza para seguir ambulancias usadas para servicios de
emergencias médicas. Estas ambulancias se encuentran en diferentes lugares a lo largo
de una zona o provincia y en caso de una emergencia médica, como accidente de
tránsito, infarto o incendio, el servicio de emergencia usa el sistema para buscar cuál de
las ambulancias está más cerca del lugar de la emergencia.
Los stakeholders de los distintos puntos de vista necesitan encontrar diferentes
instrumentos que se encuentran en las ambulancias, buscar las ambulancias disponibles
en cada depósito y controlar la salida/entrada de las mismas. Éstos son requerimientos
básicos para el sistema, los requerimientos secundarios son extensiones del sistema que
se encargan del mantenimiento, administración y soporte técnico de los instrumentos de
las ambulancias.
Un ejemplo de un crosscutting concern del sistema es la necesidad de disponibilidad del
sistema, ya que una emergencia puede ocurrir en cualquier momento. Salvar las vidas
de las personas requiere que la ambulancia llegue rápidamente al lugar de la
emergencia. Es por esto que el sistema de administración de ambulancias debe tener un
alto nivel de disponibilidad. Una solución para esto es tener un sistema de respaldo en
un algún lugar en el caso de que falle el sistema principal.
El resultado del proceso de ingeniería de requerimientos es un conjunto de
requerimientos estructurados con respecto al sistema básico más las extensiones.
Sistema
Políticas Disponibilidad Seguridad
Ambulancia
Usuario
Administrador
Empresa
Sociedad
Puntos de Vista Intereses
27
En esta etapa, es importante no tener demasiados concerns o extensiones del sistema. En
caso contrario la libertad de los diseñadores puede verse afectada y llevar a un diseño
temprano del sistema.
2.4.2 Análisis orientado a aspectos
En esta etapa, es necesario traducir los concerns relacionados con los problemas a
resolver en los correspondientes aspectos en el programa que implementa la solución.
También es necesario saber cómo estos aspectos se compondrán con los otros
componentes del sistema y asegurar que no surjan ambigüedades en esta composición.
Las condiciones de alto nivel de los requerimientos proveen una base para identificar
algunas extensiones del sistema que pueden implementarse como aspectos. Es necesario
desarrollar éstas más detalladamente para identificar futuras extensiones del sistema y
entender las funcionalidades requeridas. Una manera de realizar las extensiones es
identificar el conjunto de casos de uso [32] relacionado con lo diferentes puntos de
vista. Los modelos de casos de uso son el puente entre los requerimientos y el diseño.
Son más detallados que los requerimientos del usuario. En un modelo de casos de uso se
puede describir los pasos de cada interacción con el usuario y así comenzar a identificar
y definir las clases del sistema.
Los casos de uso cumplen un rol fundamental en la ingeniería de software orientada a
aspectos [29]. Cada caso de uso representa un aspecto, se modelan los puntos de corte y
los puntos de enlace se modelan con las extensiones. Jacobson en [31] introduce la idea
de slice el caso de uso y módulos de casos de usos, los que incluyen fragmentos de las
clases que implementan un aspecto y los cuales pueden ser compuestos para crear el
sistema completo.
En la figura 2.8 se muestran tres ejemplos de casos de uso que podrían formar parte de
sistema de administración de ambulancias. Éstos reflejan los concerns adicionales del
sistema de administración de las ambulancias y el pedido de una nueva ambulancia. El
pedido e incorporación de la ambulancia al depósito son concerns relacionados. Una vez
recibido el pedido, la ambulancia debe ser incorporada al inventario y enviada a uno de
los depósitos.
28
Figura 2.8 Casos de uso del sistema de administración de ambulancias
UML [36] tiene la noción de extensión de caso de uso donde la extensión de un caso de
uso extiende la funcionalidad de otro caso de uso. La figura 2.9 muestra como la
ubicación de una ambulancia (envío a un depósito) extiende el caso de uso básico de
incorporar una ambulancia a un depósito. Si la ambulancia a incorporar no existe, puede
ser pedida e incorporada al depósito cuando sea entregada. Durante el desarrollo de los
modelos de casos de uso, se deben buscar características similares en los modelos de
casos de uso y, donde sea posible, organizar los casos de uso como casos de uso básicos
más las extensiones. Las características transversales como el logging de todas las
transacciones, puede representarse también como una extensión.
Figura 2.9 Extensión de un Caso de Uso
2.4.3 Diseño orientado a aspectos
El diseño orientado a aspectos es el proceso de diseñar un sistema que utiliza los
aspectos para implementar los crosscutting concerns y las extensiones que se detectan
en las etapas anteriores del desarrollo de software.
29
Es esencial la realización de un proceso de diseño orientado a aspectos eficaz para que
esta metodología de desarrollo sea aceptada y utilizada. El proceso de diseño OA
debería incluir [32] las actividades que se muestran en la figura 2.10. Estas actividades
se describen a continuación.
1. Diseño del núcleo del sistema: en esta etapa, se debe diseñar una arquitectura
que soporte las funcionalidades básicas del sistema. La arquitectura debe
considerar la calidad de los servicios requeridos como así también la
performance y los requerimientos dependientes. Sin embargo, las
funcionalidades específicas deberían implementarse como extensiones.
2. Identificación y diseño de aspectos: analizar las extensiones especificadas en los
requerimientos del sistema, para determinar si son un único aspecto o si deben
dividirse en varios aspectos. Una vez que los aspectos se han identificado, estos
pueden diseñarse separadamente, considerando el diseño de las características
básicas del sistema.
3. Diseño de la composición (tejido): en esta etapa, se analiza el sistema básico y el
diseño de los aspectos para determinar donde se deben tejer los aspectos con los
componentes del sistema. Se identifican los puntos de enlace en un programa
que será tejido.
4. Análisis y solución de conflictos: un problema con los aspectos es que pueden
interferir entre sí cuando son compuestos con el sistema básico. Los conflictos
surgen cuando en un punto de corte colisionan diferentes aspectos especificando
que deben ser compuestos en el mismo punto del programa. Sin embargo,
pueden surgir conflictos menores cuando los aspectos se diseñan
independientemente. Éstos pueden realizar suposiciones acerca de
funcionalidades básicas del sistema que tienen que ser modificadas. Sin
embargo, cuando muchos aspectos son compuestos, la funcionalidad del sistema
puede no verse afectada de manera tal que las suposiciones realizadas sean
válidas.
5. Diseño de estándares de nombres: esta es una actividad importante del diseño
que define los estándares para nombrar las clases en un programa. Esto es
esencial para evitar el problema de falsos puntos de corte. Esto ocurre cuando,
en algún punto de enlace del programa, los nombres coinciden con un patrón de
un punto de corte pero no se debía tejer un advice en esa etapa. Una vez
30
diseñado los estándares para los nombres, es posible que se deban modificar los
modelos de diseño para renombrar los elementos diseñados.
Figura 2.10 Proceso genérico de diseño orientado a aspectos
El proceso de DSOA es iterativo, se realizan propuestas de diseños iniciales y luego se
refinan hasta entender los usos del diseño. Generalmente, las extensiones identificadas
en etapas anteriores del proceso de desarrollo de software se refinan en varios aspectos.
La salida del diseño orientado a aspectos es un modelo de diseño orientado a aspectos.
Esto puede expresarse en una versión extendida de UML, éste debe contener los
constructores específicos para la orientación a aspectos. Aunque ningún estándar se ha
definido, los elementos esenciales que debe incluir el UML “extendido” son: formas de
representar los aspectos y los puntos de enlace.
La figura 2.11 muestra un ejemplo de un modelo de diseño orientado a aspectos. En esta
figura se modela el sistema de administración de ambulancias más algunos aspectos que
pueden componerse a éste. Esta figura muestra una parte del diseño del sistema. Se
utilizan las notas de UML para proveer información adicional acerca de las clases que
son atravesadas y cortadas por algunos aspectos.
31
Figura 2.11 Modelo de Diseño Orientado a Aspectos
En la figura 2.12 se muestra una versión expandida del modelo orientado a aspectos la
cual detalla más información de los aspectos. Obviamente antes de realizar el diseño de
aspectos se debe tener el diseño del sistema básico. El modelo de diseño completo no es
necesario por lo que se harán algunas suposiciones acerca de las clases y métodos del
núcleo del sistema.
Figura 2.12 Modelo parcial de un aspecto
La primera sección del conjunto de aspectos establecen los puntos de corte que
especifican donde se compondrán con el núcleo del sistema. Por ejemplo, el primer
32
punto de corte especifica que los aspectos pueden ser compuestos en el punto de enlace
call getiteminfo(..). La siguiente sección define las extensiones que son implementadas
por aspectos. En el ejemplo, la sentencia de extensión se puede leer como:
En el método viewitem, después de llamar al método getiteminfo, se debería
incluir una llamada al método mostrarHistorial para mostrar el registro de
mantenimiento.
2.4.4 Implementación orientada a aspectos
El inicio de la orientación a aspectos fue a través de la programación orientada a
aspectos (POA). En 1997 en los laboratorios Xerox se crea el lenguaje de programación
AspectJ [34]. Este lenguaje orientado a aspectos de propósito general es el más utilizado
en la actualidad para la implementación de software OA. Otros lenguajes como C# y
C++ [39, 40] han realizado extensiones para soportar la separación y composición de
los croscutting concerns.
Si se ha utilizado el enfoque orientado a aspectos en el desarrollo del sistema, y se han
identificado las funcionalidades básicas y las extensiones de las clases para luego
implementar los crosscutting concerns con aspectos. La tarea principal de la
implementación es realizar la programación de las funcionalidades básicas y las
extensiones. La tarea más importante es la especificación de los puntos de corte en los
aspectos. De esta manera, el advice será tejido en el lugar correcto del código.
La correcta especificación de los puntos de corte es muy importante ya que definen
dónde los advices serán tejidos con las funcionalidades básicas. Si la especificación de
los puntos de corte es incorrecta, los aspectos serán tejidos en el programa en lugares
equivocados. Esto puede llevar a un comportamiento inesperado e impredecible del
programa. Es necesario revisar todos los aspectos para evitar interferencias entre ellos,
esto ocurrirá si dos o más aspectos son tejidos en el sistema básico en el mismo punto
de enlace. En general, es mejor evitar la completitud de los aspectos pero, a veces,
puede ser lo correcto. En esas circunstancias, se debe asegurar que los aspectos sean
completamente independientes ya que el comportamiento del programa no debería
depender del orden de tejido de los aspectos en el programa.
2.4.5 Prueba orientada a aspectos
La prueba es un proceso que demuestra si un programa cumple con las especificaciones
(verificación) y con las necesidades reales de los stakeholders. Existe gran variedad de
33
técnicas de verificación. Las técnicas de verificación estáticas se centran en el análisis
manual o automático del código fuente del programa. La dinámica intenta descubrir los
defectos en el programa o bien demostrar que el programa cumple con los
requerimientos. Cuando el objetivo es demostrar los defectos, el proceso de prueba
puede ser guiado por el código fuente del programa. Las métricas de prueba de
cobertura muestran la efectividad de las pruebas realizadas a través de la ejecución de
sentencias del código fuente.
Para los sistemas orientados a aspectos, el proceso de prueba no es diferente a cualquier
otro sistema. Cuando el programa final ejecutable es tratado como una caja negra y las
pruebas muestran si el sistema cumple o no los requerimientos. Sin embargo, existen
problemas con la inspección de código y las pruebas de caja blanca, donde se utiliza el
código del programa para identificar las potenciales pruebas de defectos. Además, el
uso de aspectos introduce problemas adicionales para los que diseñan y realizan las
pruebas [41]:
1. ¿Cómo se pueden especificar los aspectos de manera tal que se deriven las
pruebas para que alcancen estos aspectos?
2. ¿Cómo pueden probarse los aspectos independientemente del núcleo del sistema
con el que deben ser tejidos?
3. ¿Cómo se puede probar la interferencia entre los aspectos?
4. ¿Cómo se pueden diseñar las pruebas de manera tal que todos los puntos de
enlace sean ejecutados y aplicar las pruebas apropiadas?
Todos estos problemas son motivo de investigación en el desarrollo orientado a
aspectos, pero hasta ahora no hay soluciones disponibles. Los problemas de prueba que
surgen se deben a que los aspectos están altamente integrados al núcleo del sistema. Es
por esto, que son difíciles de probar de manera separada. Los aspectos deben ser tejidos
en un programa en muchos lugares diferentes, no se puede asegurar que si un aspecto
funciona exitosamente en un punto de enlace lo haga en todos.
Por otra parte, otra técnica, como la inspección de programas involucra un equipo de
lectores que miren el código fuente del programa para descubrir los defectos que el
programador pudiera introducir. Es una técnica muy efectiva para la detección de
errores. Sin embargo, los programas orientados a aspectos no pueden leerse
secuencialmente, de arriba hacia abajo. Por esto es más difícil que las personas los
entiendan.
34
Una guía general para que un programa se entienda, es que el lector debe ser capaz de
leer el programa de izquierda a derecha, de arriba hacia abajo sin tener que prestar
atención a otras partes del código. Esta guía es útil para el lector y el programador, ya
que evita cometer errores debido a que su atención está en una única sección del código.
En un sistema orientado a aspecto, la lectura secuencial del programa es imposible. El
lector debe examinar cada aspecto, entender sus puntos de corte (los cuales pueden ser
patrones) y el modelo de puntos de enlace del lenguaje orientado a aspectos. Cuando se
lee el programa, el lector debe identificar los potenciales puntos de enlace y pasar su
atención hacia el código del aspecto para ver si debe ser tejido en ese punto o no. Luego
éste debe volver la atención al flujo de control principal del código base. En realidad,
este proceso es cognitivamente imposible y la única manera de inspeccionar el código
orientado a aspectos es a través de herramientas de lectura de código.
Las herramientas de lectura de código deben escribirse de manera tal que “aplane” el
programa orientado a aspectos y presente al lector un programa con los aspectos tejidos
en el punto especificado del programa. Sin embargo, el modelo de puntos de enlace en
un lenguaje puede ser dinámico en vez de estático y puede ser imposible demostrar que
el programa aplanado se comporte exactamente como el programa en ejecución.
Además, debido a que es imposible tener la misma especificación para todos los puntos
de corte, la herramienta de lectura del programa debe saber cómo el tejedor de aspectos
maneja los aspectos y cómo se realiza la composición.
La prueba de caja blanca o estructural es un enfoque sistemático para la prueba donde el
conocimiento del código fuente se utiliza para diseñar las pruebas de errores. La idea es
diseñar las pruebas para que provean algún nivel de cobertura de programa.
Generalmente, el conjunto de pruebas debe asegurar que cada rama lógica del programa
se siga, luego cada sentencia del programa sea ejecutada al menos una vez. Pueden
utilizarse analizadores de ejecución de programas para demostrar qué nivel de cobertura
se ha alcanzado.
En un sistema orientado a aspectos, hay dos problemas con la prueba de caja blanca. :
1. Cómo derivar sistemáticamente las pruebas del programa a partir del código
fuente.
2. Qué es exactamente la prueba de cobertura en un programa orientado a aspectos.
Se puede observar un grafo de flujo del programa para diseñar pruebas en un programa
estructurado (por ej. pruebas del código de un método) sin ramas condicionales. Éste
grafo muestra cada uno de los posible caminos de ejecución del programa. Luego se
35
examina el código y, por cada camino del grafo de flujo, se eligen los valores de entrada
que causen la ejecución del camino.
Sin embargo, en un programa orientado a aspectos, el problema principal es decidir que
significa prueba de cobertura. Significa que ¿cada aspecto debe ejecutarse al menos una
vez? Esta es una condición muy débil por la interacción existente entre aspectos y
código base, en los puntos de enlace donde los aspectos son tejidos. Entonces prueba de
cobertura significa que ¿los aspectos deben ejecutarse al menos una vez en cada punto
de enlace? ¿Qué ocurre en aquellas situaciones donde diferentes aspectos definen un
mismo punto de corte? Surgen dos problemas con esta propuesta uno teórico y otro
práctico. Se necesitan herramientas para soportar la prueba de programas orientados a
aspectos que ayuden a acceder a la extensión de la cobertura de prueba de un sistema.
Los grandes proyectos por lo general tienen un equipo encargado del aseguramiento de
calidad el cual establece un conjunto de pruebas estándares y solicita un aseguramiento
y revisión formal del programa para verificar que cumpla con los estándares de calidad
establecidos.
Una barrera importante a vencer para adoptar el desarrollo orientado a aspectos en
grandes proyectos es la dificultad de inspeccionar y derivar las pruebas de los
programas.
36
Capítulo 3
Métricas de Software
3.1 Introducción
La medición de Software cumple un rol importante en la Ingeniería de Software.
En la actualidad, se ha demostrado que las métricas de software son muy efectivas para:
la construcción y estimación de proyectos de alta calidad, entender y mejorar el
desarrollo y mantenimiento de proyectos de software [42], asesorar y mantener sistemas
de software de calidad resaltando las áreas conflictivas, determinar la mejor forma de
ayudar a los desarrolladores en su trabajo [43], etc.
Además, las métricas de software son herramientas importantes para ayudar en el
asesoramiento e institucionalización de Mejoras de Procesos de Software en
organizaciones. De hecho, la medición de software es un punto clave en iniciativas de
SW-CMM (Capability Maturity Model for Software), ISO/IEC 15504 (SPICE,
Software Process Improvement and Capability dEtermination) y CMMI Capability
Maturity Model Integration) [44]. ISO/IEC 9003:2004 [45] hace hincapié en la
importancia de la medición para asegurar calidad y gerenciamiento.
Para apreciar la importancia de las métricas en la evaluación de los sistemas de software
es importante clarificar algunos conceptos básicos relacionados a las mismas. Es
necesario también distinguir las clases de métricas existentes y el rol que cumplen en las
distintas etapas del desarrollo de software.
3.2 Conceptos básicos de métricas
En esta sección se definen los posibles términos que encierra la palabra métrica, porque
es muy común asociarla con las palabras medición y medida, aunque estas tres son
distintas. La medición “es el proceso por el cual los números o símbolos son asignados
a atributos o entidades en el mundo real tal como son descritos de acuerdo a reglas
claramente definidas” [46]. Una medida “proporciona una indicación cuantitativa de
extensión, cantidad, dimensiones, capacidad y tamaño de algunos atributos de un
proceso o producto” [47]. El IEEE “Standard Glosary of Software Engineering Terms”
define la palabra métrica como “una medida cuantitativa del grado en que un sistema,
componente o proceso posee un atributo dado”.
37
Se ha intentado desarrollar una sola métrica que proporcione una medida completa de la
complejidad del software. Aunque se han propuesto docenas de métricas, cada una de
éstas tiene un punto de vista diferente; y por otro lado, aunque bien se sabe que existe la
necesidad de medir y controlar la complejidad del software, es difícil obtener un sólo
valor de estas métricas de calidad. Aún así es posible desarrollar medidas de diferentes
atributos internos del programa.
Aunque todos estos obstáculos son motivo de preocupación, no son motivo de desprecio
hacia las métricas. Si se desea realmente alcanzar la calidad en software la medición es
esencial, es por eso que existen distintos tipos de métricas para poder evaluar, mejorar y
clasificar al software final. Dependiendo del entorno de desarrollo de software se deben
orientar las métricas para evaluar el mismo.
3.3 Proceso de creación de métricas
Como se dijo en secciones previas se han propuesto cientos de métricas para el
software, pero no todas proporcionan suficiente soporte práctico para su desarrollo.
Algunas demandan mediciones que son demasiado complejas, que pocos profesionales
tienen la esperanza de entenderlas, y otras violan las nociones básicas intuitivas de lo
que realmente es el software de alta calidad. Debido a esto, se han definido una serie de
atributos que deben acompañar a las métricas efectivas de software, por lo tanto la
métrica obtenida y las medidas que conducen a ella deben cumplir con las siguientes
características fundamentales [48]:
- Simple y fácil de calcular: debería ser relativamente fácil de aprender a obtener la
métrica y su cálculo no debe causar un esfuerzo o consumir una cantidad de tiempo
inusual.
- Empírica e intuitivamente persuasiva: la métrica debería satisfacer las nociones
intuitivas del ingeniero de software sobre el atributo que se mide del producto en
cuestión (por ejemplo: una métrica que mide la cohesión de un módulo debería
aumentar su valor a medida que crece el nivel de cohesión).
- Consistente en el empleo de unidades y tamaños: el cálculo matemático de la métrica
debería utilizar medidas que no lleven a extrañas combinaciones de unidades. Por
ejemplo, multiplicar el número de personas de un equipo por las variables del lenguaje
de programación en el programa resulta una sospechosa mezcla de unidades que no son
intuitivamente concluyentes.
38
- Independiente del lenguaje de programación: las métricas deberían apoyarse en el
modelo de análisis, modelo de diseño o en la propia estructura del programa. No
deberían depender de los caprichos de la sintaxis o semántica del lenguaje de
programación.
- Un mecanismo eficaz para la realimentación de calidad: la métrica debería
suministrar al desarrollador de software información que le lleve a un producto final de
calidad superior.
La mayoría de las métricas de software compensan las características anteriores aunque
algunas métricas usualmente empleadas no cumplen una o dos características.
3.3.1 Modelo Alarcos para la obtención de métricas
Intentando progresar en la disciplina de las métricas de software, se ha buscado una
forma metodológica y disciplinada de creación de métricas. La definición de la métrica
debe tener una base sólida con objetivos de medición claros y satisfacer necesidades de
la organización. Se puede encontrar en la bibliografía diferentes métodos para la
definición de las métricas de software. Se muestra a continuación uno de ellos que es el
propuesto por el Grupo Alarcos [49] (Figura 3.1). Esta propuesta contiene los pasos
generales de la obtención de métricas siendo un modelo representativo de los existentes.
En la figura 3.1 Modelo del Grupo Alarcos las flechas continuas representan el flujo de
las métricas y las discontinuas representan el flujo de información a lo largo de todo el
proceso.
La propuesta del grupo Alarcos consta de dos fases:
- Identificación: en esta etapa se deben identificar los objetivos de medición y las
hipótesis sobre las cuales se crean las métricas. Los objetivos indican lo qué se pretende
conseguir con el proceso de medición y representan porqué se realiza la medición. La
hipótesis es parte de cómo se llevará a cabo la medición para conseguir los datos
necesarios para alcanzar los objetivos propuestos. Como resultado de ésta se deben
obtener los requisitos que debe cumplir la métrica. Además los objetivos son utilizados
nuevamente en la aceptación, aplicación y acreditación de las métricas como se muestra
en la Figura 3.1.
39
Figura 3.1: Método Alarcos para la Definición de Métricas de Software
- Creación: en este proceso se creará una métrica válida para aplicar en un entorno real.
Este proceso es evolutivo e iterativo y se subdivide en varias etapas intermedias. Se
realiza el refinamiento de las métricas a través de la retroalimentación de la validación,
teórica o empírica, fallida. Al final de la etapa de creación se dejarán las métricas
consideradas válidas y se descartarán las inválidas. Las etapas en las que se divide la
creación son:
- Definición: se considera las características del producto a medir y la
experiencia de los profesionales. Es importante que la definición sea lo más formal
posible para que logre alcanzar el objetivo propuesto en la fase anterior.
- Validación teórica: en esta etapa se debe demostrar que la métrica mide el
atributo que pretende medir, es decir se comprueba si la idea intuitiva de la métrica se
cumple. La validación teórica proporciona información relacionada a las escalas de las
métricas y poder así determinar las operaciones matemáticas y tests estadísticos a
aplicar a la hora de analizar los valores. No existe ningún estándar para la validación
teórica, pero si existen dos tendencias principales: los marcos basados en propiedades
que definen formalmente propiedades deseables de las métricas para un atributo
software concreto [50] y los que se basan en la teoría de la medida [51] y cuyo objetivo
es obtener una escala matemática relacionada a la métrica.
40
- Validación empírica: en esta etapa se debe probar la utilidad práctica de las
métricas propuestas. Es necesaria la validación empírica para obtener información
objetiva acerca de las métricas, esto se logra a través de hipótesis en el mundo real.
- Explicación psicológica: poder explicar la influencia de la métrica desde el
punto de vista psicológico.
- Aceptación: suele ser necesaria una fase de prueba de laboratorio, donde
sistemáticamente se verifique si la métrica cumple con los objetivos buscados dentro del
entorno real. Es aconsejable realizar estas pruebas con sistemas pilotos, donde el riesgo
es controlado, de esta manera la no aceptación de la métrica no causará el fracaso del
proyecto. Si se consigue demostrar que la métrica sigue cumpliendo los objetivos para
la cual fue definida se puede pasar a la etapa de aplicación.
- Aplicación: en esta fase se aplica la métrica en un entorno real y se puede llevar en
paralelo con la fase de acreditación.
- Acreditación: en esta última fase se busca mejorar la métrica. Al tener los resultados
de la aplicación en casos reales puede ser posible mejorar o especializar la métrica
(siempre y cuando siga cumpliendo los objetivos para la cual fue definida). Es posible
también que luego de la aplicación en entornos muy variables se llegue a la conclusión
de descartar la métrica. Esto puede ser porque no es aplicable y que los conocimientos
adquiridos permitan la identificación de una nueva métrica.
3.4 Objetivos de las Métricas de Software
Los objetivos principales de las métricas en el software son:
Mejor comprensión de la calidad del producto.
Estimación de la efectividad del proceso.
Mejora de la calidad del trabajo realizado en distintos niveles del proyecto.
Cada uno de estos objetivos es importante por sí mismo, pero la calidad de la ingeniería
del producto es esencial. Si el proceso de desarrollo de un producto no es evaluado a
través de algún mecanismo, como son las métricas, la calidad del producto resultante se
ve afectada.
41
3.5 Métricas de software
El objetivo de todo proceso de medición es recopilar indicadores cuantitativos sobre
entidades software1. Para realizar la medición es necesario identificar tanto las entidades
como los atributos a medir. Esto se debe a que no se puede medir una entidad o un
atributo en forma aislada. Por ejemplo, si se quiere medir el tamaño de un programa, se
deben medir de forma conjunta las entidades y los atributos [52].
Para realizar la medición del software hay que estudiar las entidades que pueden ser
objeto de medición así como los atributos característicos de dichas entidades.
A continuación se mostrará una visión general sobre el campo de las métricas software.
De acuerdo a modelos de evaluación y mejora como ISO 15504, CMM, o CMMI, a la
hora de incrementar el nivel de madurez de una organización hay que establecer una
base cuantitativa enfocada en:
- Medición del Proyecto, basado en la gestión de proyectos.
- Medición del Producto, centrado en su calidad y aspectos técnicos.
- Medición del Proceso, basado en el estudio y control de la capacidad de los
procesos, así como en la gestión de los cambios en el proceso.
La relación entre las métricas de proceso [48], proyecto y producto se muestra en la
figura 3.2. Como se puede observar en dicha figura, el proceso de software constituye la
base a partir de la cual se realiza el trabajo dentro de una organización. Dicho proceso
se aplica en forma de proyectos. Como resultado de la ejecución de proyectos concretos
se utilizan recursos y se obtienen productos. Por lo tanto, para establecer un marco de
medición dentro de la organización es necesario definir, recoger y analizar métricas
sobre el proceso, el proyecto y recursos asociados así como el producto software.
1 Una entidad software todo elemento software sobre el que se puede aplicar un proceso de medición y que están caracterizadas por una serie de atributos (tamaño, tiempo, etc.).
42
Figura 3.2: Tipos de Entidades de Medición del Software
3.5.1 Medición del Proceso
La medición del proceso implica medir las actividades relacionadas con el software
siendo algunos de sus atributos típicos el esfuerzo, el costo y los defectos encontrados
[53].
De acuerdo a Pressman en [47] las métricas del proceso de software se utilizan para
propósitos estratégicos. En muchas propuestas, la medición del proceso se realiza
extrayendo las características de tareas específicas de la ingeniería de software y
obteniendo como resultado métricas de: errores detectados antes de la entrega del
software, defectos detectados e informados por los usuarios finales, productos de trabajo
entregados, el esfuerzo humano y tiempo consumido, ajuste con la planificación, etc..
Por esta razón, en la bibliografía, el enfoque de la medición del proceso se ha centrado
en recopilar una serie de métricas de todos los proyectos. Además si esto se realiza
durante un largo período de tiempo, con el objetivo de proporcionar indicadores que
lleven a mejoras de los procesos de software a largo plazo. En este sentido un área clave
de investigación es el control estadístico de procesos [54].
Otro posible enfoque de medición del proceso es a nivel conceptual, como medir la
complejidad u otras características de calidad del modelo de los productos finales
obtenidos. En este aspecto se pueden encontrar algunos estudios para evaluar la
mantenibilidad de los modelos de procesos de software [55].
Métricas de Proceso
Métricas de Proyecto
Métricas de Proyecto
Métricas de Producto
Métricas de Producto
Métricas de Producto
Métricas de Producto
43
3.5.2 Medición del Proyecto
La medición del proyecto y sus recursos asociados constituye el elemento principal
sobre el que se basa el estudio de las métricas del proceso software. Cuando se mide el
proyecto, el objetivo fundamental es reducir el costo total del proyecto y el tiempo de
desarrollo del mismo. Los indicadores de proyecto permiten al administrador de
software [47]:
- Evaluar el estado del proyecto en curso
- Realizar un seguimiento de los riesgos potenciales
- Detectar las áreas de problemas antes de que se convirtieran en “críticas”.
- Ajustar el flujo y las tareas de trabajo
- Evaluar la habilidad del equipo del proyecto en controlar la calidad de los
productos de trabajo relacionados con la integridad de la ingeniería de software.
En relación a las métricas de proceso, las mediciones del proyecto de software son
tácticas. Las métricas de proyectos y los indicadores derivados de ellos son utilizados
por un administrador de proyectos y por un equipo de software para adaptar el flujo de
trabajo del proyecto y las actividades técnicas.
El primer conjunto de métricas de proyectos software pueden ser obtenidas durante la
fase de estimación. Las métricas recopiladas de proyectos anteriores se utilizan como la
base de partir de la cual se realizan las estimaciones del esfuerzo y del tiempo necesario
para el proyecto. A medida que avanza un proyecto, las métricas del esfuerzo y del
tiempo consumido se comparan con las estimaciones originales (y la planificación del
proyecto). El administrador de proyectos utiliza estos datos para supervisar y controlar
el avance. Para la estimación del tamaño del software cabe destacar la métrica de
“Punto Función” [56] mientras que para la estimación de costos de un proyecto caben
destacar los modelos COCOMO (COnstructive COst MOdel) creado por Barry Boehm.
Este modelo surge en 1981 y su posterior refinamiento en la versión actual COCOMO
II.
En la relación a la estimación de proyectos software existen modelos como el de
Putman y Myers [57] en el que se desarrollan una ecuación básica del software como:
Producto= Productividad * Esfuerzo*Tiempo
Donde “Producto” representa la funcionalidad expresada en tamaño, “Esfuerzo” el
esfuerzo total del personal del proyecto para desarrollar el producto, “Tiempo” es la
44
duración del proyecto, y la “Productividad” depende de diversos factores que se pueden
clasificar en factores de producto. Algunos de estos factores son dificultades técnicas en
función de aspectos como restricciones de hardware, complejidad algorítmica,
complejidad lógica, complejidad de gestión, estabilidad de la plataforma.
La anterior ecuación fue posteriormente ajustada en base al análisis de resultados
históricos de una gran base de datos de proyectos, quedando:
Tamaño Producto= Índice de Productividad*Esfuerzoa*Tiempob.
donde a=1/3 y b=4/3, el “tamaño” igual al número de líneas de código fuente (nuevas y
modificadas pero sin considerar espacios en blanco y comentarios), y esfuerzo y tiempo
representan los años de esfuerzo y duración de todas las fases del proyecto.
Otro de los elementos clave a medir a nivel de proyectos son sus recursos, que son entre
otros, el personal implicado, las infraestructuras hardware y software, etc.
Una métrica muy utilizada es la productividad del personal, que se obtiene dividiendo el
tamaño por el esfuerzo. Esto implica dividir una métrica de producto por una métrica de
proceso para obtener una métrica de recurso. En general se considera la productividad
como la división de la salida por la entrada. En ingeniería del software es habitual
indicar la entrada como el esfuerzo en personas mes, y la salida como el número de
líneas de código. Al utilizar líneas de código como métrica de tamaño existen algunas
dificultades sobre todo para comparar distintos proyectos en los que se utilizan otros
lenguajes o entornos de programación.
La métrica anterior sólo mide la productividad del personal durante la implementación.
Autores como Fenton y Pfleeger [53] sugirieron utilizar otras métricas de productividad
ya que la productividad del personal no considera la calidad del código obtenido.
Otros recursos relevantes a considerar son los equipos de trabajo y las herramientas
[53]. La productividad de los miembros del equipo de trabajo depende de muchos
factores, como por ejemplo la estructura del equipo, las herramientas y los métodos
utilizados. Por otro lado también se considera la experiencia como un factor importante
de la productividad, aunque es difícil de medir. También es importante considerar de
forma separada la experiencia de los individuos y la experiencia del equipo, ya que
aunque los integrantes del equipo puedan tener buena experiencia el equipo puede que
no funcione bien y la productividad sea baja.
45
En relación a las herramientas, es importante establecer la relación con otras variables
de proyecto como la eficacia de las herramientas en términos de la calidad obtenida,
tiempo de entrega y la productividad del personal que la utilizó. De hecho los modelos
de estimación consideran el uso de herramientas a la hora de estimar el tamaño o costo
de desarrollo de software.
Tal y como indica Pressman en [47], otras métricas de proyectos pueden ser obtenidas
una vez que comienza el desarrollo del producto propiamente dicho y en este aspecto es
importante realizar un seguimiento de los errores detectados durante todas las tareas de
la ingeniería del software. A medida que el software va evolucionando desde la
especificación al diseño, se recopilan las métricas técnicas para evaluar la calidad del
diseño y para proporcionar indicadores que influirán en el enfoque a seguir para la
generación de código y para las pruebas. El uso de las métricas para los proyectos tienen
dos características fundamentales [58]: se utilizan para minimizar la planificación de
desarrollo guiando los ajustes necesarios que eviten retrasos, atenúen problemas y
riesgos potenciales; y se utilizan para evaluar la calidad de los productos en el momento
actual con el fin de poder mejorarlos.
3.5.3. Medición del Producto
La medición del producto software está centrada en evaluar la calidad de los
entregables. Los productos del software son las salidas del proceso de producción del
software, que incluyen todos los artefactos entregados o documentos que son productos
durante el ciclo de vida del software. En la literatura existe gran diversidad de
propuestas relacionadas con la medición del producto. A continuación se resumen a
modo de ejemplo algunas propuestas representativas de métricas de producto.
3.5.3.1. Métricas de Código fuente
Las métricas de código fuente más importantes son Líneas de Código y Longitud Total.
Líneas de Código (LOC, Lines of Code), es la métrica más popular a nivel de código de
programa. Sin embargo, a pesar de ser ampliamente conocida y utilizada, el problema
de esta métrica es la falta de consenso existente a la hora de definir qué es una línea de
código, ya que esta definición variará en función de las necesidades o de la persona que
lo aplique. Por ejemplo, según el objetivo perseguido por la medición será importante
contar las líneas de comentario como líneas de código mientras que en otras ocasiones
será imprescindible no contar los comentarios como líneas de código. Por ello, para
46
aplicar esta métrica es fundamental establecer claramente qué elementos hay que
considerar como líneas de código y como deben contarse. En particular es necesario
clarificar elementos como las líneas en blanco, los comentarios, las declaraciones de
datos y las líneas que tienen instrucciones separadas. En general se recomienda separar
en la medición de la longitud, las líneas de código y los comentarios [53].
Se define Longitud Total (LT) como la suma del Número de Líneas de Código que no
son Comentarios (NCLC, Not Commented Lines of Code) más el número de líneas de
código que son comentarios (CLOC, Commented Lines of Code).
A partir de las métricas anteriores se pueden definir otras métricas derivadas útiles,
como la densidad de cometarios (CLOC/LOC), que puede dar una idea sobre el punto
hasta el cual está documentado el código.
Para facilitar la obtención e interpretación de la métrica LOC, el SEI (Software
Engineering Institute) ha definido listas de comprobación [59] en las que considera línea
de código a todo código ejecutable, declaraciones no ejecutables y directivas de
compilación, pero no las líneas en blanco. También se debe considerar en la medición la
forma en la que el código ha sido producido (programado, usando generadores de
código fuente, copiando o reutilizando sin realizar cambio, modificado o convertido con
traductores automáticos).
Otras métricas definidas para evaluar la longitud de un programa son:
- Número de sentencias de programación. Presenta el mismo tipo de problema de
ambigüedad de la métrica LOC.
- SIZE Definida como el número de puntos y coma [60]. Se creó intentando
paliar el problema de ambigüedad de definición de las líneas de código.
- Métricas de la Ciencia del Software (Software Science). Propuestas por Halstead
en [61] para intentar independizar las métricas del lenguaje de programación. Se
basan en los tokens (unidades sintácticas elementales distinguibles por el
compilador) y que pueden ser divididos en operadores y operandos. Las métricas
son la longitud de un programa, el volumen de un programa y el esfuerzo de
implementación de un programa.
A partir de métricas base Halstead [61] define una serie de métricas derivadas que
permiten evaluar [47]: la longitud global del programa; el volumen mínimo
potencial para un algoritmo; el volumen real; el nivel del lenguaje; y otras
características tales como esfuerzo de desarrollo, tiempo de desarrollo e incluso el
número esperado de fallos en el software.
47
Fenton y Pflegger en [53] consideran que aunque la propuesta de Halstead [61] ha
tenido un gran impacto en la medición software, constituye un ejemplo de medición
inadecuado. Esto se debe a que al proporcionar algunas métricas con definiciones
confusas lo que puede provocar diversas interpretaciones de las mismas.
3.5.3.2. Métricas de Complejidad
Entre las métricas de complejidad se destacan las siguientes:
- Complejidad Ciclomática (V(G)), propuesta por McCabe en [62], para evaluar la
complejidad de un programa. Esta métrica es, además de la primera métrica
conocida, una de las más estudiadas y utilizadas. La métrica V(G) está basada en
la teoría de grafos y mide el número de caminos linealmente independientes de
un programa, que puede representarse mediante un grafo de flujo de control.
Esta métrica puede calcularse de la siguiente forma:
V(G)=A-N+2
siendo A el número de arcos del grafo y N el número de nodos.
A mayor valor de la métrica V(G) mayor complejidad del programa. McCabe [62]
indicó también que un valor razonable de esta métrica debe ser menos de diez para que
un módulo sea mantenible. Otra de las aplicaciones de esta métrica es a nivel de prueba
de programa ya que indica el esfuerzo necesario para probar un módulo o programa. Las
métricas a nivel de módulo son:
- Fan-in (concentración) y fan-out (expansión). Propuesta por Henry y Kafura en
[63]. Ambas métricas trabajan sobre la estructura de un módulo representada
como un árbol o grafo de llamadas entre módulos. El fan-in de un módulo m es
el número de flujos que terminan en m mientras que el fan-out es el número de
flujos que salen de m.
- Complejidad de un módulo, que está basada en las dos métricas anteriores
creadas también por Henry y Kafura [63] siendo su definición:
MHK=longitud(i) . [fan-in(i) + fan-out(i)]2,
donde la longitud (i) es el número de sentencias en lenguaje de programación en
el módulo i.
48
Henry y Kafura [63] amplían la definición de concentración y expansión no sólo
como el número de conexiones de control del módulo (llamadas al módulo), sino
también el número de estructuras de datos del que el módulo i reúne
(concentración) o actualiza (expansión) datos.
3.5.3.3 Métricas para sistemas OO
El software desarrollado siguiendo el paradigma OO difiere en importante medida del
desarrollo utilizando enfoques tradicionales. Esta característica planteó la necesidad de
definir nuevas métricas adaptadas a las características particulares de este paradigma. A
continuación se presentan algunas propuestas representativas.
- Conjunto de Métricas MOOSE, compuesto por las siguientes seis métricas
propuestas por Chidamber y Keremer [64]:
o Métodos ponderados por clase (WMC, Weigthed Methods per Class),
que mide la complejidad de una clase, basándose en la complejidad de
cada método.
o Profundidad del Árbol de herencia de una Clase, (DIT, Depth of
Inheritance Tree). La métrica DIT mide el máximo nivel en la jerarquía
de herencia. Se trata de la cuenta directa de los niveles de jerarquía de
herencia, considerando que el nivel cero de la jerarquía se encuentra la
clase raíz. DIT se considera como una métrica del número de clases
antecesoras que una clase podría potencialmente afectar, debido a que
cuanto mayor sea el nivel de profundidad de herencia mayor es el
número de métodos y atributos que hereda de otras clases.
o Número de Hijos (NOC, Number of Children). NOC es el número de
subclases subordinadas a una clase en la jerarquía, es decir, la cantidad
de subclases que pertenecen a una clase. Según Chidamber y Kemerer
[64], NOC es un indicador de: el nivel de reutilización, la posibilidad de
haber creado abstracciones erróneas, y el nivel de pruebas requerido.
o Acoplamiento entre Objetos (CBO, Coupling Between Objects). La
métrica CBO indica para una clase el número de otras clases con las que
está acoplada. Se considera que un objeto está acoplado a otro cuando
actúa sobre ese otro objeto, por ejemplo cuando un método de un objeto
utiliza un método de otro objeto. Esta métrica se considera útil para
predecir el esfuerzo necesario para el mantenimiento y las pruebas.
49
Tabla 3.1: Métricas MOOD aplicables a la fase de diseño
o Respuesta de una clase (RFC, Response For a Class). RFC indica el
número de métodos que pueden ser ejecutados potencialmente como
respuesta a un mensaje recibido por un objeto de esa clase. RFC por lo
Nombre Descripción
MHF
El factor de ocultamiento de los métodos (Method Hiding Factor)
mide la proporción entre los métodos definidos como protegidos o
privados. El número total de métodos MHF se propone como una
medida de encapsulación, cantidad relativa de información oculta.
AHF
El factor de ocultamiento de los atributos (Attribute Hiding Factor) se
define como el cociente entre la suma de las invisibilidades de todos
los atributos definidos de todas las clases y el número total de
atributos definidos en el sistema considerado. La invisibilidad de un
atributo es el porcentaje del total de las clases desde las cuales los
atributos son invisibles. AHF se definió como una medida de
encapsulación.
MIF
El factor de herencia de los métodos (Method Inheritance Factor) se
define como el cociente entre la suma de los métodos heredados de las
clases del sistema considerado y el número total de métodos existentes
en todas las clases. MIF se define como una medida de herencia y por
lo tanto como una medida de reutilización en un sistema.
AIF
El factor de herencia de los atributos (Attribute Inheritance Factor) se
define como el cociente entre la suma de los atributos heredados en
todas las clases del sistema considerando y el número total de
atributos existentes en todas las clases. AIF se define como una
medida de herencia y por lo tanto como una medida de reutilización
en un sistema.
PF
El factor de polimorfismo (Poliymorphism Factor) se define como el
cociente entre el número actual de posibles diferentes situaciones de
polimorfismo, y el número máximo de posibles situaciones distintas
de polimorfismo para una clase. PF es una mediad del polimorfismo y
una medida indirecta de la asociación dinámica de un sistema.
50
tanto se calcula contando las ocurrencias de llamadas a otras clases de
una clase particular.
o Falta de cohesión en los métodos (LCOM, Lack of Cohesion in
Methods). LCOM establece en qué medida los métodos hacen referencia
a atributos. Se calcula como el número de pares de funciones sin
variables compartidas de instancia menos el número de pares de
funciones con variables de instancia compartida. LCOM es una métrica
de la cohesión de una clase en base al número de atributos comunes
usados por diferentes métodos. Un valor alto de LCOM implica falta de
cohesión, es decir, escasa similitud entre los métodos siendo siempre
deseable un alto grado de cohesión en lo métodos de una clase.
- Métricas MOOD [65]. El objetivo de las métricas MOOD es medir los
principales mecanismos del paradigma OO, tales como encapsulamiento,
herencia, polimorfismo y paso de mensajes, así como polimorfismo y su
consecuente influencia sobre la calidad del software y la productividad en el
desarrollo. Las métricas MOOD se pueden utilizar en las fases de diseño y se
definieron para ser aplicadas a nivel de clases (ver Tabla 3.1)
- Métricas de Lorenz y Kidd [63] propusieron un conjunto de métricas llamadas
“Métricas de Diseño”, que se refieren a características estáticas del diseño de un
producto software. Estos autores clasificaron las métricas de tamaño, métricas de
herencia y métricas de características internas de las clases. En la tabla 3.2 se
muestran aquellas métricas que pueden ser aplicadas a un diseño de alto nivel.
En resumen, se consideran las relaciones de inclusión y extensión y las
relaciones de control y de dependencia de datos. La intuición aconseja que
cuantas más relaciones haya en el modelo, más difícil será hacer cualquier
cambio. Otro factor que influye en la modificabilidad de los casos de uso es el
tipo de caso de uso. Simplificando la idea, si un caso tiene varios objetivos, es
más susceptible de cambiar que si tiene sólo un objetivo.
51
Tipo Nombre Descripción
PIM El número total de métodos de instancia públicos de
una clase. (Public Instances of Methods)
NIM El número de métodos de instancia es el total de
métodos públicos, privados y protegidos (Number of
Instances od Methods)
NIV El número de variable de instancias públicas, privadas
y protegidas (Number of Instances Variables )
NCM El número de métodos de clase es el número total de
métodos a nivel de una clase.(Number of Class
Methods)
Métricas
de Tamaño
NVV El número de variables de clase es el número total de
variables a nivel de clase de una clase.(Number of
Variables )
NMO El número de métodos sobrecargados totales de una
subclase.(Number of Method Overwritten )
NMI El número de métodos que hereda una clase.(Number
of Methods Inherited)
NMA El número de métodos nuevos que define una
subclase. (Number of Method Added)
Métricas de
Herencia
SIX Índice de especialización de cada clase (Specialization
Index)
Numero de métodos sobreescritos * Nivel de Anidamiento en la Jerarquía
Número total de métodos
Métricas de
características
internas de las
clases
APPM El promedio de parámetros por método(Avarage
Parameters Pass by Methods)
Número Total de Parámetros por Método
Numero Total de Métodos
Tabla 3.2 Métricas de Lorenz y Kidd
- Métricas para UML. En la bibliografía se pueden encontrar diversas propuestas
de métricas para los distintos tipos de diagramas de UML. Algunas de ellas son:
52
o Casos de Uso: pocas métricas se han definido para este diagrama. Se
destaca Marchesi [66] que propuso un conjunto de métricas de
complejidad para diagramas de caso de uso. Dichas métricas contabilizan
el número de casos de uso, el número de actores, y el número de
relaciones de inclusión y extensión.
o Diagramas de Clase UML. Genera et al. [67] definieron un conjunto de
métricas para la complejidad estructural de diagramas de clase de UML
debido al uso de relaciones de UML, tales como asociaciones,
generalizaciones, dependencias y agregaciones (Tabla 3.3). Los autores
suponen que estas métricas pueden ser buenos indicadores de las
características de mantenibilidad de los diagramas de clases de UML.
Bansiya et al. [68] también definieron métricas a nivel de clase para
evaluar propiedades de diseño como el encapsulamiento, el
acoplamiento, la cohesión, la composición y la herencia.
Métricas Definición
Nassoc Es el número total de asociaciones (Number of Associations).
NAgg Es el número total de relaciones de asociación de un diagrama
de clases (Number of Aggregations).
NDep Es el número total de relaciones de dependencia de un
diagrama de clases (Number of Dependences).
NGen Es el número total de relaciones de generalización de un
diagrama de clases (Number of Generalizations).
NAggH Es el número total de jerarquías de agregación dentro de un
diagrama de clases (Number of Aggregations Hierarchies).
NGenH Es el número total de jerarquías de herencias dentro de un
diagrama de clases (Number of Generalizations Hierarchies).
MaxDIT Es el camino más largo en el árbol de herencia desde una clase
hasta la raíz de la jerarquía para cada clase (Max Deepness of
Inheritance Tree).
MaxHagg Es el camino más largo en una jerarquía de agregación desde
una clase hasta la raíz para cada clase (Max Hierarchy
Aggregation).
Tabla 3.3 Métricas para complejidad estructural de diagramas de clase UML
53
o Diagramas de Estados. Derr en [69] definió el número de estados y el
número de transiciones como métricas que miden la complejidad de los
diagramas de estados OMT (aunque también se pueden aplicar a UML).
Miranda en [70] propone, con la hipótesis de que el tamaño y la
complejidad estructural de los diagramas de estados de UML puede
influenciar su facilidad de entendimiento (y por tanto mantenibilidad),
definió un conjunto de métricas para la complejidad estructural y el
tamaño de los diagramas de estados de UML.
o Expresiones OCL (Object Constraint Language). La propuesta de
Reynoso [71] toma como hipótesis que las propiedades estructurales de
una expresión OCL tienen un importante impacto en la propiedad
cognitiva de los modeladores. Aunque las expresiones OCL pueden
añadirse a cualquier diagrama de UML, Reynoso et al. [71] definieron
métricas para expresiones OCL que puedan usarse en un diagrama de
clases de UML. Un ejemplo de éstas son las métricas relacionadas con el
“tracing” como el Número de Relaciones Navegadas (NNR, Number of
Navigable Relationships), que cuenta el número total de relaciones que
se navegan en una relación.
3.6 Herramientas de medición de software
El desarrollo de un marco efectivo para la medición requiere un soporte metodológico,
pero también es muy importante el aspecto tecnológico [72]. Es decir, para que las
métricas puedan ser evaluadas de un modo práctico, eficiente y exacto es necesario
contar con las herramientas que permitan automatizar la adquisición, la presentación y
el análisis de los valores de las métricas [73]. Las ventajas de contar con una
herramienta que permita automatizar tanto la adquisición y la presentación como el
análisis de los valores de las métricas son [72]:
- Posibilitar la obtención de los valores de las métricas sin mayor esfuerzo.
- Minimizar los errores en el cálculo de las métricas, logrando una mayor
exactitud en sus valores.
- Permitir centrarse en el análisis de los resultados de la medición y no en la etapa
de adquisición.
54
Una herramienta de métricas de software puede definirse como una herramienta
para el modelado y el cálculo de componentes de desarrollo de software, bien sean
del proceso, del producto o de los recursos.
El proceso de desarrollo de software también incluye la preparación de los
componentes del software a la medición y del proceso de evaluación. Entonces, es
necesario contar con herramientas que den soporte a la medición de software como
un grupo dentro del conjunto de métricas. Son las denominadas CAME (Computer
Assisted Software Measurement and Evaluation), es decir, Herramientas para la
Medición y Evaluación de Software Asistidas por Computador.
Giles y Daich [73] distinguen las tres principales tareas que deben realizar las
herramientas de métricas y las características necesarias que deben implementar
para que dichas tareas se puedan llevar a cabo:
- Adquisición de datos: manual, semiautomática, automática y programable
- Análisis de las mediciones: almacenamiento de los datos, recuperación de
los datos, análisis aritmético y análisis estadístico.
- Presentación de los datos: tablas, gráficos, posibilidad de exportar archivos a
otras aplicaciones.
3.7 Importancia de las métricas en el proceso
Las métricas de proceso de software se emplean para fines estratégicos, y las métricas
del proyecto de software son tácticas. Éstas últimas van a permitir proporcionar al
desarrollador de proyectos de software una evaluación al proyecto que sigue en
continuo desarrollo. Además, podrá ver los defectos que logren provocar riesgos a largo
plazo (áreas de problema); y observar si el área de trabajo (equipo) y las distintas tareas
se ajustarán.
Existe una preocupación en la unificación de las métricas dentro del proceso del
software, dado que los desarrolladores de software no tienen la cultura de la medición.
Es por eso que el uso de métricas demanda un cambio cultural, tanto en el recopilado de
datos (investigación histórica), como en el cálculo de métricas (LDC, PF, métricas de
calidad, orientadas a objetos y orientada a aspectos) y también en la evaluación
(resultados obtenidos) para adquirir una visión más profunda de lo que se está
elaborando.
Las métricas de software aportan una manera de estimar la calidad de los atributos
internos del producto, permitiendo al ingeniero de software valorar la calidad antes de
55
construir el producto, el tiempo invertido será identificando, examinando y
administrando el riesgo. Este esfuerzo merece la pena por muchas razones ya que habrá
disminución de problemas durante el proyecto, asimismo se podrá desarrollar una
habilidad de seguir y controlar el proyecto y se alcanzará la seguridad que da planificar
los problemas antes de que ocurran. Además se conseguirá absorber una cantidad
significativa del esfuerzo en la planificación del proyecto.
Del mismo modo existen diferentes tipos de métricas para poder evaluar, mejorar y
clasificar al software desde sus inicios hasta el producto final.
56
Capítulo 4
Metamodelo de UML 2.3
4.1 Introducción
Para la descripción de un modelo, es necesario tener un lenguaje con una sintaxis y
semántica precisa. Un lenguaje de modelado, permite elaborar los modelos requeridos
en el diseño de un sistema. UML (Unified Modelling Language) es uno de los lenguajes
de modelado más conocidos y utilizados en la actualidad.
En 1997 la OMG (Object Management Group), presenta la primera versión de UML
como lenguaje de modelado estándar. A partir de allí, la OMG realiza numerosas
versiones, hasta llegar a la versión 2.3, vigente en la actualidad.
La versión UML 2.3 se presenta a través de dos documentos que se complementan entre
sí, una “Superstructure” (superestructura) [74] y una “Infraestructure” (infraestructura)
[75]. La primera define los constructores a nivel de usuario y la segunda los
fundamentos de los constructores del lenguaje.
En este capítulo se detalla la Infraestuctura de UML 2.3, la cual define el lenguaje, sin
detallar los usos de UML como lenguaje de modelado. Esto se debe a que en esta tesis
de maestría se utiliza una extensión del metamodelo de UML para la definición de las
métricas, así como se utiliza OCL (Object Constraint Language) [76] para la definición
de restricciones y métricas para sistemas orientados a aspectos.
4.2 Arquitectura del lenguaje
La especificación de UML se realiza usando un metamodelado (un metamodelo se
utiliza para especificar un modelo que represente UML) que se adapte a las técnicas
formales de especificación. Aunque este acercamiento carece del rigor formal de un
método de especificación, ofrece las ventajas de ser más intuitivo y pragmático para la
mayoría de los implementadores y prácticos.
4.2.1 Niveles de Modelado
La especificación de UML se define a través de un enfoque de metamodelado. Cuando
se utiliza meta-niveles para definir lenguajes, generalmente siempre se tiene en cuenta
un lenguaje de especificación (o metalenguaje), especificación de usuario (o modelo), y
objetos del modelo. En particular, la arquitectura UML se divide de cuatro niveles
57
conceptuales. En la figura 4.1 se muestra un ejemplo que ayuda a explicar los niveles de
modelado.
Nivel 3 (M3): El nivel de meta-metamodelado es la base en la jerarquía de
metamodelado. En este nivel se definen lenguajes para especificar metamodelos.
Es conveniente que tanto el meta-metamodelo y el metamodelo compartan
constructores comunes. Sin embargo, ambos niveles mantienen independencia
en cuanto al diseño. MOF (Meta-Object Facility) es considerado como un
ejemplo de lenguajes dentro de este nivel. Dicho lenguaje se define por la OMG
con el fin de establecer constructores y mecanismos para describir metamodelos.
Nivel 2 (M2): El metamodelo es una instancia del meta-metamodelo. Su función
es la de definir un lenguaje para especificar modelos. UML, es un ejemplo de un
lenguaje que se encuentra en este nivel. La semántica de UML se describe a
través de su meta-modelo, que, a su vez, se expresa en MOF. Dado que la
semántica de UML se define en esta etapa, todas las extensiones al modelo
deben hacerse en este nivel. La especificación de UML se lleva a cabo de
manera recursiva; es decir, utilizando un subconjunto de su sintaxis y semántica.
Nivel 1 (M1): Un modelo es una instancia de un metamodelo. En este nivel, el
usuario de un lenguaje, describe la semántica de un dominio particular. Los
conceptos definidos en M1 especifican la clasificación para los elementos de M0
(por ejemplo, el concepto “Video” y su atributo “title”).
Nivel 0 (M0): Los elementos de este nivel son instancias de un modelo
particular, de un sistema real. Se describe información del dominio, los
elementos concretos. Por ejemplo, el video “Avatar” es una instancia de la clase
Video.
Existen tres categorías de elementos dentro de un modelo: clasificadores,
eventos y comportamientos. Los clasificadores establecen un conjunto de
objetos relacionados, cada uno de ellos en un estado determinado. Un evento
describe un conjunto de posibles ocurrencias, cada ocurrencia produce una
consecuencia dentro del sistema. Finalmente, el comportamiento representa un
conjunto de posibles ejecuciones de algún algoritmo.
58
Figura 4.1- Ejemplo de la jerarquía de metamodelos
UML tiene una arquitectura estructurada en capas y a su vez está organizada en
paquetes. Los elementos del modelo, son definidos por medio de una sintaxis abstracta,
reglas bien formadas y la semántica.
- Sintaxis Abstracta: Se utilizan diagramas de clases para presentar el
metamodelo. El metamodelo se compone de metaclases, relaciones y
restricciones, cuyas definiciones también se incluyen.
- Reglas bien formadas: Se especifican reglas y restricciones sobre modelos
válidos. Se puede utilizar el lenguaje natural o el lenguaje formal OCL (ver
4.2.5).
- Semántica: La semántica del modelo se describe en lenguaje natural.
4.2.2 Infraestructura
La infraestructura de UML se establece a través de una librería (Figura 4.2) [75]. Esta
librería define el núcleo del metalenguaje (“metalanguage core”) que puede ser
59
reutilizado para definir metamodelos (incluidos UML y MOF). Intenta alinear UML,
MOF y XMI para poder soportar el intercambio entre modelos. También permite
personalizar UML por medio de los “Perfiles UML”.
El paquete Core es un metamodelo particularmente diseñado para tener alta
reusabilidad. Otros metamodelos tales como, MOF, CWM (Common Warehouse
Metamodel), pueden importar o especializar sus metaclases. En la figura 4.3 se muestra
como UML, CWM y MOF depende de un mismo Core. La reutilización de dicho
paquete permite que otros metamodelos se beneficien de una sintaxis abstracta y una
semántica ya definida.
Figura 4.2 - Infraestructura UML
Para facilitar la reutilización, el núcleo es dividido en subpaquetes, ellos son:
PrimitiveTypes, Abstractions, Basic y Constructs. En las figura 4.4, se muestra la
relación entre estos elementos [75].
Figura 4.3 Reutilización de “Core”
60
PrimitiveTypes contiene un conjunto de tipos predefinidos. Abstractions está compuesta
de metaclases abstractas para que sean utilizarlas en diferentes metamodelos y
Constructs agrupa a las metaclases concretas. Finalmente Basic representa a algunos
constructores usados como base para producir metamodelos basados en la
Infraestrucure Library (como UML y MOF).
Figura 4.4 Núcleo
Como puede observarse, existen una serie de principios sobre el que se guía el diseño
del metamodelo. Ellos son: la modularidad, la separación en niveles, el particionado, la
extensibilidad y el reuso. A continuación se describen brevemente cada uno de ellos.
- Modularidad: Los constructores se agrupan en paquetes y las características
en metaclases.
- Separación en niveles: Por un lado, la estructura paquete se separa en dos
niveles: los constructores del núcleo (en inglés, core) del metalenguaje y los
constructores que ellos usan. Por otro lado, se definen cuatro niveles de
abstracción del metamodelo.
- Particionado: Las áreas conceptuales se organizan dentro de un mismo
nivel. En el metamodelo, el particionado contiene muchas partes
superficiales permitiendo incrementar la cohesión dentro de los paquetes.
- Extensibilidad: Se definen nuevos elementos UML para plataformas o
dominios particulares. O se define un nuevo lenguaje relacionado a UML,
reutilizando parte del lenguaje y aumentando con metaclases y
metarelaciones.
61
- Reuso: Se provee una librería de metamodelo flexible. La misma es
reutilizada para definir el metamodelo UML. También para otros
metamodelos relacionados al de UML, como los son MOF y CWM.
Como se dijo en secciones anteriores UML permite realizar extensiones para modelar
diferentes dominios. En particular, se profundiza sobre la extensibilidad de UML
presentando el concepto de “Perfiles UML”. Dicho mecanismo permite extender UML
sin la necesidad de definir un nuevo lenguaje, utilizando MOF.
En esta tesis de maestría se utilizan los perfiles UML para poder modelar sistemas
orientados a aspectos.
4.2.3 Modelos Estáticos
En esta sección se realiza una breve explicación del metamodelo de UML (Nivel 2 de la
arquitectura) en particular las metaclases correspondientes a los diagramas de clases de
UML (Figuras 4.5, 4.6). Esto se debe a que el paquete Class, que corresponde al
modelado estático de UML, es utilizado en este trabajo de tesis.
Descripción de Metaclases
La descripción de las metaclases se realiza de la siguiente manera: breve descripción,
atributos que contiene, asociaciones en las que la metaclase es origen o destino,
restricciones más relevantes si las hubiere.
Class (Clase) describe un conjunto de objetos que comparten las mismas características
de especificación, restricciones y semántica. Una clase es un tipo de clasificador cuyas
características son atributos y operaciones. Los atributos de una clase se representan
como instancias de Property que posee la clase. Algunos de estos atributos pueden
representar los extremos de asociación de una relación binaria.
Atributos: no posee atributos adicionales
Asociaciones:
nestedClassifier: Classifier Element[*]1 hace referencia a todos los
Classifier que están definidos anidados en la clase.
ownedAttribute: Property[*] son los atributos que posee la clase.
ownedOperation: Operation [*] son las operaciones que posee la clase.
1 El valor especificado entre [] representa la cardinalidad, ej. * (cero o más), 1..* (uno o más), [n] n >0
62
/superClass: Class[*]: esta da las superclases de la clase. Es derivada
Restricciones: no posee restricciones adicionales
Association (Asociación) describe un conjunto de tuplas cuyos valores referencia a la
instancia tipada. Una instancia de una asociación se denomina enlace (link). Un enlace
es una tupla con un valor para cada extremo de asociación, donde cada valor es una
instancia de tipo del final de asociación. Es una especificación de la metaclase
Relationship y Classifier. Una asociación representa la relación semántica que ocurre
entre dos instancias tipadas. Tiene al menos dos extremos representados por
propiedades, cada una de las cuales está conectada al tipo del extremo de asociación.
Atributos
isderived: Boolean especifica si la asociación es derivada de un modelo
de elementos como asociaciones o restricciones.
Asociaciones
memberEnd: Property[*] cada extremo de asociación representa la
participación de la instancia de los clasificadores conectados en el enlace.
ownedEnd: Property[*] los extremos que posee la asociación en sí.
navigableOwnedEnd: Property[*] el extremo navegable que posee la
asociación.
Operation (Operación) es una característica de comportamiento de un clasificador que
especifica el nombre, tipo, parámetros y restricciones para invocar el comportamiento
asociado. Es una especificación de Behavioral Feature.
Atributos
/isOrdered: Boolean indica si los parámetros están ordenados.
/isQuery: Boolean indica si el estado del sistema no cambia luego de la
ejecución del comportamiento
/lower: Integer[0..1] indica la multiplicidad inferior de parámetros
necesarios.
/upper: UnlimitedNatural[0..1] indica la multiplicidad superior del
parámetro de retorno.
Asociaciones
Class: Class[0..1] la clase que posee la operación
63
ownedParameter: Parameter[*] los parámetros que posee la operación
/type: Type[0..1] especifica el tipo de retorno de la operación
redefinedOperation: Operation[*] indica la operación que es redefinida
por ésta.
Figura 4.5 Class Diagrams
Dependency (Dependencia) es una relación que significa que un elemento o un conjunto
de elementos del modelo requieren otros elementos del modelo para su especificación o
implementación. Esto significa que la semántica del elemento dependiente se completa
con la semántica del elemento prestador (supplier).
Atributos: no posee atributos adicionales.
Asociaciones:
client: NamedElement[1..*]. El/los elemento/s dependiente/s del o los
elementos prestadores (supplier). Se puede asignar una dirección a la
relación, la cual queda a discreción del modelador.
64
supplier: NamedElement[1..*] son los elemntos independientes del electo
cliente.
Restricciones: no posee restricciones adicionales
Realization (Realización) es una abstracción de Dependency. Una realización es una
abstracción de una relación entre dos conjuntos de elementos del modelo. Uno
representa una especificación (supplier) y el otro representa una implementación del
anterior (client). La realización se puede utilizar para modelar pasos de refinamiento,
optimizaciones, transformaciones, composiciones, etc.
Atributos: no posee atributos adicionales
Asociaciones: no posee asociaciones adicionales
Restricciones: no posee restricciones adicionales
Property (Propiedad) es una característica estructural. Property representa un estado de
una o más instancias de una relación de un valor o valores. Cuando una propiedad es un
atributo de un clasificador, el valor o valores relacionados están asociados a una
instancia del clasificador que contiene los valores actuales. Si la propiedad es un
extremo de asociación, el valor o valores relacionado/s a la instancia/s representan el fin
de la asociación.
Atributos:
aggregation: AggreationKind[1] especifica el tipo de agregación que se
aplica a Property.
/isComposite: Boolean[1] indica si la agregación es una composición. Es
derivada.
isReadOnly: Boolean[1] si es verdadero indica que el atributo es de solo
lectura.
Asociaciones:
association: Association[0..1] hace a la asociación de la cual es miembro.
owingAssociation: Association [0..1] referencia la asociación que posee
la propiedad.
redefinedProperty: Property[*] indica las propiedades redefinidas por
ésta.
associationEnd: Porperty[0..1] designa el extremo de asociación opcional
que posee el atributo.
65
class: Class[0..1] hace referencia a la clase a la cual pertenece la
propiedad.
Figura 4.6 Dependencies
4.2.4 Mecanismos de extensión de UML
En repetidas ocasiones, UML no es lo suficientemente expresivo para representar
conceptos de dominios específicos. Por esta razón, UML estándar incluyó un
mecanismo para extender y adaptar UML a diferentes dominios y plataformas: el “Perfil
UML”.
El mecanismo de extensión basado en perfiles, no permite modificar el metamodelo
existente, sino adaptarse al metamodelo existente, agregando constructores propios para
un dominio particular.
El origen de este mecanismo se remonta a la versión UML 1.1. En ese momento se
definieron los conceptos de “estereotipos” y “valores etiquetados” como elementos
básicos de extensión. La intención inicial era proveer un conjunto de características que
permitiese añadir información a los elementos del modelo de una manera sencilla y
flexible.
66
Las versiones siguientes procuraron otorgar cada vez mayor precisión en su definición.
Pero UML 2.0 es el que muestra mayores avances en este sentido, proveyendo una
técnica de metamodelado sólida y consistente. Los estereotipos son especificados como
metaclases, los valores etiquetados como metaatributos y los perfiles como una clase de
paquete.
El mecanismo de extensión del metamodelo impone restricciones en cómo el
metamodelo UML puede ser modificado. No está permitido insertar nuevas metaclases,
o modificar definiciones de la metaclase (agregando metaasociaciones).
Las características presentes a partir de UML 2.0 hacen que sea posible especializar la
semántica de elementos del metamodelo de UML estándar. También brinda una
convención de notación para definiciones de estereotipos gráficos.
Han sido creados numerosos perfiles para los más variados dominios. Por ejemplo, se
han definido perfiles para “Testing”, “Java y especificaciones EJB”, “Tiempo Real”,
“Agentes inteligentes”, “Tolerancia a las fallas”; entre otros.
4.2.4.1 Ventajas
Algunas de las ventajas que genera el uso de perfiles son:
- Definir un nuevo vocabulario para un dominio o plataforma específica (para
Tiempo Real, Enterprise Java Beans –EJB-, etc.).
- Dar una sintaxis para constructores que no tienen notación.
- Definir una notación particular para elementos ya existentes, de acuerdo al
dominio donde dichos elementos se encuentran.
- Agregar semántica a elementos del metamodelo que tienen un significado
impreciso.
- Agregar nueva semántica al metamodelo.
- Agregar restricciones que especifiquen la forma en que el metamodelo y sus
constructores puedan ser usados.
- La posibilidad de agregar información en los modelos puede ser usada para
transformarlos en código.
4.2.4.2 Elementos
El perfil UML incluye los elementos necesarios para hacer posible la extensión del
lenguaje. Ellos son: los estereotipos (stereotypes), los valores etiquetados (tags values) y
las restricciones (constrains).
67
Un estereotipo permite extender el vocabulario UML. Durante su definición, se lleva a
cabo su asociación con elementos del metamodelo (clase, operación, etc.). Dentro de los
modelos el estereotipo es denotado de la siguiente manera “<<stereotype-name>>”.
Los valores etiquetados están cercanamente relacionados a los estereotipos, dado que
son sus atributos asociados. La forma de expresarlos es a través de {name=value}.
Las restricciones permiten agregar semántica tanto a los elementos del modelo como a
los del metamodelo. Este último caso, es llevado cabo cuando se le añaden restricciones
a los estereotipos. Si esto sucede, debe cumplirse que los modelos que utilicen dichos
estereotipos, conformen las restricciones impuestas para él.
En muchas ocasiones, el lenguaje natural es usado para definir restricciones. Sin
embargo, OCL [76] es una mejor alternativa, debido a su precisión y consistencia.
Un ejemplo se muestra en la figura 4.7 para ilustrar los conceptos antes descriptos. En
esta figura se muestra el Perfil de Enterprise Java Beans (EJB) (En el ejemplo se
muestra cómo definir estereotipos, valores etiquetados y restricciones).
La forma de especificar un estereotipo es asociando su nombre con elementos del
metamodelo. Por ejemplo, el estereotipo JAR es asociado con el metaelemento Artifact;
Remote y Home con Interface, y el estereotipo abstracto Bean con Component (una
instancia de clases concretas Entity o Session debe ser asociado a cada instancia de
Component). Un ejemplo de valor etiquetado es state, el cual es asociado a Session.
Además existen dos restricciones, una relacionada a Component y otra a Bean, ambas
en lenguaje natural, OCL no es utilizado.
68
Figura 4.7 - Perfil EJB
Es importante recordar que MOF construye expresiones equivalentes a las extensiones.
Lo hace a través de una agregación desde la metaclase extendida al estereotipo, también
es posible navegar desde el estereotipo a la metaclase extendida. Los nombres de rol son
provistos usando las siguientes reglas:
- El nombre de rol de la metaclase extendida es:
‘base$’ extendedMetaclassName.
- El nombre de rol del estereotipo es:
‘extension$’ stereotypeName
4.2.5 OCL: Descripción y ventajas de su uso
Tal como se mencionó anteriormente, las restricciones son frecuentemente descriptas a
través del lenguaje natural, pero esto resulta en ambigüedades. OCL es un lenguaje de
modelado formal para la especificación de restricciones no ambiguas [76].
Una de sus principales características es su amigabilidad, no es necesario tener excesivo
conocimiento previo en matemáticas para entender sus especificaciones y son fáciles de
69
leer y escribir. La utilidad de OCL se manifiesta en la diversidad de propósitos para los
cuales puede ser aplicado, algunos usos son:
- Como lenguaje de consultas
- Para especificar invariantes sobre clases y tipos en los modelos de clases.
- Para especificar invariantes de tipos para estereotipos.
- Para describir pre y post condiciones sobre operaciones y métodos.
- Para describir guardas.
- Para especificar objetivos (o conjuntos) para mensajes y acciones.
- Para especificar restricciones sobre operaciones.
- Para especificar reglas de derivación de atributos para cualquier expresión
sobre un modelo UML.
OCL es un lenguaje tipado, cada expresión tiene un tipo. Por ejemplo, no se puede
comparar un Integer con un String. Los tipos pueden ser cualquier clase de
clasificadores dentro de UML.
Cabe destacar que no es un lenguaje de programación, por lo que no es posible escribir
lógica de programas o flujos de control. Tampoco es válido pensar que la especificación
pueda ser directamente ejecutable.
El mismo OCL es utilizado para definir la semántica de UML, especificando reglas bien
formadas sobre el metamodelo. Las reglas bien formadas son definidas como
invariantes sobre las metaclases en la sintaxis abstracta. También es usado para definir
operaciones adicionales, cuando las reglas bien formadas las precisan.
En las expresiones OCL, la palabra clave “context” introduce el contexto para una
expresión. Las palabras claves “inv”, “pre” y “post” denotan respectivamente a los
estereotipos «invariant», «precondition», y «postcondition». Se muestra a continuación
un ejemplo (todos las especificaciones OCL que se presentan fueron extraídas de [76])
el cual indica cómo se especificaría una restricción para TypeName.
context TypeName inv:
'una expresión OCL con el estereotipo <<invariant>> en el
contexto de TypeName' = 'restricción'
Las expresiones OCL pueden ser usadas para especificar invariantes, precondiciones y
postcondiciones. Una invariante es asociada con un tipo, la expresión es verdadera si
todas las instancias del tipo cumplen con la restricción. Una operación OCL es
especificada en el contexto de una instancia de un tipo específico. La palabra reservada
“self” es usada para referenciar una instancia contextual.
70
La siguiente invariante específica que el número de empleados de una compañía debe
exceder a 50.
context Company inv:
self.numberOfEmployees > 50
Una expresión OCL también puede ser parte de una precondición o poscondición.
Normalmente, este tipo de restricciones están relacionadas a una característica de
comportamiento o a una operación. La forma de definirlas es como se sigue.
context Typename::operationName(param1 : Type1,
.. ): ReturnType
pre : param1 > ...
post: result = ...
Antes de especificar el contexto de una invariante, precondición o poscondición; es
posible mostrar el paquete al cual pertenece el clasificador. Esto se logra utilizando la
palabra clave “package”. La sintaxis se muestra a continuación.
package Package::SubPackage
context X inv:
... some invariant ...
context X::operationName(..)
pre: ... some precondition ...
endpackage
Un archivo OCL puede contener varias sentencias de paquete. De esta forma,
invariantes, precondiciones y poscondiciones se agrupan en un único archivo. Dicho
archivo puede coexistir con modelos UML como una entidad separada.
Dentro del contexto de los perfiles, cuando las restricciones son agregadas sobre los
estereotipos, los nombres de rol son usados también para navegar en las restricciones
OCL. Por ejemplo, la siguiente expresión establece que la interfaz Home (ver figura
4.7) no tiene atributos:
self.baseInterface.ownedAttributes->size() = 0
Una expresión OCL puede ser utilizada para indicar un valor inicial o un valor derivado
de un atributo o final de asociación. Las expresiones iniciales y derivadas pueden ser
combinadas, tal como se muestra en el siguiente ejemplo:
context Person::income : Integer
init: parents.income->sum() * 1% -- pocket
allowance
71
derive: if underAge
then parents.income->sum() * 1% -- pocket
allowance
else job.salary -- income from regular job
endif
4.2.5.1 Tipos básicos
OCL tiene un conjunto de tipos básicos predefinidos. Para cada uno de estos tipos,
existen también un conjunto de operaciones predefinidas. En la tabla 4.1 y 4.2 se
exponen algunas de las más importantes [76].
OCL tiene también otros tipos predefinidos. Estos tipos básicos son Collection, Set,
Bag, Sequence y Tuple. Sus operaciones predefinidas se encuentran definidas en [76].
Finalmente, es importante aclarar que cada expresión OCL se escribe en el contexto de
un modelo UML. Esto significa que todos los clasificadores de un modelo (tipos, clases,
interfaces, asociaciones) son tipos en las expresiones OCL.
4.2.5.2 Objetos y propiedades
Las expresiones OCL pueden referirse a clasificadores, atributos, fin de asociaciones,
métodos y operaciones (o métodos) de modelos UML. En un diagrama de clases, los
atributos, asociaciones finales, y operaciones (libre de efectos colaterales) son
propiedades dentro de las expresiones OCL.
Tipos predefinidos Operaciones
Integer *, +, -, /, abs()
Real *, +, -, /, floor()
Boolean and, or, xor, not, implies, if-then-else
String concat(), size(), substring()
Tabla 4.2 Operaciones predefinidas
Tipos predefinidos Ejemplos
Boolean true, false
Integer 1, -5, 0
Real 1.5, 7.2
String ‘hola’
Tabla 4.1 Tipos básicos
72
Cabe mencionar que self hace referencia a un objeto, y “self.propiedad” se relaciona al
valor de una propiedad para self. En el siguiente ejemplo, se muestra cómo el valor de
una propiedad para un objeto se expresa a través de OCL.
context Person inv:
self.isMarried
La forma de especificar el valor de un atributo en OCL, también se muestra con un
ejemplo. En este caso, la expresión “self.age” especifica el valor del atributo age para
una instancia de Person. Dicha expresión es expuesta en forma seguida.
context Person inv:
self.age > 0
A partir de un objeto específico, es posible navegar una asociación de un diagrama de
clases para alcanzar a otros objetos. Esto se logra a partir de las asociaciones finales de
una asociación (role name), tal como se muestra a continuación:
object.associationEndName
El valor de la expresión previa es el conjunto de objetos que están en el otro extremo de
associationEndName. Si la multiplicidad en el final de la asociación es 1, el resultado
de la expresión es un objeto. Pero si la multiplicidad es “*”, el resultado es un conjunto.
context Company
inv: self.manager.isUnemployed = false
inv: self.employee->notEmpty()
En el ejemplo que se encuentra el la parte superior, “self.manager” devuelve una
instancia (un objeto) de la clase persona ya que la multiplicidad del fin de asociación es
uno. En cambio, “self.employee” devuelve un conjunto, dado que la multiplicidad del
fin de asociación es superior a uno.
Por defecto, la navegación a través de una asociación resulta en un conjunto. Pero si la
asociación esta adornada con “{ordened}”, entonces resulta en un conjunto ordenado
(OrdenedSet).
Los tipos Set, OrdenedSet, Bag y Sequence tienen como supertipo común a Collect.
Todos los tipos predefinidos de OCL, tienen asociadas operaciones predefinidas. Una
propiedad de Collect se accede por medio del símbolo “->”, seguido del nombre de la
propiedad; por ejemplo:
context Person inv
self.employer->size() < 3
73
Figura 4.8 - Uso de operador “oclAsType()”
Cuando las propiedades se redefinen para un tipo, la propiedad de los supertipos pueden
ser accedidas usando la operación oclAsType(). En la figura 4.8 la clase ModelElement
tiene dos subclases Note y Dependency. Si se desea acceder al atributo source, desde el
contexto Dependency (el cual hereda de ModelElement), pueden surgir ambigüedades
que sólo son resueltas a través del uso del operador oclAsType(). Esto queda explícito en
la siguiente restricción:
context Dependency
inv: self.oclAsType(Dependency).source
->isEmpty()
inv: self.oclAsType(ModelElement).source
->isEmpty()
Existen otras operaciones predefinidas que resultan de utilidad. Dos de las más
importantes son oclIsType y oclIsKindOf, cuya sintaxis se muestra a continuación:
oclIsTypeOf(t : OclType):Boolean
soclIsKindOf(t : OclType):Boolean
La operación oclIsTyeOf devuelve true si el tipo de objeto representado por self y “t” es
el mismo; y oclIsKindOf devuelve true si el tipo es el mismo o es un supertipo. A
continuación, se ejemplifica la utilización de la primera de dichas operaciones.
context Person
inv: self.oclIsTypeOf( Person ) -- is true
inv: self.oclIsTypeOf( Company) -- is false
74
4.2.5.3 OCL y el metamodelo UML
Las referencias hechas a las metaclases del metamodelo UML son utilizadas en la
definición de la sintaxis abstracta de OCL. Estas referencias necesitan ser alineadas con
el metamodelo de UML.
La infraestructura de UML 2.3 y el núcleo de MOF 2.3, se desarrollaron en paralelo con
OCL 2.2. La especificación de OCL se define basándose en el núcleo de UML y MOF.
Esto permite que el subconjunto de OCL pueda ser utilizado tanto por UML como por
MOF.
Las herramientas CASE que manipulen a OCL, UML y MOF, deben tener en cuenta
algunos puntos para lograr compatibilidad. Algunas de ellas son la compatibilidad de
sintaxis y de XMI (XML Metadata Interchange) [76].
Compatibilidad en la sintaxis se refiere a que la herramienta puede leer y escribir
expresiones OCL de acuerdo con la gramática. Esto incluye la validación, teniendo en
cuenta la compatibilidad de sus tipos y la de las reglas bien formadas. Por otro lado, la
compatibilidad XMI, se relaciona al hecho de que la herramienta intercambia
expresiones OCL utilizando XMI.
4.2.6 Sintaxis Abstracta de Perfil UML
Se describe a continuación la sintaxis abstracta. Las clases del paquete Profile se
muestran a través de un diagrama de clases (ver figura 4.9).
Descripción de metaclases
Dentro de la especificación de la sintaxis abstracta, se describen las metaclases
principales con sus respectivas restricciones y operaciones adicionales. Se muestran
algunas de las restricciones y de las operaciones.
Class (Clase) se relaciona con un subtipo de asociación. Esto indica como ésta puede
ser extendida a través de uno o más estereotipos. Pero un estereotipo no puede ser
extendido por otros estereotipos.
75
Figura 4.9 - Elementos definidos en el paquete Profile
Asociaciones
• / extension: Extension [*]
Hace referencia a las extensiones que especifican propiedades adicionales
de la metaclase. La propiedad es derivada desde las extensiones. Donde el
valor entre [] representa la cardinalidad.
Extension (Extension) es una clase de asociación. Se utiliza para indicar que las
propiedades de una metaclase son extendidas a través de un estereotipo. Brinda la
capacidad para flexibilizar la agregación y el borrado de estereotipos. El elemento
Extension no existe en versiones anteriores a UML 2.0. Las ocurrencias de
“Stereotype::baseClass” en UML 1.4 son en UML 2.0 una instancia de Extension.
Atributos
• / isRequired: Boolean
Indica si debe crearse una instancia del estereotipo extendido cuando una
instancia de la clase extendida es creada. El valor por defecto de isRequired es
false. El atributo es derivado de la multiplicidad de Extension::ownedEnd; una
multiplicidad de 1 significa que isRequired es true, de otra forma es false. La
multiplicidad por defecto de un ExtensionEnd es 0..1.
Asociaciones
• ownedEnd: ExtensionEnd [1]
76
Hace referencia el lado final de la extensión que es tipado por un
estereotipo, redefine a Association::ownedEnd.
• / metaclass: Class [1]
Referencia a la clase que es extendida. La propiedad es derivada desde el
tipo de memberEnd que no es el ownedEnd.
Restricciones
Si una extensión no tiene owned end entonces es tipada por una
clase.
metaclassEnd()->notEmpty() and
metaclass()->oclIsKindOf(Class)
Una extensión es binaria (tiene sólo dos memberEnds).
memberEnd->size() = 2
ExtensionEnd (final de extensión) es una clase de Property utilizada para asociar una
extensión a un estereotipo, cuando se extiende una metaclase. Sólo puede se accedida a
través de Extension. No es posible agregar propiedades a un clasificador extendido (no
esta permitido cambiar un elemento del metamodelo, únicamente agregar nuevas
propiedades).
Asociaciones
• type: Stereotype [1]
Hace referencia al tipo de la extensión final. Restringe sus posibles tipos
sólo a Stereotype, redefine Property::type
Restricciones
- ExtensionEnd tiene multiplicidad 0..1 o 1.
(self->lowerBound() = 0 or self->lowerBound() = 1)
and self->upperBound() = 1
- El destino de la relación de agregación que termina en
ExtensionEnd es una composición.
self.aggregation = #composite
Package (paquete) un paquete puede tener uno o más ProfileApplications para indicar
cuáles son los perfiles que se aplican. Dado que un perfil es un paquete, es posible
aplicar un perfil no sólo a un paquete sino también a perfiles.
Asociaciones
77
• appliedProfile: ProfileApplication [*]
Hace referencia a ProfileApllications, el cual indica cuáles son los perfiles
que se aplican al paquete appliedProfile que asocia un paquete y un perfil,
relaciona un elemento desde un modelo (una clase de paquete) a un
elemento de su metamodelo. Representa al conjunto de perfiles que
definen las extensiones aplicables al paquete. Esto muestra que el modelo
y el metamodelo pueden coexistir en el mismo espacio y pueden tener
vínculos entre ellos.
Profile (perfil) es una clase de paquete que establece las extensiones para un elemento
del metamodelo. El propósito es adaptarlo a un dominio particular. El elemento básico
de extensión es el estereotipo. Por esta razón es definido como parte del perfil. Un perfil
es una forma restrictiva de un metamodelo. Las extensiones se definen como
estereotipos que se aplican a metaclases existentes.
Asociaciones
• metaclassReference: ElementImport [*] es la metaclase extendida.
• metamodelReference: PackageImport [*] es el paquete que contiene las
metaclases extendidas.
• ownedStereotype: Stereotype [*] son los estereotipos que conforman el
perfil.
Restricciones
Una metaclase importada no puede ser especializada ni generalizada.
self.metaclassReference.importedElement->
select(c | c.oclIsKindOf(Classifier) and
(c.generalization.namespace = self or
(c.specialization.namespace = self) )->isEmpty()
Todos los elementos importados, ya sea como referencia a una metaclase
o a través de una referencia al metamodelo, son miembros de la misma
referencia base del metamodelo.
self.metamodelReference.importedPackage.elementI
mport.
importedElement.allOwningPackages())->
union(self.metaclassReference.importedElement.
allOwningPackages() )->notEmpty()
78
ProfileApplication (perfil de aplicación) se utiliza para mostrar cuáles son los perfiles
que se aplican a un paquete. Uno o más perfiles pueden ser aplicados a un paquete, tal
como se muestra en la figura 4.10.
Asociaciones
importedProfile: Profile [1]
Hace referencia a los perfiles que se aplican a un paquete por medio de
“ProfileApplication”.
Figura 4.10 - Ejemplo de aplicación de perfiles a un paquete
Stereotype (estereotipo) un estereotipo define cómo se extiende una metaclase y habilita
al uso de una terminología específica para un dominio particular. Es un tipo de clase que
extiende clases a través de Extension. Una clase puede ser extendida por uno o más
estereotipos.
Dado que es una clase, puede tener propiedades, a las cuales se refiere como
definiciones de etiquetas (tags). Cuando un estereotipo se aplica a un elemento del
modelo, los valores de las propiedades se refieren como valores etiquetados.
Asociaciones
icon: Image [*]
Un estereotipo puede cambiar la apariencia gráfica del modelo extendido
utilizando íconos añadidos.
Restricciones
Un estereotipo sólo puede generalizar o especializar a otro estereotipo.
generalization.general->
forAll(e | e.oclIsKindOf(Stereotype)) and
generalization.specific->
79
forAll(e |
e.oclIsKindOf(Stereotype))
Cuando un estereotipo es aplicado a un elemento del modelo, se asocia una instancia de
un estereotipo a una instancia de la metaclase. Un ejemplo de la definición de
estereotipo se muestra en la figura 4.11 [74].
Figura 4.11 - Ejemplo de definición de un estereotipo
En la figura 4.12, es posible observar una instancia de la especificación expresada en la
figura 4.11. En este caso, la instancia extendida es una clase (en Class, el atributo name
es Class).
Figura 4.12 - Instancia de especificación de un estereotipo
4.2.7 Notación gráfica
En el momento de llevar a cabo la definición de un perfil se hace uso de distintos
elementos gráficos que representan diferentes elementos de un perfil. Se han establecido
diferentes estereotipos que denotan los elementos. A continuación se exponen las
diferentes notaciones gráficas, cada notación con su correspondiente elemento de perfil
80
asociado. En la tabla 4.3 se muestran los vínculos y en la tabla 4.4, se muestra la
notación para los estereotipos, metaclases y perfiles.
Tabla 4.3 Notación gráfica de vínculos
4.2.8 Relación entre paquetes y perfiles
Uno o más perfiles pueden ser aplicados a un paquete utilizando el estereotipo
<<apply>>. Esto significa que: si se aplica un perfil es posible, aunque no estrictamente
necesario, utilizar en el paquete estereotipos definidos en el perfil. Pueden ser aplicados
en múltiples perfiles siempre que no exista conflicto con las restricciones. El nuevo
perfil debe respetar las restricciones de los perfiles que fueron aplicados previamente.
Un paquete puede ser importado desde un perfil a través del estereotipo <<import>>.
Esto permite utilizar los elementos del paquete dentro del perfil. Si el perfil es aplicado
a otro paquete, los tipos importados también están disponibles desde el paquete que
aplica el perfil.
En la figura 4.13 se muestra un ejemplo de cómo un perfil puede importar elementos de
un paquete [75]. También se ejemplifica la forma en que un perfil puede ser aplicado.
Elemento de Perfil Notación gráfica
Extension
ProfileApplication
Elemento de Perfil Notación gráfica
Stereotype
Metaclass
Profile
Tabla 4.4 Notación gráfica de estereotipos, metaclases y perfiles
81
Es importante observar que JavaInteger puede ser utilizado como metapropiedad (en
Device) y como propiedad común (en TV).
Figura 4.13 - Ejemplo de relación de perfiles con paquetes
82
Capítulo 5
Definición de Métricas para el Diseño Orientado a Aspectos
5.1. Introducción
Las métricas de software intentan medir la complejidad del mismo para predecir el
costo final del proyecto, evaluar la calidad y la eficiencia del diseño.
Las métricas de software tienen múltiples aplicaciones en diferentes tareas de la
ingeniería del software como prueba, gerenciamiento y mantenimiento.
La investigación en el campo de las métricas se va adaptando a las necesidades y a las
nuevas propuestas de desarrollo de software, lenguajes y paradigmas de programación
como por ejemplo la POA.
Los aspectos son “concerns” que tienden a atravesar los componentes principales del
sistema, incrementando la interdependencia, y reduciendo su reutilización en los
sistemas desarrollados siguiendo la orientación a objetos. Sin embargo estos problemas
serían resueltos por el desarrollo de software orientado a aspectos. El diseño orientado a
aspectos provee un soporte explícito para lidiar con los crosscutting concerns. Usando
esta técnica, los aspectos se separan en módulos que luego son tejidos con las clases
bases para construir la aplicación. Además los aspectos en el diseño permiten capturar a
los componentes más reutilizables y posibilita la generación automática de código.
Como se dijo anteriormente el paradigma orientado a aspectos se basa en el de
orientación a objetos introduciendo a los aspectos como un tipo “especial” de clase. De
esta manera se pueden aplicar métricas que evalúen algunas características similares a la
OO y otras propias de la OA.
5.2 Extensión de UML 2.3 para sistemas OA
Para extender UML estándar a una plataforma o dominio particular se utiliza el paquete
“Profile” provisto por UML 2.3 [74]. Este paquete incluye tres mecanismos para
redefinir estereotipos, valores etiquetados y restricciones. Estos elementos permiten
adaptar la semántica de UML a un requerimiento particular sin cambiar el metamodelo
UML. En la figura 5.1 se muestra el paquete Profile de UML utilizado en este trabajo.
En esta sección se muestra la definición de un Perfil UML para la orientación a
aspectos. Este perfil considera trabajos existentes, los cuales si bien definen un perfil
considerando los valores etiquetados y los estereotipos, no especifican las restricciones
83
o lo hacen con lenguaje natural, el cual es ambiguo. La presente propuesta de perfil
cumple con los tres elementos necesarios para su definición, con la ventaja de que las
Figura 5.1: Paquete Profiles de UML 2.3
restricciones son especificadas en OCL, el cual, como se dijo anteriormente, provee un
formalismo gracias a la lógica de primer orden que utiliza.
Un perfil es un paquete estereotipado que contiene elementos de modelado, los cuales
son específicos al dominio particular al cual se aplica, en este caso orientación a
aspectos.
La definición del perfil tiene en cuenta los elementos de los LOA de propósito general.
Esto se debe a que estos lenguajes son los más utilizados a la hora de implementar el
software, tomando como caso de estudio Aspect J [34].
AspectJ es un lenguaje orientado a aspectos de propósito general, cuya primera versión
fue lanzada en 1998 por el equipo conformado por Gregor Kickzales.
AspectJ es una extensión compatible de Java para facilitar el uso de aspectos por parte
de los programadores de Java. Por compatible se entiende:
- Compatibilidad base: todos los programas válidos de Java deben ser programas
válidos de AspectJ.
84
- Compatibilidad de plataforma: todos los programas válidos de AspectJ deben correr
sobre la máquina virtual estándar de Java.
- Compatibilidad de programación: la programación en AspectJ debe ser una extensión
natural de la programación en Java.
Esta última meta fue una de las guías más importante a la hora de tomar decisiones
sobre el lenguaje. Es estáticamente tipado y usa el sistema de tipos estático de Java.
Se extiende Java [34] para soportar el manejo de aspectos agregando a la semántica de
Java cuatro entidades principales.
- Los puntos de enlace (join point) son puntos bien definidos en la ejecución de un
programa, entre ellos se pueden citar llamadas a métodos y accesos a atributos.
- Los cortes (pointcuts) agrupan puntos de enlace y permiten exponer el contexto en
ejecución de dichos puntos. Existen dos tipos de cortes los primitivos y los definidos
por el usuario.
- Los consejos (advices) son acciones que se ejecutan en cada punto de enlace incluido
en un corte. Los consejos tienen acceso a los valores expuestos por el corte. Las tres
entidades anteriores son dinámicas porque permiten definir comportamiento adicional
que actuará en tiempo de ejecución.
- Las introducciones y declaraciones permiten cambiar la estructura de clases de un
programa, agregando o extendiendo interfaces y clases con nuevos atributos,
constructores o métodos. Esta última entidad es estática porque afecta la signatura
estática del programa.
Se puede concluir entonces que AspectJ soporta tanto implementación estática como
dinámica de los croosscutting concerns.
5.2.1 Participantes
A continuación se listan los estereotipos que participan en el perfil.
Aspect: es el estereotipo que modela los aspectos como un “tipo particular” de clase.
Dado que la estructura y comportamiento de un aspecto es semejante al de una clase se
realiza una extensión de la metaclase Class para definirlo. Un aspecto puede contener
atributos, operaciones y referirse a los demás componentes a través de relaciones.
Realize: es la relación entre una clase y un aspecto. Indica que una clase incorpora el
comportamiento del aspecto relacionado. Se realiza la extensión de la metaclase
Realization ya que Realize es un tipo particular de relación. Pero es más específica que
una relación ya que sólo puede existir entre una clase y un aspecto.
85
PointCut: es el estereotipo que modela el punto de corte; describe un conjunto mínimo
de propiedades que se deben cumplirse en una clase. En definitiva, un punto de corte es
una sentencia que indica el lugar dónde se debe colocar el conjunto de sentencias a
ejecutar siempre y cuando se cumpla una determinada condición y/o operación. Pointcut
extiende la metaclase Operation ya que indica a través de una sentencia invoca la
ejecución de un conjunto de sentencias que incorporan el comportamiento del aspecto
en la clase base.
WeavedClass: es la unión de la clase y el/los aspectos que la afectan. Una clase tejida
aparece en el momento que se realiza el tejido de los aspectos a la/s clase/s que lo
utilizan. Es una subclase de un aspecto ya que la misma tiene características de clase y
aspecto por esto WeavedClass extiende la metaclase Class.
Advice: son acciones que se ejecutan en cada punto de enlace incluido en un corte. Las
acciones son en definitiva partes de código que son ejecutadas en el punto de corte.
Advice se extiende de la metaclase Operation ya que es una operación a realizar en un
lugar determinado.
En la figura 5.2 se muestra la definición del perfil para modelar sistemas orientados a
aspectos para lenguajes de propósito general como AspectJ.
Figura 5.2: Definición de Perfil para Orientación de Aspectos
86
5.2.3 Restricciones
En esta sección se definen las restricciones semánticas correspondientes al perfil OA
(Figura 5.2). En las figuras 5.3 (a) y (b) se muestra parte de la Superestructura de UML
2.3 [74] para facilitar el seguimiento de las restricciones.
Se define la operación IsAspect para identificar si la clase está estereotipada como un
aspecto.
Context Class:: IsAspect():boolean
Pre:
Post:
IsAspect=self.extension.ownedEnd->exist(e/e.type.name=’Aspect’)
Otras operaciones similares a la anterior se definen con el fin de establecer si una
metaclase es un estereotipo particular ya que UML 2.3 no provee una operación que
devuelva los estereotipos que tengan la etiqueta ‘X’, en el caso anterior ‘Aspect’.
a) Una WeavedClass (clase tejida) tiene como superclase al menos un aspecto y una
clase. Esto se debe a que una clase tejida es el resultado de la unión entre una clase y al
menos un aspecto. La clase tejida es una clase base que incorpora en el momento de la
ejecución el comportamiento de al menos un aspecto.
Context Class::IsWeavedClass():Boolean
Pre:
Post: IsWeavedClass= self.extension.ownedEnd ->
exist (e/e.name=”WeavedClass”)
La operación anterior (IsWeavedClass) indica si la clase esta estereotipada como
WeavedClass
Context Class:
Inv: self.IsWeavedClass() implies self.parents()->
exist(x,y/x.isAspect() and x<>y and not y.IsAspect())
Donde parents() es una operación propia de UML que devuelve las superclases de la
clase que invoca la operación.
87
b) Un aspecto en caso de ser una subclase sólo puede tener como superclase a otro
aspecto. Esto se debe a que puede existir la necesidad de especificar un aspecto, esto se
puede realizar creando una subclase del mismo. Un aspecto no puede ser una subclase
de una clase ya que violaría el sentido de la OA la cual indica que los aspectos
implementan los crosscutting concerns del sistema. Si un aspecto tiene como superclase
una clase este debería ser una clase tejida, por consiguiente debe tener otra superclase
estereotipada como aspecto.
Context Class
Inv: self.isAspect()and self.parents()->notempty()
implies self.allparents()->
forall(c/c.isAspect())
La operación allparents() es de UML y devuelve todos las superclases de todas las
superclases de la clase que la invoca.
c) La relación Realize existe únicamente entre un Aspecto y una clase. Esta relación
indica que una clase utiliza el aspecto en algún punto de su especificación. El aspecto
modela un crosscutting concern que luego será incorporado a la clase base en el
momento indicado por los puntos de enlace definidos.
Context Class::IsRealize():Boolean
Pre:
Post: IsRealize= self.extension.ownedEnd->
exist(e/e.name=”Realize”)
La operación anterior (IsRealize) indica si la clase esta estereotipada como Realize.
Context Realization:
Inv: self.IsRealize() implies (self.supplier.isAspect()-
>exist(x\x.IsApect())) and (self.client->exist(y\y->not
isAspect())
En esta restricción pide que el extremo de la relación Realize (supplier) exista una clase
que es un aspecto y a su vez que el origen (client) exista una clase que no sea un
aspecto.
88
d) Las operaciones Pointcut y Advice sólo pueden pertenecer a un aspecto. Estas
operaciones son propias de la OA, por lo que no pueden existir en las clases que no sean
aspectos las cuales modelan dónde (Pointcut) ejecutar las sentencias (Advice) que
implementan el crosscutting concern.
Se definen las operaciones IsAdvice e IsPointcut de manera que indique si las clases
están estereotipadas como Advice y Pointcut respectivamente.
Context Class::IsPointCut():Boolean
Pre:
Post: IsPointCut= self.extension.ownedEnd->
exist(e/e.name=”PointCut”)
Context Class::IsAdvice():Boolean
Pre:
Post: IsAdvice= self.extension.ownedEnd->
exist(e/e.name=”Advice”)
Context Operation
Inv: self.IsPointCut() implies self.class.IsAspect()
Inv: self.IsAdvice() implies self.class.IsAspect()
Las restricciones anteriores aunque parecen obvias son necesarias debido a que no se
puede modelar en los perfiles UML relaciones entre los estereotipos a menos que esta
sea una generalización y/o especialización.
89
Figura 5.3 (a): Metamodelo UML 2.3 (Class Diagrams)
Figura 5.3 (b): Metamodelo UML 2.3 (Dependencies)
90
e) No pueden existir aspectos aislados. Está restricción se debe a que si se define un
aspecto para implementar un crosscutting concern, éste debe estar relacionado. Un
aspecto sólo puede “ejecutarse” si otra clase lo incorpora en su comportamiento.
Context Class
Inv: Class.allInstances()->
forall(c/c.IsAspect() implies
(RelationShip.allInstances().relatedelement-> exist(x| x=c)
En esta restricción se afirma que todas las clases que son estereotipadas con Aspect
implica que existe alguna relación que tiene ese aspecto como origen o destino.
Con el fin de verificar la utilidad del perfil OA definido y de contrastar las restricciones
en OCL aplicadas sobre el metamodelo UML se han realizado aplicaciones del mismo.
En las secciones siguientes se detallan las aplicaciones del perfil OA en dos casos de
estudio.
5.2.4 Definición del perfil OA en la herramienta Papyrus
Se realizó la definición del Perfil OA utilizando una herramienta de modelado. La
herramienta utilizada fue Papyrus[77].
Papyrus es un proyecto de software libre que se incorpora a Eclipse. Esta herramienta se
utiliza para graficar modelos UML 2 y definir restricciones en OCL para el mismo.
Utiliza la versión UML 2.2 y la versión OCL 2.1. Además de la definición de modelos
es posible definir perfiles y luego aplicarlos en un modelo particular. Siendo esta
característica la que llevó a elegirlo como herramienta de prueba. Existen otras
herramientas que permiten validar OCL pero no permiten la incorporación de un perfil
para aplicarlo en modelos.
Para verificar la utilidad del perfil así como las restricciones del mismo se define el
perfil propuesto en esta tesis de maestría en el entorno de Papyrus. La ventaja del uso de
esta herramienta es que permite validar y “ejecutar” las operaciones de OCL. Papyrus
utiliza una definición de UML 2.2 la cual es semejante a la última versión de UML 2.3.
91
Figura 5.4 Perfil OA en la Herramienta Papyrus
Una vez definido gráficamente el perfil se definieron las restricciones en el nivel M2 de
modelado (Figura 5.4).
Como ejemplo de implementación de las restricciones definidas en la sección anteior se
muestra a continuación la restricción (a). Ésta especifica que una WeavedClass debe
tener como superclase al menos un aspecto y al menos una clase. En este caso la
restricción se define en el contexto WeavedClass.
self.parents()->exists( x,y |y.getAppliedStereotypes().name->
includes('Aspect')->notEmpty() and x<>y)
Se muestra ahora la definición en Payrus de la restricción (e). Ésta indica que no debe
haber aspectos aislados. La restricción es definida a nivel del perfil, no en una clase o
estereotipo particular.
Relationship.allInstances().relatedElement->
includesAll(Class.allInstances()->
select(c|c.getApplicableStereotypes().name->includes('Aspect')))
92
Como se puede observar en las restricciones anteriores se utiliza la operación
getAppliedStereotypes(). Esta operación es provista por Papyrus, permite determinar si
una metaclase tiene un estereotipo aplicado. La operación getAppliedStereotypes()
devuelve un conjunto de estereotipos. Luego se pregunta si incluye el estereotipo
‘Aspect’.
Por otro lado se puede observar que la implementación de esta restricción (e) no fue tan
directa como el caso de la restricción (a). Esto se debe a que por motivos de
implementación de la herramienta Papyrus algunos de los caminos accesibles a través
de las metaclases de UML no están implementadas. Por esta razón, se toman todas las
relaciones y luego se solicita que todos los aspectos del modelo estén incluidos en ese
conjunto.
Luego de definir las restricciones correspondientes al perfil (ver Anexo A) se aplico el
mismo a un modelo particular. En la figura 5.5 se muestra el modelado de un sistema
que envía mensajes a través de un comunicador. El comunicador se encarga de enviar
un mensaje. Como este mensaje lleva un encabezado que indica la modalidad de envío
(urgente, normal, etc.) el aspecto Modal le antepone esta información. Luego del
mensaje el aspecto SaludoJapones coloca el saludo de despedida al mensaje el cual va
en Japones. Este modelo es una parte de un sistema de mensajes internacionales, que
para los fines de ejemplo ha sido simplificado.
Figura 5.5. Modelado de sistema
93
Se realizaron diferentes modelos de manera tal que se pudiera realizar la verificación de
éstos de acuerdo al perfil OA definido. En particular el modelo de la figura 5.5 cumple
con las restricciones definidas en el perfil.
Siguiendo con el ejemplo anterior se muestra el mismo modelo con un aspecto aislado.
Recuerde que se definió como restricción (e) del perfil que no puede haber aspectos
aislados. En este caso la validación es fallida ya que no cumple con la restricción
mencionada. En la figura 5.6 se muestra el error al validar el modelo, es decir la
restricción “No existen aspectos aislados” devuelve el valor FALSE; por lo tanto el
modelo no cumple con la restricción (e) del perfil OA.
Figura 5.6. Modelo que contiene un aspecto aislado (SaludoJapones)
Como se dijo anteriormente se realizaron diferentes pruebas del Perfil OA aplicado a
distintos modelos OA con el fin de evaluar su aplicación en casos, aunque de
laboratorio, permitieran de alguna manera verificar su aplicabilidad y validez.
5.2.5 Generación automática de código AspectJ a partir del Perfil OA
El perfil OA definido en este trabajo se utilizó como base para la construcción de una
herramienta que genera código AspectJ automáticamente.
A continuación se explica brevemente la herramienta construida como trabajo final de
Licenciatura en Cs. de la Computación [78].
94
Para el soporte de aspectos, se mostró anteriormente la definición de un Perfil OA, el
cual es aplicado para lograr construir el modelo OA. Una vez generado el modelo OA
con formato XMI [79], se hace la transformación del documento XMI al metamodelo
XML basado en el esquema OA visto antes.
Este metamodelo es construido a través del lenguaje de consulta XQuery [80].
Utilizando el metamodelo XML para el cual se definió un esquema OA, se comienza la
transformación de código XML a AspectJ. Esta transformación se hace por medio de un
programa escrito en lenguaje de programación Java.
La Figura 5.7 muestra los pasos seguidos para la construcción la herramienta que genera
código AspectJ.
Figura 5.7: Transformaciones desde Perfil OA hasta código AspectJ
El programa construido en Java parsea el metamodelo XML guardándolo en una
estructura interna. Esta estructura está compuesta de un conjunto de clases y un
conjunto de relaciones. Las clases poseen un conjunto de atributos y un conjunto de
operaciones. A su vez las operaciones poseen un conjunto de parámetros. Una vez
95
guardada toda la información en la estructura interna, se comienza la generación de
código AspectJ.
5.3 Definición de Métricas Orientadas a Aspectos en OCL
Se realizó la definición de métricas específicas para sistemas OA, aplicables a partir de
la etapa del diseño. En esta etapa, la más costosa, surge el modelado de los aspectos del
sistema.
Teniendo en cuenta que la POA es una nuevo paradigma para el desarrollo de sistemas
de software. La evaluación de la misma puede realizarse a través de distintas
herramientas para poder así calificar su uso. Una de las herramientas que permiten
medir de manera más objetiva el diseño realizado son las métricas. Mediante la
aplicación de distintas técnicas se puede evaluar el proceso de desarrollo de sistemas
OA.
La mayor parte del diseño OA es subjetivo, un diseñador “sabe” como caracterizar un
sistema OA para implementar efectivamente los requerimientos del cliente. Pero se sabe
que una vista más objetiva del diseño es más beneficiosa. La definición de métricas
proporciona esta vista objetiva del diseño realizado [48]
Se pueden encontrar distintos trabajos acerca de métricas aplicadas a diferentes
metodologías, en particular las métricas para sistemas OO [81, 82] es un campo muy
estudiado. Éstos trabajos definen formal o semi formalmente métricas aplicables a la
OO.
En cuanto a métricas específicamente para sistemas OA hay muy poco realizado,
algunos como el trabajo [12] han establecido que si se aplica la metodología de OA para
el desarrollo se mejoran los valores obtenidos en las métricas para OO: es decir se
compara un sistema OA con un sistema OO usando métricas OO y se puede observar
que la aplicación de la OA mejora el diseño del sistema.
Teniendo en cuenta las similitudes entre la OA y la OO algunas métricas como las C&K
(Chidamber & Kemerer) [64] o las métricas MOOD (Metrics for Object Oriented
Design) [65], sirven de base para la definición de métricas para sistemas OA y además
al tener una extensión de UML a través de un perfil se puede definir métricas para
sistemas OA utilizando OCL.
96
5.3.1 Peso de método por Aspecto (PMA)
La cantidad de métodos y su complejidad es un indicador razonable de la cantidad del
esfuerzo necesario para implementar y verificar un aspecto. Si el número de métodos es
grande el árbol de herencia será más complejo porque los aspectos hijos heredan los
métodos de sus predecesores.
Context Class:: PMA():Integer;
pre: self.isAspect()
PMA=(self.ownedOperation->collect(m/m.CPMA())-> sum();
Donde el valor que devuelve CPMA() es la complejidad del método asignada por el
equipo de desarrollo.
Context Operation::CPMA():Integer
Pre:
CPMA= if self.IsPointcut() then 100
else
If self.IsAdvice() then 50
else 10
endif
endif
Es importante tener en cuenta que el número de los métodos de los aspectos debería ser
pequeño ya que su función es encapsular la funcionalidad.
En los sistemas OO, si el número de métodos crece para una clase particular es probable
que sea muy específica para la aplicación, limitando su potencial reuso. Esto puede
considerarse como un indicador de que la clase tiene mezclada en su estructura un
aspecto.
En cambio en los sistemas OA si el valor de PMA es alto, el esfuerzo de prueba del
aspecto será mayor y no necesariamente indicará que éste no es reutilizable como en el
caso de la OO.
5.3.2 Profundidad del árbol de herencia (PAH)
Esta métrica indica la longitud máxima desde el nodo raíz a la hoja del árbol de
herencia. Es decir PAH mide el número de ancestros de un aspecto.
Context Class::PAH:Integer
pre: self.isAspect()
97
PAH= if self.parents()-> isEmpty() then 0;
else 1+ (self.parents().PAH())-> sum()
endif
dónde parents() es una operación provista por UML que devuelve los predecesores
inmediatos de la clase.
Considerando que en los sistemas OO muchas veces las subclases se definen para
modelar el comportamiento transversal de la clase. La profundidad del árbol de herencia
(PAH) será menor en los sistemas OA ya que ese comportamiento se encapsula en un
aspecto separado.
5.3.3 Número de Hijos (NH)
Los aspectos que están subordinamos por una clase, se llaman descendientes. A medida
que el número de descendientes crece, la reutilización aumenta, pero también es cierto
que a medida que crece NH, la abstracción representada por sus predecesores puede
disolverse.
Context Class::hijos():Set(Class)
hijos= (Class.allinstances()-> select(c/ c.parents()->
includes(self)));
Context Class::NH:Integer
pre: self.isAspect()
NH=(self.hijos()->size())
Esta métrica representa el mismo indicador en los sistemas OO que en los OA un
número alto de NH puede causar que el predecesor sea abstracto perjudicando el diseño
del sistema.
5.3.4 Acoplamiento entre Aspectos (AA)
AA está asociado a la noción de que un aspecto está acoplado a otro si uno actúa sobre
el otro. Esto significa que dos clases (clase y aspecto o aspecto y aspecto) están
acopladas cuando métodos declarados en una clase utilice métodos o variables de
instancias definidas por otra clase.
AA es la suma de las clases y/o aspectos a las cuales un aspecto se encuentra acoplado.
98
Se define la operación asociaciones y dependencias las que devuelven las asociaciones y
dependencias en la cual la clase es origen o destino.
context Class::asociaciones(): Set (Association)
asociaciones= (Association.allInstances()->
select(a|a.memberEnd.class->includes(self)) ->asset();
context Class::dependencias()Set (Dependency)
dependencias=Dependency.allInstance()-> select (d\d.supplier
->includes(self.clientDependency.client)->union
(self.clientDependency.supplier) ->asset())
context Class::AA:Integer
pre: self.isAspect()
AA= (self.asociaciones()->size()+ self.dependencias()-> size())
Si bien AA indica el nivel de acoplamiento de un aspecto es interesante saber por
separado si el acoplamiento es con otros aspectos o con otras clases. Esto se debe a que
es esfuerzo de prueba se ve incrementado si una clase esta fuertemente acoplada con
mas de un aspecto.
5.3.5 Dependencia entre Aspectos (DA)
Una métrica que indica si se produce la llamada “paradoja entre aspectos” es la que
indique si se produce el acoplamiento y/o dependencia entre aspectos.
La paradoja entre aspectos surge cuando en pos de mejorar el diseño se reutilizan los
aspectos entre aspectos. Es decir se produce acoplamiento entre aspectos el cual tiene
consecuencias similares al acoplamiento entre objetos.
Entonces ocurre que al aplicar la OA para resolver el problema de crosscutting concerns
el que causa el acoplamiento entre objetos se llega al acoplamiento entre aspectos el
cual trae los mismos inconvenientes, esta es la paradoja entre aspectos.
Se define la métrica DA la cuál indica si existe acoplamiento entre aspectos del sistema.
context Class::DA:Boolean
pre: self.isAspect()
DA= (self.asociaciones()->exist(c\c.memberEnd.class.IsAspect()
and c.memberEnd.class <> self)
99
or self.dependencias()-> excluding(self)->
exist(c\c.IsAspect())
5.3.6 Dependencia entre Clase -Aspectos (DCA)
Una clase puede utilizar uno o más aspectos para complementar una funcionalidad. Un
aspecto es tejido en muchos lugares diferentes, y no se puede asegurar que la clase
tejida funcione correctamente sino no se han probado cada uno de los puntos de enlace.
Además si se tiene en cuenta que muchas veces una clase esta relacionada con más de
un aspecto, el costo de prueba de la clase aumentará a medida que crece el acoplamiento
entre clases y aspectos. La siguiente métrica indica el nivel de dependencia de una clase
con respecto a los aspectos del sistema
context Class::DCA:Integer
pre:
DCA= (self.dependencias()->select(x/x.IsRealize()))->size());
5.3.7 Respuestas por Aspecto (RA)
El total de las respuestas de un aspecto a una clase es el conjunto de métodos que
pueden ejecutarse potencialmente como respuesta a un mensaje que recibe el aspecto.
Estos son todos los métodos accesibles en una jerarquía de clases. Se define RA como
el número de métodos existentes en el conjunto de respuestas.
context Class::RA:Integer
pre: self.isAspect()
RA=
If self.allparents() -> isempty() then self.allmethod()->size();
else collect(self.parents().RA())->sum()
endif
5.3.8 Número de Aspectos (NA)
En un diseño orientado a aspectos la unidad principal es el aspecto, es natural medir la
cantidad existente.
context Class::NA:Integer
pre:
100
NA=Class.allInstances()->select (c\c.IsAspect())->size();
Se considera la orientación a aspectos como una mejora a los problemas que tiene la
orientación a objetos con respecto a los crosscutting concerns. Pero si en un diseño
orientado a aspectos el número de aspectos es alto, indica que probablemente el diseño
haya sido demasiado específico.
El uso de la orientación a aspecto promueve que los aspectos sean utilizados por
distintas clases. Un alto acoplamiento de un aspecto de una clase causara un incremento
en el esfuerzo de prueba del aspecto. Esto se debe a que uno de los problemas de la OA
es el costo de prueba de un aspecto (esto es porque se debe probar en todas las clases y
en todos los lugares de la misma en la que se incorpora el aspecto). Además si el
número de aspectos es alto el esfuerzo total se incrementará también.
Un diseño orientado a aspectos es aceptable si el número de aspectos es bajo caso
contrario la utilización de este paradigma debería reconsiderarse ya que no aporta
mejora con respecto al uso de la OO.
5.3.9 Cantidad de operaciones de un aspecto (COA)
Esta medida indica la cantidad de operaciones de un aspecto sin tener en cuenta las
operaciones heredadas.
Context Class::COA():Integer
Pre: self.isAspect()
Post: COA=self.ownedOperation->size()
De forma similar se puede calcular a partir de esta medida cuantas de las operaciones
existentes son pointcut.
Context Class::CPCA():Integer
Pre: self.isAspect()
Post:CPCA=self.ownedOperation->select (x/x.IsPointCut())->size()
Cuantas operaciones son advice.
Context Class::CAdA():Integer
Pre: self.isAspect()
101
Post: CAdA=self.ownedOperation->select (x/x.IsAdvice())->size()
5.3.10 Cantidad de atributos de un aspecto (CAA)
Esta medida indica los atributos de un aspecto sin tener en cuenta los atributos
heredados.
Context Class:CAA():Integer()
Pre: self.isAspect()
Post: CAA=self.ownedAttribute->size()
5.3.11 Cantidad total de operaciones de un aspecto (CTO)
Esta medida indica las operaciones de un aspecto teniendo en cuenta las operaciones
heredadas. Recuerde que una clase puede heredar de múltiples padres.
Context Class::CTO():Integer
Pre: self.isAspect()
Post: CTO= if self.parents()->isempty() then self.COA()
else
collect(self.parents().CTO())-> sum()
endif
5.3.12 Cantidad total de atributos de un aspecto (CTA)
Esta medida indica los atributos de un aspecto teniendo en cuenta los heredados.
Recordemos que una clase puede heredar de múltiples padres.
Context Class:CTA():Integer
Pre: self.isAspect()
Post: CTA= if self.parents()->isempty() then self.CAA()
else collect(self.parents().CTA())->sum()
endif
102
5.3.13 Tamaño de un aspecto (TA)
Teniendo en cuenta que el tamaño total de un aspecto depende de la cantidad total de
atributos y operaciones que contiene, es directa la definición del tamaño de un aspecto.
Context Class:TA():Integer
Pre: self.isAspect()
Post: TA= self.CTA()+self.CTO()
5.3.14 Indicación de herencia múltiple (HM)
Esta medida indica si el aspecto hereda o no de múltiples superclases, y en caso de que
sea así indica de cuantas.
Context Class:HM():Integer
Pre: self.isAspect()
Post: HM= self.parents()->size()
5.3.15 Clases Tejida
Las WeavedClass surgen del tejido de la clase con el/ los aspectos que utiliza en el
momento de la implementación del sistema. En la etapa de diseño el diseñador puede
predecir cuantas clases surgirán en el momento de la implementación si es que el
lenguaje utilizado hace uso de esta componente. Los LOA que no especifican las clases
tejidas son aquellos lenguajes de propósito específico. En ese caso las clases tejidas no
serán artefactos del diseño por lo que las métricas relacionadas a la misma carecen de
interés.
En el caso de AspectJ la cantidad de clases tejidas es un indicador para la realización de
las pruebas. Esto se debe a que éstas son las que efectivamente pasan por el proceso de
prueba y no las clases y los aspectos separadamente.
Se puede estimar la cantidad de clases tejidas en la etapa del diseño con respecto a la
cantidad de clases que se utilizan aspectos. Luego ECT estima la cantidad de clases
tejidas que surgirán en la implementación. Esta medición es interesante ya que dará un
indicador del esfuerzo de prueba.
103
Context Class:ECT:Integer
Pre:
Post: Class.allinstances->select(c/c.DCA()>0)->size()
Otras métricas para clases tejidas se derivan directamente de las vistas en las secciones
anteriores como la cantidad de operaciones, atributos, el tamaño de la clase tejida y el
acoplamiento con otras clases o entre clases tejidas. Estas métricas son semejantes a las
realizadas para aspectos por esto se presentará el acoplamiento entre clases tejidas
(AWC) a manera de ejemplo.
Ésta métrica es significativa ya que cuanto mayor sea el acoplamiento entre clases
tejidas mayor será el esfuerzo de prueba ya que no se podrán hacer pruebas modulares.
Si el sistema esta altamente acoplado la prueba deberá realizarse sobre todos el sistema.
El equipo de prueba deberá desarrollar una técnica de manera tal que se verifique el
cumplimiento de los requerimientos principales sin realizar un prueba total, la cual es
costoso en tiempo y recursos.
context Class:AWC:Integer
pre: self.isWeavedClass()
AWC= (self.asociaciones()->size()+ self.dependencias()->size();
5.4 Aplicación empírica de métricas en un diseño orientado a aspectos
En esta sección se mostrarán algunos de los valores de la aplicación de las métricas para
un modelado orientado a aspectos. La aplicación de las métricas se realiza de forma
empírica para poder constatar las afirmaciones realizadas en las secciones anteriores.
Se mostrará el diseño de un sistema que aplica la orientación a aspectos de acuerdo a las
métricas definidas se evaluará que tan adecuado es.
Como se dijo en la sección 5.2.4 el perfil OA fue definido en la herramienta Papyrus.
Además se definieron diferentes modelos OA con el fin de calcular sobre ellos las
métricas definidas en la sección 5.3.
Se muestra a continuación la aplicación de las métricas en un caso de estudio. Éste es
ampliamente utilizado en el desarrollo OA.
104
5.4.1 Pool de conexiones de base de datos OA
Se muestra a continuación el modelo de diseño correspondiente a un Pool de recursos,
en particular conexiones de base de datos (BD). Como se sabe la creación y destrucción
de conexiones a BD es costosa, el Pool de conexiones es una mejora tradicional que se
utiliza en los sistemas para mejorar su performance. El código convencional para
realizar esta tarea requiere de un código que explícitamente maneje la lógica del pool en
cada uno de los módulos que crean o destruyen las conexiones. Si además se pretende
reutilizar el pool en otros sistemas, seguramente de debe adaptar al mismo modificando
todos los módulos que crean y destruyen las conexiones. Si se implementa el pool con
OA, se puede ver la creación y destrucción de las conexiones como un crosscutting
concern. Se puede entonces encapsular la lógica del pool en un aspecto. La figura 5.8 se
muestra el modelo OA de este sistema.
Figura 5.8 Pool de conexiones de BD utilizando OA
Si bien el modelo es simple se pueden encontrar en el los principales problemas a la
hora de utilizar la OA, como la reutilización de aspectos, tejido de las clases, etc. Se
muestra a continuación la aplicación de las métricas más significativas para este
modelo.
105
5.4.2 Resultados y análisis de métricas
Se definieron todas las métricas presentadas en esta tesis de maestría (Anexo B), en
particular se muestran algunas de las métricas y la explicación del significado del valor
obtenido.
RA: self.allParents().getOperations()->size()+self.ownedOperation
->size()
Es el número posible de respuestas de un aspecto frente a un posible mensaje recibido.
La métrica es aplicada en el contexto de un aspecto particular, en este caso el aspecto
DBConexionPoolAspect. El valor de RA es 4 (Figura 5.9) esto indica que existen 4
operaciones que pueden responder a un mensaje. En el caso que el aspecto sea una
subclase RA considera las operaciones heredadas.
Para la implementación de RA se utilizan la operación getOperations provista por la
herramienta, la cual devuelve todas las operaciones. Esta operación no se encuentra
definida en UML.
Figura 5.9 RA
106
CAA: self.attribute->size()
En este caso se modifica el modelo de conexión agregando un atributo al aspecto
DBConexionPoolAspect (Figura 5.10). La existencia de atributos en un aspecto muchas
veces indica la dependencia o relación con otra clase del modelo, por lo cual es
necesaria una revisión del mismo de manera tal que no exista información redundante o
ambigua en éste.
Figura 5.10 CAA
COA: self.ownedOperation->size()
En este caso particular el valor obtenido de COA es el mismo de RA ya que el aspecto
sólo cuenta de operaciones propias del aspecto y no de superclases u interfaces.
CTO: self.ownedOperation->
union(self.allParents().getAllOperations())->size()
La cantidad total de operaciones de un aspecto considera además las operaciones de las
superclases del aspecto, estas se obtienen utilizando una operación propia de la
107
herramienta Papyrus, no presente en UML. Esta implementación difiere en gran manera
de la definición teórica ya que debido a las operaciones adicionales de la herramienta no
es necesaria realizar una recursión para obtener el valor de CTO.
DA : (self.clientDependency.supplier->
union(Dependency.allInstances()->
select(d|d.clientDependency.supplier ->
includes(self.clientDependency.client)).supplier)-> excluding
(self)->exist(c:NamedElement|c.getApplicableStereotypes().name-
>includes(‘Aspect’)))
or
(Association.allInstances()->
select(a|a.endType-> includes(self))) .memberEnd.class.
getAppliedStereotypes().name
->includes(‘Aspect’)
Aunque a simple vista la implementación de la dependencia entre aspectos parece
diferir notablemente de la definición teórica. Esto no es así, lo que sucede es que en este
caso particular no se puede utilizar operaciones definidas por el usuario de la
herramientas (dependencias() y asociaciones()). Esto se debe a que al utilizar la
operación getAppliedstereotypes que indica si la clase esta estereotipada con una
etiqueta en particular no se puede aplicar a un conjunto resultante de clases y realizar la
colección de éstas. Se muestra en la Figura 5.11 el modelo de Pool de Conexiones
modificado. Se modela la necesidad de realizar la conexión antes de la autenticación de
usuario a través de una dependencia entre aspectos.
El valor de DA en este caso es TRUE indicando que existe dependencia entre aspectos.
Este valor puede ser un indicador de que se produce la “paradoja entre aspectos”.
Además al tener dependencia entre aspectos la prueba de los mismos debe realizarse
simultáneamente y a su vez en todos los puntos de cortes que tengan cada uno de ellos.
El esfuerzo de prueba se ve incrementado como se dijo en el capitulo 2, el principal
problema de la OA es la prueba del sistema desarrollado.
ECT: Class.allinstances->select(c|
108
(c.clientDependency.supplier->
union(Dependecy.allInstances()->
select(d|d.clientDependency.supplier ->
includes(self.clientDependency.client)).supplier))
->(select(x|x.getAppliedStereotypes().name
->includes(‘Realize’))->size())
> 0)->size();
Figura 5.11 DA
ECT es definida a nivel de modelo. La estimación de la cantidad de clases tejidas indica
en esfuerzo necesario para probar el sistema. En particular para LOAs de propósito
general esta métrica es muy significativa ya que si ECT crece el esfuerzo de prueba
también. Note que (1) es la implementación de dependencias() y (2) es la
implementación de DCA (Dependencia entre Clase-Aspecto). El valor de ECT en este
modelo es 4 (Figura 5.12).
Una manera más simple de obtener la cantidad de clases tejidas es a través de la
cantidad de relaciones estereotipadas Realize. Dado que cada clase se puede relacionar
con más de un aspecto y un aspecto puede relacionarse con más de una clase, por cada
1
2
109
relación existente se creará una clase tejida. Considere que existe la relación Realize la
cual modela que clase con qué aspecto será tejido, luego la cantidad de clases tejidas es
igual a la cantidad de relaciones Realize.
ECT = DCA
Dependency.allInstances()->
select(d|d.getApplicableStereotypes().name->
includes('Realize'))->size()
Figura 5.12 ECT
110
Capítulo 6
Conclusiones y Trabajos Futuros
La orientación a aspectos ha surgido como una mejora de la orientación a objetos. Ésta
permite aumentar la reutilización de los crosscutting concerns encapsulados en unidades
denominadas aspectos.
El propósito de este trabajo es ayudar a los ingenieros de software que decidan
incorporar la OA (orientación a aspectos) en su desarrollo de software proveyendo
herramientas que faciliten esta tarea y permitan además evaluarla de manera objetiva.
En la actualidad no hay acuerdo con respecto al modelado de sistemas orientados a
aspectos por lo que la definición del perfil basado en ApectJ, el lenguaje OA más
utilizado, ayuda a los arquitectos y diseñadores de software en las etapas de diseño e
implementación, ya que en éstas se modelan los aspectos desarrollados en este trabajo.
Si bien se tomó un lenguaje de propósito general como caso de estudio para definir la
extensión OA, el perfil, debido a sus características es aplicable a otros lenguajes OA e
incluso a lenguajes de propósito específico. Esto se debe a que el perfil contiene los
elementos necesarios para modelar cualquier sistema OA (Aspect, PointCut, Advice y
Realize).
Uno de los objetivos de este trabajo de tesis fue definir una extensión precisa de UML
(Unified Modeling Language) para el modelado de sistemas OA, para ello, se realizó
una extensión de UML, esto se logró a través de perfiles. Se define no sólo los
estereotipos, sino también las restricciones necesarias para completar la semántica del
mismo. Al definir las restricciones utilizando lógica de primer orden, que proporciona
OCL (Object Constraint Language), se tiene la ventaja de no ser ambigua y más precisa
que otras definiciones existentes. Además al utilizar estándares de la OMG (Object
Management Group), ampliamente conocidos en la ingeniería de software, es simple de
comprender y de rápida aplicación.
El perfil definido se aplicó a modelos reales para validar su utilidad. Esto se hizo a
través de dos formas:
- Definición y aplicación del Perfil OA en la herramienta Papyrus. Definiendo
modelos OA en los cuales se aplicó el perfil y se verificó si estos modelos
cumplían o no con las restricciones del perfil.
111
- Generación automática de código AspectJ. A partir de un modelo que utiliza el
perfil se realizan una serie de transformaciones que llevan a la generación
automática de código AspectJ.
La ventaja de la aplicación del perfil en el modelado de sistemas OA reales es que se
provee a los ingenieros de software de una herramienta que les permite simplificar la
tarea del diseño OA. Al definir el perfil en una herramienta de modelado utilizada,
como lo es Papyrus, la cual permite no sólo la definición sino la exportación de perfiles,
se puede aplicar el perfil a distintos modelos OA simple y rápidamente. De esta forma
se logra alcanzar otro de los objetivos propuestos en este trabajo de tesis.
Como se ha visto la OA permite un manejo más fácil del seguimiento y mantenimiento
del software desarrollado. Pero como toda nueva técnica debe ser evaluada a través de
distintas herramientas para calificar su uso. Una de las herramientas que permiten medir
de manera más objetiva el diseño realizado mediante la aplicación de distintas técnicas
son las métricas.
Las métricas proporcionan una vista más objetiva del desarrollo que se realiza, esto es
crucial en el momento de mejorar y evaluar la calidad. Por este motivo el análisis de las
métricas aplicadas a distintas etapas del desarrollo de software es un tema que debe ser
profundizado, en particular para la orientación a aspectos ya que su uso en grandes
proyectos de software aumenta rápidamente.
Esto ha motivado el análisis de las métricas para poder aplicarlas al diseño OA y
encontrar además de los posibles efectos, nuevas métricas que ayuden a calificar
objetivamente un sistema OA.
La definición de métricas para sistemas OA fue el objetivo principal de este trabajo de
tesis. Estas métricas son aplicables en la etapa del diseño, ya que ésta es la más costosa
y en la cual surge generalmente el modelado de los aspectos del sistema.
Para realizar la definición de las métricas se utilizó OCL a través de expresiones
lógicas. Además la definición de las métricas se realizó a partir de la extensión de UML
2.3 realizada, la que permite modelar el dominio específico de la OA.
Luego de la verificación teórica y semántica de las métricas propuestas se realizan
pruebas de aplicación a través de la herramienta Papyrus. Se utiliza esta herramienta ya
que permite definir perfiles, restricciones OCL y luego aplicarlas sobre modelos UML.
La definición práctica de las métricas se adecua a las propiedades de la herramienta
tales como nuevas operaciones y también a sus limitaciones. Esto se debe que la
112
implementación de la capa M2 de la arquitectura UML que realiza Papyrus no es
exactamente igual a la definición propuesta por la OMG.
Uno de los objetivos de este trabajo de tesis era no sólo la definición, sino también la
aplicación de las métricas propuestas, esto se logra a través de casos de estudio. Se
realizó el modelado de sistemas OA utilizando el perfil para aplicar y ejecutar las
métricas en la herramienta Papyrus.
Los resultados obtenidos, en los modelos correspondientes a la capa M1 de la
arquitectura UML, estuvieron acorde a lo esperado. De esta manera se realizó una
validación empírica de las métricas propuestas.
A continuación se mencionan ventajas del presente trabajo de tesis que surgen
directamente del uso de estándares y de la gran variedad de herramientas CASE
existentes que los utilizan:
- Es posible automatizar la incorporación de perfiles a otras herramientas de modelado
UML de la misma manera que se hizo en Papyrus.
- A partir del uso del perfil OA realizar transformaciones en el marco de MDA para
llegar automáticamente, como se hizo la generación de código AspectJ, a código
ejecutable en diferentes lenguajes OA.
- Es posible incluir en otras herramientas, que permitan incorporar perfiles y
restricciones OCL, las métricas definidas de forma automatizada. Esto es colocando en
un archivo las métricas en OCL para aplicarlas sobre el modelo desarrollado y realizar
de esta manera el cálculo de las mismas.
Esta tesis de maestría, no sólo realiza una contribución en la evaluación de la calidad del
diseño de software OA, sino también deja la puerta abierta para seguir trabajando en la
OA en diferentes sentidos. Algunos de trabajos futuros relacionados son:
- Luego del refactoring de un sistema OO a uno OA realizar mediciones claves como la
no existencia de la paradoja entre aspectos o el alto acoplamiento.
- Proponer transformaciones específicas que lleven en el contexto de MDA, código OO
a OA (reingeniería).
- Definir métricas que ayuden a determinar la existencia de código OA en código OO.
Finalmente se puede decir que los tres objetivos planteados en este trabajo de tesis
fueron alcanzados de manera exitosa, logrando así ayudar al ingeniero de software a
evaluar objetivamente el diseño realizado e incluso evaluar la utilización o no de la OA
en el desarrollo de software.
113
Referencias
[1]. Dines Bjorner: “Software Engineering 2”: Ed. Springer, 2006 [2]. Lorenz, Mark and Kidd, Jeff, “Object Oriented Software Metrics”, Prentice Hall
Publishing, 1994. [3]. Quintero A.; “Visión General de la Programación Orientada a Aspectos.”
Departamento de Lenguajes y Sistemas Informáticos. Universidad de Sevilla. http://www.us.es/centrosdptos/departamentos/departamento_I0A3
[4]. Elisa Baniassad and Siobh´an Clarke, “An Approach for Aspect-Oriented Analysis and Design”; ICSE 04 0270-5257/04 IEEE
[5]. Zakaria, H. Hosny, A.Zeid; “A UML extension for Aspect Oriented Systems”, International Workshop on Aspect-Oriented Modeling with UML,2002
[6]. O. Aldawud, T. Elrad, A. Bader; “A UML Profile for AOP”, OOPSLA 2001 workshop on Aspect Oriented Programming
[7]. Zambrano A., Rousselot J.;“Supporting Aspect Oriented requirements Engineering for Large Documents”; Anales de la 39 Jornadas Argentinas de Informática, ASSE 2010, ISBN
[8]. Dianxiang Xu, Weifeng Xu, Kendall Nygard: “A State-Based Approach to Testing Aspect-Oriented Programs”. In Proc. of the 17"h International Conference on Software Engineering and Knowledge Engineering (SEKE'05), Taiwan, July 2005.
[9]. Moui ad Badri,Linda Badri, Maxime Bourque-Fortin; “Generating unit test sequences for aspect-oriented programs: towards a formal approach using UML state diagrams”, APSEC’04 1530-1362/04 IEEE
[10]. Iris Groher, Stefan Schulze:” Generating Aspect Code from UML Models”: AOSD 2003
[11]. M. Reina Quintero,J. Torres Valderrama; “Using aspect-orientation techniques to improve the reuse of metamodels”. Aspect-Based and Model-Based Separation of Concerns in Software Systems (ABMB 2006)
[12]. Zhao J.; “Measuring Coupling in Aspect-Oriented Systems”; Department of Computer Science and Engineering; Fukuoka Institute of Technology
[13]. Shiu Lun Tsang, Siobhán Clarke, Elisa Baniassad; “Object Metrics for Aspect Systems: Limiting Empirical Inference Based on Modularity”; ABMB 2006.
[14]. Abait E., Marcos C.; “Improving Effectiveness in the Identification of Crosscutting Concerns in Source Code ”; Anales de la 39 Jornadas Argentinas de Informática, ASSE 2010, ISBN
[15]. Marcos C., Vidal S.; “Automatización de un Proceso de Refactorización para la Separación de Concerns”; Anales de la 39 Jornadas Argentinas de Informática, ASSE 2010, ISBN
[16]. Martin A. Cechich A.; “Reingeniería Orientada a Aspectos para mejorar la Accesibilidad de sitios Web”; GIISCo Research Group; Departamento de Ciencias de la Computación, Universidad Nacional del Comahue
[17]. Mostefaoui F., Vachon J.; “Verification of Aspect-UML models using Alloy”; Workshop AOM ’07, March 12-13, 2007 Vancouver, British Columbia, ACM; 1-59593-658-5/07/03
[18]. Mostefaoui F., Vachon J.; “Design-level Detection of Interactions in Aspect-UML models using Alloy”; Journal of Object Technology; Vol. 6, No. 7, Special Issue: Aspect-Oriented Modeling, August 2007
114
[19]. Ubayashi N., Sato Y., et al.; “Alloy-based Lightweight Verification for Aspect-oriented Architecture”; sixth International Conference on Software Engineering Research, Management and Applications; 978-0-7695-3302-5/08; 2008; IEEE
[20]. .Object Management Group. Model Driven Architecture Guide; http://www.omg.org; 2003
[21]. Baigorria L. - Montejano G. - Riesco D.; “Definición y Aplicación de Perfil UML para AspectJ”; ASSE; 39 Jornadas Argentinas de Informática; Buenos Aires; 2010.
[22]. L. Baigorria, G. Montejano, D. Riesco, C. Abdelahad, N. Perez, "Definición del Diseño Orientado a Aspectos según el Metamodelo de la OMG", XV Congreso Argentino de Ciencias de la Computacion, 05/10/2009, San Salvador de Jujuy, Jujuy, Universidad Nacional de Jujuy, pp 832-. Red de Universidades Nacionales con Carreras en Informática.
[23]. N. Debnath, L. Baigorria, D. Riesco, G. Montejano, “Metrics Applied to Aspect Oriented Design using UML Profiles”, IEEE 13TH Symposium on Computers and Communications 2008 (ISCC’08), July 6 - 9, 2008, Marrakech, Morocco. Page(s):654–657. ISSN: 1530-1346, ISBN: 978-1-4244-2702-4. Indexed by INSPEC. Proceedings published by the IEEE Computer Society. http://ieexplore.ieee.org
[24]. L. Baigorria, G. Montejano, D. Riesco, “Metricas C&K Aplicadas al Diseño Orientado a Aspectos”, XII Congreso Argentino de Ciencias de la Computación, San Luis, del 24 al 27 de Octubre de 2006. Pg. 368-377. Universidad Nacional de San Luis, Red de Universidades Nacionales con Carreras en Informática. ISBN 950-609-050-5.
[25]. L. Baigorria, D. Riesco, G. Montejano, “Métricas Aplicadas a la Programación Orientada a Aspectos" WICC2006 en Morón (Argentina), Anales del VIII Workshop de Investigadores en Ciencias de la Computación, ISBN en CD 950-9474-35-5 y obra impresa 950-9474-34-7, pg. 313-317. Universidad Nacional de Moron, Red de Universidades Nacionales con Carreras en Informática.
[26]. N. Debnath, D. Riesco, G. Montejano, R. Uzal, L. Baigorria, A. Dasso, A. Funes, "A Technique Based on the OMG Metamodel: A Definition of Object Oriented Metrics applied to UML Models", The 3rd ACS/IEEE International Conference on Computer Systems and Applications January 3-6, 2005, Cairo, Egypt. pp 118-125. ISBN: 0-7803-8735-X, IEEE Catalog Number: 05EX949, Library of Congress Number: 2004110879. URL: http:// ieeexplore.ieee.org. IEEE Computer Society Press.
[27]. Ramnivas Laddad; “I want my AOP”; Parte 1, 2 y 3; JavaWorld; 2002. [28]. Colyer A., Clement A., Harley G., Webster M.; “Eclipse AspectJ: Aspect-
Oriented Programming with AspectJ and the Eclipse AspectJ Development Tools”; 2004
[29]. Colyer A., Clement A.; Aspect-oriented programming with AspectJ. IBM Systems J.; 44(2); 301-308; 2005.
[30]. Colyer, Clement; “Large-scale AOSD for middleware”; Proceedings of the 3rd international conference on Aspect-oriented software development; ACM, 2004
[31]. Jacobson and P. Ng; “Aspect-oriented Software Development”; Adison Wesley, 2005
[32]. Sommerville I.; “Software Engineering”, 8va. Ed.; Prentice Hall; 2007. [33]. Kiczales G., Lamping J., Mendhekar A., Maede C., et al.; “Aspect-Oriented
Programming”, Publicado en European Conference on Object-Oriented Programming (ECOOP); Finland, 1997
115
[34]. Ramnivas Laddad, “AspectJ in action”. Practical Aspect-Oriented Programming; Manning Publictions, 2003.
[35]. Birrer I, Pasetti A., et al; “The Xweaver Project: aspect-oriented programming for on-board applications”; http://control.ee.ethz.ch/index.cgi?page=publications;action=details; id=2361.
[36]. Ivar Jacobson, Grady Booch, James Rumbaugh; “El lenguaje unificado de modelado”; Adison Wesley; 1999
[37]. Easterbrook S., Nuseibeh B., “Using ViewPoints for Inconsistency Management”, Software Engineering Journal, 11(1): 31-43, BCS/IEE Press, January 1996
[38]. Finkelstein A., Kramer J. et al.; “Viewpoints: a framework for integrating multiple perspectives in system development. Int. Software Engineering Knowledge Engineering; Vol 2; 310-58; 1992.
[39]. R.E. Filman, T. Elrad ; “Aspect-oriented Software Development”; Adison Wesley; 2005
[40]. T. Highley, M. Lack, P. Myers, “Aspect-Oriented Programming: A Critical Analysis of a New Programming Paradigm”. University of Virginia, Department of Computer Science, Technical Report CS-99-29, Mayo 1999 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.5033 último acceso 04/07/2009.
[41]. Katz E., Katz S.; “Verifying Scenario-Based Aspect Specifications”; Formal Methods, International Symposium of Formal Methods Europe, Newcastle; 2005
[42]. Briand L., El Eman K., Morasca S.; “Theorical and empirical validation of software product measures”; Technical report ISERN-95-03, International Software Engineering Research Network; 1995.
[43]. IEEE Computer Society. "Metrics in Software." Computer 27, 9; pag 13-79; 1995.
[44]. Shrum, Sandy, Konrad, Mike, “CMMI: Guía pata la integración de procesos y la mejora de productos”, Addison Wesley, 2da Edición, 2009
[45]. ISO/IEC 9003. Software engineering-Guidelines for the application of ISO 9001:2000 to computer software. International Organizations for Standarization. Ginebra, Suiza, 2004.
[46]. Fenton N.; “Software Measurement: A Necessary Scientific Basis”; IEEE Transaction of software engineering; 1994.
[47]. Pressman, R., “Software Engineering”, Mc Graw Hill, 6ta Edición; 2005. [48]. Piattini M., Garcia F., Caballero I.; “Calidad de Sistemas Informáticos”;
Alfaomega, Ra-Ma; 2007. [49]. Serrano, M. Calero C., Piattini M.; “Validating Metrics for Data Warehouses ”;
Proceeding of the Conference on Empirical Assesement in Software Engineering (EASE 2002); Reino Unido;pag 8-10 ; 2002.
[50]. Weyuker E.; “Evaluating software complexity measures”; IEEE Transactions Software Eng., Vol 14 N 9, pag. 1357-1365; 1988.
[51]. Zuse H.; “A framework of software measurement”; Berlin, Walter de Gruyter. [52]. Morasca S.; “Software measurement”; En Handbook of Software Engineering
and Knowledge Engineering; Vol 1.; Fundamentals. Pag. 239-276; 2001. [53]. Fenton N., Pflegger S.; “Software Metricas: a Rigorous Approach”; 2da. Ed.;
Londres; Chapman & Hall; 1997. [54]. Florac W., Carlenton A.; “Measuring the software Process”; Statistical Process
Control for Software Process Improvement, Addison Wesley; 1999.
116
[55]. Garcia F.; et al.; “Towards a Consistent Terminology for Software Measuremrent”; Information and Software Technology; 2005.
[56]. Garmus D., Herron; “Function Point Analysis: Measurement Practices for Successful Software Projects”; Addison Wesley; Boston; 2000.
[57]. Putman L., Myers W.; “Measures for excellence – Reliable software on time, within budget”; Prentice Hall; 1992.
[58]. McDerming J.; “Software Engineering Reference Book”; Butterworth Heinemann; 1991.
[59]. Park R.; “Software size measurement: A framework for Counting Source Statements”; Software Engineering Institute; Carnegie Mellon University; Pittsburgh; 1992.
[60]. Li W., Henry S.; “Object-oriented metrics that predict maintainability”, Journal of Systems and Software; vol. 23; pag 111-122; 1993.
[61]. Halstead, M.; “Elements of Software Science”; Elsevier North Holland; The Netherlands; 1977.
[62]. McCabe T.; “A software complexity measure”; IEEE Transaction Software on Software Engineering; vol 2; pag 308-320; 1976.
[63]. Henry S., Kafura S.; “Software Structure Metrics Based on Information Flow”; IEEE Transaction Software on Software Engineering; pag. 510-518; 1981.
[64]. Chidamber S., Kemerer C.; IEEE Transaction Software on Software Engineering; pag 476-493; 1994.
[65]. Brito e Abreu F., Melo W.; “Object-oriented Software Engineering: Measuring and controlling the development process”; 4th. International Conference on Software Quality; McLean; USA; 1994.
[66]. Marchesi M.; “OOA Metrics for the Unified Modeling Language”; 2nd. Euromicro Conference on Software Maintenance and Reengineering; pag 67-73; 1998.
[67]. Genero M., Piattini M., Calero M.; “Metrics for Software Conceptuals Models”; Imperial College Press; UK; 2004.
[68]. Bansiya J., Davis C.; “A Hierarchical Model for Object-Oriented Design Quality Assesement”; IEEE Transaction on Software Engineering; pag 4-17; 2002.
[69]. Derr K.; “Applying OMT”. SIG Books; Prentice Hall; New York; 1995. [70]. Miranda D., Genero M., Piattini M.; “Empirical Validation of Metrics for UML
statechart diagrams”; 5th International Conference on Enterprice Information Systems (ICEIS 03); pag 87-95; 2003.
[71]. Reynoso L. et al.; “Measuring OCL Expressions: An Approach Based on Cognitive Techniques”; Capítulo 5 en Metrics for Software Conceptual Models; Imperial College Press; UK; 2004.
[72]. Lavazza L.; “Providin Automated Support for the GQM Measurement Process”; IEEE Software; 2000.
[73]. Giles A., Daich G., “Metrics Tools”; Crosstalk; The Journal of Defense Software Engineering; 1995.
[74]. UML 2.3 Superstructure; http://www.omg.org/spec/UML/2.3/Superstructure/PDF/; Mayo 2010.
[75]. UML 2.3 Infrastructure; http://www.omg.org/spec/UML/2.3/Infrastructure/PDF/Mayo 2010.
[76]. UML 2.0 OCL Specification, http://www.omg.org, Agosto del 2006.
[77]. Papyrus http://www.papyrusuml.org/ último acceso septiembre 2010.
117
[78]. Adbelahad C, Trabajo de Licenciatura en Ciencias de la Computación; Facultad de Ciencias Físico Matemáticas y Naturales; UNSL; 2010.Directores: Riesco D. Baigorria L
[79]. IBM “XML (Extensible Markup Language)” IBM Corp. 1998, 2001 http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/rzakl/rzakl.pdf
[80]. XQuery J. J. Gutiérrez, M. J. Escalona, M. Mejías, J. Torres, D.Villadiego “XQuery”. Universidad de Sevilla Lenguajes y Sistemas Informáticos España Sevilla, Febrero 2005 http://www.lsi.us.es/investigacion/informes.php último acceso 16/4/2010
[81]. Uzal, R.; Baigorria, L., Peralta, M.; Riesco, D.; “Object Oriented Metrics Applied To Rup Models”; Special Issue of the Journal of Computational Methods in Science and Engineering (JCMSE), ISBN 1-58603-495-2; 2004.
[82]. Yacoub S., Ammar H., Robinson T.; “Dynamic Metrics for Object Oriented Design”; Software Metrics Symposium; Proceedings. Sixth International; IEEE; 1999.
118
Anexo A
Restricciones del Perfil OA
Restricción (b)
En el caso de que el aspecto sea una subclase entonces la superclase debe ser un
aspecto.
self.superClass->notEmpty() implies self.superClass ->exists( y
|y.getAppliedStereotypes().name->includes('Aspect')->notEmpty())
Figura A.1 Restricción b
Restricción (c)
La relación Realize sólo existe entre clase y aspecto
Realization.allInstances()->select(d|d.getAppliedStereotypes().name-
>includes('Realize')).supplier.getAppliedStereotypes().name->
includes('Aspect')
and
Realization.allInstances()->select(d|d.getAppliedStereotypes().name-
>includes('Realize')).client.getAppliedStereotypes().name->
excludes('Aspect')
119
Figura A.2 Restricción c
Restricción (d)
Las operaciones Pointcut y Advice sólo pueden pertenecer a aspectos
Pointcut
Operation.allInstances()->select(o|o.getAppliedStereotypes().name->
includes('Pointcut')).class.getAppliedStereotypes().name-
>includes('Aspect')
Figura A.3 Restricción d.1 Pointcut
120
Advice
Operation.allInstances()->select(o|o.getAppliedStereotypes().name->
includes('Advice')).class.getAppliedStereotypes().name-
>includes('Aspect')
Figura A.4 Restricción d.2 Advice
121
Anexo B
Métricas OA en Papyrus
PAH self.allParents()->size()+1
RA self.allParents().getOperations()->size()+self.ownedOperation->size()
122
PMA self.getAllOperations()->collect (c| if c.getAppliedStereotypes().name->includes('Pointcut') then 10 else if c.getAppliedStereotypes().name->includes('Advice')then 50
else 0 endif endif)->sum()
CAA self.attribute->size()
CTA
self.allParents()->collect(attribute)->union(self.attribute)
123
COA self.ownedOperation->size()
CTO self.ownedOperation->union(self.allParents().getAllOperations())->size()
124
AA Association.allInstances()->select(a: Association| a.endType->includes(self))->size()+ Dependency.allInstances()->select(d:Dependency |d.client->includes(self) or d.supplier->includes(self))->size()
NA Class.allInstances()->select(c|c.getApplicableStereotypes().name->includes('Aspect'))->size()
125
![Tesis terminada[1]](https://img.document.onl/doc/110x75/555f46e8d8b42a0e4c8b4b42/tesis-terminada1.jpg)
