UNIVERSIDAD DE CARTAGENA

CENTRO TUTORIAL LORICA

 
PROTOCOLO GRUPAL DE LA UNIDAD N-3:
TEMA ESCOGIDO (DESARROLLO DE SOFTWARE ORIENTADO A
ASPECTOS)

NOMBRE Y APELLIDO:
WILSON ANTONIO CORREA AGAMEZ
YEISON MANUEL POLO ÁVILA
MARÍA ANGÉLICA NEGRETE MATTOS
 
TUTOR(A):
ELIANA ROSA CRUZ MERCADO

AREA:
INGENIERÍA DE SOFTWARE

CARRERA PROFESIONAL
INGENIERIA DE SISTEMAS

SEMESTRE IX

SAN BERNARDO DEL VIENTO – CORDOBA

FECHA: 08/12/2020
 Desarrollo de software orientado a aspectos

Antes de comenzar temes que definir que es un aspecto, un aspecto es un módulo

que encapsula una preocupación. Un aspecto se compone de cortes de puntos,
órganos de asesoramiento y declaraciones entre tipos. En algunos enfoques, un
aspecto también puede contener clases y métodos.

Las características más relevantes de los aspectos para ser considerados

como tales son:
 Un aspecto no debe interferir con otro.
 Cada aspecto debe ser claramente identificable.
 Los aspectos no deben interferir con los mecanismos usados para definir y
evolucionar la funcionalidad, como la herencia.
 Los aspectos deben ser fácilmente intercambiables.

El desarrollo de software orientado a aspectos (AOSD), es una tecnología de

desarrollo de software que busca nuevas modularizaciones de los sistemas de
software para aislar las funciones secundarias o de apoyo de la lógica empresarial
del programa principal. AOSD permite que múltiples preocupaciones se expresen
por separado y se unifiquen automáticamente en sistemas de trabajo.

El desarrollo de software tradicional se enfoca en descomponer los sistemas en

unidades de funcionalidad primaria, reconociendo al mismo tiempo que hay otros
problemas de preocupación que no encajan bien en la descomposición primaria.
El proceso de desarrollo tradicional deja que los programadores codifiquen los
módulos correspondientes a la funcionalidad principal y se aseguren de que todos
los demás problemas de interés se aborden en el código cuando sea apropiado.
Los programadores deben tener en cuenta todas las cosas que deben hacerse,
cómo lidiar con cada problema, los problemas asociados con las posibles
interacciones y la ejecución del comportamiento correcto en el momento
adecuado. Estas preocupaciones abarcan múltiples unidades funcionales
primarias dentro de la aplicación y, a menudo, resultan en problemas graves que
se enfrentan durante el desarrollo y mantenimiento de la aplicación. La distribución
del código para darse cuenta de una inquietud se vuelve especialmente crítica a
medida que evolucionan los requisitos para esa inquietud: un responsable de
mantenimiento del sistema debe encontrar y actualizar correctamente una
variedad de situaciones.

Funcionalidad del desarrollo de software orientado a aspectos:

El desarrollo de software orientado a aspectos se centra en la identificación,

especificación y representación de preocupaciones transversales y su
modularización en unidades funcionales separadas, así como su composición
automatizada en un sistema de trabajo.

La motivación para los enfoques de programación orientada a aspectos proviene

de los problemas causados por la dispersión y el enredo del código. El propósito
del desarrollo de software orientado a aspectos es proporcionar medios
sistemáticos para modularizar las preocupaciones transversales.

La implementación de una preocupación se dispersa si su código se distribuye en

varios módulos. La preocupación afecta la implementación de múltiples módulos.
Su implementación no es modular.

La implementación de una preocupación se complica si su código se mezcla con

el código que implementa otras preocupaciones. El módulo en el que se produce
el enredo no es cohesivo.

La dispersión y el enredo a menudo van de la mano, aunque son conceptos

diferentes.

El desarrollo de software orientado a aspectos considera que la dispersión y el

enredo del código son síntomas de preocupaciones transversales. Las
preocupaciones transversales no pueden modularizarse utilizando los mecanismos
de descomposición del lenguaje (objeto o procedimientos) porque, de manera
inherente, siguen diferentes reglas de descomposición. La implementación e
integración de estas preocupaciones con la descomposición funcional primaria del
sistema provoca enredos y dispersión de código.

Ejemplo 1: Iniciar sesión en Apache Tomcat La carga de clases en Tomcat es una

preocupación modular con respecto a la descomposición del sistema. Su
implementación está contenida en un pequeño número de clases y no está
entrelazada con la implementación de otras preocupaciones. Iniciar sesión en
Tomcat es una preocupación transversal. Su implementación se extiende a
muchas clases y paquetes y se mezcla con la implementación de muchas otras
preocupaciones.

Ejemplo 2: Coordinación de componentes La Figura 3 representa el diagrama de

la arquitectura UML de un componente de telecomunicaciones. Cada caja
corresponde a un proceso que se comunica con otros procesos a través de
conectores.

Ejemplos de preocupaciones transversales:

Problemas causados por dispersión y enredos. La dispersión y el enredo del

comportamiento son síntomas de que la implementación de una preocupación no
está bien modularizada. Una preocupación que no está modularizada no presenta
una interfaz bien definida. Las interacciones entre la implementación de la
preocupación y los módulos del sistema no se declaran explícitamente. Están
codificados implícitamente a través de las dependencias e interacciones entre
fragmentos de código que implementan la preocupación y la implementación de
otros módulos.

La falta de interfaces entre la implementación de preocupaciones transversales y

la implementación de los módulos del sistema impide el desarrollo, la evolución y
el mantenimiento del sistema.

Desarrollo del sistema:

Un módulo es principalmente una unidad de desarrollo independiente. Se puede

implementar en gran medida independientemente de otros módulos. La
modularidad se logra mediante la definición de interfaces bien definidas entre
segmentos del sistema.

La falta de interfaces explícitas entre las preocupaciones transversales y los

módulos obtenidos a través de la descomposición funcional del sistema implica
que la implementación de estas preocupaciones, así como la responsabilidad con
respecto a la correcta implementación de estas preocupaciones, no puede ser
asignada a equipos de desarrollo independientes. Esta responsabilidad debe ser
compartida entre diferentes desarrolladores que trabajan en la implementación de
diferentes módulos del sistema y tienen que integrar la preocupación transversal
con el comportamiento del módulo.

Además, los módulos cuya implementación está enredada con preocupaciones

transversales son difíciles de reutilizar en diferentes contextos. El corte transversal
impide la reutilización de componentes. La falta de interfaces entre las
preocupaciones transversales y otros módulos hace que sea difícil representar y
razonar sobre la arquitectura general de un sistema. Como la preocupación no
está modularizada, las interacciones entre la preocupación y los componentes de
nivel superior del sistema son difíciles de representar explícitamente. Por lo tanto,
resulta difícil razonar sobre estas preocupaciones porque no se especifican las
dependencias entre las preocupaciones transversales y los componentes.

Por último, las preocupaciones que no están modularizadas son difíciles de probar
de forma aislada. Las dependencias de la preocupación con respecto al
comportamiento de otros módulos no se declaran explícitamente. Por lo tanto, la
implementación de la prueba unitaria para tales preocupaciones requiere
conocimientos sobre la implementación de muchos módulos en el sistema.

Mantenimiento y evolución del sistema:

La falta de apoyo para la implementación modular de preocupaciones

transversales es especialmente problemática cuando la implementación de esta
preocupación necesita ser modificada. La comprensión de la implementación de
una preocupación transversal requiere la inspección de la implementación de
todos los módulos con los que interactúa. Por lo tanto, las modificaciones del
sistema que afectan la implementación de la preocupación transversal requieren
una inspección manual de todas las ubicaciones en el código que son relevantes
para la preocupación transversal. El responsable del mantenimiento del sistema
debe encontrar y actualizar correctamente una variedad de situaciones mal
identificadas.
Naturaleza de la orientación de aspecto:

El enfoque del desarrollo de software orientado a aspectos está en la investigación

e implementación de nuevas estructuras para la modularidad del software que
brindan soporte para abstracciones explícitas para modularizar las
preocupaciones. Los enfoques de programación orientados a aspectos
proporcionan abstracciones explícitas para la implementación modular de
preocupaciones en diseño, código, documentación u otros artefactos desarrollados
durante el ciclo de vida del software. Estas preocupaciones modularizadas se
denominan aspectos , y los enfoques orientados a aspectos proporcionan métodos
para componerlos. Algunos enfoques denotan una preocupación fundamental
como base . Varios enfoques proporcionan una flexibilidad diferente con respecto
a la composición de aspectos.

Ejemplo la figura siguiente ilustra un ejemplo clásico de una preocupación:

Ingeniería de requisitos orientada a aspectos:

La ingeniería de requisitos orientada a aspectos (también denominada "Aspectos

iniciales") se centra en la identificación, especificación y representación de
propiedades transversales a nivel de requisitos . Ejemplos de tales propiedades
incluyen seguridad , movilidad, disponibilidad y restricciones en tiempo real . Las
propiedades transversales son requisitos, casos de uso o características que
tienen un efecto de alcance amplio en otros requisitos o componentes de la
arquitectura .

Los enfoques de ingeniería de requisitos orientados a aspectos son técnicas que

reconocen explícitamente la importancia de abordar claramente las
preocupaciones transversales tanto funcionales como no funcionales , además de
las no transversales. Por lo tanto, estos enfoques se centran en tratar, razonar,
componer y, posteriormente, rastrear de manera sistemática y modular las
preocupaciones transversales funcionales y no funcionales a través de
mecanismos adecuados de abstracción , representación y composición adaptados
al dominio de la ingeniería de requisitos.

Las áreas específicas de excelencia bajo el denominador de Análisis de

Requisitos AO son:

 El propio proceso de requisitos orientados a aspectos.

 Las notaciones de requisitos orientados a aspectos.
 Los soporte de herramientas de requisitos orientados a aspectos.
 La adopción e integración de la ingeniería de requisitos orientada a
aspectos.
 La valoración / evaluación de requisitos orientados a aspectos.

Gestión de procesos de negocio orientada a aspectos (AOBPM):

La reducción de la complejidad es un tema importante en el área de Gestión de
Procesos de Negocio (BPM). Una fuente de complejidad radica en la variedad de
preocupaciones que aborda un proceso empresarial, como la seguridad y la
privacidad. Idealmente, estas preocupaciones deberían definirse por separado de
los procesos de negocio, ya que normalmente abarcan varios procesos y pueden
estar sujetos a cambios a nivel organizativo general en lugar de a nivel de proceso
específico. Sin embargo, los sistemas de gestión de procesos empresariales
actuales no admiten este tipo de modelado. La gestión de procesos de negocio
orientada a aspectos (AOBPM) intenta apoyar la separación de las
preocupaciones transversales de las preocupaciones comerciales centrales.
Define un conjunto de requisitos y un modelo formal. Este modelo está diseñado
con redes de Petri de colores (CPN).

Arquitectura del sistema orientada a aspectos:

La arquitectura de sistemas orientada a aspectos se centra en la localización y

especificación de preocupaciones transversales en diseños arquitectónicos. Las
preocupaciones transversales que aparecen a nivel arquitectónico no se pueden
modular mediante la redefinición de la arquitectura del software utilizando
abstracciones arquitectónicas convencionales. Los lenguajes de arquitectura de
sistemas orientados a aspectos proponen mecanismos explícitos para identificar,
especificar y evaluar aspectos a nivel de diseño de arquitectura.

La arquitectura orientada a aspectos parte de la observación de que necesitamos

identificar, especificar y evaluar aspectos explícitamente a nivel de diseño de
arquitectura. Los enfoques de arquitectura dimensional describen los pasos para
identificar aspectos arquitectónicos. Esta información se utiliza para rediseñar una
arquitectura determinada en la que se explicitan los aspectos arquitectónicos.

En este sentido, las áreas específicas de excelencia son:

 El propio proceso de arquitectura orientada a aspectos.

 Las notaciones de arquitectura orientada a aspectos.
 Los soporte de herramientas de arquitectura orientada a aspectos.
  La adopción e integración de arquitectura orientada a aspectos.
 La valoración / evaluación de la arquitectura orientada a aspectos.

Modelado y diseño orientado a aspectos:

El diseño orientado a aspectos tiene los mismos objetivos que cualquier actividad
de diseño de software, es decir, caracterizar y especificar el comportamiento y la
estructura del sistema de software. Su contribución única al diseño de software
radica en el hecho de que las preocupaciones que están necesariamente
dispersas y enredadas en enfoques más tradicionales se pueden modularizar.
Normalmente, este enfoque incluye tanto un proceso como un lenguaje. El
proceso toma como entrada los requisitos y produce un modelo de diseño. El
modelo de diseño producido representa preocupaciones separadas y sus
relaciones. El lenguaje proporciona construcciones que pueden describir los
elementos a representar en el diseño y las relaciones que pueden existir entre
esos elementos. En particular, se proporcionan constructos para respaldar la
modularización de preocupaciones y la especificación de la composición de
preocupaciones, teniendo en cuenta los conflictos. Más allá de eso, el diseño de
cada empresa modularizada individual se compara con el diseño de software es
estándar.

Aquí, las áreas específicas de áreas de excelencia son:

 El propio proceso de diseño orientado a aspectos.

 Las notaciones de diseño orientadas a aspectos,
 Los soporte de herramientas de diseño orientado a aspectos.
 La adopción e integración del diseño orientado a aspectos.
 La valoración / evaluación del diseño orientado a aspectos.

Programación orientada a aspectos (AOP):

La programación orientada a aspectos AOP incluye técnicas y herramientas de

programación que apoyan la modularización de preocupaciones a nivel del código
fuente. Al igual que cualquier otro lenguaje de programación, un lenguaje
orientado a aspectos generalmente consta de dos partes (una especificación del
lenguaje y una implementación)

Por lo tanto, hay dos áreas de preocupación correspondientes:

 Soporte para desarrolladores de lenguajes.

 soporte para desarrolladores de aplicaciones.

Soporte para desarrolladores de aplicaciones:

Un enfoque orientado a aspectos apoya la implementación de inquietudes y cómo

componer esas inquietudes implementadas de forma independiente. Si bien la
especificación de dicho lenguaje es el manual principal para los desarrolladores de
aplicaciones, obviamente no proporciona ninguna garantía de que el desarrollador
de aplicaciones producirá programas orientados a aspectos de alta calidad.

Las areas específicas de excelencia:

 Los conceptos cruciales de la programación orientada a aspectos.

 Programación en lenguajes orientados a aspectos.
 Componer componentes de software escritos en cualquier idioma utilizando
mecanismos de composición orientados a aspectos.
 Entornos de programación orientados a aspectos.

Soporte para desarrolladores de idiomas:

La excelencia en la construcción de lenguajes orientados a aspectos incluye las

siguientes áreas:

 Construir lenguajes o DSL para dominios y / o plataformas específicos.

 Transferir principios de implementación de otros entornos de ejecución
orientados a aspectos. Está compuesto de: (intérpretes, compiladores, y
maquinas virtuales).

Ventajas del desarrollo de software orientado a aspectos:

 Permite una implementación modularizada reduciendo el acoplamiento

entre sus partes.
  El código es más limpio, menos duplicado, más fácil de entender y de
mantener.
 Elimina los problemas causados por el código mezclado y el código
diseminado.
 Mayor reutilización, los aspectos tienen mayor probabilidad de ser
reutilizados en otros sistemas con requisitos similares.
 Estos sistemas son más adaptables a cambios, la separación de conceptos
permite agregar nuevos conceptos, modificarlos y removerlos de forma
sencilla.

Desventajas del desarrollo de software orientado a aspectos:

 Sufre de un anti-patrón de diseño: acciones a distancia.

 Vuelve difícil de comprender el código puesto que el programa hace tareas
que no están en los métodos que deberían estar.

 Posibles choques entre el código funcional (expresado en el lenguaje

componente) y el código de aspectos (expresados en los lenguajes de
aspectos): Usualmente estos choques nacen de la necesidad de violar el
encapsulamiento para implementar los diferentes aspectos, sabiendo de
antemano el riesgo potencial que se corre al utilizar estas prácticas.
 Posibles choques entre los aspectos: El ejemplo clásico es tener dos
aspectos que trabajan perfectamente por separado pero al aplicarlos
conjuntamente resultan en un comportamiento anormal.

Conclusión

Para concluir este tema podemos decir que el desarrollo orientado a aspecto es
una muy importante forma de desarrollo de software, la utilización de aspectos en
el proceso de desarrollo de software proporciona un soporte avanzado para la
separación de intereses introduciendo una nueva forma de modularizar el sistema.
El resultado de este enfoque es obtener un producto software más fácil de
mantener, extender y reutilizar, ya que una tecnología de desarrollo de software
busca nuevas modularizaciones de los sistemas de software para aislar las
funciones secundarias o de apoyo de la lógica empresarial del programa principal.
El enfoque del desarrollo de software orientado a aspectos está en la investigación
e implementación de nuevas estructuras para la modularidad del software que
brindan soporte para abstracciones explícitas para modularizar las
preocupaciones.