Urbieta Mario Matias

Universidad Nacional de La Plata

Facultad de Informtica

Metodologa dirigida por modelos

para el diseo de Funcionalidad

Voltil en aplicaciones Web

Autor: Lic. Mario Matias Urbieta

Director: Dr. Gustavo H. Rossi

Tesis presentada para obtener el grado de Doctor en Ciencias Informticas

- Abril 2012-

Resumen

La popularidad y facilidad de acceso de las aplicaciones Web expone a una aplicacin Web a

exigencias de nuevas caractersticas realizadas por sus usuarios que sta debe proveer para

mantener cautivo al usuario implantando un estado de constante evolucin. La evolucin

requiere usualmente modificaciones de funcionalidad existente o nueva funcionalidad para

mejorar la experiencia del usuario en la aplicacin Web. Muchas veces estos cambios son

requeridos para mantener vigente a la aplicacin, es decir acompaar a las tendencias del

mercado. Los cambios introducidos pueden corresponder a un tipo de funcionalidad llamado

voltil caracterizado por ser temporal, surgir de improviso y muchas veces por deber ser

incorporada a la brevedad. Cuando esta funcionalidad es temporal, se incorpora al sistema para

luego ser retirada de forma planificada en base a una fecha determinada o de forma espontanea

en base a un evento de negocio. En este escenario, entre otras variables, se ve comprometida la

mantenibilidad y estabilidad de la aplicacin. Por otro lado, su inesperado surgimiento

usualmente no permite una adopcin fcil y econmica ya que la aplicacin no fue diseada

teniendo en cuenta esta nueva funcionalidad.

En esta tesis se presenta una metodologa modular para dar solucin a los requerimientos

voltiles en aplicaciones Web. La metodologa abordar el problema desde las etapas anlisis

brindando herramientas conceptuales para su adecuado diseo y posterior implementacin. Es

modular ya que puede complementar las metodologas de ingeniera Web ms maduras; en esta

tesis se utilizara como metodologa de referencia OOHDM. En la etapa de anlisis de

requerimientos, se proveern herramientas que permitan identificar, aislar, y gestionar

inconsistencias de requerimientos voltiles. Para las tareas de diseo se proveern herramientas

tericas que faciliten el modelado de los requerimientos de las aplicaciones Web brindando

instrumentos para los diferentes modelos involucrados: conceptual, navegacional, y de interfaz.

Finalmente, se proveer una gua de implementacin de ste tipo de funcionalidad con un

anlisis comparativo con la implementacin de funcionalidad voltil ad-hoc.

Agradecimientos

A la mujer de mi vida Cecilia

Contenido

Captulo 1 Introduccin ........................................................................................................... 11

1.1 Motivacin ..................................................................................................................... 11

1.1.1 Problemtica presente en aplicaciones RIA ........................................................... 13

1.1.2 Problemtica presente en aplicaciones Web GIS ................................................... 15

1.1.3 Funcionalidad voltil entrelazada ........................................................................... 17

1.2 Resumen de la motivacin ............................................................................................. 19

1.3 Contribuciones ............................................................................................................... 20

1.4 Estructura de la tesis ....................................................................................................... 21

Captulo 2 Background ............................................................................................................ 25

2.1 Metodologas de desarrollo Web .................................................................................... 25

2.1.1 OOHDM ................................................................................................................. 25

2.1.2 WEBSPEC DSL para especificar aplicaciones Web ........................................... 34

2.2 Modularizacin en Software .......................................................................................... 35

2.2.1 Cohesin - Definicin ............................................................................................ 35

2.2.2 Acople - Definicin ................................................................................................ 36

2.2.3 Inversin de control - Definicin ........................................................................... 36

2.2.4 Concerns en Software ............................................................................................. 37

2.2.5 Desarrollo Software Orientado a Aspectos ............................................................ 41

2.3 Herramientas de diseo .................................................................................................. 45

2.3.1 MATA Descripcin y ejemplo ............................................................................ 45

2.3.2 Especificacin de Patrn - Descripcin y ejemplo ................................................. 46

Captulo 3 Trabajos relacionados ............................................................................................. 48

3.1 Metodologas existentes ................................................................................................. 48

3.2 Desarrollo dirigido por modelos .................................................................................... 50

3.3 Tecnologas para separacin de concerns ...................................................................... 51

Captulo 4 Caracterizacin de funcionalidad voltil ................................................................ 53

Captulo 5 Metodologa de desarrollo de funcionalidad voltil ............................................... 59

Captulo 6 Anlisis de requerimientos ..................................................................................... 67

6.1 Caracterizacin de conflictos en requerimientos de aplicaciones Web .......................... 69

6.1.1 Conflictos estructurales: Definicin ....................................................................... 69

6.1.2 Conflictos navegacionales: Definicin ................................................................... 70

6.1.3 Conflicto semntico: Definicin ............................................................................ 71

6.2 Detectando y corrigiendo conflictos............................................................................... 72

6.3 Relevamiento de requerimientos y modelado de requerimientos ................................... 74

6.4 Detectando conflictos sintcticos ................................................................................... 74

6.5 Anlisis semntico.......................................................................................................... 75

6.6 Proceso de conciliacin .................................................................................................. 80

6.7 Herramienta CASE de soporte ....................................................................................... 84

Captulo 7 Modelo Conceptual ................................................................................................ 87

7.1 Requerimientos del ejemplo gua .................................................................................. 88

7.2 Identificar crosscutting concerns .................................................................................... 90

7.3 Modelado de funcionalidad Core Orientado a Objetos .................................................. 92

7.4 Modelado conceptual Orientado a Aspectos .................................................................. 93

7.4.1 Modelado de funcionalidad voltil con MATA ..................................................... 94

7.4.2 Diseando generalizaciones de aspectos ................................................................ 95

7.4.3 Implementacin AOP de diagramas MATA y PS .................................................. 96

7.5 Solucin Orientado a Objetos sin soporte de aspectos ................................................... 98

7.5.1 Reglas de transformacin de modelos AOP a modelos OOP ................................. 99

7.5.2 Discusin sobre las reglas de transformacin ...................................................... 104

Captulo 8 Modelo navegacional ........................................................................................... 107

8.1 Definicin de afinidad .................................................................................................. 108

8.2 La ejecucin de las consultas de Afinifidad ................................................................. 110

8.3 Volatilidad en procesos de negocios ............................................................................ 110

Captulo 9 Modelo de Interfaz de Usuario ............................................................................. 113

9.1 Diseo de Iinterfaces de Usuario Core ......................................................................... 114

9.2 Composicin estructural de funcionalidad voltil en la Interfaz de Usuario ............... 116

9.3 Funcionalidad voltil de comportamiento en interfaces de usuario ............................. 119

9.3.1 Implementacin ADV y ADV-Charts .................................................................. 124

9.4 Modelando comportamiento voltil en interfaces de usuario con aspectos ................. 126

9.4.1 Diseo de Interfaz de Usuario utilizando MATA ................................................ 127

9.4.2 Resultado de la composicin de aspectos ............................................................. 127

9.4.3 Detalles de implementacin del ejemplo de Calles bloqueadas .......................... 130

Captulo 10 Gestin del ciclo de vida de las funcionalidades voltiles ................................... 131

10.1 Modelo de ciclo de vida ............................................................................................... 131

Captulo 11 Framework de soporte de la metodologa: Cazon ................................................ 137

Captulo 12 Evaluacin tcnica de pruebas ............................................................................. 143

12.1 Anlisis de impacto ...................................................................................................... 143

12.1.1 Modelo Conceptual .............................................................................................. 144

12.1.2 Modelo navegacional ........................................................................................... 144

12.1.3 Modelo de interfaz ............................................................................................... 145

12.2 Anlisis de cdigo fuente ............................................................................................. 146

Captulo 13 Conclusiones ........................................................................................................ 149

Captulo 14 Trabajos futuros .................................................................................................... 151

14.1 En validacin de requerimientos .................................................................................. 151

14.2 Metodologa ................................................................................................................. 151

14.3 Interfaces de Usuario convencionales .......................................................................... 152

14.4 Herramienta WebSpec .................................................................................................. 152

Captulo 15 Referencias ........................................................................................................... 153

Apndice A. Abreviaturas ..................................................................................................... 163

Apndice B. Produccin cientfica ........................................................................................ 167

Apndice C. Trminos........................................................................................................... 169

Apndice D. Ejemplo de implementacin de funcionalidades voltiles con Cazon ............. 171

Metodologa dirigida por modelos para el diseo de Funcionalidad Voltil en

aplicaciones Web Introduccin

Lic. Mario Matias Urbieta

Pgina 11

Captulo 1 Introduccin

1.1 Motivacin

Una de las caractersticas ms destacables de las aplicaciones Web es su continua evolucin en

respuesta a nuevos requerimientos o solo con el propsito de mantener su atractivo para los

usuarios. El contexto actual de Internet expone a las aplicaciones Web a millones de potenciales

usuarios para que las utilicen; ms precisamente el 29% de la poblacin mundial [1], [2], [3].

Ante tal exposicin, el equipo responsable de estas aplicaciones Web se ve agobiado ante la

necesidad de satisfacer las necesidades de la mayora de estos usuarios para capturar/mantener

clientes del negocio subyacente. Estas necesidades empujan a las aplicaciones Web a ponerse a la

altura de las circunstancias mediante una evolucin continua, con el principal motivo de no perder

vigencia. Esta evolucin no necesariamente resulta de una solicitud especfica de algn usuario

sino que puede surgir internamente desde la organizacin que brinda la aplicacin Web con el

objetivo de mejorar la experiencia del usuario.

Nuevos requerimientos surgen constantemente durante la vida de las aplicaciones Web donde su

mayora son incorporados para ser parte de la aplicacin de forma permanente. Por ejemplo, una

aplicacin Web dedicada al comercio electrnico [4] de productos en general comienza a brindar

un servicio de envo por correo de productos adquiridos por los clientes. Esta nueva caracterstica

de la aplicacin implica la incorporacin de un nuevo formulario donde se solicitan los datos del

domicilio dnde realizar el envo. Esta nueva funcionalidad es un servicio que ha sido planificado

por los responsables del rea de ventas y que se encuentra disponible por una variedad de

comercios, tanto fsicos como electrnicos, donde se pudo comprobado su utilidad y estabilidad.

Sin embargo, no todas las nuevas funcionalidades que se pueden presentar en una aplicacin Web

pueden ser planificadas de forma tal que su incorporacin pueda ser diseada e implementadas

como el ejemplo anterior, sino que pueden ser solicitadas de forma espontanea para un evento de

negocio en particular y para perdurar por perodo de tiempo indefinido. Por ejemplo, en el mismo

sitio de comercio electrnico del ejemplo anterior, nuevos requerimientos se pueden presentar

como ofertas especiales en ciertos periodos del ao (Navidad, el da de los enamorados, etc.) para

productos especficos, adecuacin de contenido especficos correspondientes a nuevos

lanzamientos tal como la incorporacin de videos, funcionalidad para brindar ayuda luego de una

catstrofe, entre otros.

Las funcionalidades que son implementadas una vez, relacionada con un evento espordico e

inesperado, por ejemplo basados en catstrofes naturales o campaas de marketing espontaneas,




Pgina 12

y luego removida definitivamente, o son peridicamente activadas durante momentos particulares

del ao, son denominadas como Funcionalidades Voltiles [5].

En la Ilustracin 1 e Ilustracin 2 se muestra la promocin Volver a la Escuela (Back-to-

School) en Amazon.com[6] que tiene como principal objetivo capturar clientes con necesidades

bien conocidas adaptando gran parte de la aplicacin Web para que la navegacin general del ste

simplifique el acceso de productos escolares. La Ilustracin 1 muestra un link voltil (con una

imagen de la promocin y una breve descripcin) remarcado con una elipsis punteada en la

pgina principal el sitio que permite navegar a un catalogo de productos que fueron

seleccionados para la promocin; esta pgina puede ser apreciada en la Ilustracin 2. Algunos

das antes de que las vacaciones de verano terminen y durante el periodo en que las actividades

acadmicas comienzan, los clientes pueden acceder a ciertas ofertas, ms precisamente, pueden

beneficiarse con el envo gratuito de productos adquiridos dentro de la promocin con algunas

restricciones.

Ilustracin 1 Link voltil a las ofertas de

Vuelta a la Escuela.

Ilustracin 2 Pgina principal de Vuelta a la Escuela

Los cambios requeridos para incorporar el link (con su imagen y descripcin) y pgina con las

promociones pueden parecer simples, sin embargo su incorporacin desata cambios que se

propagan en todas las dimensiones de una aplicacin Web modificando reglas de negocio,

estructura de datos, estructura navegacionales, interfaces de usuario, entre otros.




Pgina 13

Este tipo de funcionalidad que se introduce en la aplicacin Web de forma inesperada no solo est

ligada a aplicaciones de comercio electrnico sino que se pueden encontrar en una diversa

variedad de aplicaciones tal como Sistemas de Informacin Geogrfico (GIS, Geographic

Information System) [7], [8], Blogs [9], diarios online [10], entre otros.

Las aplicaciones Web denominadas perpetual beta ( [11], [12]) debido a su estrategia gil,

fomenta el lanzamiento de nuevas funcionalidades tan pronto como sea posible (Por ej. Cada 30

minutos) para que el mismo usuario perfeccione la aplicacin mediante su feedback directo

(comentarios explcitos) e indirecto (detectado por los ingenieros de la aplicacin a partil del

patrn de uso de la aplicacin). Estos requerimientos, pueden ser funcionalidades voltiles ya que

nuevos requerimientos surgen espontneamente motivados por analistas y en el caso de no ser

adoptado por los clientes son removidos. En aplicaciones Web del tipo perpetual Beta, la

funcionalidad es introducida de forma incremental como evolucin, mayormente de forma

transparente, sin romper la estructura y apariencia de la interfaz de usuario. En diferentes

ocasiones estas funcionalidades son luego descartadas. De ahora en adelante se referenciar como

Funcionalidad Beta funcionalidades de este tipo de aplicacin. A pesar de que la vigencia de

sta funcionalidad es claramente es una decisin de negocio que incumbe a reas de Marketing,

ventas, etc. de una compaa., la gerencia de sistema debe asegurar que el diseo sea tambin

estable y que no est comprometido cada vez que hay un cambio.

A lo largo de esta tesis se presentarn una variedad de ejemplos para poder destacar la

problemtica existente asociadas a la funcionalidad voltil en diferentes dominios de negocio

(aplicaciones GIS y comercio electrnico), y tipo de aplicacin (convencionales y Aplicaciones

de Internet Ricas).

1.1.1 Problemtica presente en aplicaciones RIA

Muchos de los sitios publicados en internet estn evolucionando del hipertexto convencional a

Aplicaciones de Internet Ricas[13] (RIA, Rich Internet Applications). Incorporando caractersticas

RIA, estos sitios son capaces de mejorar la usabilidad y en consecuencia atraer una mayor

cantidad de potenciales compradores. Las funcionalidades RIA permiten mostrar datos relevantes

de productos de forma ms novedosa y efectiva. Por ejemplo, en las aplicaciones RIA que

gestiona informacin de productos tal como en el ejemplo de la aplicacin de comercio

electrnico que se viene utilizando, es posible mejorar la experiencia de la bsqueda de productos

de varias formas: (i) Una de ellas, al momento de introducir el nombre de un producto a buscar en

un campo del formulario de bsqueda, se puede resolver la bsqueda en paralelo a medida que se

ingresan los caracteres del nombre mostrando los resultados parciales de dicha bsqueda; de esta

forma el usuario puede tomar conocimiento de los resultados ms relevantes de forma inmediata

presentados en un pop-up. O por otro lado, (ii) una vez listados los productos que concuerdan con

el nombre ingresado en el formulario de bsqueda, se puede permitir presentar un detalle del

producto (valorizacin, comentarios, imgenes, etc.) que se encuentra debajo del mouse sin




Pgina 14

perder el contexto de la bsqueda ya que usualmente los listados presentan informacin bsica de

un producto para luego navegar hacia el detalle en otra pgina. Utilizando el esquema

navegacional convencional, la solucin requiere navegar hacia la pgina de un producto para

conocer su detalle, requiriendo volver a atrs en la navegacin en el caso de que no corresponda

al producto deseado. En cambio la solucin RIA, permite fcilmente conocer el detalle del

producto sin navegaciones adicionales dado que se utilizan caractersticas ricas de interaccin.

Volvamos al ejemplo del sitio de comercio electrnico. Los usuarios son capaces de navegar a

travs de un producto para conocer su detalle con funcionalidad RIA para mejorar la experiencia

del usuario. Por ejemplo, en la Ilustracin 3 se muestra como la interfaz permite intercambiar la

foto principal del producto (la imagen que se encuentra del lado izquierdo a la descripcin del

producto) simplemente posicionando el mouse sobre alguna de las imgenes pequeas que se

encuentran debajo de la imagen principal (sealado con una elipse en la ilustracin). Con el

objetivo de capturar el conocimiento de los diferentes usuarios y facilitar su transferencia entre

ellos, a continuacin se presenta un caso particular de funcionalidad Beta donde se permiten

anotaciones sobre la imagen del detalle de un producto para comentar diferentes aspectos del

producto fcilmente tal como se puede en la Ilustracin 4.

TVs picture 1

TV acme Other products by a Manufacturer

List Price: $xx.xx

Our Price: $xx.xx

Your Save: $zz.zz (tt%)

Ilustracin 3 Interfaz del detalle de un Producto

Con la incorporacin de esta funcionalidad RIA (por su taxonoma), el sitio de comercio

electrnico satisface la curiosidad del cliente o la falta de conocimiento acerca del producto de

una forma concisa con solo una mirada rpida, evitndole la necesidad de leer largos prrafos de

descripcin al usuario. Esta funcionalidad es una funcionalidad Beta ya que su permanencia en la

aplicacin depender de la adopcin que sufra por los usuarios.




Pgina 15

TVs picture 2

TV acme

List Price: $xx.xx

Our Price: $xx.xx

Your Save: $zz.zz (tt%)

Pictures highlight popup with some

feature description

Other products by a Manufacturer

Ilustracin 4 Imagen de producto con anotacin RIA

Desde el punto de vista de diseo, este tipo de extensiones son usualmente un serio problema para

arquitectos y desarrolladores de software debido a que ellos muchas veces no conocen cundo la

nueva funcionalidad ser parte de la aplicacin o si sta va a durar por un perodo de tiempo (por

ejemplo cuando el usuario no la adopta).

1.1.2 Problemtica presente en aplicaciones Web GIS

Veamos ahora un ejemplo en un dominio diferente a aplicaciones Web convencionales y RIA.

Supongamos que necesitamos extender la aplicacin de comercio electrnico con un mdulo Web

para la gestin del servicio de envo a domicilio de los productos adquiridos. Para mejorar la

funcionalidad del sistema, se decidi agregar algunas funcionalidades tpicas de sistemas GIS

para poder generar reportes de rutas y seguimiento del paquete donde se encuentra el producto.

Un reporte de ruta es un plan, utilizado por el conductor de camiones, que provee la ruta ms

corta desde la compaa hasta el destino del producto. Una vez que el requisito de transporte de

encomienda es registrado, el cliente puede ingresar a la aplicacin Web de la compaa para dar

seguimiento a la ruta seguida por el transporte utilizado donde se encuentra el paquete en tiempo

real. Para hacer el ejemplo ms concreto, supongamos que nosotros queremos enviar un paquete

desde el punto de venta (A) hasta un domicilio particular (B). Para planear el envo del paquete, el

sistema debe resolver la ruta ms corta entre ambos puntos. La Ilustracin 5 muestra el mapa de

la ruta que se debera utilizar para el transporte del paquete.

Una situacin que surge de forma imprevista y que tiene un tiempo de vida no determinado (pero

finito) es el mantenimiento de un segmento de calle (identificado con lneas perpendiculares en la

misma imagen) que impide su trnsito. La presencia de este segmento de ruta no disponible

genera un impacto severo en la aplicacin ya que si sta no se adapta, la funcionalidad de hoja de

ruta dejara de ser til. La aplicacin debera ser capaz de tener en cuenta sta situacin para

evitar el segmento de calle en mantenimiento al momento de elaborar la hoja de ruta. De esta




Pgina 16

forma, el mejor camino desde el punto de venta actual hasta el domicilio destino (por ejemplo

utilizando la distancia ms corta del conocido algoritmo de bsqueda A* [14]) es uno de mayor

longitud que el origina como se puede apreciar en la Ilustracin 6.

Ilustracin 5 Ruta de envo directa de encomienda desde punto de venta (A) hasta domicilio

particular (B)

Ilustracin 6 Ruta de envo directa de encomienda desde el punto de venta (A) hasta el domicilio

particular (B) teniendo en cuenta una refaccin temporal de una calles

Si la posibilidad de indicar que un segmento de la calle puede sufrir obras de mantenimiento no

fue planeado, y, en consecuencia, diseado cuando la aplicacin fue construida, sta necesitar

ser mejorada mediante el establecimiento de un nuevo criterio de bsqueda de caminos que

desprecie segmentos intransitables.




Pgina 17

Usualmente, las funcionalidades de bsquedas de caminos son implementadas utilizando

algoritmo de bsqueda de grafos tal como el A*. Por ejemplo, este algoritmo consulta los nodos

adyacentes de un nodo dado para obtener el nodo adyacente de menor coste que ser navegado

para intentar alcanzar el nodo destino. La incorporacin de la funcionalidad voltil que bloquea

calles, afecta el algoritmo A* core, ya que este requiere ahora deber tener en cuenta en el

proceso de bsqueda de los adyacentes a nodos adyacentes que representen nodos bloqueados

para no producir resultados invlidos. Este comportamiento puede replicarse en todos los

algoritmos de bsqueda utilizados en la aplicacin (Dijktra[15], A*, breadth-first [15], etc.).

Adicionalmente, se deber presentar en la interfaz de usuario, por ejemplo con un color diferente,

las calles cortadas para entender el porqu las mismas no son utilizadas en la bsqueda

modificando no slo la capa conceptual de la aplicacin sino tambin la presentacin.

1.1.3 Funcionalidad voltil entrelazada

Como se mencion hasta ahora, las funcionalidades voltiles pueden encontrarse en diferentes

tipos de aplicaciones Web convencionales, en aplicaciones Web GIS y RIA. Adems de la

complejidad inherente de la incorporacin de cualquier funcionalidad voltil por su alto impacto

en tareas de codificacin y gestin de cambios, la variedad de funcionalidades voltiles con la que

tiene que lidiar una aplicacin complejiza la situacin an ms. Varias funcionalidades voltiles

pueden convivir en un determinado componente, o grupo de ellos, afectando el mismo conjunto

de recursos, componentes, estructuras de datos, etc..

La funcionalidad voltil puede tambin afectar un subconjunto de objetos irregular; por ejemplo,

algunos CDs de un comercio pueden estar involucrados en una promocin, algunos videos de un

artista pueden aparecer en ciertas novedades para su promocin, etc..

En la Ilustracin 7 se puede apreciar una pgina del sitio de comercio Amazon[6] correspondiente

al CD de Norah Jones. Por otro lado, en la Ilustracin 8 se muestra la pgina del mismo CD que

se ve afectado por dos funcionalidades voltiles: un video corto del artista que ser retirado luego

de algunas semanas, conocido como Video promocional, y un link a la seccin de ventas de

San Valentn (referenciado como St. Valentine).




Pgina 18

Ilustracin 7 Vista del CD de Norah Jones Not Too Late en Amazon.com

CoreInformation

RelatedVideo

St. ValentineReminder

Ilustracin 8 Diferentes funcionalidades voltiles en un CD en Amazon.com

Siguiendo con el ejemplo, el perodo de vigencia del video promocional ser establecido por

diferentes eventos de negocio. Si se acaba el stock del CDs, un evento de negocio puede




Pgina 19

dispararse para indicar que el video no es ms vigente requiriendo as su anulacin. En el caso del

link a la seccin de San Valentn, siendo esta una promocin regida por fechas fijas,

probablemente, unos das despus de la 14 de febrero1 los links a la seccin de la promocin

podrn ser retirados. En esta situacin irregular, el mantenimiento de la aplicacin se ve

desfavorecido cuando las funcionalidad base correspondiente a la presentacin de la informacin

del producto es el destino de diferentes funcionalidades voltiles correspondientes a San

Valentn y Video relacionado. La activacin o desactivacin de estas dos nuevas

caractersticas de la aplicacin pueden no ser sincrnicas complicando las tareas de

mantenimiento y requiriendo as esfuerzo independiente para cada uno en las tareas de

modificacin del cdigo fuente, pruebas e instalacin. Por ello, esto resulta ser una tarea

altamente propensa a error por ende incrementando las probabilidades de introducir una falla en

la aplicacin.

1.2 Resumen de la motivacin

A partir los ejemplos expuestos anteriormente, lo que caracteriza todo el problema no es solo la

naturaleza inesperada del nuevo requerimiento sino tambin su volatilidad. Estos no son

frecuentemente previstos durante el diseo de la aplicacin y cada vez es ms comn que sean

vlidos por un perodo de tiempo desconocido. Esta situacin compleja caracteriza el problema de

volatilidad y su impacto en el desarrollo de software de aplicaciones Web.

Por cada requerimiento voltil podemos identificar un patrn de volatilidad, un conjunto de

caractersticas de la aplicacin y objetos que se ven afectados, y varias caractersticas adicionales

que sern examinadas en esta tesis.

En general, la incorporacin de una nueva funcionalidad voltil en una aplicacin Web puede

comprender, por ejemplo:

(i) la publicacin de nuevos tipos de contenidos,

(ii) la extensin de estructura de datos existentes,

(iii) la creacin de nuevas estructuras de contenido,

(iv) la implementacin de nuevos comportamientos en la aplicacin y operaciones de

usuario,

(v) y la modificacin del look and feel de una pgina.

Debido a las exigencias de los tiempos de salida al mercado y la ausencia de enfoques

sistemticos, la necesidad de dichas funcionalidades es usualmente resuelta en la etapa de

1 Fecha oficial en Argentina para el da de los Enamorados. Conocido tambin como San Valentn.




Pgina 20

implementacin: nuevos componentes y cdigo son agregados a la aplicacin cuando la

funcionalidad tiene que ser incorporada y luego, una vez que cumple su propsito, los mismos

son removidos o desactivados. Esta prctica, que comprende la edicin iterativa del cdigo fuente

de la aplicacin, a largo plazo, puede tener un impacto negativo en la aplicacin, introduciendo

errores debido a que son tareas manuales y deteriorando la calidad.

La funcionalidad voltil a nivel de modelo puede causar problemas; ya que los requerimientos

voltiles pueden ser, por su naturaleza intrnseca, imprevistos; los diferentes modelos de la

aplicacin (conceptual, navegacional, e interfaces) usualmente no estn preparados para la

correspondiente incorporacin. Estos ltimos deben ser editados dos veces, cuando se agrega y

retira la lgica asociada a la funcionalidad voltil; con el riesgo del alterar el cdigo e introducir

errores.

El refactoring[16] de modelos de diseo para dar lugar modularmente a las nuevas

funcionalidades puede ser un desperdicio de esfuerzo y recursos, debido a que podramos caer en

un sobre diseo de la aplicacin solo por una pieza de funcionalidad que probablemente

desaparecer ms tarde.

Con el propsito de facilitar la incorporacin de funcionalidad voltil dentro de aplicaciones Web

simplificando su evolucin y reduciendo el riesgo de introduccin de errores, se defini, a lo

largo de varias investigaciones, una metodologa que permite el diseo sistemtico,

implementacin y automatizacin de la activacin/desactivacin de funcionalidad voltil como

parte de un enfoque asistido por modelos.

Esta metodologa es modular y, como se describe en el trabajo, aunque es presentado en el

contexto del enfoque Object Oriented Hypermedia Design Method (OOHDM)[17], sus principios

son aplicables a cualquier metodologa de diseo Web. Esta metodologa consiste en un conjunto

de lineamientos que permiten separar el ncleo, o core, (comportamiento estable de la aplicacin)

de funcionalidades voltiles (comportamiento temporal) en la etapa de diseo y este es soportado

por un framework que permite la integracin de funcionalidades voltiles con funcionalidades

ncleo en la etapa de validacin Cazon (ser descripto en las secciones siguientes).

1.3 Contribuciones

La tesis presenta una metodologa para la identificacin, anlisis, diseo e implementacin de

funcionalidades voltiles. En la que se desglosan las siguientes contribuciones:

Proveer un marco de trabajo conceptual para caracterizar funcionalidad voltil de acuerdo

a sus caractersticas. Se promover la discusin sobre las caractersticas ms importantes

de las funcionalidades voltiles siendo estas ilustradas con diferentes ejemplos.




Pgina 21

Facilitar una metodologa de anlisis, diseo e implementacin de funcionalidad voltil.

Presentar una metodologa con herramientas y conceptos que permitir de forma

modular, transparente y no intrusiva la implementacin de funcionalidad voltil.

o Ilustrar, mediante ejemplificaciones las funcionalidades voltiles en diferentes

casos de estudio donde se aplica el enfoque cubriendo las etapas del ciclo de

desarrollo de software: anlisis, diseo, implementacin y testing. Los ejemplos

cubrirn diversos tipos de aplicaciones tal como E-commerce y GIS para

demostrar la eficacia de la metodologa

o Mostrar una metodologa novedosa para la identificacin de inconsistencia de

requisitos de interaccin (Usuario-Maquina). Para ello, se realizar una

caracterizacin de inconsistencias en requerimientos de una aplicacin Web

dependiendo de la taxonoma del conflicto, un mtodo modular para detectar las

inconsistencias que fcilmente puede complementar cualquier mtodo de

ingeniera Web Maduro sin importar su estilo: gil o unificado, y un conjunto de

ejemplos que ilustran la solucin

o Brindar una metodologa sistemtica para el diseo de interfaces de usuario RIA.

La metodologa es una extensin liviana de OOHDM en la cual las interfaces son

especificadas utilizando Abstract Data View y aprovechando la naturaleza

orientada a objetos de la misma. La metodologa tambin toma prestado algunos

conceptos de la orientacin a aspectos para lidiar con composiciones crosscuting

a nivel de interfaz.

Prototipos de aplicaciones que brindan soporte a esta metodologa.

o Se presentar un prototipo para la identificacin de conflictos en la etapa

temprana de identificacin y anlisis de requerimientos,

o y un framework Web que implementa las herramientas conceptuales definidas

para el diseo de los modelos conceptuales, navegacionales e interfaz de una

aplicacin Web.

1.4 Estructura de la tesis

La tesis est estructurada en los siguientes captulos:

Captulo 2 Background: en esta seccin se presentarn mtodos, herramientas y conceptos en

los que esta tesis utiliza como base para el desarrollo de la solucin a la problemtica disparada

por las funcionalidades voltiles. Por ejemplo, se presentar OOHDM debido a que es la base de

la metodologa desarrollada en esta tesis, o Programacin Orientada a Aspecto debido a que se

utilizan conceptos de este paradigma en la solucin desarrollada en esta tesis.




Pgina 22

Captulo 3 Trabajos relacionados: se referenciarn trabajos relacionados directa o

indirectamente a la problemtica surgida por la funcionalidad voltil. Segn se requiera, se

destacarn las diferencias del trabajo discutido con la solucin propuesta en esta tesis.

Captulo 4 Caracterizacin de funcionalidad voltil: se analizarn las caractersticas

fundamentales de la funcionalidad voltil. Se establecer un marco de trabajo para facilitar su

anlisis.

Captulo 5 Metodologa de desarrollo de funcionalidad voltil: en este captulo se introduce

la metodologa que brinda soporte a las funcionalidades voltiles. Se presenta una descripcin

general cada uno de los pasos de la metodologa para luego ser ser desarrollado en las secciones

siguientes. La metodologa cubre casi todo el proceso de desarrollo de una aplicacin Web, desde

la identificacin de los requerimientos hasta su implementacin.

Captulo 6 Anlisis de requerimientos: en este captulo se presenta uno de los aportes ms

novedosos de la tesis, una metodologa para la deteccin y resolucin de conflictos de interaccin

Web en la etapa de anlisis de requerimientos. Se introduce el concepto de conflicto de

requerimientos de interaccin, se lo caracteriza y provee una solucin modular que puede ser

utilizada en otras metodologas de diseo de aplicaciones Web.

Captulo 7 Modelo Conceptual: a partir del esquema de trabajo definido en el Captulo 5

Metodologa de desarrollo de funcionalidad voltil, en este captulo se describe cmo modelar

los objetos de negocios voltiles utilizando diagramas UML y MATA como herramientas

principales. Posteriormente se discutir como llevar los modelos diseados en base a una

Orientacin a Aspectos a un paradigma Orientado a Aspecto para aquellas plataformas que no

soporten AOP.

Captulo 8 Modelo navegacional: al igual que en el modelo conceptual, en este captulo se

proveen herramientas conceptuales para disear el aspecto navegacional de una funcionalidad

voltil. Adems, se describir brevemente como disear e implementar funcionalidades voltiles

que comprometen el proceso de negocio subyacente de un concern core.

Captulo 9 Modelo de Interfaz : en este captulo se presenta otro de los aspectos ms

novedosos de esta tesis, el diseo aspectos de interfaces de usuario voltiles. Utilizando ADVs y

ADV-Charts se disean interfaces y mediante extensiones, desarrolladas en esta tesis, se

especifican cambios interfaces no invasivos a la interfaz core.

Captulo 10 Gestin del ciclo de vida de las funcionalidades voltiles: se presenta un

Lenguaje Especfico de Dominio (DSL) que ser utilizado para indicar de qu forma se activarn

y desactivarn las funcionalidades voltiles. Se utilizarn ejemplos para describir claramente cada

concepto.




Pgina 23

Captulo 11 Framework de soporte de la metodologa: Cazon: aqu se presenta la arquitectura

de un prototipo de framework Web llamado Cazon. Este framework permite implementar los

conceptos discutidos en las secciones anteriores.

Captulo 12 Evaluacin tcnica de pruebas: se discutir cul es el impacto de las

funcionalidades voltiles en aplicaciones Web. Habiendo medido aspectos de calidad de cdigo

fuente, se compara el impacto de utilizar una metodologa de desarrollo convencional en

comparacin a la propuesta en esta tesis.

Captulo 13 Conclusiones: como indica su nombre, en este captulo se concluye la tesis

destacando los aspectos principales de la misma.

Captulo 14 Trabajos futuros: Finalmente, se enumeran las lneas de investigacin abiertas en

las que se continuar el trabajo.

Apndice A - Abreviaturas: Se enumeran y describen cada una de las abreviaturas utilizadas

en la tesis.

Apndice B - Produccin cientfica: Se enumera la produccin cientfica asociada a la tesis.

Apndice C - Trminos: Se hace una breve resea de los trminos ms importantes utilizados

a lo largo de la tesis.


aplicaciones Web Background


Pgina 25

Captulo 2 Background

2.1 Metodologas de desarrollo Web

El desarrollo de aplicaciones Web involucra decisiones no triviales de diseo e implementacin

que inevitablemente influyen en todo el proceso de desarrollo, afectando la divisin de tareas. Los

problemas involucrados, como el diseo del modelo del dominio, modelo navegacional y la

construccin de la interfaz de usuario, tienen requerimientos disjuntos que deben ser tratados por

separado. A partir de esta separacin de intereses, surgen las metodologas de desarrollo de

aplicaciones Web que permiten especificar los requerimientos atacando cada uno de sus aspectos

ms importantes: el modelo conceptual, navegacional y de interfaz de usuario. El modelo

conceptual define cules sern los conceptos/objetos del negocio que sern manipulados en la

aplicacin. El modelo navegacional permite describir qu informacin ser presentada

usualmente agrupada en un Nodo y de qu forma se interactuar con esta informacin a partir de

las relaciones conceptuales; un nodo, por ejemplo, indica el criterio con el que se mostrarn lo

objetos de negocio. Finalmente el modelo de interfaz de usuario especifica de qu forma se

presentar la informacin al usuario y como ste la percibir en trminos de elementos visuales.

Las metodologas de Web maduras tal como OOHDM, UWE, WebML, OO-H, entre otras (ver

[17] para conocer en detalle cada una) son ejemplos de metodologas que facilitan el diseo de

una aplicacin Web atacando los aspectos (conceptual, navegacional y de interfaz de usuario) por

separado.

A continuacin se presentar OOHDM como metodologa de cabecera en sta tesis. Sin embargo,

los conceptos que se desarrollarn dentro de esta tesis pueden ser migrados a las metodologas de

diseo de aplicaciones Web nombradas anteriormente.

2.1.1 OOHDM

Object-Oriented Hypermedia Design Method (OOHDM)[18] es un mtodo orientado a modelos

para el desarrollo de aplicaciones Web. Este mtodo permite a los diseadores especificar una

aplicacin Web mediante el uso de varios meta-modelos especializados: conceptual, navegacin y

de interfaz de usuario. Cada meta-modelo pone foco en diferentes aspectos de una aplicacin.

Una vez que estos modelos han sido especificados para una aplicacin dada, es posible generar

cdigo en tiempo de ejecucin que implemente la aplicacin; es decir, los diseos de la

aplicacin. Existen varios intrpretes de estos modelos encargados de producir una aplicacin

Web basada en ellos : el ambiente HyperDE[19] y el framework Cazon[20].




Pgina 26

OOHDM utiliza mecanismos de abstraccin y composicin diferentes en un framework orientado

a objetos, para permitir por un lado, una descripcin concisa de elementos de informacin

correspondientes al negocio subyacente y, por el otro lado, la especificacin de escenarios de

navegacin complejos en base a los datos del modelo conceptual y transformaciones de interfaz

para hacer percibible la informacin indicada en el modelo anterior. Los principios de OOHDM

han sido aplicados sobre una variante del mtodo, SHDM[21], en la cual el modelo de datos es

utilizado est basado en RDF y RDFS[22].

En OOHDM una aplicacin Web es construida en un proceso de cinco pasos: anlisis de

requerimientos; diseo conceptual; diseo navegacional; diseo de interfaz e implementacin.

Cada paso de diseo se enfoca en un aspecto de diseo particular, y, en consecuencia, un modelo

es elaborado a partir de esto.

A continuacin se resumen los cinco pasos tomando como ejemplo ilustrativo una aplicacin

Web de catalogo de pelculas y series de televisin. Esta aplicacin Web permite la navegacin

de informacin relacionada a las diferentes pelculas tal como en IMDB[23]. Por cada pelcula se

conoce su director, actor, genero, comentarios de usuarios, etc.. Las relaciones con otras pelculas

pueden ser navegadas tal como primeras partes, continuaciones o pelculas con el mismo

director entre otros criterios. Una descripcin completa y descriptiva del ejemplo puede ser leda

en [17].

2.1.1.1 Anlisis de requerimientos

El paso inicial paso es obtener los requerimientos de los stakeholders2. Para esto, es necesario

primero identificar los actores y las tareas que ellos deben realizar en casos de uso. Luego, los

casos de uso son acopiados (o bosquejados) para cada tarea y tipo de actor utilizando Diagramas

de Interaccin de Usuario[24] (UID, User Interaction Diagram). Estos diagramas proveen una

representacin concisa utilizando una metfora grafica del flujo de informacin entre el usuario y

la aplicacin durante la ejecucin de una tarea. Los UIDs son validados con el actor del caso de

uso y rediseado, si fuese necesario, a partir del retorno que haya brindado este ltimo.

En Ilustracin 9 se muestra el UID correspondiente al caso de uso Buscar pelcula por nombre.

Con las elipses se grafican los paso de interaccin (Interaction), dentro de estos se enumeran los

elementos de datos que participarn de la interaccin tanto de escritura (utilizando un rectngulo)

o de solo lectura (sin detalle). Tambin es posible indicar conjuntos de datos usando puntos

suspensivos como prefijo al nombre del dato. La transicin de una interaccin a otra se

especifica mediante una flecha llamada transicin (Interaction) y las operaciones que son

2 En la bibliografa en ingles se utiliza el trmino de stakeholder para indicar todos aquellas personas

interesados en el sistema tal como los gerentes de rea con sus intereses comerciales, los usuarios con sus

necesidades operativas, etc..




Pgina 27

disparadas desde una interaccin dada se especifican con una lnea que se desprende de la

interaccin con una cabeza redonda y rellena en el otro extremo.

Interaction

Transition

Ilustracin 9 UID correspondiente al caso de uso de Buscar pelcula por nombre [17]

En este proceso de relevamiento de requerimientos, una gua con reglas y heursticas[24]

permiten extraer un modelo conceptual bsico a partir de los UIDs.

2.1.1.2 Diseo conceptual

En este paso se elabora un Modelo Conceptual de dominio de la aplicacin utilizando principios

de modelado orientados a objetos. En este paso solo se enfoca en la semntica del dominio de

aplicacin y no en los tipos de usuarios y tareas. OOHDM utiliza el meta-modelo de clases de

UML[25] (Unified Modelling Language), con pequeas extensiones, para expresar el diseo

conceptual.

La Ilustracin 10 corresponde al modelo conceptual de la aplicacin simplificado en detalle para

mejorar su legibilidad destacando las entidades pero evitando detalles como la navegabilidad de

las relaciones y su aridad. Este modelo se obtiene a partir de una versin bsica derivada desde

los UIDs (siguiendo las reglas definidas en [24]) a la que se le aplicaron iteraciones de

refinamientos donde se elimina informacin redundante; se aplican buenas prcticas de diseo de

software tal como generalizaciones y especializaciones, patrones de diseo orientado a

objetos[26], entre otro.




Pgina 28

Ilustracin 10 Modelo conceptual de la aplicacin Web del catlogo de pelculas [17]

2.1.1.3 Diseo navegacional

En OOHDM, una aplicacin Web es concebida como una vista navegacional sobre un Modelo

Conceptual. Esto refleja la mayor innovacin de OOHDM (que tambin fue adoptado por

UWE[17] y WebML[17]) la cual reconoce que los objetos que el usuario navega no son objetos

conceptuales sino un tipo de objetos que se construye a partir de ellos para soportar tareas y una

presentacin adecuada de la informacin. En otras palabras, para cada perfil de usuario se puede

definir una vista navegacional en base a la tarea que este tipo de usuario debe realizar, dicha vista

refleja los datos y relaciones en el esquema conceptual. Estas definiciones pertenecen al Modelo

Navegacional. En OOHDM existe un conjunto de tipos de bsicos predefinidos de clases

navegacionales usuales en aplicaciones de hipermedia: Nodo, Links, Anchors y estructuras de

acceso. Los Nodos en OOHDM representan la vista lgica sobre el Modelo Conceptual definidos

a partir de un lenguaje de consulta. Desde una perspectiva orientada a objetos, los nodos

implementan una variante del patrn Observer[26] ya que presentan una vista particular de los

objetos de negocio. Los cambios en el Modelo Conceptual son notificados inmediatamente a los




Pgina 29

nodos (objetos observadores) y, por otro lado, los nodos pueden invocar mensajes de los objetos

del modelo conceptual a partir de eventos surgidos en la interfaz de usuario. En la actualidad, el

patrn Observer es implementado utilizando requerimientos HTTP para actualizar la informacin

presentada al usuario bajo demanda y solo un conjunto de tecnologas basadas en el uso de

Javascript con XML de forma asincrnica [13] (AJAX, Asynchronous JavaScript and XML) tal

como Google Web Toolkit[27] (GWT) soporta la notificacin de cambios tal como lo indica el

patrn.

Cuando se habla de Links, nos referimos a la realizacin hipermedial de las relaciones del modelo

conceptual as como tambin las asociaciones. Es importante destacar que pueden existir Links

que no reflejen relaciones en el Modelo Conceptual que permiten mejorar, por ejemplo, la

navegacin de la aplicacin. Las estructuras de acceso, tal como los ndices, representan puntos

de inicio de la navegacin.

Aplicaciones Web diferentes (en el mismo dominio) pueden contener topologas de Nodos y

Links debido a los perfiles de usuario. En la aplicacin de ejemplo Internet Movie Database

(IMDB), la vista administrativa de un DVD puede indicar que por cada copia disponible cundo

esta debe ser retornada mientras que la perspectiva de un cliente no lo mostrar.

En la Ilustracin 11 se puede ver el Modelo de Navegacin compuesto por Nodos y Links que

rigen la navegacin de la aplicacin. Los nodos son usualmente contrapartes del modelo

navegacional, sin embargo muchas veces nodos especficos de la navegacin pueden definirse

como el caso del nodo Orden que permite modelar el pedido de compras que est realizando el

usuario en el momento y agrupa todas las pelculas que ste desea adquirir.

Los nodos navegacionales son objetos que pueden poseer mtodos que encapsulan lgica

especfica de navegacin de la aplicacin tal como la resolucin de ciertos datos mediante la

ejecucin de una consulta sobre el Modelo Conceptual.




Pgina 30

La mayora de las aplicaciones Web permiten realizar tareas que involucran un conjunto de

objetos que representan conceptos similares tal como libros por autor, CDs por cantante, hoteles

en una ciudad, etc. OOHDM estructura el espacio de navegacin en conjuntos llamados contextos

de navegacin. Estos poseen las mismas alternativas de navegacin y son significativos para

cierto paso de alguna tarea que un usuario realice.

Cada contexto navegacional es un conjunto de nodos, y es descripto especificando sus elementos,

su estructura interna e ndices asociados. Los contextos navegacionales juegan un rol anlogo con

respecto a la navegacin que las clases con respecto a la estructura y comportamiento de los

objetos. Por ejemplo, se puede modelar un conjunto de actores en una pelcula dirigida por un

director, el conjunto de copias de DVD de una pelcula, etc.. Para un ejemplo detallado de los

contextos navegacionales, ver [17].

2.1.1.4 Diseo de interfaces

El diseo de interfaces se puede desdoblar en dos tareas: el diseo estructural y el diseo de

comportamiento. En las dos subsecciones siguientes se describir cada una de estas tareas.

2.1.1.4.1 Describiendo el contenido de interfaces de aplicaciones Web

OOHDM utiliza Vistas de Datos Abstractas (ADV, Abstract Data View) para representar de

manera abstracta las interfaces de usuario que requiere una aplicacin Web. Un ADV tiene una

Nodo Link

Ilustracin 11 Modelo Navegacional reducido del ejemplo de la aplicacin Web de catalogo de

pelculas




Pgina 31

estructura (expresada como un conjunto de atributos), comportamiento (definido como un

conjunto de mensajes o eventos externos que ste puede manejar) y puede ser definido

recursivamente componiendo otros ADVs. Dado su naturaleza estructurada, los ADVs pueden ser

mapeados fcilmente en documentos XML facilitando as su escritura y edicin. Del lado

izquierdo de la Ilustracin 12 (mostrada en la motivacin), se muestra el ADV correspondiente al

componente ChangeablePicture de la interfaz Web presentada en Ilustracin 4. Este ADV est

compuesto de forma anidada por otros ADVs primitivos como Imagen Picture o Text, mostrando

como los componentes sern percibidos por el usuario. Del lado derecho de la Ilustracin 12 se

muestra la pantalla esperada correspondiente ADV y con lneas punteadas se muestra la relacin

entre los elementos concretos y abstractos. Es importante notar que la posicin de los objetos

anidados en el ADV refleja la apariencia (look and feel) de la interfaz siendo de esta forma un

medio efectivo para validar con el cliente cmo ser el resultado final del desarrollo de la interfaz.

TVs picture 1

ADV ChangeablePicture

Image:

Picture

Icons: array (1..n, horizontal)

SmallImage: Picture

Description: Text

Ilustracin 12 ADV e interfaz concreta del componente ChangeablePicture

Los ADVs observan Objetos de Datos Abstractos (ADO, Abstract Data Objects), conocidos

como dueos de ADV, con dos objetivos: ser una vista de los datos y disparar comportamientos

de aplicacin o interfaz. Los ADV de la Ilustracin 12 obtiene sus contenidos del correspondiente

ADO; en este caso, un nodo del modelo navegacional tal como puede apreciarse en la Ilustracin

13. La relacin entre el ADV y su ADO es descripta utilizando diagramas de configuracin

(configuration diagram), una combinacin entre clases UML y diagramas de colaboracin,

mostrando qu mensajes son intercambiados entre el ADV (actuando como cliente de consulta) y

el ADO (en role de servidor de datos). En la Ilustracin 13, el ADV ChangeablePicture resuelve

informacin invocando los mtodos getImage() y getText() del nodo ChangeablePicture. Esta

informacin es utilizada para presentar los componentes de la interfaz concreta: Image,

Description y SmallImage (arreglo de elementos). El parmetro i hace referencia al ndice de la

imagen seleccionada en el arreglo.




Pgina 32


Image:

Picture

Icons: array (1..n, horizontal)

SmallImage: Picture

Description: Text

Node ChangeablePicture

getImage(i).getURL()

getImage(i).getURL()

getText(i)

Image: getImage(Int index)

String: getText(Int index)

Image[n] pictures

String[n] pictureDescription

Ilustracin 13 Diagrama de configuracin para el componente ChangeablePicture

En las aplicaciones Web convencionales, usualmente se especifica un ADV anidado observando

un nico ADO. Esto puede ser la causa de que el mismo nodo tenga varios ADVs (por ejemplo

para proveer muchas interfaces), pero no es comn que dos nodos (ADOs) yuxtapongan un nico

ADV. En aplicaciones Web RIA, podemos necesitar que un ADV consuma informacin desde

diferentes ADOs (nodos) de acuerdo con las caractersticas de las interfaces.

Ntese que los aspectos de comportamiento de una interfaz de aplicacin Web convencional son

simples. Cuando un anchor es seleccionado, el ADV del nodo actual debe cerrarse y el

correspondiente destino del link (otro nodo) debe abrirse. En consecuencia, hay otros

comportamientos en aplicaciones Web interesantes pero no simples como, por ejemplo, permitir

autocompletado de formularios. Se explicar el mecanismo de expresar comportamientos de

ADVs en la prxima Seccin (2.1.1.4.2) cuando se trate la problemtica de las interfaces

dinmicas RIA.

Luego de que la interfaz ha sido completamente especificada, los modelos conceptuales,

navegacionales y de interfaz son implementados en plataformas particulares. Con el objetivo de

facilitar la adopcin de la metodologa OOHDM, se ha implementado un framework de ejecucin

, llamado Cazon [28][20], que soporta la generacin semi-automtica de cdigo de modelos

OOHDM, incluyendo la instanciacin de pginas desde modelos navegacionales OOHDM.

2.1.1.4.2 Describiendo la dinmica de RIAs con ADV-Charts

Las aplicaciones Web RIAs estn caracterizadas por tener una interfaz dinmica y

comportamiento rico que permite mejorar la experiencia del usuario. Mientras que los ADV nos

permiten expresar las caractersticas estticas de las aplicaciones convencionales, OOHDM utiliza

ADV-Charts para especificar los aspectos dinmicos de este tipo de aplicaciones.

Los ADV-Charts son una variante de las maquinas de estado que permiten expresar las

transformaciones de una interfaz que pueden surgir a partir de la interaccin con un usuario. Estas

son similares a los StateCharts[29].




Pgina 33

Como puede apreciarse en la Ilustracin 14, una transicin en un ADV-Chart es anotada con un

identificador (ID), el/los evento/s que la causan, una precondicin que debe ser satisfecha para

disparar la transicin, y una post condicin que es obtenido despus de que esta transicin se

procesada. La post condicin es expresada en trminos de propiedades de objetos que son

alterados luego que la transicin ocurre.


Image

Icons:Array (1..n)

SmallImage: Picture

1

Event: MouseOver

PreCond: Focus (Icons[i])

PostCond:

Image.getURL() = owner.getImage(i).getURL()

Description.getText() = owner.getDescription(i)

on

on

1

Description

on

Ilustracin 14 ADV-Chart Transicin de estados simple

En el ejemplo, tambin se utiliza la funcin Focus que indica la posicin del cursor y una pseudo

variable PerCont (para referir el contexto de percepcin) para indicar los objetos que son

percibibles por el usuario. Cuando un objeto es agregados al conjunto PerCont este pasa a ser

percibible por el usuario, caso contrario, cuando es retirados, este deja de ser visible. La palabra

clave owner referencia al ADO observado que puede ser utilizado como parte de una definicin

de transicin para consultar su estado.

En la ilustracin, se puede ver el ADV-Chart especificando el comportamiento del ADV

ChangeablePicture: cuando el mouse se encuentra sobre un cono, los Widget grficos

correspondientes a la imagen actual y la descripcin deben ser actualizados con datos icono

seleccionado. El objeto propietario, u owner, del ADV es consultado por la informacin requerida

en la actualizacin utilizando la posicin en la lista (o ndice) como parmetro. La flecha negra

hacia el mismo estado seala que el componente SmallImage va a retornar al estado inicial luego

de que la transicin est completa.

Los ADV-Charts pueden componerse(a travs del anidamiento de estados) indicando como los

ADVs internos son afectados cuando el usuario interacta con el sistema. Estos pueden tambin

ser utilizados (en combinacin con los diagramas de configuracin) para indicar la forma en la

que las operaciones navegacionales son disparadas por los eventos de interfaz.

Mientras que los estados anidados en un ADV siguen la semntica de los Statecharts, significando

que un ADV puede estar en algunos estados (mediante los operadores lgicos Y u O), el




Pgina 34

anidamiento de ADVs dentro de estados indica que el ADV es perceptible por el usuario en ese

estado.

2.1.1.5 Implementacin

La implementacin consiste en mapear los objetos del Modelo de Navegacin e Interfaz a una

aplicacin final y puede requerir elaborar arquitecturas (por ejemplo, Cliente-Servidor) en las

cuales las aplicaciones son clientes son Browsers Web para compartir el servidor de base de datos

que contiene los objetos del modelo conceptual. Un numero de aplicaciones basadas en DVD

como tambin aplicaciones Web han sido desarrollados utilizando OOHDM como metodologa y

empleando una diversidad de tecnologas tal como Java (J2EE), ASPX (.NET), Lua (CGILua),

ColdFusion y Ruby (Ruby on Rails) para llevar a cabo la implementacin.

HyperDe y Cazon son ambientes que implementan de forma nativa los conceptos de OOHDM y

estn basados en Ruby on Rails[30] y Java respectivamente.

2.1.2 WEBSPEC DSL para especificar aplicaciones Web

WebSpec[31] es un leguaje visual donde su principal componente para especificar requerimientos

es el diagrama WebSpec el cual utiliza interacciones, navegaciones y comportamiento rico para

especificar requerimientos en aplicaciones Web.

Un diagrama WebSpec define un conjunto de escenarios que la aplicacin Web debe satisfacer.

Una interaccin (denotado como un rectngulo redondeado) representa un punto donde el usuario

puede interactuar con la aplicacin usando objetos de interfaz (widgets). Cada diagrama se define

en base a dos elementos principales:

Las interacciones tienen un nombre (nico por diagrama) u puede tener widgets tal como

Etiquetas, listas, etc.

La transicin (tanto una navegacin o comportamiento rico) es grficamente representada

con flechas entre interacciones mientras que el nombre, precondiciones y acciones

disparadoras son presentadas como etiquetas sobre estas. En particular, el nombre aparece

con el prefijo #, la precondicin entre {} y la accin en las lneas siguientes.

Los escenarios especificados por un diagrama WebSpec son obtenidos atravesando el diagrama

usando un algoritmo de bsqueda en profundidad (depth-first). Este algoritmo comienza desde un

conjunto especial de interacciones denominadas de inicio (interacciones bordeadas con lneas

punteadas) y sigue con las transiciones (transiciones o comportamiento rico) del grafo

(diagrama).

Un ejemplo de los conceptos de WebSpec se presentan en la Ilustracin 15, donde se especifica el

escenario: Como cliente, me gustara buscar productos por nombre y ver todos sus detalles en




Pgina 35

una aplicacin de comercio electrnico. Home representa el punto de inicio de la especificacin y

contiene dos widgets: campo de texto searchField y botn search.

Ilustracin 15 Diagrama WebSpec para el requerimiento Buscar pelcula por nombre

2.2 Modularizacin en Software

2.2.1 Cohesin - Definicin

La cohesin es una mtrica de la POO que permite medir que tan bien los elementos (variables y

mtodos) de una clase (de la programacin orientada a objetos) estn relacionados entre ellos.

Una clase no cohesiva realiza dos o ms funciones no relacionadas. Un diseo con una baja

cohesin debera ser reformulado para que los componentes sean reestructurados en dos o ms

componentes pequeos.

Esta mtrica es usualmente calculada en las clases de modelos OO bajo el nombre de Falta de

Cohesin de Mtodos (LCOM, Lack of COhesion of Methods). Existen diferentes variantes para

medir la falta de cohesin[32] LCOM1, LCOM2, LCOM3 y LCOM4; en esta tesis se utilizar la

variante LCOM4.

En la Ilustracin 16 podemos apreciar la relacin entre los elementos de una Clase llamada

Chofer. Estos elementos (variables y mtodos) fueron agrupados (con cajas de lneas punteadas)

en tres conjuntos segn cmo estn relacionados. Como se puede ver, en el primer conjunto (con

un 1 en la cabecera del conjunto) se dispone de una variable Auto y tres mensajes parar(),

manejar() e irHasta(); donde los dos primeros manipulan la variable Auto y el ltimo interacta

con el mtodo Manejar(). Luego, de forma similar al caso anterior, el segundo grupo (con

cabecera 2) solo tiene una variable de instancia llamada cerebro y un mtodo que la manipula:

dormir(). Finalmente, en el ltimo grupo (con cabecera 3) se puede apreciar que existe un

mtodo aislado llamado tomarTe(). Este agrupamiento indica que el valor de la mtrica LCOM4

es de 3 debido a que los tres aspectos de la clase Chofer detectados no estn relacionados de

ninguna forma. Ntese que mientras ms alto es este valor ms baja es la cohesin. Por cuestiones

de alcance, en esta tesis no se desarrollar la mtrica LCOM4; ver [32] para ms informacin.




Pgina 36

Se recomienda el rediseo de las clases con LCOM4 mayor a 1 ya que la misma posee

responsabilidades o comportamientos disjuntos. Es decir, proveen funcionalidad que

probablemente corresponda a dos clases diferentes.

Mtodo

Variable

Manipular

Clase Chofer

Auto Cerebro

Parar()

Manejar()

IrHasta()

Dormir() TomarTe()

1 2 3

Ilustracin 16 Ejemplos de cohesin en clase Chofer

2.2.2 Acople - Definicin

El acople es la relacin que existe entre dos clases en donde los cambios sobre una impactan

sobre la otra. El nivel de acoplamiento [33] determina que tan fuerte es el vnculo entre clases de

un sistema. En trminos prcticos, cuando al modificar una clase debemos modificar otra , esto

significa que existe acople. Un alto acople perjudica la reutilizacin de las clases de forma aislada

ya que una depende de la otra.

Por otro lado, cuando el acople es bajo, se incrementa la posibilidad de poder reusar las clases por

separado. Los patrones de diseo OO promueven sistemas con bajo acople. Por ejemplo, el patrn

diseo Observer[26] es bajo en acople debido a que el sujeto (rol subject del patrn) slo conoce

que el observador (rol observer del patrn) implementa una interfaz especfica. En este caso

nunca se conoce la interfaz concreta del observador sino que se sabe que tiene un contrato

especfico. Se pueden agregar observadores, eliminar o reemplazar observadores en cualquier

momento sin necesidad de modificar el objeto sujeto. Cambios tanto al sujeto como al observador

no van a implicar cambios al otro objeto.

2.2.3 Inversin de control - Definicin

La tcnica de Inversin de Control[34] (IoC, Inversion of Control) permite eliminar la creacin de

componentes y gestin de dependencias de componentes. La inversin de control usa

exhaustivamente diseos basados en interfaces ya que el framework que implementa la inversin




Pgina 37

de control configura objetos a partir de su contrato y no de su implementacin. De esta forma se

disminuye el acople de los componentes de la aplicacin como se discuti anteriormente.

Supongamos el caso donde la clase CarritoDeCompras en un sitio de comercio electrnico

colabora con una clase MedioDePago para alcanzar su objetivo. Del lado izquierdo de la

Ilustracin 17, la clase CarritoDeCompras obtiene un objeto TarjetaMPImpl (que implementa la

interfaz MedioDePago) mediante la invocacin del constructor de este ltimo o utilizando algn

objeto que implementa el patrn Factory[26]; en ambos casos gestionando las dependencias

dentro de la clase. Por otro lado, utilizando IoC tal como se puede apreciar del lado derecho de la

17, la instancia TarjetaMPImpl es inyectada por algn proceso externo; usualmente

implementado en un framework. La inyeccin de dependencias dinmicamente en tiempo de

ejecucin es tambin conocido bajo el concepto de Inyeccin de Dependencias (DI, Dependency

Injection).

CarritoDeCompras

MedioDePago

TarjetaMPImpl

CarritoDeCompras

MedioDePago

TarjetaMPImplFramework

Ilustracin 17 Comparacin entre gestin de dependencias tradicionalicional e inversin de control

2.2.4 Concerns en Software

Un concern[35][36] representa un inters sobre el sistema, agrupando un conjunto de

requerimientos o consideraciones especficas que deben ser alcanzadas para satisfacer los

objetivos de un sistema. Por ejemplo, un sistema bancario puede estar compuesto por los

siguientes concerns: administracin de clientes y cuentas, computo de intereses, transacciones

interbancarias, transacciones ATM, persistencia, etc.. Estos concerns son denominados core

concern porque representan la funcionalidad principal del sistema.

El principio de separacin de propsitos (concerns) propone encapsular caractersticas en

entidades separadas para poder localizar cambios de estos y trabajarlos de forma aislada

reduciendo su complejidad de diseo e implementacin. El primer paso es descomponer el

conjunto de requerimientos separndolos en concern.

Identificar y separar los concerns en un sistema es un ejercicio importante en el desarrollo de un

sistema de software, sin importar la metodologa utilizada.




Pgina 38

2.2.4.1 Concern voltil

Un concern voltil es un conjunto coherente de requerimientos voltiles sobre un inters del

sistema. Este tipo de concern posee las mismas caractersticas que las funcionalidades voltiles,

ya que est definido a partir de estas funcionalidades, donde surge de forma inesperada,

permanece en el sistema por un tiempo indeterminado y puede retirarse tanto por un evento de

tiempo o de negocio especfico.

2.2.4.2 Crosscutting concerns

Los concerns que entrecruzan otros concerns son denominados crosscutting concerns. stos

son responsables de producir representaciones entrelazadas; las cuales son difciles de entender y

mantener. Ejemplos de este crosscutting concern son los de remoting (lgica especfica para

hacer invocaciones remotas a objetos) y sincronizacin (lgica que permite ordenar el acceso a

secciones crticas) de cdigo que no puede ser encapsulado en una clase y en general se distribuye

en varas clases.

La metodologa de Programacin Orientada a Objetos (POO) fue desarrollada como respuesta a la

necesidad de modularizar los concerns de un sistema de software. La realidad es que aunque POO

es bueno a la hora de modularizar core concerns, sta falla cuando se tratan de crosscutting

concerns. Los diseos OOP crean acople entre los concerns core y crosscutting que es

indeseable, ya que la incorporacin de nuevas funcionalidades o incluso ciertas modificaciones a

la funcionalidad crosscutting requieren modificar mdulos relevantes correspondientes al

concern core. En AOSD [36] y AspectJ [35] se pueden encontrar descripciones claras e

ilustrativas de la falencia de POO para aplicar separacin de concerns diseos teniendo en

cuenta ms de un nico criterio de separacin.

Existen dos tipos de crosscutting concern dependiendo del cdigo que estos producen: cdigo

tangling y cdigo scattered.

Tangling

Cuando un componente OO implementa varios concerns simultneamente con lgica de stos

entrelazada, nos encontramos con cdigo Tangling (enredado o entrelazado). Un desarrollador

usualmente considera concerns como: lgica de negocio, performance, sincronizacin, logging (o

registro en bitcora), seguridad, etc. que son implementados en el mismo mdulo.

En el Tabla 4 el pseudo cdigo de ejemplo se puede apreciar cmo diferentes crosscutting

concerns producen cdigo tangling en una funcionalidad del sistema. Concerns de Traza

(logging), Concurrencia, Seguridad y Transaccionalidad producen un cdigo mezclado que

entorpece la tarea del programador ya que el mismo debe prestar atencin a diferentes aspectos en

lugar de hacer foco en mantener la lgica de negocio.




Pgina 39

public class ClaseEspecifica extends ClaseAbstracta {

- atributos de la clase especfica

- variable necesaria para de traza en archivos log

- Semforo de control de concurrencia

public void operacion () {

- Cdigo de validacin de autorizacin

- Bloqueo de objeto para sincronizar acceso a

seccin crtica

- Comienzo de transaccin

- Traza de inicio de operacin

- Realizar la operacin de negocio esperada

- Traza de fin de operacin

- Commit o rollback de transaccin

- Desbloqueo de objeto para sincronizacin

}

...

}

Concern Traza Concern Concurrencia

Concern Seguridad Concern Concurrencia

Concern Transaccionalidad Concern Traza

Concern Traza Concern Transaccionalidad Concern Concurrencia

Tabla 1 Pseudo cdigo de un componente tpico con cdigo tangling

Scattered

Cdigo scattered (esparcido o disperso) es representa escenarios cuando una idea es

implementada en mltiples mdulos. Por ejemplo, en un sistema que usa una Base de datos, el

concern de performance puede afectar todos los mdulos que acceden a la BD.

Es importante destacar que los crosscutting no son excluyentes con lo cual un crosscutting

concern puede producir tanto cdigo tangling como scattered. En la Ilustracin 18 se puede

apreciar como el mismo cdigo utilizado para crear transacciones se ve replicado en varios

artefactos de software en el sistema.

La Ilustracin 183 muestra un tpico ejemplo en el cual existe cdigo de acceso a una base de

datos repetido en diferentes lugares de una aplicacin.

3 Imagen tomada del libro Aspect-Oriented Analysis and Design: The Theme Approach [37]




Pgina 40

Ilustracin 18 Cdigo Scattered [37]

Un ejemplo de crosscutting concern es el sistema de logging4 utilizado en Tomcat

5, donde dicha

funcionalidad se encuentra esparcida a travs de todo el sistema y no localizada en una nica

entidad del lenguaje. Se puede comprobar, por tanto, cmo en los sistemas OO de una cierta

complejidad se encuentran a menudo con problemas de modularidad.

2.2.4.2.1 Problemas de modularizacin

Los cdigos tangling y scattering juntos impactan en el diseo y desarrollo de software en las

siguientes formas:

Mala trazabilidad: Implementaciones simultneas de varios concerns incrementa el nivel

de complejidad de las tareas de implementacin de un concern; esto causa dificultad en el

seguimiento de requerimientos desde su relevamiento a su implementacin y viceversa.

Poca productividad: La implementacin simultnea de mltiples concerns mueve el foco

del concern core (el de la lgica de negocio) a los concerns secundarios. La falta de foco

4 Logging se refiere al proceso de bitcora, en el cual se asientan los pasos realizados.

5 Apache Tomcat es un servidor de aplicaciones. Es un contenedor de Servlets. Los Servlets es generar

pginas Web de forma dinmica a partir de los parmetros de la peticin que enve el navegador Web.

(http://tomcat.apache.org)




Pgina 41

empeora la productividad porque los desarrolladores tiene que dejar de lado el objetivo

primario para solucionar los crosscutting concern.

Bajo reso de cdigo: Si un mdulo est implementando mltiples concerns, otros

sistemas que requieren funcionalidad similar no van a ser capaces de usar fcilmente el

mdulo.

Baja calidad: el cdigo tangling dificulta el examen de cdigo y en consecuencia la

localizacin de errores, y la correccin del cdigo. Por ejemplo, revisar el cdigo de un

mdulo que implementa varios concerns va a requerir la participacin de un experto en

cada uno de los concerns.

Dificultad en la evolucin: Una perspectiva incompleta y limitada resulta en un diseo

que solo alcanza los concerns actuales. Cuando un nuevo requerimiento llega, ste

requiere una reimplementacin. Esto se debe a que la implementacin no esta

modularizada e implica la modificacin de varios mdulos. Modificar cada mdulo para

tales cambios puede llevar a inconsistencias; lo cual requiere mucho esfuerzo en testeo

para asegurar que los cambios no introducen errores.

2.2.5 Desarrollo Software Orientado a Aspectos

La comunidad de Desarrollo Software Orientado a Aspectos (AOSD, Aspect Oriented Software

Development) ha estado estudiando durante ms de una dcada cmo incrementar y mejorar la

expresividad de los paradigmas Orientados a Objetos. Las principales propuestas de AOSD se

basan en la idea de desarrollar un software de mayor calidad mediante la separacin de concerns,

especificando cada uno de ellos de forma separada y las relaciones existentes entre los mismos,

para posteriormente, utilizando un mecanismo adecuado, componerlos formando un sistema

completamente coherente.

Actualmente, POO constituye el paradigma dominante en el desarrollo de software. Se pueden

encontrar distintas metodologas, herramientas de anlisis y diseo, y lenguajes de programacin

OO. La programacin OO ha hecho posible el desarrollo de sistemas y aplicaciones de una cierta

complejidad sin dejar de lado el mantenimiento de un cdigo comprensible y estructurado. Sin

embargo, la OO an presenta algunas limitaciones. Los investigadores OO ven como ciertos

aspectos de los sistemas que implementan no pueden ser separados de una manera clara en

objetos; aunque se pueda encontrar un diseo orientado a objetos, est sufre de sobre-ingeniera.

El cdigo que implementa esos aspectos se encuentra esparcido y/o anidado en diferentes

elementos o estructuras. Para los desarrolladores, resulta complicado centrarse en esos concerns,

de manera que el mantenimiento y la adaptabilidad del software de cierto tamao se convierte en

un proceso de una complejidad importante.




Pgina 42

Bsicamente, AOSD reduce las principales limitaciones de la orientacin a objetos con respecto a

este problema de modularidad. Desde el punto de vista del desarrollador, es evidente que algunas

de las caractersticas ms importantes del software son la facilidad de comprensin de su cdigo y

la flexibilidad del mismo para adaptarse a las extensiones y cambios que puedan producirse en los

requisitos para los que fue diseado. Para conseguir que el software presente estas caractersticas,

es importante conseguir mantener una buena modularidad del mismo.

2.2.5.1 Programacin Orientada a Aspectos

Un aspecto es una unidad modular diseada para implementar un concern. Una definicin de

aspectos puede contener algo de cdigo y las instrucciones de dnde, cundo, y cmo invocarlos.

Dependiendo del lenguaje de aspectos, los aspectos pueden ser construidos jerrquicamente, y el

lenguaje puede proveer mecanismos separados para definir un aspecto y especificar su interaccin

con el sistema subyacente.

Programacin Orientada a Aspectos (AOP) complementa las metodologas existentes de

programacin como la programacin orientada a objetos (POO) y la programacin procedural,

aumentando la capacidad de expresin permitiendo modularizar los crosscutting concerns. Los

crosscutting concerns son modularizados por su rol definido en el sistema, implementando cada

rol en su propio mdulo y reduciendo el acoplamiento entre mdulos.

Usualmente, con AOP, los core concerns son implementados usando la metodologa base elegida,

por ejemplo POO. Los Aspectos del sistema encapsulan los crosscutting concerns; estos estipulan

como los mdulos del sistema son ensamblados para conformar el sistema final.

En [35] se puede encontrar una interesante reflexin sobre la utilizacin de patrones de diseo

OO para implementar crosscutting concern donde se destacan ventajas y desventajas de su

utilizacin.

2.2.5.2 Metodologa AOP - Descripcin

De muchas formas, desarrollar un sistema usando AOP es similar a desarrollar un sistema usando

otras metodologas: identificar los concerns, implementarlos, y formar el sistema final

combinando stos. Para esto se definen tres pasos:

Descomposicin de Aspectos: En este paso, se descomponen los requerimientos para

identificar los crosscutting y los core concerns.

Implementacin de Concerns: Se implementa cada concern de manera independiente.

De esta forma, los desarrolladores pueden implementar, por ejemplo, las unidades de

lgica de negocio, de logueo, de persistencia y de autorizacin.




Pgina 43

Recomposicin de Aspectos: Finalmente, se especifican las reglas de recomposicin

para los mdulos, o aspectos. Este proceso de recomposicin, conocido como weaving,

usa esta informacin para componer el sistema final.

El cambio fundamental que AOP provee es la preservacin de la independencia de los concerns

cuando son implementados. La implementacin puede ser fcilmente ensamblado al

correspondiente concern, resultando en un sistema que es ms simple, fcil implementar y ms

adaptable a los cambios.

2.2.5.3 Beneficios de AOP

Las

Urbieta Mario Matias

Documents

Transcript of Urbieta Mario Matias