OOAspectZ and aspect-oriented UML class diagrams for Aspect-oriented software modelling (AOSM)

OOAspectZ y diagramas de clase orientados a los aspectos para la Modelación Orientada a Aspectos (MSOA)

En la búsqueda de desarrollo del software modularizado, la Programación Orientada a Aspectos (POA) identifica y representa de manera separada funcionalidades cruzadas en la etapa de programación del ciclo de desarrollo del software. Para las etapas previas del ciclo de desarrollo del software, particularmente, en la especificación de requerimientos y el diseño estructural de los datos y comportamientos, este trabajo propone y aplica OOAspectZ para la especificación formal de requerimientos orientados a aspectos, además, describe y aplica diagramas de clases UML orientados en el diseño y la asociación entre clases y aspectos, para el proceso de Desarrollo del Software Orientado a Aspectos (DSOA), respectivamente. Particularmente, OOAspectZ es un lenguaje que integra los lenguajes formales Object-Z y AspectZ, mientras que, los diagramas de clases UML orientados a aspectos representan la estructura del código de POA, clases de objetos y clases de funcionalidades cruzadas con el uso de estereotipos. Este artículo muestra y aplica las principales características de los lenguajes OOAspectZ y diagramas de clase UML orientados a aspectos, para la modelación del software orientado a aspectos (MSOA) que se aplican a un ejemplo clásico de POA, además, se entregan ideas de trabajo futuro respecto a una actual versión de POA.

Introducción

Según Kiczales et al., (1997) "en la implementación de sistemas, un aspecto es una propiedad que no puede encapsularse claramente en un procedimiento general". Además, los aspectos no pueden modularse mediante métodos tradicionales de procedimiento u orientados a objetos (OO) (Kiczales, & Mezini, 2005). Así, los aspectos intercalan los métodos encapsulados de un sistema, produciendo preocupaciones transversales. Para resolver estos problemas, AOP permite modularizar los aspectos para permitir el razonamiento modular en las preocupaciones transversales. Ejemplos típicos de problemas transversales en un sistema de software serían los problemas de registro y de seguridad.

Los aspectos saben qué elementos encapsulados deben ser asesorados, ya que (en la AOP clásica) cada aspecto declara explícitamente qué rutinas y clases deben ser asesoradas y en qué condiciones, es decir, los aspectos saben cuándo y dónde tienen que asesorar a los elementos encapsulados de un sistema mediante la definición de una regla de acceso puntual (PC). Un PC es un predicado que define puntos de unión (JP) entre los elementos de un sistema y los aspectos (Kiczales, & Mezini, 2005). Para un JP determinado, los aspectos pueden utilizar tres tipos de consejos: antes, después y alrededor. El comportamiento de los aspectos (asesoramiento) se añade o sustituye al comportamiento encapsulado (Kiczale et al., 1997; Kiczales, & Mezini, 2005). En el caso de las aplicaciones de software, los aspectos pueden modificar el comportamiento de su código base.