ArticlePDF Available

Abstract

El desarrollo de sistemas software actuales es necesario abordarlo mediante plataformas que permitan describir modelos de arquitectura complejos, distribuidos, evolutivos y reutilizables. PRISMA es un modelo que integra el Desarrollo de Software Basado en Componentes (DSBC) y el Desarrollo de Software Orientado a Aspectos (DSOA) para la construcción de modelos arquitectónicos. Dicho modelo permite evolucionar sus arquitecturas gracias a sus capacidades reflexivas implementadas mediante su meta-nivel. Este trabajo presenta la visión orientada a aspectos de PRISMA: el soporte que ofrece al DSOA, su capacidad de evolucionar aspectos y las ventajas que estos aportan al model
PRISMA: Arquitecturas Software Orientadas a Aspectos y
Basadas en Componentes
Jennifer Pérez, Nour H. Ali, Isidro Ramos, Jose A. Carsí
Departamento de Sistemas Informáticos y Computación
Universidad Politécnica de Valencia
Camino de Vera s/n
E-46022 Valencia – España
{jeperez | nourali | iramos | pcarsí}@dsic.upv.es
Resumen. El desarrollo de sistemas software actuales es necesario abordarlo
mediante plataformas que permitan describir modelos de arquitectura complejos,
distribuidos, evolutivos y reutilizables. PRISMA es un modelo que integra el
Desarrollo de Software Basado en Componentes (DSBC) y el Desarrollo de Software
Orientado a Aspectos (DSOA) para la construcción de modelos arquitectónicos.
Dicho modelo permite evolucionar sus arquitecturas gracias a sus capacidades
reflexivas implementadas mediante su meta-nivel. Este trabajo presenta la visión
orientada a aspectos de PRISMA: el soporte que ofrece al DSOA, su capacidad de
evolucionar aspectos y las ventajas que estos aportan al modelo.
Palabras clave: Arquitecturas Software Orientadas a Aspectos, Análisis y Diseño de
Software Orientado a Aspectos.
1. Introducción
Los sistemas de información cada vez son más difíciles de desarrollar debido a sus complejas
estructuras y a la dinámica y competitividad del mercado que implica una evolución constante de los
requisitos del sistema. Éstas, entre otras razones, hacen que los entornos de desarrollo deban permitir
construir aplicaciones con arquitecturas complejas, distribuidas, evolutivas y reutilizables.
El modelo PRISMA [Per03] se basa en componentes y aspectos para la construcción de modelos
arquitectónicos. Dicho modelo se caracteriza por la integración que realiza del Desarrollo de Software
Basado en Componentes (DSBC) y del Desarrollo de Software Orientado a Aspectos (DSOA) y por sus
propiedades reflexivas. El DSBC propone el desarrollo de sistemas software mediante el acoplamiento de
entidades que proporcionan servicios específicos. El paradigma orientado a aspectos integrado al DSBC
separa funcionalidades de las entidades (componentes) que pueden ser descritas independientemente de
las otras. De esta forma, es posible analizar, manipular y adaptar estas funcionalidades de forma separada
al resto. Además, la capacidad de reutilización no solo se limita a las entidades, también es posible
reutilizar estas funcionalidades separadas en aspectos. Estas ventajas son las que consigue PRISMA
mediante la integración de DSBC y DSOA. La capacidad reflexiva se consigue a través de un meta-nivel
que permite evolucionar al modelo arquitectónico. PRISMA se presenta como un enfoque integrado y
flexible para describir modelos de arquitectura complejos, distribuidos, evolutivos y reutilizables.
En este trabajo se presenta la definición de aspecto, el modo en que el modelo PRISMA da soporte al
desarrollo de software orientado a aspectos y las ventajas que éste le proporciona. Su estructura es la
siguiente: en primer lugar se presenta el modelo arquitectónico PRISMA. En el apartado 3, se presenta la
perspectiva de aspectos PRISMA. En el apartado 4 se comenta el estado del arte del desarrollo de
arquitecturas basadas en componentes y aspectos. Finalmente, en el apartado 5 se presentan las
conclusiones y trabajos futuros.
2. Modelo PRISMA
El modelo arquitectónico PRISMA que se presenta a continuación integra dos aproximaciones de
desarrollo de software, el DSBC y el DSOA. Esta integración se consigue definiendo los tipos mediante
la composición (monotónica) de aspectos.
La mayoría de modelos arquitectónicos analizan cuáles son los tipos básicos para la especificación de
sus arquitecturas y exponen su sintaxis y semántica. El modelo PRISMA, además de definir sus tipos,
también especifica los aspectos que cubren las necesidades de cada uno de ellos.
Un tipo del modelo de arquitectura puede ser visto como un prisma con tantas caras como aspectos
considere (ver figura 1). Dichos aspectos están definidos desde la perspectiva del problema y no de su
solución, aumentando el nivel de abstracción y evitando el solapamiento de código (no monotonicidad)
que puede producir la programación orientada a aspectos [Kic01].
El metanivel de PRISMA y las propiedades reflexivas de los lenguajes diseñados dan soporte tanto
para la evolución de los elementos, como para la reconfiguración dinámica de la topología. Esta
característica del modelo permite definir un metanivel por aspecto que reifica las propiedades que deseen
ser evolucionadas basándose en la reflexión de OASIS [Car99]. De este modo, PRISMA da soporte a la
evolución de sus modelos reduciendo el esfuerzo de mantenimiento de sus productos. La evolución
proporciona la dinámica del tipo, es decir, la capacidad de cambio de su estructura y comportamiento
basándose en la evolución del software que plantea la reflexión de OASIS.
Figura 1. Tipo PRISMA
El modelo arquitectónico consta de tres tipos: componentes, conectores y sistemas. Cada uno de estos
tipos esta compuesto por tantos aspectos como se consideren relevantes para definir el sistema de
información con precisión. Esto permite que el modelo PRISMA pueda analizarse desde dos perspectivas
diferentes (ver figura 2), la orientada a aspectos y la orientada a componentes. En este trabajo se presenta
la visión de aspectos del metamodelo PRISMA.
Visión Interna Visión Externa
Figura 2. Vistas de un componente PRISMA
PRISMA esta basado en el lenguaje de especificación formal OO llamado OASIS [Let98]. OASIS es
un lenguaje formal para definir modelos conceptuales de sistemas de información orientados a objetos,
que permite validar y generar las aplicaciones automáticamente a partir de la información capturada en
los modelos. PRISMA preserva las ventajas de OASIS, garantizando la compilabilidad de sus modelos, y
lo extiende, para poder definir formalmente la semántica de los modelos arquitectónicos, ya que OASIS
únicamente es capaz de especificar sistemas de información orientados a objetos.
NAVEGATIONAL
COORDINACIÓN
NIVEL
META
NIVE
L
BASE
DISTRIBUCIÓN
CALIDAD
FUNCIONAL
CONTEX
T
AWARENESS
NAVEGATIONAL
COORDINACIÓN
NIVEL
META
NIVE
L
BASE
DISTRIBUCIÓN
CALIDAD
FUNCIONAL
CONTEX
T
AWARENESS
3. DSOA en PRISMA
Los aspectos se definen en [Kiz97] como propiedades de un sistema que tienden a estar presentes en
varias componentes funcionales, dando lugar al término inglés crosscutting concerns. La distribución y
sincronización son ejemplos claros de crosscutting concerns a nivel de implementación, ya que no están
presentes en un solo componente, sino que están dispersas en varios.
En este trabajo se presenta una nueva definición de aspecto, entendiendo un aspecto como la
definición completa de la estructura y el comportamiento de un tipo desde un determinado punto de vista
(concern). Hay que tener en cuenta que dicho punto de vista puede ser cualquiera, incluso el funcional.
Por lo tanto, el crosscutting no sólo se realiza sobre propiedades funcionales sino sobre cualquier
concern.
El hecho de que el paradigma de la orientación a aspectos (AOP) y el DSOA hayan surgido de los
lenguajes de programación orientados a aspectos ya consolidados como AspectJ [Kic01], ha ocasionado
que la mayoría de aproximaciones abstraigan el concepto de aspecto a partir del nivel de implementación,
estando claramente influenciados por dichos lenguajes. Por este motivo, estas aproximaciones asocian
siempre el concepto de aspecto con propiedades no funcionales.
Sin embargo, en PRISMA se define el concepto de aspecto sin tener en cuenta las peculiaridades
sintácticas de dichos lenguajes. Su definición se basa en las características comunes de un sistema
susceptibles de ser reutilizadas. Atendiendo a esta definición, menos dependiente del lenguaje de
desarrollo, la funcionalidad es susceptible de reutilización en distintos tipos e incluso dicha funcionalidad
se puede subdividir en distintos aspectos. Los últimos trabajos de Ana Moreira [Brio03] empiezan a
apuntar hacia esta última idea, a pesar de no haberse llevado todavía a la práctica.
Figura 3. Aspectos asociados a un componente funcional
Este cambio de la definición de aspecto proporciona un conjunto de ventajas al modelo, permitiendo
que un tipo se construya mediante un operador composicional de aspectos (ver figura 4) y no mediante un
tipo funcional al que se le añaden aspectos (ver figura 3). De esta manera, se consigue un modelo más
uniforme, ya que los parámetros origen a partir de los cuales se construye el tipo son homogéneos. Por
otro lado, se consigue una mayor reutilización y modularidad al reutilizar el aspecto funcional y
considerar que puede ser común a un conjunto de tipos. Este aporte es importante, ya que la definición de
[Kic97] limita la posibilidad de que existan un conjunto de tipos que tengan en común su funcionalidad y
que lo que les diferencie unos de otros sean otros aspectos. Finalmente, se ha de tener en cuenta que esta
definición de aspecto hace que el modelo sea completamente independiente del lenguaje de
implementación, teniendo la posibilidad de compilarse tanto a lenguajes orientados a componentes como
a lenguajes orientados a aspectos.
Figura 4. Aspectos que forman un componente
En PRISMA, un aspecto puede verse como la unión de un conjunto de interfaces que incluyen
servicios del tipo del aspecto, más la especificación semántica de su estructura y comportamiento. Por lo
tanto, un aspecto es una plantilla que recoge las propiedades de estructura y comportamiento compartidas
por todas las instancias del componente que tengan dicho aspecto.
Un aspecto (
aspecto
) se define mediante una función de identificación (I) y una plantilla (P). De forma
que dicha plantilla esta representada por la tupla ( A, X ,Φ,), siendo:
A: El conjunto de atributos
X: El conjunto de servicios
Φ: El conjunto de formulas en lógica dinámica
: Términos en álgebra de procesos
A su vez, A y X forman la signatura o conjunto de interfaces que describen las propiedades visibles
del aspecto.
Existen diferentes tipos de aspecto, definiéndose cada uno de ellos de forma independiente. El número
de tipos de aspecto no esta limitado, ya que gracias al metanivel, se pueden definir nuevos. La necesidad
de nuevos tipos de aspecto emerge de los requisitos de los sistemas arquitectónicos a los que se aplique
PRISMA. Por lo tanto, a través de los requisitos del sistema se identificarán tanto los aspectos del sistema
como las necesidades que han de cubrir cada uno de ellos [Nav03].
Existe un conjunto de conceptos que forman un aspecto de forma general, además de aquellos propios
de cada aspecto. Estos estan definidos en el metamodelo de PRISMA, tal y como se muestra en la figura
5.
Figura 5. Paquete aspecto del metamodelo de PRISMA
La especificación de la relación inter-aspectos se realiza en el componente mediante el weaving. El
weaving es necesario para sincronizar los aspectos que componen un componente. Esta sincronización es
necesaria ya que la ejecución de un servicio en un aspecto puede desencadenar acciones en otro aspecto
de la componente y a que las decisiones que se toman en un aspecto pueden estar influenciadas por el
valor de los atributos de otros aspectos. Por ejemplo, el seguir un enlace del aspecto navegacional puede
implicar un cambio en el aspecto de presentación de la componente.
El weaving se realiza en el componente porque de ese modo se preserva la independencia y
reutilización de los aspectos y se aumenta la flexibilidad del modelo. La independencia y reutilización se
consiguen al no definir dentro de cada aspecto su sincronización con el resto, ya que no se establecen
referencias que generen dependencias con otros aspectos. Mientras que la flexibilidad se aumenta debido
a que es posible establecer un comportamiento diferente en componentes que estén formados por los
mismos aspectos, definiendo distintas sincronizaciones inter-aspectos. Por ejemplo, la invocación de un
link del aspecto navegacional de un componente se puede sincronizar con un servicio que realice un
cambio en el aspecto de presentación del componente; sin embargo, en otro componente, en el que el
servicio que se desencadene en el aspecto de presentación sea diferente, obteniendo así en cada caso una
presentación de la información en un formato diferente.
La sincronización entre servicios PRISMA de diferentes aspectos se puede realizar de tres formas
diferentes: after, before o around. Estas tres formas de sincronizar los servicios inter-aspectos son las que
propone la programación orientada a aspectos. PRISMA mantiene los tres modos de sincronización, no
sólo por seguir el enfoque orientado a aspectos, también porque cubren todas las necesidades de
sincronización inter-aspecto que el modelo PRISMA necesita.
4. Estado del arte
En la actualidad existen una gran variedad de trabajos relacionados con modelos arquitectónicos,
componentes, aspectos, lenguajes de definición de arquitecturas, reconfiguración dinámica de
arquitecturas y todo aquello que guarda relación con el desarrollo de sistemas software complejos. Este
gran esfuerzo de investigación persigue el objetivo de encontrar un consenso en los conceptos básicos de
sistemas software complejos, así como una definición precisa y una metodología a aplicar para su
desarrollo.
El concepto de arquitectura software está muy extendido, sin embargo no existe una definición única y
estándar para este concepto. Un autor, cuya contribución en el mundo de las arquitecturas software y las
componentes ha sido muy aceptada, es David Garlan. Sus trabajos han sido un gran precedente en la
elaboración de este trabajo y su definición de arquitectura es una de las más utilizadas en la literatura
[Gar95].
La arquitectura software esta compuesta por la estructura de los componentes de un programa o
sistema, sus interrelaciones, y los principios y reglas que gobiernan su diseño y evolución a lo largo del
tiempo.
En una línea cercana a la nuestra, se encuentra Model-Driven Architecture (MDA), un enfoque
propuesto por la OMG (www.omg.org) para la integración e interoperabilidad de los sistemas. MDA
enfatiza el modelado (con UML) independiente de las plataformas de implementación. MDA está basado
en el modelado de diferentes aspectos y niveles de abstracción, explotando las interrelaciones y
estableciendo transformaciones hacia su implementación.
El desarrollo de software orientado a aspectos [Aos03] esta teniendo un gran auge en la comunidad
informática debido a que su código modular consigue que los costes de desarrollo, mantenimiento y
evolución del software se reduzcan. Por este motivo, existe una tendencia hacia la incorporación del
concepto de aspecto desde las primeras fases del ciclo de vida, existiendo trabajos elaborados en el área
de la especificación de requisitos [Ras02].
El principio de separation of concerns propone la encapsulación de propiedades en entidades
separadas que localicen los cambios y traten una misma cuestión. Se han propuesto varios modelos de
separación de propiedades, sin embargo, de todos ellos el que ha tenido una mayor aceptación ha sido el
paradigma orientado a aspectos (AOP).
Dentro de los distintos modelos de aspectos que se han creado hasta el momento, se pueden observar
dos claras tendencias que permiten clasificarlos en dos grandes grupos: los modelos estáticos y los
dinámicos. La diferencia entre ambos se encuentra en el proceso de generación de código. Los modelos
estáticos (AspectJ) generan un solo componente en el que se encuentra mezclado el código funcional y el
código de los aspectos, mientras que en los modelos dinámicos se generan distintas entidades para los
distintos aspectos y el componente (Modelo de disfraces) [Her03] . La ventaja de los modelos dinámicos
es la facilidad que proporcionan para incluir o eliminar aspectos durante el proceso de ejecución.
Alguna de las aproximaciones que han integrado el DSBC y el DSOA a nivel de implementación han
extendido los java beans utilizando aspectos para su descripción y añadiendo el concepto de conectores
[Suv03]. Además, los aspectos pueden ser manipulados en tiempo de ejecución. Un trabajo que describe
los asuntos que se tienen que tener en consideración para la integración de ambos aproximaciones es
introducido en [Con00]. Los asuntos y requisitos descritos en este trabajo son contemplados en PRISMA.
5. Conclusiones y Trabajos Futuros
Se ha presentado el modelo PRISMA desde su punto de vista orientado a aspecto. Dicho modelo se
caracteriza por el tratamiento de los aspectos a un alto nivel de abstracción, su capacidad de evolución en
el marco de la orientación de aspectos, su definición de concern y el modo en el que se realiza el weaving
monotónico entre aspectos. Todas estas propiedades dotan a PRISMA de una gran flexibilidad,
reutilización, modularidad y evolución dentro del desarrollo orientado aspectos.
Existen una gran variedad de trabajos que se desean abordar dentro de los distintos aspectos que
soporta el modelo PRISMA. Las líneas de trabajo a corto plazo a destacar se centran en el operador
monotónico de weaving y su especificación en el lenguaje de definición de arquitecturas PRISMA y la
elaboración de un profile UML para la especificación gráfica de modelos arquitectónicos PRISMA.
6. Bibliografía
[Aos03] Aspect Oriented Software Development, http://aosd.net
[Bri03] I Brito, A. Moreira. Towards a Composition Process for Aspect-Oriented Requirements. Early
Aspects 2003: Aspect-Oriented Requirements Engineering and Architecture Design, workshop
of the 2nd International Conference on Aspect-Oriented Software Development,Boston, USA,
17 March 2003.
[Car99] Carsí J. A., "OASIS como marco conceptual para la evolución del software". Ph.D. Thesis 1999.
DSIC (Universidad Politécnica de Valencia).
[Con00] Constantinides C.A., Errad T., “On the Requirements for Concurrent Software Architectures to
Support Advanced Separation of Concerns", Proceedings of OOPSLA 2000 Workshop on
Advanced Seperation of Concerns in Object-Oriented Systems
[Kic01] G. Kiczales, E. Hilsdale, J. Huguin, M. Kersten, J. Palm, W.G. Griswold, An Overview of
AspectJ, proceeding of the European Conference on Object-Oriented Programming, Springer-
Verlag, 2001.
[Kiz97] G. Kiczales et al., Aspect-Oriented Programming, Proc. European Conference on Object-
Oriented Programming (ECOOP’ 97). LNCS 1241, Springer Verlang, 1997.
[Her03] Herrero, Propuesta de una Plataforma, Lenguaje y Diseño para el desarrollo de Aplicaciones
Orientadas a Aspectos, Tesis Doctoral, Extremadura, España, 2003.
[Let98] Letelier P., Sánchez P., Ramos I., Pastor O. OASIS 3.0: "Un enfoque formal para el modelado
conceptual orientado a objeto". Universidad Politécnica de Valencia, SPUPV -98.4011, ISBN
84-7721- 663-0, 1998.
[Nav03] E. Navarro, I. Ramos, J. Pérez, Software Requirements for Architectured Systems, 11t h IEEE
International Requirements Engineering Conference (RE'03), September 8-12, 2003 in
Monterey, California. (Pendiente de Publicación)
[Per03a] J. Pérez, I. Ramos, J. Jaén and P. Letelier, E. Navarro: “PRISMA: Towards Quality, Aspect
Oriented and Dynamic Software Architectures”, 3rd IEEE International Conference on Quality
Software (QSIC 2003), Dallas, Texas, USA, November 6 - 7, 2003 (Pendiente de Publicación)
[Ras02] A. Rashid, P. Sawer, A. Moreira, J. Araújo. “Early Aspects: a Model for Aspect-Oriented
Requirements Engineering”, International Conference on Requirements Engineering (RE 2002),
University of Essen, Germany, September 9-13, 2002.
[Suv03] ] Sube D., Vanderperren W., Jonckers V., JAsCo: an Aspect-Oriented approach tailored for
CBSD. In Proceedings of AOSD International Conference, Boston USA. ACM Press. March
2003.
ResearchGate has not been able to resolve any citations for this publication.
Conference Paper
Full-text available
The development of software systems must be done using platforms that allow the description of quality, complex, distributed, dynamic and reusable architectural models. We present in this paper PRISMA, an architectural modelling approach based on aspects and components that uses a component definition language (components, connectors and systems) to define architectural types at a high abstraction level and a configuration language to design the architecture of software systems. The component definition language increases reuse allowing importation of COTS and reduces complexity by integrating two modern software development approaches: component-based software development and aspect-oriented software development. The configuration language designs the architecture of software systems by creating and interconnecting instances of the defined types including possible imported COTS. PRISMA has a metalevel with reflexive properties for these two languages. For this reason, the types of PRISMA may evolve and the topologies of PRISMA may be reconfigured dynamically.
Article
Full-text available
OASIS v.3.0 es un enfoque formal para la especificación de modelos conceptuales siquiendo el enfoque orientado a objetos. Esta nueva versión supone diversas mejoras y aportaciones que podemos resumir en: (1) definición de un marco formal homogéneo para el modelo OASIS, (2) incorporación de la perspectiva cliente, (3) consideración de un concepto de proceso más amplio que engloba obligaciones y prohibiciones, (4) enriquecimiento de los mecanismos de definición de clases complejas (agregación y herencia, (5) incorporación de un metanivel que permite abordar aspectos relativos a evolución y reutilización de especificaciones software, y (6) presentación de OASIS como un lenguaje con una sintaxis bien definida Este trabajo está financiado por el proyecto MENHIR de la Comisión Interministerial de Ciencia y Tecnología con referencia TIC97-0593-C05-01
Conference Paper
Full-text available
Recently, increased attention has been paid to how to establish and strengthen the relationships between requirements and architectural design. In particular, how the process must encompass changes to requirements over time and their effects upon a system's architecture. We sketch our work-in-progress in this field, which we concern about a methodology to guide the architecture development from the inception.
Conference Paper
Full-text available
Effective RE must reconcile the need to achieve separation of concerns with the need to satisfy broadly scoped requirements and constraints. Techniques such as use cases and viewpoints help achieve separation of stakeholders' concerns but ensuring their consistency with global requirements and constraints is largely unsupported. We build on recent work that has emerged from the aspect-oriented programming (AOP) community to propose a general model for aspect oriented requirements engineering (AORE). The model supports separation of crosscutting functional and non-functional properties at the requirements level. We argue that early separation of such crosscutting properties supports effective determination of their mapping and influence on artefacts at later development stages. A realisation of the model based on a case study of a toll collection system is presented.
Article
Full-text available
In this paper we initiate a discussion of a possible process to compose crosscutting concerns with the concerns they cut across. This process should be regarded as a task of an approach to manage concerns at the requirements level. The main concepts behind this process are those of match point, conflicting aspect, dominant aspect and composition rule. A match point is where one or more crosscutting concerns are applied to a given functional concern (or model element). This information is useful to identify conflicting crosscutting concerns. To resolve conflicts we need to identify dominant crosscutting concerns, i.e. the concerns with higher priority. Finally, the composition rule is defined as a sequential list of simpler compositions of crosscutting concern, some operators and the model element.
Conference Paper
form only given on an article discussing Aspect-oriented programming.
OASIS como marco conceptual para la evolución del software
  • J A Carsí
Carsí J. A., "OASIS como marco conceptual para la evolución del software". Ph.D. Thesis 1999. DSIC (Universidad Politécnica de Valencia).
Towards a Composition Process for Aspect-Oriented Requirements Early Aspects 2003: Aspect-Oriented Requirements Engineering and Architecture Design
  • I Brito
  • A Moreira
I Brito, A. Moreira. Towards a Composition Process for Aspect-Oriented Requirements. Early Aspects 2003: Aspect-Oriented Requirements Engineering and Architecture Design, workshop of the 2nd International Conference on Aspect-Oriented Software Development,Boston, USA, 17 March 2003.
Lenguaje y Diseño para el desarrollo de Aplicaciones Orientadas a Aspectos
  • Propuesta Herrero
  • De Una Plataforma
Herrero, Propuesta de una Plataforma, Lenguaje y Diseño para el desarrollo de Aplicaciones Orientadas a Aspectos, Tesis Doctoral, Extremadura, España, 2003.
JAsCo: an Aspect-Oriented approach tailored for CBSD
  • D Sube
  • W Vanderperren
  • V Jonckers
Sube D., Vanderperren W., Jonckers V., JAsCo: an Aspect-Oriented approach tailored for CBSD. In Proceedings of AOSD International Conference, Boston USA. ACM Press. March 2003.