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.
Esta es una versión de prueba de citación de documentos de la Biblioteca Virtual Pro. Puede contener errores. Lo invitamos a consultar los manuales de citación de las respectivas fuentes.
Artículo:
Una antena lectora RFID UHF con identificación multietiqueta para sistemas médicos de temperatura extremadamente baja
Artículo:
Modelo AC para el despacho combinado de contratos bilaterales y bolsa de energía considerando restricciones de seguridad
Artículo:
Sobre la solución numérica de la ecuación de onda
Artículo:
Reconocimiento de objetivos espaciales basado en el microdoppler con una red paralela unidimensional
Artículo:
Partición de la escena de propagación de ondas de radio para carriles de alta velocidad
Libro:
Metodología del marco lógico para la planificación, el seguimiento y la evaluación de proyectos y programas
Artículo:
¿Por qué debemos conservar la fauna silvestre?
Artículo:
Emisiones globales de gases de efecto invernadero provenientes de materiales de construcción residencial y comercial: estrategias de mitigación para 2060
Guía:
Manual de operaciones de destilación