SlideShare une entreprise Scribd logo
1  sur  6
Télécharger pour lire hors ligne
INTRODUCCIÓN A LA ORIENTACIÓN A ASPECTOS


La motivación: Separación de incumbencias
En la Ingeniería del Software se ha utilizado durante años el principio de la separación de incumbencias 
(Separation of Concerns) para gestionar la complejidad del desarrollo de software mediante la separación 
de   las   funcionalidades   principales   de   la   aplicación   de   otras   partes   con   un   propósito   específico, 
ortogonales a la funcionalidad principal (autenticación, administración, rendimiento, gestión de memoria, 
logging, etc.). La aplicación final se construye con el código de las funcionalidades principales más el 
código de propósito específico. Los principales beneficios de esta aproximación son: 

     •    Un nivel  de abstracción  más alto, porque el desarrollador se puede centrar en incumbencias 
          concretas y de forma aislada.
     •    Una mayor facilidad a la hora de entender la funcionalidad de la aplicación.
     •    El   código   que   implementa   dicha   funcionalidad   no   está   entremezclado   con   el   de   otras 
          incumbencias.
     •    Una mayor reusabilidad al haber un menor acoplamiento.
     •    Una mayor mantenibilidad del código, al ser éste menos complejo.
     •    Una mayor flexibilidad en la integración de componentes.
     •    Un incremento de la productividad en el desarrollo.

Una   buena   SoC   debe   poder   identificar   y   manejar   de   forma   individual   los   distintos   componentes   del 
sistema tanto en la fase de diseño como en la codificación.
A lo largo de los años se han desarrollado aproximaciones y técnicas para conseguir la SoC, que han ido 
evolucionando con el objetivo de hacer frente a las características cambiantes, ámbito y complejidad de 
las aplicaciones software. Entre ellas, una de las más destacables es el Desarrollo de Software Orientado 
a Aspectos (DSOA).


Definición de Aspecto
Puesto que el DSOA es una aproximación de la SoC, antes de definir un aspecto es mejor saber qué es 
una  incumbencia:   básicamente,   todo   lo   que   sea   importante   para   la   aplicación,   ya   sea   código, 
infraestructura, requerimientos, elementos de diseño, etc.
En el DSOA hay dos términos muy importantes:


     •    Un  componente   (component)  es   el   módulo   software   que   puede   ser   encapsulado   en   un 
          procedimiento   (un   objeto,   método,   procedimiento   o   API).   Los   componentes   serán   unidades 
          funcionales en las que se descompone el sistema.
     •    Un  aspecto  (aspect)   es   aquel   módulo   software   que   no   puede   ser   encapsulado   en   un 
          procedimiento.   No   son   unidades   funcionales   en   las   que   se   pueda   dividir   un   sistema,   sino 
          propiedades que afectan a la ejecución o semántica de los componentes, por ejemplo, la gestión 
          de la memoria o la sincronización de hilos.

Un aspecto es una clase particular de incumbencia. La definición formal más aceptada es: “Un aspecto es 
una   unidad   modular   que   se   disemina   por   la   estructura   de   otras   unidades   funcionales.   Los   aspectos 
existen tanto en la etapa de diseño como en la de implementación. Un aspecto de diseño es una unidad 
modular   del   diseño   que   se   entremezcla   en   la   estructura   de   otras   partes   del   diseño.   Un   aspecto   de 
programa o de código es una unidad modular del programa que aparece en otras unidades modulares del 
programa” [Kiczales97]:
De una forma más básica, se puede decir que los aspectos son elementos que se diseminan por todo el 
código y son difíciles de describir con respecto a otros componentes.

En la parte izquierda de la siguiente figura puede verse la forma que tiene el código de un programa que 
sigue el paradigma Orientado a Objetos. Se puede observar que está entremezclado y resulta difícil de 
entender,   depurar   y   modificar.   En   cambio,   siguiendo   el   DSOA,   en   la   parte   derecha   de   la   figura,   las 
diferentes incumbencias están separadas, con lo que resulta más fácil entenderlas y trabajar con ellas.




Cómo Funciona la POA
Básicamente en el funcionamiento de la POA se pueden identificar tres pasos:

     1.    Descomposición en aspectos: Se descomponen los requerimientos para identificar las distintas 
           incumbencias (las comunes y aquellas que se entremezclan con el resto).
     2.    Implementación   de   incumbencias:  Se  implementan  de  forma  independiente  las  incumbencias 
           detectadas anteriormente, tanto la funcionalidad básica como los aspectos ortogonales.
     3.    Recomposición   de   aspectos:   En   este   proceso,   denominado  tejido   (weaving),   se   toman   los 
           módulos implementados anteriormente (funcionalidad básica y aspectos) y se tejen para formar 
           el sistema completo. Esta tarea es realizada por el tejedor de aspectos (aspect weaver).

Los lenguajes orientados a aspectos definen una nueva unidad de programación de software, el aspecto, 
para encapsular las funcionalidades que están diseminadas (crosscutted) y enmarañadas (tangled)  por 
todo el código. A la hora de formar el sistema se ve que hay una relación entre los componentes y los 
aspectos, y que, por lo tanto, el código de ambos tiene que interactuar de alguna manera. Para que los 
aspectos y los componentes se mezclen, deben fijarse los puntos donde puedan hacerlo, que son lo que 
se conoce como puntos de enlace (joinpoints).
El proceso de realizar esta unión se conoce como tejido (weave), y el encargado de realizarlo es el tejedor 
de aspectos (aspect weaver). El tejedor, además de los aspectos, los módulos y los puntos de enlace, 
recibe unas reglas que le indican cómo debe realizar el tejido. Dichas reglas son los llamados puntos de 
corte (pointcuts), que indican al tejedor qué aspecto tiene que aumentar a qué módulo a través de qué 
punto de enlace.
El   código  de   los   aspectos   normalmente   recibe el nombre de  advice,  al ser el término utilizado en el 
sistema AspectJ y que han adoptado la mayoría de sistemas posteriores.
Realmente, los aspectos describen unos añadidos al comportamiento de los objetos, hacen referencia a 
las clases de estos y definen en qué punto se han de colocar los añadidos.

Como se puede ver en la figura siguiente, en las metodologías tradicionales el proceso de generar un 
programa consistía en pasar el código a través de un compilador o un intérprete para así disponer de un 
ejecutable.   En   la   POA   no   se   tiene   un   único   código   del   programa   sino   que   el   que   implementa   la 
funcionalidad básica y el de cada uno de los aspectos están separados. Todo este código debe pasar no 
sólo a través del compilador, sino que debe ser tratado por el tejedor, que es el que se encarga de crear 
un único programa con toda la funcionalidad, la básica más los aspectos.




Terminología
Aunque ya se han mencionado algunos de los términos que se emplean en la POA, a continuación se 
definirán los más importantes:


         Incumbencia:   Todo   aquello   que   resulta   importante   para   una   aplicación   (requisitos, 
          infraestructura, código, etc.).
         Componente:   Módulo   software   que  puede ser  encapsulado en  un procedimiento  (un objeto, 
          método,   procedimiento,   API).   Los   componentes   son   unidades   funcionales   en   las   que   se 
          descompone el sistema.
         Aspecto: Módulo software que no puede ser encapsulado en un procedimiento. Los aspectos no 
          son unidades funcionales en las que se pueda dividir un sistema, sino propiedades que afectan a 
          la ejecución o semántica de los componentes.
    Punto de enlace (joinpoint): Punto de la ejecución de un programa bien definido donde se podrá 
          añadir código, es decir, funcionalidad. No todos los puntos de ejecución de un programa son 
          puntos de enlace, sino solo aquellos que se puedan tratar de forma controlada. Cada sistema 
          que soporta POA ofrece una serie de puntos de enlace distintos, como invocaciones a métodos, 
          acceso a campos, etc.
         Sombra de punto de enlace (joinpoint shadow): “Sombra” que deja un punto de enlace a bajo 
          nivel   (en   código   intermedio,   por   ejemplo  bytecode  de   Java).   Existen   puntos   de   enlace   cuya 
          sombra se corresponde con una instrucción y es sencilla de localizar. En cambio, para otros la 
          sombra no se corresponde con una única instrucción o, incluso, no se corresponde con ninguna 
          instrucción sino con una zona del código.
         Punto de corte (pointcut): Conjunto de instrucciones que se le pasan al tejedor para que sepa 
          qué código (advice  del aspecto) se debe añadir en qué punto de enlace a una aplicación. Un 
          ejemplo podría ser invocar el método X del aspecto cuando se produzca un acceso de lectura al 
          campo Y de la clase C.
         Advice: Código del aspecto que se ejecuta en los puntos de enlace seleccionados por un punto 
          de corte. Normalmente, desde su código se puede acceder al contexto de ejecución del punto de 
          enlace (como los valores de variables, etc.).


Tipos de POA
El proceso de tejido es el punto más importante para cualquier solución que emplee POA. En la definición 
original de ésta, Kiczales y su equipo especificaron las siguientes posibilidades para hacer el tejido:


         Un preprocesador que haga las sustituciones pertinentes en el código.
         Un postprocesador que modifique archivos binarios.
         Un compilador que soporte POA y que genere archivos con el tejido realizado.
         Tejido en tiempo de carga, realizando el proceso cuando las clases son cargadas en memoria, 
          como haría Java con la JVM.
         Tejido en tiempo de ejecución, capturando cada punto de enlace mientras el programa está en 
          funcionamiento y ejecutando el código que corresponda.


Posteriormente   se   ha   presentado   una   alternativa   denominada   “tejido   en   tiempo   de 
despliegue” (deploytime weaving), que implica un postprocesamiento del código, pero en vez de modificar 
el   código   generado,   se   generan   subclases   a   partir   de   las   clases   existentes,   introduciendo   las 
modificaciones pertinentes mediante redefinición de métodos. Las clases que ya existían no se modifican 
en   ningún   momento,   con   lo   que   todas   las  herramientas  ya  existentes  pueden  ser  usadas  durante  el 
desarrollo.   Una   aproximación   similar   a   esta   se   ha   usado   en   la   implementación   de   servidores   de 
aplicaciones JavaEE como IBM WebSphere.
Si se utiliza como criterio el  momento  en el que se realiza el tejido se distinguen entre  tejido estático  y 
tejido dinámico. De las formas de tejido anteriormente mencionadas todas son estáticas, excepto el tejido 
en tiempo de carga y el tejido en tiempo de ejecución, que son dinámicas.


Tejido estático
La mayoría de las actuales implementaciones de POA están basadas en el tejido estático, que consiste en 
la modificación en tiempo de compilación del código fuente, insertando llamadas a las rutinas específicas 
de   los   aspectos.   Los   lugares   donde   estas   llamadas   se   pueden   insertar   son   los  puntos   de   enlace 
(joinpoints), definidos por cada sistema.
En la figurar anterior se puede ver el proceso que se sigue en el tejido estático. Se parte del programa con 
la funcionalidad básica implementada en un lenguaje base (C++, Java, etc.) y además se tiene uno o 
varios aspectos, escritos en un lenguaje de aspectos que puede ser una extensión de algún lenguaje 
normal, o uno específicamente definido con este fin. 
Por aspecto se entiende el código que se debe añadir (advice) y las instrucciones que recibe el tejedor 
sobre  dónde   y   cómo  insertar   el   código   de   los   aspectos   en   el   código   principal   (pointcut).   Estas 
instrucciones pueden venir expresadas en el mismo lenguaje o en otro particular, y pueden encontrarse 
en el mismo fichero o en otro.
El   tejedor   realiza   la   composición   de   código,   insertando   el   proveniente   de   los   aspectos   en   el   de   la 
funcionalidad básica, siguiendo las instrucciones recibidas. El resultado es un nuevo código fuente que 
pasará a través de un compilador, el cual generará el programa ejecutable.


El  tejido   estático  presenta   algunos  inconvenientes como la imposibilidad de adaptarse a cambios (no 
previstos   en   el   momento   del   desarrollo   del   programa)   en   el   entorno   de   ejecución,   debido   a   que   la 
aplicación final es generada tejiendo la funcionalidad básica con los aspectos en tiempo de compilación; 
cualquier funcionalidad que necesite ser adaptada en tiempo de ejecución implica detener la aplicación, 
recompilarla con los nuevos aspectos e iniciarla de nuevo. Por ello, el uso del tejido estático no es factible 
en aplicaciones que no puedan detenerse y que necesiten ser adaptadas.


Al mismo tiempo, la depuración de una aplicación ya compilada a la que se hayan añadido los aspectos 
es una tarea compleja porque el código que se debe analizar es el resultante del proceso de tejido: el 
código original está entremezclado con el de los aspectos, que estará diseminado por toda la aplicación.
La principal ventaja que ofrecen estos sistemas es que se evita que el uso de la POA derive en una 
penalización en el rendimiento, ya que antes de la compilación se dispone de la totalidad del código, 
pudiendo ser optimizado por el compilador.
Una desventaja muy importante que suelen presentar las herramientas que ofrecen tejido estático (y las 
que ofrecen tejido dinámico) es que son dependientes del lenguaje, no pudiendo crear distintos aspectos 
en distintos lenguajes. Por ejemplo, AspectJ sólo puede usarse con el lenguaje Java.


Tejido dinámico
Usando un tejedor estático, el programa final se genera tejiendo el código de la funcionalidad básica y el 
de los aspectos seleccionados en la fase de compilación. Si se quiere enriquecer la aplicación con un 
nuevo   aspecto,   o   incluso   eliminar   uno   de   los   aspectos   actualmente   tejidos,   el   sistema   debe   ser 
recompilado y reiniciado.
Aunque no todas las aplicaciones necesitan ser adaptadas mediante aspectos en tiempo de ejecución, 
hay aspectos específicos que se benefician de un sistema con tejido dinámico; puede haber aplicaciones 
que necesiten adaptar sus competencias específicas en respuesta a cambios en el entorno de ejecución, 
como la gestión de recursos y el equilibrio de carga en sistemas distribuidos, entre otros.
En la  última figura  se puede  ver representado el proceso del tejido dinámico. En un primer paso, un 
programa escrito en un lenguaje “normal” pasa por el compilador y se genera un programa que se pone 
en ejecución y que no tiene por qué saber que va a ser adaptado. Cuando se necesita adaptar (añadir o 
modificar funcionalidad) porque surgen nuevos requerimientos o en respuesta a cambios en el entorno, 
sin   detenerlo,   se   procesa   el   programa   en  ejecución   (no  el   programa  ejecutable,   sino  el   que  está   en 
memoria) junto a los aspectos que van a adaptarlo, y por medio del tejedor se le añade la funcionalidad de 
estos, dando lugar a una nueva versión del programa que continúa la ejecución. El programa ejecutable 
inicial no ha sido modificado, con lo que se puede utilizar de nuevo sin las modificaciones realizadas en 
memoria.


En sistemas que usan tejido dinámico de aspectos, la funcionalidad básica permanece separada de los 
aspectos en todo el ciclo de vida del software, incluso en la ejecución del sistema. El código resultante es 
más   adaptable   y   reutilizable,   y   los   aspectos   y   la   funcionalidad   básica   pueden   evolucionar   de   forma 
independiente.


Muchas de las herramientas que afirman ofrecer un tejido dinámico de aspectos realmente ofrecen un 
híbrido   entre   el   tejido   estático   y   el   dinámico,   pues   los   aspectos   deben   conocerse   y   definirse   en   el 
momento   del   diseño   e   implementación,   para   posteriormente   poder   instanciarlos   durante   la   ejecución. 
Aunque esta solución aporta alguna ventaja respecto al tejido estático hay casos en que no es suficiente, 
por ejemplo, cuando una vez que la aplicación está funcionando surge un requerimiento nuevo que no se 
tuvo en cuenta en el diseño.
Al igual que ocurre con las herramientas de tejido estático, la mayoría de las herramientas que ofrecen 
tejido dinámico son dependientes del lenguaje.
La  principal  desventaja  del  tejido  dinámico respecto al estático es el menor rendimiento en ejecución 
causado por la adaptación dinámica de las aplicaciones.



Referencias

Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Videira Lopes, Jean-
Marc Loingtier, John Irwin, Aspect-Oriented Programming, 1997.

Luis Vinuesa, Separación Dinámica de Aspectos independiente del Lenguaje y Plataforma
mediante el uso de Reflexión Computacional, 2007.

Contenu connexe

Tendances

METODOLOGÍA PARA EL DISEÑO DE SOFTWARE
METODOLOGÍA PARA EL DISEÑO DE SOFTWAREMETODOLOGÍA PARA EL DISEÑO DE SOFTWARE
METODOLOGÍA PARA EL DISEÑO DE SOFTWAREadark
 
Sesion1.1 uml
Sesion1.1 umlSesion1.1 uml
Sesion1.1 umlyonnyl
 
FUNDAMENTO DEL DISEÑO DE SOFTWARE
FUNDAMENTO DEL DISEÑO DE SOFTWAREFUNDAMENTO DEL DISEÑO DE SOFTWARE
FUNDAMENTO DEL DISEÑO DE SOFTWAREEstebanOrtegon
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructuradoazuajesimon
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructuradoDascorp
 
Programación orientada a aspectos
Programación orientada a aspectosProgramación orientada a aspectos
Programación orientada a aspectosprogramadorjavablog
 
P R O G R A M A C I O N O R I E N T A D A
P R O G R A M A C I O N  O R I E N T A D AP R O G R A M A C I O N  O R I E N T A D A
P R O G R A M A C I O N O R I E N T A D Achayna
 
Fundamentos del sofware
Fundamentos del sofwareFundamentos del sofware
Fundamentos del sofwareKatyPerez17
 
Fundamentos de Diseño Orientado a Objetos
Fundamentos de Diseño Orientado a ObjetosFundamentos de Diseño Orientado a Objetos
Fundamentos de Diseño Orientado a Objetosforwer1223
 
Capitulo04
Capitulo04Capitulo04
Capitulo04martin
 
Diseno Software
Diseno SoftwareDiseno Software
Diseno Softwarealfmuny
 
Proyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de CosteProyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de CosteCAMILO
 

Tendances (19)

METODOLOGÍA PARA EL DISEÑO DE SOFTWARE
METODOLOGÍA PARA EL DISEÑO DE SOFTWAREMETODOLOGÍA PARA EL DISEÑO DE SOFTWARE
METODOLOGÍA PARA EL DISEÑO DE SOFTWARE
 
Sesion1.1 uml
Sesion1.1 umlSesion1.1 uml
Sesion1.1 uml
 
Diseño arquitectónico
Diseño arquitectónicoDiseño arquitectónico
Diseño arquitectónico
 
FUNDAMENTO DEL DISEÑO DE SOFTWARE
FUNDAMENTO DEL DISEÑO DE SOFTWAREFUNDAMENTO DEL DISEÑO DE SOFTWARE
FUNDAMENTO DEL DISEÑO DE SOFTWARE
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructurado
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructurado
 
Programaciuon
ProgramaciuonProgramaciuon
Programaciuon
 
Programación orientada a aspectos
Programación orientada a aspectosProgramación orientada a aspectos
Programación orientada a aspectos
 
Fis 4 5
Fis 4 5Fis 4 5
Fis 4 5
 
P R O G R A M A C I O N O R I E N T A D A
P R O G R A M A C I O N  O R I E N T A D AP R O G R A M A C I O N  O R I E N T A D A
P R O G R A M A C I O N O R I E N T A D A
 
Fundamentos del sofware
Fundamentos del sofwareFundamentos del sofware
Fundamentos del sofware
 
Sesion 2
Sesion 2Sesion 2
Sesion 2
 
Fundamentos de Diseño Orientado a Objetos
Fundamentos de Diseño Orientado a ObjetosFundamentos de Diseño Orientado a Objetos
Fundamentos de Diseño Orientado a Objetos
 
Capitulo04
Capitulo04Capitulo04
Capitulo04
 
Modelado, Ingenieria de Software
Modelado, Ingenieria de SoftwareModelado, Ingenieria de Software
Modelado, Ingenieria de Software
 
Poa 01
Poa 01Poa 01
Poa 01
 
Diseno Software
Diseno SoftwareDiseno Software
Diseno Software
 
Proyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de CosteProyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de Coste
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructurado
 

En vedette

Trendlines: Perspectives on Utah's Economy, Nov/Dec 2009
Trendlines: Perspectives on Utah's Economy, Nov/Dec 2009Trendlines: Perspectives on Utah's Economy, Nov/Dec 2009
Trendlines: Perspectives on Utah's Economy, Nov/Dec 2009State of Utah, Salt Lake City
 
Unit 3 presentation
Unit 3 presentationUnit 3 presentation
Unit 3 presentationJessBenrud
 
Programa universitario en medicina dermatológica
Programa universitario en medicina dermatológicaPrograma universitario en medicina dermatológica
Programa universitario en medicina dermatológicazarelacielo
 
Assises Internationales du Journalisme et de l'Information
Assises Internationales du Journalisme et de l'InformationAssises Internationales du Journalisme et de l'Information
Assises Internationales du Journalisme et de l'InformationMarc Mentré
 

En vedette (7)

Trendlines: Perspectives on Utah's Economy, Nov/Dec 2009
Trendlines: Perspectives on Utah's Economy, Nov/Dec 2009Trendlines: Perspectives on Utah's Economy, Nov/Dec 2009
Trendlines: Perspectives on Utah's Economy, Nov/Dec 2009
 
Informe Argentina 2013
Informe Argentina 2013Informe Argentina 2013
Informe Argentina 2013
 
jorgegavilanesviscarra
jorgegavilanesviscarrajorgegavilanesviscarra
jorgegavilanesviscarra
 
Unit 3 presentation
Unit 3 presentationUnit 3 presentation
Unit 3 presentation
 
Ley organica de salud
Ley organica de saludLey organica de salud
Ley organica de salud
 
Programa universitario en medicina dermatológica
Programa universitario en medicina dermatológicaPrograma universitario en medicina dermatológica
Programa universitario en medicina dermatológica
 
Assises Internationales du Journalisme et de l'Information
Assises Internationales du Journalisme et de l'InformationAssises Internationales du Journalisme et de l'Information
Assises Internationales du Journalisme et de l'Information
 

Similaire à Introducción A La Orientación A Aspectos - Programador PHP

Fundamentos Basicos para El Diseño de Software
Fundamentos Basicos para El Diseño de SoftwareFundamentos Basicos para El Diseño de Software
Fundamentos Basicos para El Diseño de SoftwareRicardoAlvarez235
 
Fundamentos del diseño de software
Fundamentos del diseño de software Fundamentos del diseño de software
Fundamentos del diseño de software AlessandreMndez
 
Aspect Oriented Programming Middleware
Aspect Oriented Programming MiddlewareAspect Oriented Programming Middleware
Aspect Oriented Programming MiddlewareLenin Lozano
 
Clase no. 1 unidad no. iii introduccion al analisis y diseño estructurado d...
Clase no. 1 unidad no. iii  introduccion al analisis y diseño estructurado  d...Clase no. 1 unidad no. iii  introduccion al analisis y diseño estructurado  d...
Clase no. 1 unidad no. iii introduccion al analisis y diseño estructurado d...negroues
 
Clase no. 1 unidad no. iii introduccion al analisis y diseño estructurado d...
Clase no. 1 unidad no. iii  introduccion al analisis y diseño estructurado  d...Clase no. 1 unidad no. iii  introduccion al analisis y diseño estructurado  d...
Clase no. 1 unidad no. iii introduccion al analisis y diseño estructurado d...negroues
 
Fundamentos de programación semana 3 ppt
Fundamentos de programación semana 3 pptFundamentos de programación semana 3 ppt
Fundamentos de programación semana 3 pptpedro millapi montiel
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructuradoYamnibel
 
Fundamentos básicos para el diseño de software
Fundamentos básicos para el diseño de softwareFundamentos básicos para el diseño de software
Fundamentos básicos para el diseño de softwareluis javier perez
 
14704374 arquitectura-basada-en-componentes
14704374 arquitectura-basada-en-componentes14704374 arquitectura-basada-en-componentes
14704374 arquitectura-basada-en-componentesGary Araujo Viscarra
 
Implementan en metodología RUP
Implementan en metodología RUPImplementan en metodología RUP
Implementan en metodología RUPAlberto Tatés
 
Arquitectura de software.docx
Arquitectura de software.docxArquitectura de software.docx
Arquitectura de software.docxKeiberOrtiz1
 
Fundamentos Básicos del Diseño de Software
Fundamentos Básicos del Diseño de SoftwareFundamentos Básicos del Diseño de Software
Fundamentos Básicos del Diseño de SoftwareJoseCaira2
 
arquitectura de software 1 parte.pdf
arquitectura de software 1 parte.pdfarquitectura de software 1 parte.pdf
arquitectura de software 1 parte.pdfjhonademirpalominopa
 
Apun9algol
Apun9algolApun9algol
Apun9algolpabesacv
 

Similaire à Introducción A La Orientación A Aspectos - Programador PHP (20)

Nixon torrealbav
Nixon torrealbavNixon torrealbav
Nixon torrealbav
 
Fundamentos Basicos para El Diseño de Software
Fundamentos Basicos para El Diseño de SoftwareFundamentos Basicos para El Diseño de Software
Fundamentos Basicos para El Diseño de Software
 
Fundamentos
FundamentosFundamentos
Fundamentos
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructurado
 
Fundamentos del diseño de software
Fundamentos del diseño de software Fundamentos del diseño de software
Fundamentos del diseño de software
 
Aspect Oriented Programming Middleware
Aspect Oriented Programming MiddlewareAspect Oriented Programming Middleware
Aspect Oriented Programming Middleware
 
Clase no. 1 unidad no. iii introduccion al analisis y diseño estructurado d...
Clase no. 1 unidad no. iii  introduccion al analisis y diseño estructurado  d...Clase no. 1 unidad no. iii  introduccion al analisis y diseño estructurado  d...
Clase no. 1 unidad no. iii introduccion al analisis y diseño estructurado d...
 
Clase no. 1 unidad no. iii introduccion al analisis y diseño estructurado d...
Clase no. 1 unidad no. iii  introduccion al analisis y diseño estructurado  d...Clase no. 1 unidad no. iii  introduccion al analisis y diseño estructurado  d...
Clase no. 1 unidad no. iii introduccion al analisis y diseño estructurado d...
 
1127082.ppt
1127082.ppt1127082.ppt
1127082.ppt
 
Fundamentos de programación semana 3 ppt
Fundamentos de programación semana 3 pptFundamentos de programación semana 3 ppt
Fundamentos de programación semana 3 ppt
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructurado
 
Fundamentos básicos para el diseño de software
Fundamentos básicos para el diseño de softwareFundamentos básicos para el diseño de software
Fundamentos básicos para el diseño de software
 
14704374 arquitectura-basada-en-componentes
14704374 arquitectura-basada-en-componentes14704374 arquitectura-basada-en-componentes
14704374 arquitectura-basada-en-componentes
 
Fr amework
Fr ameworkFr amework
Fr amework
 
Componentes
ComponentesComponentes
Componentes
 
Implementan en metodología RUP
Implementan en metodología RUPImplementan en metodología RUP
Implementan en metodología RUP
 
Arquitectura de software.docx
Arquitectura de software.docxArquitectura de software.docx
Arquitectura de software.docx
 
Fundamentos Básicos del Diseño de Software
Fundamentos Básicos del Diseño de SoftwareFundamentos Básicos del Diseño de Software
Fundamentos Básicos del Diseño de Software
 
arquitectura de software 1 parte.pdf
arquitectura de software 1 parte.pdfarquitectura de software 1 parte.pdf
arquitectura de software 1 parte.pdf
 
Apun9algol
Apun9algolApun9algol
Apun9algol
 

Plus de Juan Belón Pérez

Aplicaciones y juegos para móbiles 2011: iOS, Android, Bada, Palm
Aplicaciones y juegos para móbiles 2011: iOS, Android, Bada, PalmAplicaciones y juegos para móbiles 2011: iOS, Android, Bada, Palm
Aplicaciones y juegos para móbiles 2011: iOS, Android, Bada, PalmJuan Belón Pérez
 
Yahoo! pipes + Wordpress plugin - RSS POWER to your blog
Yahoo! pipes + Wordpress plugin - RSS POWER to your blogYahoo! pipes + Wordpress plugin - RSS POWER to your blog
Yahoo! pipes + Wordpress plugin - RSS POWER to your blogJuan Belón Pérez
 
Proyecto Campos Electricos - Programador Servicios 3d
Proyecto Campos Electricos - Programador Servicios 3dProyecto Campos Electricos - Programador Servicios 3d
Proyecto Campos Electricos - Programador Servicios 3dJuan Belón Pérez
 
Aecem - Libro Blanco - Para Programador Php.org
Aecem - Libro Blanco  - Para Programador Php.orgAecem - Libro Blanco  - Para Programador Php.org
Aecem - Libro Blanco - Para Programador Php.orgJuan Belón Pérez
 
Introducción a PHP - Programador PHP - UGR
Introducción a PHP - Programador PHP - UGRIntroducción a PHP - Programador PHP - UGR
Introducción a PHP - Programador PHP - UGRJuan Belón Pérez
 
Composicion de servicios web, un ejemplo
Composicion de servicios web, un ejemploComposicion de servicios web, un ejemplo
Composicion de servicios web, un ejemploJuan Belón Pérez
 
Memoria Zenphp - Programador PHP
Memoria Zenphp - Programador PHPMemoria Zenphp - Programador PHP
Memoria Zenphp - Programador PHPJuan Belón Pérez
 
Depurando Java Script - Programador PHP
Depurando Java Script - Programador PHPDepurando Java Script - Programador PHP
Depurando Java Script - Programador PHPJuan Belón Pérez
 
Zenphp - Presentación de Septiembre en la Etsiit - Programador PHP
Zenphp - Presentación de Septiembre en la Etsiit - Programador PHPZenphp - Presentación de Septiembre en la Etsiit - Programador PHP
Zenphp - Presentación de Septiembre en la Etsiit - Programador PHPJuan Belón Pérez
 
Tutorial A Z A - Programador PHP
Tutorial A Z A - Programador PHPTutorial A Z A - Programador PHP
Tutorial A Z A - Programador PHPJuan Belón Pérez
 
Ensayo Cientifico - Programador PHP
Ensayo Cientifico - Programador PHPEnsayo Cientifico - Programador PHP
Ensayo Cientifico - Programador PHPJuan Belón Pérez
 
Zen Scaffolding - Programador PHP
Zen Scaffolding - Programador PHPZen Scaffolding - Programador PHP
Zen Scaffolding - Programador PHPJuan Belón Pérez
 
Rendimiento Java Script - Programador PHP
Rendimiento  Java Script - Programador PHPRendimiento  Java Script - Programador PHP
Rendimiento Java Script - Programador PHPJuan Belón Pérez
 
Bibliografia Y Menciones - Programador PHP
Bibliografia Y Menciones - Programador PHPBibliografia Y Menciones - Programador PHP
Bibliografia Y Menciones - Programador PHPJuan Belón Pérez
 

Plus de Juan Belón Pérez (20)

Aplicaciones y juegos para móbiles 2011: iOS, Android, Bada, Palm
Aplicaciones y juegos para móbiles 2011: iOS, Android, Bada, PalmAplicaciones y juegos para móbiles 2011: iOS, Android, Bada, Palm
Aplicaciones y juegos para móbiles 2011: iOS, Android, Bada, Palm
 
¿Cómo elegir servidor web?
¿Cómo elegir servidor web?¿Cómo elegir servidor web?
¿Cómo elegir servidor web?
 
Yahoo! pipes + Wordpress plugin - RSS POWER to your blog
Yahoo! pipes + Wordpress plugin - RSS POWER to your blogYahoo! pipes + Wordpress plugin - RSS POWER to your blog
Yahoo! pipes + Wordpress plugin - RSS POWER to your blog
 
Proyecto Campos Electricos - Programador Servicios 3d
Proyecto Campos Electricos - Programador Servicios 3dProyecto Campos Electricos - Programador Servicios 3d
Proyecto Campos Electricos - Programador Servicios 3d
 
Aecem - Libro Blanco - Para Programador Php.org
Aecem - Libro Blanco  - Para Programador Php.orgAecem - Libro Blanco  - Para Programador Php.org
Aecem - Libro Blanco - Para Programador Php.org
 
Bpel y Open Esb
Bpel y Open EsbBpel y Open Esb
Bpel y Open Esb
 
Introducción a PHP - Programador PHP - UGR
Introducción a PHP - Programador PHP - UGRIntroducción a PHP - Programador PHP - UGR
Introducción a PHP - Programador PHP - UGR
 
Composicion de servicios web, un ejemplo
Composicion de servicios web, un ejemploComposicion de servicios web, un ejemplo
Composicion de servicios web, un ejemplo
 
Presentación: xUnit y Junit
Presentación: xUnit y JunitPresentación: xUnit y Junit
Presentación: xUnit y Junit
 
Cómo elegir un servidor Web
Cómo elegir un servidor WebCómo elegir un servidor Web
Cómo elegir un servidor Web
 
Memoria Zenphp - Programador PHP
Memoria Zenphp - Programador PHPMemoria Zenphp - Programador PHP
Memoria Zenphp - Programador PHP
 
Depurando Java Script - Programador PHP
Depurando Java Script - Programador PHPDepurando Java Script - Programador PHP
Depurando Java Script - Programador PHP
 
Zenphp - Presentación de Septiembre en la Etsiit - Programador PHP
Zenphp - Presentación de Septiembre en la Etsiit - Programador PHPZenphp - Presentación de Septiembre en la Etsiit - Programador PHP
Zenphp - Presentación de Septiembre en la Etsiit - Programador PHP
 
Zenphp - Programador PHP
Zenphp - Programador PHPZenphp - Programador PHP
Zenphp - Programador PHP
 
Tutorial A Z A - Programador PHP
Tutorial A Z A - Programador PHPTutorial A Z A - Programador PHP
Tutorial A Z A - Programador PHP
 
Ensayo Cientifico - Programador PHP
Ensayo Cientifico - Programador PHPEnsayo Cientifico - Programador PHP
Ensayo Cientifico - Programador PHP
 
Zen AJAX - Programador PHP
Zen AJAX - Programador PHPZen AJAX - Programador PHP
Zen AJAX - Programador PHP
 
Zen Scaffolding - Programador PHP
Zen Scaffolding - Programador PHPZen Scaffolding - Programador PHP
Zen Scaffolding - Programador PHP
 
Rendimiento Java Script - Programador PHP
Rendimiento  Java Script - Programador PHPRendimiento  Java Script - Programador PHP
Rendimiento Java Script - Programador PHP
 
Bibliografia Y Menciones - Programador PHP
Bibliografia Y Menciones - Programador PHPBibliografia Y Menciones - Programador PHP
Bibliografia Y Menciones - Programador PHP
 

Dernier

De Código a Ejecución: El Papel Fundamental del MSIL en .NET
De Código a Ejecución: El Papel Fundamental del MSIL en .NETDe Código a Ejecución: El Papel Fundamental del MSIL en .NET
De Código a Ejecución: El Papel Fundamental del MSIL en .NETGermán Küber
 
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdf
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdfTENDENCIAS DE IA Explorando el futuro de la tecnologia.pdf
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdfJoseAlejandroPerezBa
 
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdf
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdfInmersión global en ciberseguridad e IA en la conferencia RSA.pdf
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdfOBr.global
 
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOS
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOSPRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOS
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOSLincangoKevin
 
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...OLGAMILENAMONTAEZNIO
 
Tecnológia 2024.docx.Tecnológia 2024.docx.
Tecnológia 2024.docx.Tecnológia 2024.docx.Tecnológia 2024.docx.Tecnológia 2024.docx.
Tecnológia 2024.docx.Tecnológia 2024.docx.marianarodriguezc797
 
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdf
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdfPresentación - Diseño de Algoritmos Paralelos - Grupo 2.pdf
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdfymiranda2
 
Matriz de integración de tecnologías- Paola Carvajal.docx
Matriz de integración de tecnologías- Paola Carvajal.docxMatriz de integración de tecnologías- Paola Carvajal.docx
Matriz de integración de tecnologías- Paola Carvajal.docxPaolaCarolinaCarvaja
 
VIDEOS DE APOYO.docx E
VIDEOS DE APOYO.docx                                  EVIDEOS DE APOYO.docx                                  E
VIDEOS DE APOYO.docx Emialexsolar
 
Los mejores simuladores de circuitos electrónicos.pdf
Los mejores simuladores de circuitos electrónicos.pdfLos mejores simuladores de circuitos electrónicos.pdf
Los mejores simuladores de circuitos electrónicos.pdfodalistar77
 
Actividad 14_ Diseño de Algoritmos Paralelos.pdf
Actividad 14_ Diseño de Algoritmos Paralelos.pdfActividad 14_ Diseño de Algoritmos Paralelos.pdf
Actividad 14_ Diseño de Algoritmos Paralelos.pdfalejandrogomezescoto
 
Inteligencia artificial dentro de la contabilidad
Inteligencia artificial dentro de la contabilidadInteligencia artificial dentro de la contabilidad
Inteligencia artificial dentro de la contabilidaddanik1023m
 
La Electricidad y La Electrónica.pdf....
La Electricidad y La Electrónica.pdf....La Electricidad y La Electrónica.pdf....
La Electricidad y La Electrónica.pdf....Aaron Betancourt
 
Carta de Premio y Excel angeline 11-2pdf
Carta de Premio y Excel angeline 11-2pdfCarta de Premio y Excel angeline 11-2pdf
Carta de Premio y Excel angeline 11-2pdfangelinebocanegra1
 
Análisis de artefactos tecnologicos .pdf
Análisis de artefactos tecnologicos .pdfAnálisis de artefactos tecnologicos .pdf
Análisis de artefactos tecnologicos .pdfcastrodanna185
 
El diseño de Algoritmos Paralelos.pdf - analisis de algortimos
El diseño de Algoritmos Paralelos.pdf - analisis de algortimosEl diseño de Algoritmos Paralelos.pdf - analisis de algortimos
El diseño de Algoritmos Paralelos.pdf - analisis de algortimosLCristinaForchue
 
La tablet trabajo en grupo del grado 9-2
La tablet trabajo en grupo del grado 9-2La tablet trabajo en grupo del grado 9-2
La tablet trabajo en grupo del grado 9-2montoyagabriela340
 
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...RaymondCode
 

Dernier (20)

De Código a Ejecución: El Papel Fundamental del MSIL en .NET
De Código a Ejecución: El Papel Fundamental del MSIL en .NETDe Código a Ejecución: El Papel Fundamental del MSIL en .NET
De Código a Ejecución: El Papel Fundamental del MSIL en .NET
 
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdf
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdfTENDENCIAS DE IA Explorando el futuro de la tecnologia.pdf
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdf
 
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdf
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdfInmersión global en ciberseguridad e IA en la conferencia RSA.pdf
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdf
 
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOS
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOSPRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOS
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOS
 
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...
 
Tecnológia 2024.docx.Tecnológia 2024.docx.
Tecnológia 2024.docx.Tecnológia 2024.docx.Tecnológia 2024.docx.Tecnológia 2024.docx.
Tecnológia 2024.docx.Tecnológia 2024.docx.
 
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdf
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdfPresentación - Diseño de Algoritmos Paralelos - Grupo 2.pdf
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdf
 
Matriz de integración de tecnologías- Paola Carvajal.docx
Matriz de integración de tecnologías- Paola Carvajal.docxMatriz de integración de tecnologías- Paola Carvajal.docx
Matriz de integración de tecnologías- Paola Carvajal.docx
 
VIDEOS DE APOYO.docx E
VIDEOS DE APOYO.docx                                  EVIDEOS DE APOYO.docx                                  E
VIDEOS DE APOYO.docx E
 
Los mejores simuladores de circuitos electrónicos.pdf
Los mejores simuladores de circuitos electrónicos.pdfLos mejores simuladores de circuitos electrónicos.pdf
Los mejores simuladores de circuitos electrónicos.pdf
 
Actividad 14_ Diseño de Algoritmos Paralelos.pdf
Actividad 14_ Diseño de Algoritmos Paralelos.pdfActividad 14_ Diseño de Algoritmos Paralelos.pdf
Actividad 14_ Diseño de Algoritmos Paralelos.pdf
 
BEDEC Sostenibilidad, novedades 2024 - Laura Silva
BEDEC Sostenibilidad, novedades 2024 - Laura SilvaBEDEC Sostenibilidad, novedades 2024 - Laura Silva
BEDEC Sostenibilidad, novedades 2024 - Laura Silva
 
Inteligencia artificial dentro de la contabilidad
Inteligencia artificial dentro de la contabilidadInteligencia artificial dentro de la contabilidad
Inteligencia artificial dentro de la contabilidad
 
La Electricidad y La Electrónica.pdf....
La Electricidad y La Electrónica.pdf....La Electricidad y La Electrónica.pdf....
La Electricidad y La Electrónica.pdf....
 
Carta de Premio y Excel angeline 11-2pdf
Carta de Premio y Excel angeline 11-2pdfCarta de Premio y Excel angeline 11-2pdf
Carta de Premio y Excel angeline 11-2pdf
 
Análisis de artefactos tecnologicos .pdf
Análisis de artefactos tecnologicos .pdfAnálisis de artefactos tecnologicos .pdf
Análisis de artefactos tecnologicos .pdf
 
El diseño de Algoritmos Paralelos.pdf - analisis de algortimos
El diseño de Algoritmos Paralelos.pdf - analisis de algortimosEl diseño de Algoritmos Paralelos.pdf - analisis de algortimos
El diseño de Algoritmos Paralelos.pdf - analisis de algortimos
 
La tablet trabajo en grupo del grado 9-2
La tablet trabajo en grupo del grado 9-2La tablet trabajo en grupo del grado 9-2
La tablet trabajo en grupo del grado 9-2
 
BEDEC Proyecto y obra , novedades 2024 - Xavier Folch
BEDEC Proyecto y obra , novedades 2024 - Xavier FolchBEDEC Proyecto y obra , novedades 2024 - Xavier Folch
BEDEC Proyecto y obra , novedades 2024 - Xavier Folch
 
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...
 

Introducción A La Orientación A Aspectos - Programador PHP

  • 1. INTRODUCCIÓN A LA ORIENTACIÓN A ASPECTOS La motivación: Separación de incumbencias En la Ingeniería del Software se ha utilizado durante años el principio de la separación de incumbencias  (Separation of Concerns) para gestionar la complejidad del desarrollo de software mediante la separación  de   las   funcionalidades   principales   de   la   aplicación   de   otras   partes   con   un   propósito   específico,  ortogonales a la funcionalidad principal (autenticación, administración, rendimiento, gestión de memoria,  logging, etc.). La aplicación final se construye con el código de las funcionalidades principales más el  código de propósito específico. Los principales beneficios de esta aproximación son:  • Un nivel  de abstracción  más alto, porque el desarrollador se puede centrar en incumbencias  concretas y de forma aislada. • Una mayor facilidad a la hora de entender la funcionalidad de la aplicación. • El   código   que   implementa   dicha   funcionalidad   no   está   entremezclado   con   el   de   otras  incumbencias. • Una mayor reusabilidad al haber un menor acoplamiento. • Una mayor mantenibilidad del código, al ser éste menos complejo. • Una mayor flexibilidad en la integración de componentes. • Un incremento de la productividad en el desarrollo. Una   buena   SoC   debe   poder   identificar   y   manejar   de   forma   individual   los   distintos   componentes   del  sistema tanto en la fase de diseño como en la codificación. A lo largo de los años se han desarrollado aproximaciones y técnicas para conseguir la SoC, que han ido  evolucionando con el objetivo de hacer frente a las características cambiantes, ámbito y complejidad de  las aplicaciones software. Entre ellas, una de las más destacables es el Desarrollo de Software Orientado  a Aspectos (DSOA). Definición de Aspecto Puesto que el DSOA es una aproximación de la SoC, antes de definir un aspecto es mejor saber qué es  una  incumbencia:   básicamente,   todo   lo   que   sea   importante   para   la   aplicación,   ya   sea   código,  infraestructura, requerimientos, elementos de diseño, etc. En el DSOA hay dos términos muy importantes: • Un  componente   (component)  es   el   módulo   software   que   puede   ser   encapsulado   en   un  procedimiento   (un   objeto,   método,   procedimiento   o   API).   Los   componentes   serán   unidades  funcionales en las que se descompone el sistema. • Un  aspecto  (aspect)   es   aquel   módulo   software   que   no   puede   ser   encapsulado   en   un  procedimiento.   No   son   unidades   funcionales   en   las   que   se   pueda   dividir   un   sistema,   sino  propiedades que afectan a la ejecución o semántica de los componentes, por ejemplo, la gestión  de la memoria o la sincronización de hilos. Un aspecto es una clase particular de incumbencia. La definición formal más aceptada es: “Un aspecto es  una   unidad   modular   que   se   disemina   por   la   estructura   de   otras   unidades   funcionales.   Los   aspectos  existen tanto en la etapa de diseño como en la de implementación. Un aspecto de diseño es una unidad  modular   del   diseño   que   se   entremezcla   en   la   estructura   de   otras   partes   del   diseño.   Un   aspecto   de  programa o de código es una unidad modular del programa que aparece en otras unidades modulares del  programa” [Kiczales97]:
  • 2. De una forma más básica, se puede decir que los aspectos son elementos que se diseminan por todo el  código y son difíciles de describir con respecto a otros componentes. En la parte izquierda de la siguiente figura puede verse la forma que tiene el código de un programa que  sigue el paradigma Orientado a Objetos. Se puede observar que está entremezclado y resulta difícil de  entender,   depurar   y   modificar.   En   cambio,   siguiendo   el   DSOA,   en   la   parte   derecha   de   la   figura,   las  diferentes incumbencias están separadas, con lo que resulta más fácil entenderlas y trabajar con ellas. Cómo Funciona la POA Básicamente en el funcionamiento de la POA se pueden identificar tres pasos: 1. Descomposición en aspectos: Se descomponen los requerimientos para identificar las distintas  incumbencias (las comunes y aquellas que se entremezclan con el resto). 2. Implementación   de   incumbencias:  Se  implementan  de  forma  independiente  las  incumbencias  detectadas anteriormente, tanto la funcionalidad básica como los aspectos ortogonales. 3. Recomposición   de   aspectos:   En   este   proceso,   denominado  tejido   (weaving),   se   toman   los  módulos implementados anteriormente (funcionalidad básica y aspectos) y se tejen para formar  el sistema completo. Esta tarea es realizada por el tejedor de aspectos (aspect weaver). Los lenguajes orientados a aspectos definen una nueva unidad de programación de software, el aspecto,  para encapsular las funcionalidades que están diseminadas (crosscutted) y enmarañadas (tangled)  por  todo el código. A la hora de formar el sistema se ve que hay una relación entre los componentes y los  aspectos, y que, por lo tanto, el código de ambos tiene que interactuar de alguna manera. Para que los  aspectos y los componentes se mezclen, deben fijarse los puntos donde puedan hacerlo, que son lo que  se conoce como puntos de enlace (joinpoints). El proceso de realizar esta unión se conoce como tejido (weave), y el encargado de realizarlo es el tejedor  de aspectos (aspect weaver). El tejedor, además de los aspectos, los módulos y los puntos de enlace, 
  • 3. recibe unas reglas que le indican cómo debe realizar el tejido. Dichas reglas son los llamados puntos de  corte (pointcuts), que indican al tejedor qué aspecto tiene que aumentar a qué módulo a través de qué  punto de enlace. El   código  de   los   aspectos   normalmente   recibe el nombre de  advice,  al ser el término utilizado en el  sistema AspectJ y que han adoptado la mayoría de sistemas posteriores. Realmente, los aspectos describen unos añadidos al comportamiento de los objetos, hacen referencia a  las clases de estos y definen en qué punto se han de colocar los añadidos. Como se puede ver en la figura siguiente, en las metodologías tradicionales el proceso de generar un  programa consistía en pasar el código a través de un compilador o un intérprete para así disponer de un  ejecutable.   En   la   POA   no   se   tiene   un   único   código   del   programa   sino   que   el   que   implementa   la  funcionalidad básica y el de cada uno de los aspectos están separados. Todo este código debe pasar no  sólo a través del compilador, sino que debe ser tratado por el tejedor, que es el que se encarga de crear  un único programa con toda la funcionalidad, la básica más los aspectos. Terminología Aunque ya se han mencionado algunos de los términos que se emplean en la POA, a continuación se  definirán los más importantes:  Incumbencia:   Todo   aquello   que   resulta   importante   para   una   aplicación   (requisitos,  infraestructura, código, etc.).  Componente:   Módulo   software   que  puede ser  encapsulado en  un procedimiento  (un objeto,  método,   procedimiento,   API).   Los   componentes   son   unidades   funcionales   en   las   que   se  descompone el sistema.  Aspecto: Módulo software que no puede ser encapsulado en un procedimiento. Los aspectos no  son unidades funcionales en las que se pueda dividir un sistema, sino propiedades que afectan a  la ejecución o semántica de los componentes.
  • 4. Punto de enlace (joinpoint): Punto de la ejecución de un programa bien definido donde se podrá  añadir código, es decir, funcionalidad. No todos los puntos de ejecución de un programa son  puntos de enlace, sino solo aquellos que se puedan tratar de forma controlada. Cada sistema  que soporta POA ofrece una serie de puntos de enlace distintos, como invocaciones a métodos,  acceso a campos, etc.  Sombra de punto de enlace (joinpoint shadow): “Sombra” que deja un punto de enlace a bajo  nivel   (en   código   intermedio,   por   ejemplo  bytecode  de   Java).   Existen   puntos   de   enlace   cuya  sombra se corresponde con una instrucción y es sencilla de localizar. En cambio, para otros la  sombra no se corresponde con una única instrucción o, incluso, no se corresponde con ninguna  instrucción sino con una zona del código.  Punto de corte (pointcut): Conjunto de instrucciones que se le pasan al tejedor para que sepa  qué código (advice  del aspecto) se debe añadir en qué punto de enlace a una aplicación. Un  ejemplo podría ser invocar el método X del aspecto cuando se produzca un acceso de lectura al  campo Y de la clase C.  Advice: Código del aspecto que se ejecuta en los puntos de enlace seleccionados por un punto  de corte. Normalmente, desde su código se puede acceder al contexto de ejecución del punto de  enlace (como los valores de variables, etc.). Tipos de POA El proceso de tejido es el punto más importante para cualquier solución que emplee POA. En la definición  original de ésta, Kiczales y su equipo especificaron las siguientes posibilidades para hacer el tejido:  Un preprocesador que haga las sustituciones pertinentes en el código.  Un postprocesador que modifique archivos binarios.  Un compilador que soporte POA y que genere archivos con el tejido realizado.  Tejido en tiempo de carga, realizando el proceso cuando las clases son cargadas en memoria,  como haría Java con la JVM.  Tejido en tiempo de ejecución, capturando cada punto de enlace mientras el programa está en  funcionamiento y ejecutando el código que corresponda. Posteriormente   se   ha   presentado   una   alternativa   denominada   “tejido   en   tiempo   de  despliegue” (deploytime weaving), que implica un postprocesamiento del código, pero en vez de modificar  el   código   generado,   se   generan   subclases   a   partir   de   las   clases   existentes,   introduciendo   las  modificaciones pertinentes mediante redefinición de métodos. Las clases que ya existían no se modifican  en   ningún   momento,   con   lo   que   todas   las  herramientas  ya  existentes  pueden  ser  usadas  durante  el  desarrollo.   Una   aproximación   similar   a   esta   se   ha   usado   en   la   implementación   de   servidores   de  aplicaciones JavaEE como IBM WebSphere. Si se utiliza como criterio el  momento  en el que se realiza el tejido se distinguen entre  tejido estático  y  tejido dinámico. De las formas de tejido anteriormente mencionadas todas son estáticas, excepto el tejido  en tiempo de carga y el tejido en tiempo de ejecución, que son dinámicas. Tejido estático La mayoría de las actuales implementaciones de POA están basadas en el tejido estático, que consiste en  la modificación en tiempo de compilación del código fuente, insertando llamadas a las rutinas específicas  de   los   aspectos.   Los   lugares   donde   estas   llamadas   se   pueden   insertar   son   los  puntos   de   enlace  (joinpoints), definidos por cada sistema.
  • 5. En la figurar anterior se puede ver el proceso que se sigue en el tejido estático. Se parte del programa con  la funcionalidad básica implementada en un lenguaje base (C++, Java, etc.) y además se tiene uno o  varios aspectos, escritos en un lenguaje de aspectos que puede ser una extensión de algún lenguaje  normal, o uno específicamente definido con este fin.  Por aspecto se entiende el código que se debe añadir (advice) y las instrucciones que recibe el tejedor  sobre  dónde   y   cómo  insertar   el   código   de   los   aspectos   en   el   código   principal   (pointcut).   Estas  instrucciones pueden venir expresadas en el mismo lenguaje o en otro particular, y pueden encontrarse  en el mismo fichero o en otro. El   tejedor   realiza   la   composición   de   código,   insertando   el   proveniente   de   los   aspectos   en   el   de   la  funcionalidad básica, siguiendo las instrucciones recibidas. El resultado es un nuevo código fuente que  pasará a través de un compilador, el cual generará el programa ejecutable. El  tejido   estático  presenta   algunos  inconvenientes como la imposibilidad de adaptarse a cambios (no  previstos   en   el   momento   del   desarrollo   del   programa)   en   el   entorno   de   ejecución,   debido   a   que   la  aplicación final es generada tejiendo la funcionalidad básica con los aspectos en tiempo de compilación;  cualquier funcionalidad que necesite ser adaptada en tiempo de ejecución implica detener la aplicación,  recompilarla con los nuevos aspectos e iniciarla de nuevo. Por ello, el uso del tejido estático no es factible  en aplicaciones que no puedan detenerse y que necesiten ser adaptadas. Al mismo tiempo, la depuración de una aplicación ya compilada a la que se hayan añadido los aspectos  es una tarea compleja porque el código que se debe analizar es el resultante del proceso de tejido: el  código original está entremezclado con el de los aspectos, que estará diseminado por toda la aplicación. La principal ventaja que ofrecen estos sistemas es que se evita que el uso de la POA derive en una  penalización en el rendimiento, ya que antes de la compilación se dispone de la totalidad del código,  pudiendo ser optimizado por el compilador. Una desventaja muy importante que suelen presentar las herramientas que ofrecen tejido estático (y las  que ofrecen tejido dinámico) es que son dependientes del lenguaje, no pudiendo crear distintos aspectos  en distintos lenguajes. Por ejemplo, AspectJ sólo puede usarse con el lenguaje Java. Tejido dinámico Usando un tejedor estático, el programa final se genera tejiendo el código de la funcionalidad básica y el  de los aspectos seleccionados en la fase de compilación. Si se quiere enriquecer la aplicación con un  nuevo   aspecto,   o   incluso   eliminar   uno   de   los   aspectos   actualmente   tejidos,   el   sistema   debe   ser  recompilado y reiniciado. Aunque no todas las aplicaciones necesitan ser adaptadas mediante aspectos en tiempo de ejecución,  hay aspectos específicos que se benefician de un sistema con tejido dinámico; puede haber aplicaciones  que necesiten adaptar sus competencias específicas en respuesta a cambios en el entorno de ejecución,  como la gestión de recursos y el equilibrio de carga en sistemas distribuidos, entre otros.
  • 6. En la  última figura  se puede  ver representado el proceso del tejido dinámico. En un primer paso, un  programa escrito en un lenguaje “normal” pasa por el compilador y se genera un programa que se pone  en ejecución y que no tiene por qué saber que va a ser adaptado. Cuando se necesita adaptar (añadir o  modificar funcionalidad) porque surgen nuevos requerimientos o en respuesta a cambios en el entorno,  sin   detenerlo,   se   procesa   el   programa   en  ejecución   (no  el   programa  ejecutable,   sino  el   que  está   en  memoria) junto a los aspectos que van a adaptarlo, y por medio del tejedor se le añade la funcionalidad de  estos, dando lugar a una nueva versión del programa que continúa la ejecución. El programa ejecutable  inicial no ha sido modificado, con lo que se puede utilizar de nuevo sin las modificaciones realizadas en  memoria. En sistemas que usan tejido dinámico de aspectos, la funcionalidad básica permanece separada de los  aspectos en todo el ciclo de vida del software, incluso en la ejecución del sistema. El código resultante es  más   adaptable   y   reutilizable,   y   los   aspectos   y   la   funcionalidad   básica   pueden   evolucionar   de   forma  independiente. Muchas de las herramientas que afirman ofrecer un tejido dinámico de aspectos realmente ofrecen un  híbrido   entre   el   tejido   estático   y   el   dinámico,   pues   los   aspectos   deben   conocerse   y   definirse   en   el  momento   del   diseño   e   implementación,   para   posteriormente   poder   instanciarlos   durante   la   ejecución.  Aunque esta solución aporta alguna ventaja respecto al tejido estático hay casos en que no es suficiente,  por ejemplo, cuando una vez que la aplicación está funcionando surge un requerimiento nuevo que no se  tuvo en cuenta en el diseño. Al igual que ocurre con las herramientas de tejido estático, la mayoría de las herramientas que ofrecen  tejido dinámico son dependientes del lenguaje. La  principal  desventaja  del  tejido  dinámico respecto al estático es el menor rendimiento en ejecución  causado por la adaptación dinámica de las aplicaciones. Referencias Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Videira Lopes, Jean- Marc Loingtier, John Irwin, Aspect-Oriented Programming, 1997. Luis Vinuesa, Separación Dinámica de Aspectos independiente del Lenguaje y Plataforma mediante el uso de Reflexión Computacional, 2007.