Abstract

Ante la inminente imposición de un nuevo paradigma para el desarrollo de sistemas, como lo es la

orientación a aspectos, hemos decidido estudiar el tema más de cerca, buscando alcanzar una
conclusión concreta al respecto, dejando claras las ventajas y desventajas de un posible cambio de
paradigma en la construcción de sistemas. Es claro que nuestro objetivo es comparar y contrastar un
paradigma instalado, implementado durante años de desarrollo, contra un paradigma joven, donde
la cantidad de expertos es mucho más reducida y sus aplicaciones son menos conocidas. Por tanto,
como es de esperar, la documentación disponible sobre el paradigma de aspectos es bastante
acotada, y es aún más difícil encontrar estudios que propongan una comparación objetiva de
aptitudes entre los paradigmas competidores. Por todo esto, intentaremos recopilar la mayor
cantidad de información posible para nuestro estudio, aunque es probable que la conclusión
alcanzada sea sólo de carácter cualitativo, ante la falta de experiencias cuantizables.

1 – Introducción
Existen actualmente dos paradigmas de construcción de sistemas informáticos Existen mas
paradigmas, yo pondría algo así como: si bien existen vario o muchos paradigmas, en la actualidad
se utilizan principalmente dos paradigmas….. (y pongan alguna referencia bibliográfica) . El
primero, programación orientada a objetos, más conocido por su nombre y su sigla en inglés
“Object Oriented Programming” - 'OOP', es actualmente el de uso mayoritario, y lleva vigente ya,
varios años, tiempo que para todo lo relacionado con la tecnología informática es cuasi infinito.
Este paradigma está basado en el reconocimiento de entidades concretas y abstracciones
distinguibles, suceptibles de ser modeladas. El segundo paradigma en pugna es la programación
orientada a aspectos -”Aspect Oriented Programming”, 'AOP'. Es el paradigma joven, aún sin
mucha experiencia, aunque su juventud no es una contra en absoluto, ya que al momento de su
aparición, se contaba con toda la experiencia cosechada en los años anteriores, primero de
programación estructurada, y luego de programación orientada a objetos. Su aparición fue
impulsada por un concepto preexistente: Separación de incumbencias - “Separation of Concerns”
(SoC). Hasta el momento, esta cuestión venía siendo manejada elegantemente sobre el paradigma
de objetos, sin embargo, el enfoque propuesto por el nuevo paradigma es precisamente facilitar la
tarea.
Falta un párrafo que le genere interés al lector por seguir leyendo, tengan en cuenta que en general
la gente lee la introducción y si le resulta interesante lee las conclusiones y si en ese momento le
sigue resultando interesante lee el resto del artículo. Creo que el párrafo debería decir algo así: no
existe un consenso universal a cerca de que paradigma utilizar….. existen varios trabajos
experimentales que analicen este aspecto pero sin una coincidencia completa en sus conclusiones,
por ello en el presente trabajo se llevará adelante una revisión sistemática que permita analizará la
eficiencia de ambos paradigmas para ayudar a los desarrolladores a determinar cual de los
paradigmas es mas conveniente……

2- Estado de la cuestión
2.12 – Programación Orientada a Objetos
La programación orientada a objetos o POO (OOP por sus siglas en inglés) es un paradigma 
que usa un concepto basado en abstracciones, y en un modelado de la realidad mediante 
objetos e interacciones mutuas, para diseñar aplicaciones y programas informáticos. Los 
pilares fundamentales de este paradigma son varios: abstracción, herencia, polimorfismo y 
encapsulamiento. Su uso se popularizó a principios de los años 1990 y creció con el tiempo. 
En la actualidad, existe variedad de lenguajes de programación que soportan la orientación 
a objetos. Entre los más representativos podemos mencionar 'Smalltalk', 'Java', 'C++', 
'Python' y 'PHP'. Para completar esta idea, presentamos algunas citas de otros autores.

“ La programación orientada a objetos (POO) ha supuesto uno de los avances más importantes de
los últimos años en la ingeniería del software para construir sistemas complejos utilizando el
principio de descomposición, ya que el modelo de objetos subyacente se ajusta mejor a los
problemas del dominio real que la descomposición funcional. La ventaja que tiene es que es fácil la
integración de nuevos datos, aunque también quedan las funciones esparcidas por todo el código, y
tiene los inconvenientes de que, con frecuencia, para realizar la integración de nuevas funciones hay
que modificar varios objetos, y de que se produce un enmarañamiento de los objetos en funciones
de alto nivel que involucran a varias clases. ”
[ref-1] “Visión General de la Programación Orientada a Aspectos” - Antonia Ma. Reina Quintero -
Departamento de Lenguajes y Sistemas Informáticos - Universidad de Sevilla - Diciembre, 2000 -
http://www.willydev.net/descargas/abcpoa.pdf

“La orientación a objetos proporciona un nuevo paradigma para la creación de software. En este
nuevo paradigma, los objetos y las clases son los pilares, mientras que los métodos, los mensajes y
la herencia producen los mecanismos primarios. Históricamente, la creación de un programa
implicaba la definición de procesos que actuaban sobre un conjunto independiente de datos. (…) la
orientación a objetos cambia el centro de atención del proceso de programación desde el
procedimiento a los objetos -módulos autocontenidos que incluyen tanto los datos como los
procedimientos que actúan sobre los datos.”
[ref-2] - “Software orientado a objetos” - Ann L. Winblad, Samuel D. Edwards, David R. King -
Addison-Wesley/Diaz de Santos (Versión en español de Ramón Ruiz Ayuso)

2.23 – Programación Orientada a Aspectos

La Programación Orientada a Aspectos (POA) es un paradigma de programación relativamente
reciente cuya intención es permitir una adecuada modularización de las aplicaciones y posibilitar
una mejor separación de incumbencias. Gracias a la POA se pueden encapsular los diferentes
conceptos que componen una aplicación en entidades bien definidas, eliminando las dependencias
entre cada uno de los módulos. De esta forma se consigue razonar mejor sobre los conceptos, se
elimina la dispersión del código y las implementaciones resultan más comprensibles, adaptables y
reusables. Varias tecnologías con nombres diferentes se encaminan a la consecución de los mismos
objetivos y así, el término POA es usado para referirse a varias tecnologías relacionadas como los
métodos adaptativos, los filtros de composición, la programación orientada a sujetos o la separación
multidimensional de competencias. Nuevamente presentamos algunas citas para ilustrar el
problema.

“La programación orientada a aspectos (POA) es una nueva metodología de programación que
aspira a soportar la separación de competencias para los aspectos antes mencionados. Es decir, que
intenta separar los componentes y los aspectos unos de otros, proporcionando mecanismos que
hagan posible abstraerlos y componerlos para formar todo el sistema. En definitiva, lo que se
persigue es implementar una aplicación de forma eficiente y fácil de entender.
POA es un desarrollo que sigue al paradigma de la orientación a objetos, y como tal, soporta la
descomposición orientada a objetos, además de la procedimental y la descomposición funcional.
Pero, a pesar de esto, POA no se puede considerar como una extensión de la PO”
[ref-1] “Visión General de la Programación Orientada a Aspectos” - Antonia Ma. Reina Quintero -
Departamento de Lenguajes y Sistemas Informáticos - Universidad de Sevilla - Diciembre, 2000 -
http://www.willydev.net/descargas/abcpoa.pdf

“La Programación tradicional carece actualmente de mecanismos adecuados para abstraer, y

encapsular conceptos que no forman parte de la funcionalidad básica de los sistemas, tales como
debugging, sincronización, distribución, seguridad, administración de memoria, y otros. El
resultado de esta insuficiente abstracción es una notable disminución de la calidad del software
final. Una de las alternativas más prometedoras para resolver este problema es la Programación
Orientada a Aspectos (POA). En este trabajo damos una visión informativa acerca de este nuevo
Paradigma en la programación, su historia, ventajas y desventajas, analizaremos una aplicación
basada en la POA y los lenguajes que desarrollan aplicaciones con la POA. ”
[ref-3] - “Programación Orientada a aspectos ” - Eric Ruiz Campos , Eduardo Rodriguez
Maysundo , Heider Ysaias Sanchez Enriquez - Universidad Nacional de Trujillo - Escuela
Académico Profesional de Informática

2.3 Revisiones sistemáticas

Acá pongan un par de párrafos que diga en que consiste la revisión.
3 – Definición del problema
Acá habría que ampliar lo dicho en el introducción respecto de la falta de un consenso universal
respecto de que paradigma utilizar, si es posible mensionen también dos de los papers encontrados
con resultados antagónicos esto va a dar mas fuerza a la necesidad de hacer una revisión

4 – Presentación del Asunto Desarrollo de la solución

En presencia de las variantes introducidas en este documento, hemos decidido desarrollar una
RS….. planteen acá lo que sería la pregunta de investigación: es mejor utilizar el paradigma A o
B…..

investigar el asunto para lograr una comparación fiel a la realidad, basándonos en las
investigaciones existentes, entre las fuerzas y debilidades de ambos paradigmas de programación.
La intención entonces es cuantizar las diferencias entre los objetos de nuestro estudio y encontrar
una relación de superioridad de uno sobre el otro.
Cabe aclarar que, como ya se mencionó anteriormente, el paradigma de aspectos surgió con una
intención muy clara, que es la de facilitar la separación de incumbencias, dentro de los distintos
aspectos de una aplicación. Fuera de esto, a excepción de repercusiones que tenga en otros asuntos,
no es posible una comparación entre los paradigmas, al menos no con la intención de cuantizar la
superioridad de uno sobre otro. Por estas razones, nos enfocaremos en los casos en que lo que se
compara son diferencias logradas sobre problemas que tengan que ver con este aspecto.

Pongan también las fase de la revisión que indica Kitchenham (definir la pregunta de investigación,
búsqueda y selección de experimentos y sisntesis de resultados….)

Antes de detallar los estudios tienen que detallar la pregunta de investigación y el contexto de
búsqueda y selección. También es importante docuemntar cuantos experiemntos encontraron y
cuantos descartaron, sino el trabajo deja de ser una revisisón sistemática real y se transforma en una
simple revisión bibliográfica, la cual puede esta fuertemente influenciada por la opinión de quien la
realiza.

5 - Estudios empíricos recogidos

An Initial Assessment of Aspect-oriented Programming [ref 1]
Autors:
Robert J. Walker
Elisa L.A. Baniassad
Gail C. Murphy
Identificador de paper: 00841001
El informe presenta varias mediciones de algunas experiencias, de común ocurrencia en la
programación: debugging y modificación. En la experiencia participaron equipos de desarrolladores
conformados de manera tal que sus habilidades fueran niveladas lo mejor posible para no sesgar el
estudio. De esta manera, algunos equipos trabajando con objetos y otros con aspectos, se plantearon
situaciones comunes para medir algunas variables. Las variables consideradas en este experimento
fueron: el tiempo consumido en cada tarea planteada, la cantidad de cambios realizados para
resolver un problema, ocasiones de análisis semántico del código, cantidad de compilaciones
realizadas y granularidad en las cuestiones de concurrencia.
Valores cuantizados (cálculos en apéndice):
Costo de debugging: 0,67
Tiempo de desarrollo: 2,47

6 – Ponderaciones cualitativas

7 – Conclusión

8 – Referencias Bibliográficas
Ref 1: “Visión General de la Programación Orientada a Aspectos” - Antonia Ma. Reina Quintero -
Departamento de Lenguajes y Sistemas Informáticos - Universidad de Sevilla - Diciembre, 2000 -
http://www.willydev.net/descargas/abcpoa.pdf

Ref 2: “Software orientado a objetos” - Ann L. Winblad, Samuel D. Edwards, David R. King -
Addison-Wesley/Diaz de Santos (Versión en español de Ramón Ruiz Ayuso)

Ref 3: “Programación Orientada a aspectos ” - Eric Ruiz Campos , Eduardo Rodriguez Maysundo ,
Heider Ysaias Sanchez Enriquez - Universidad Nacional de Trujillo - Escuela Académico
Profesional de Informática.
Apéndice

Estudio 1:
Este set de datos refiere al tiempo en minutos que demoraron ciertas tareas de debugging.
AspectJ
T1 1 1 5 = 7/3 = 2.33
T2 14 32 26 = 72/3 = 24.00
T3 7 2 2 = 11/3 = 3.66
-------
30 /3 = 10

Java
T1 20 9 10 = 39/3 = 13.00
T2 16 25 41 = 82/3 = 27.33
T3 9 2 10 = 21/3 = 7.00
-------
47 /3 = 15.66

Aspectos 10.00
-------- = ------- = 0.63829
Objetos 15.66
Resultado a favor de AspectJ

Este set de datos refiere a la cantidad de instancias de análisis semántico del código
AspectJ
0 0 2 = 2/3 = 0.66
2 5 2 = 9/3 = 3.00
1 0 0 = 1/3 = 0.33
-------
4 /3 = 1.33

Java
4 1 5 = 10/3 = 3.33
4 4 4 = 12/3 = 4.00
1 8 4 = 13/3 = 4.33
-------
11.66 /3 = 3.88

Aspectos 1.33
-------- = ------- = 0.34285
Objetos 3.88
Resultado a favor de AspectJ

Este set de datos refiere a la cantidad de modificaciones hechas a los archivos

AspectJ
1 1 3 = 5/3 = 1.66
6 3 6 = 15/3 = 5.00
1 1 2 = 4/3 = 1.33
-------
8 /3 = 2.66

Java
2 2 3 = 7/3 = 2.33
3 3 7 = 13/3 = 4.33
1 1 3 = 5/3 = 1.66
-------
25/3 7.33 /3 = 2.77

Aspectos 2.66
-------- = ------- = 0.96
Objetos 2.77
Resultado ligeramente a favor de AspectJ, aunque no es una diferencia
significativa

Esta experiencia refiere a la cantidad de compilaciones realizadas para lograr el objetivo de la

prueba en cada caso
AspectJ
1 1 1 = 3/3 = 1.00
1 6 5 = 12/3 = 4.00
1 1 2 = 4/3 = 1.33
-------
19/3 6.33 /3 = 2.11

Java
5 1 1 = 7/3 = 2.33
1 5 9 = 15/3 = 5.00
1 1 2 = 4/3 = 1.33
-------
26/3 7.33 /3 = 2.88

Aspectos 2.11
-------- = ------- = 0.73 076
Objetos 2.88
Nuevamente a favor de AspectJ, aunque una diferencia bastante ajustada.

Con todas estas experiencias tenidas en cuenta, tomaremos de este estudio, un valor para el costo de
debugging promediando los datos
Tiempo invertido: 0,64
Análisis semánticos de código: 0,34
Cantidad de archivos alterados: 0,96
Cantidad de compilaciones hechas: 0,73
( 0,64 + 0,34 + 0,96 + 0,73 ) / 4 = 0,6675 ~ 0,67
De donde nuestra variable de costo de debugging en aspectos sobre objetos según este estudio toma
el valor de 0,67.
La siguiente variable de este mismo estudio es el tiempo empleado en efectuar un cambio de
comportamiento en el programa. En este caso solo se evaluó el tiempo que demoró cada equipo en
completar la tarea, por lo que será más sencillo de valorar.
AspectJ
32 85 47 =174/3 = 58.00
45 45 43 =133/3 = 44.33
40 - 34 = 74/2 = 37.00
-------
139.33 /3 = 46.44

Java
46 60 45 =151/3 = 50.33
37 15 27 = 79/3 = 26.33
15 20 19 = 54/3 = 18.00
-------
338/6 94.66 /3 = 18.77

Aspectos 46.44
-------- = ------- = 2.47337
Objetos 18.77

para poder compararlo contra las relaciones obtenidas anteriormente invertimos: 1/2.47337 =
0.40431 .
Por lo que la siguiente variable, tiempo de desarrollo en aspectos sobre objetos nos da una
proporción de 2,47.