Borra Dorf Valverde

7/17/2019 Borra Dorf Valverde

1/223

1

Francisco Valverde Girom

[email protected]

Director: scar Pastor Lpez

[email protected]

Borrador de Tesis Doctoral

Programa de Doctorado de Ingeniera del Software, Mtodos Formales ySistemas de Informacin

OOWS 2.0: Un Mtodo de Ingeniera WebDirigido por Modelos para la Produccin de

Aplicaciones Web 2.0

Septiembre del 2010, Valencia


2/223


3/223

3

ndice1. Introduccin.........................................................................................13

"#" $%&' ()* +,( ,-+./,/.)*0( 102 3#45 ######################################################### #################################"6

"#3 7)8.9,/.:*############################################################################################################################################";

"#6 0 +, 80(.(##########################################################################################################################"?

"#@ A)+&/.:* BC)-&0(8,###########################################################################################################################"D

"#E FG2.8) >0 ,-+./,/.:*#######################################################################################################################"H

"#; I(8C&/8&C, >0 +, 80(.( >)/8)C,+#####################################################################################################"H

2. Fundamentos Metodolgicos.............................................................21

3#" 708)>)+)JK, >0 L*90(8.J,/.:*M !"#$%& ()$"&)"######################################################################3"

3#3 N.(.:* J0*0C,+ >0+ G'8)>) )( >0 L*J0*.0CK, 102#################################@3

*+,+- ./012++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3*

*+,+, 45671"89:;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 334?@ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3A

*+,+3 ==>!1 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3B

*+,+C 5./ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ C-

*+,+)( -,C, 0+ >0(,CC)++) >0 ULV#################### ###########################################EE

6#@ SC,2,=)( C0+,/.)*,>)( /)* +, >0W.*./.:* >0 B,8C)*0( -,C, +, 102 3#4 ######################E?

4. Especificacin del Modelo de Interaccin Abstracto ......................61

@#" 7)>0+,>) >0 +, .*80C,//.:*###########################################################################################################;"

@#3 A)-)C80 , +, .*80C,//.:* 0*


4/223

4

@#6 X0W.*./.:* >0+ G)>0+) >0 .*80C,//.:* ,2(8C,/8)##################################################################?"

3+*+- /E ;$H%IHFH ;" 5#KHI$:# L "E FHGH ;" $&8"IH))$M&+++++++++++++++++++++++++++++++++++++++++++++++++++++++ A-

3+*+, 5&$;H;"# ;" $&8"IH))$M& HN#8IH)8H#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ A3

3+*+* @KO$E$HIL ?&8"IH)8$:& PH88"I ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AA

@#6#6#" Y.+8C) ZY.+80C[#######################################################################################################################################D4

@#6#6#3 \*>./0 ZL*>0T[#####################################################################################################################################D3

@#6#6#6 N.(8, U0(&G.>, ZA&GG,CO 9.0][ ##############################################################################################D3

@#6#6#@ 0*,/.:* Z0C ^C.80C.,[########################################################################################################D@

@#6#6#E B,J.*,/.:* ZB,J.*,8.)*[ ################################################################################################################D@

@#6#6#; A0+0//.:* I*&G0C,>, ZX0W.*0> R.(8[########################################################################################DE

@#6#6#? U0J+, >0 N,+.>,/.:* ZN,+.>,8.)* U&+0[#####################################################################################D;

@#6#6#D L*./.,+._,/.:* >0 VCJ&G0*8) ZVCJ&G0*8 A088.*J[ ##############################################################D?

@#6#6#H `,90J,/.:* -)C ./.:* >0 L*(8,*/., ZL*(8,*/0 I>.8.)*[###############################################################################H6

@#@ ^)*/+&(.)*0( ################################################### ############################################################# #######################HE

5. Modelado de interfaces de usuario en el mbito de las RIA...........97

E#" $%&' ()* +,( 4$)9 ?&8"I&"8 @GGE$)H8$:Q#################################################################################H?

E#3 X0W.*./.:* >0 &* G08,G)>0+) -,C, 0+ >0(,CC)++) >0 .*80CW,/0( ULV ######################## "43

C+,+- 1:;"EH;: ;" E:# ):FG:&"&8"# ;" EH $&8"IRHS 4?@ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-T*

C+,+, 1:;"EH;: ;" EH $&8"IH))$M& ;$I$%$;H G:I "J"&8:# ;" ?5++++++++++++++++++++++++++++++++++++++++++++++-TB

E#6 V-+./,/.:* >0+ G08,G)>0+) ULV 0* 0+ aG2.8) >0 &* G'8)>) >0 L*J0*.0CK, 102>.C.J.>) -)C G)>0+)( ###################################################### ############################################################# #################### ""E

C+*+- /#8IH8"%$H ;" ):&"O$M& H &$J"E ;" F"8HF:;"EH;:U ."HJ$&% F:;"E#++++++++++++++++++++--


5/223

5

E#@ b0*0C,/.:* >0+ /:>.J) >0 +, .*80CW,_ ULVM@;:N" WE"O#####################################################"3@

E#E ^)*/+&(.)*0( ################################################### ############################################################# #################### "3H

6. Patrones de Modelado para la Web 2.0...........................................131

;#" V*a+.(.( >0 -,8C)*0( ,-+./,>)( 0* 0+ aG2.8) >0 +, 102 3#4######################################### "6"

;#3 7)>0+,*>) -,8C)*0( /)*/0-8&,+0( 0* 0+ aG2.8) >0 +, 102 3#4#################################"@3

0+ -,8C:* `)8.W./,8.)*#################################################################################### ";@

;#6#3#6 I(-0/.W./,/.:* >0 +,( 8C,*(W)CG,/.)*0( >0 +)( -,8C)*0(##############################################";;

;#@ ^)*/+&(.)*0( ################################################### ############################################################# #################### "?"

7. Evaluacin de la viabilidad................................................................173

?#" L*8C)>&//.:*#####################################################################################################################################"?6

?#3 V*a+.(.( >0+ ()-)C80 -C)-)C/.)*,>) , *.90+ >0 G)>0+,>)############################################"?@

?#6 7)>0+,>) >0 +, >0G)(8C,/.:* >0 +,2)C,8)C.)####################################################################"D4

A+*+- 1:;"EH;: ;"E "#)"&HI$: \:FGHI" ]"&"#+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-[T

A+*+, 1:;"EH;: ;"E "#)"&HI$: ,*H&;1" \:FFK&$8L ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-[A

?#@ X.(0d) 0T-0C.G0*8,+ -,C, +, 09,+&,/.:* >0+ G'8)>) ##################################################### "H3

A+3+- !"R$&$)$M&++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-B*

A+3+, PEH&$R$)H)$M&++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-B3

A+3+* ?IKF"&8H)$M&++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-BA


6/223

6

A+3+3 PI:)"#:+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++,T-

?#E ^)*/+&(.)*0( ################################################### ############################################################# #################### 343

8. Conclusiones......................................................................................205

D#" ^)*8C.2&/.)*0( BC.*/.-,+0(########################################################################################################34E

D#3 SC,2,=) ,/8&,+ O W&8&C) #################################################### ############################################################ 34?

D#6 B&2+./,/.)*0( ################################################## ############################################################# #################### 34D

9. Referencias Bibliogrficas................................................................211

10. Anexos ..............................................................................................221

"4#" I=0G-+) .+&(8C,8.9)M 1L (:)$HE 4"#"HI)9 ############################################################################33"


7/223

7

ndice de figurasFig. 2.1 Framework de investigacin propuesto por [Hevner, March et al. 2004] ....................................22

Fig. 2.2: Metamodelo principal del mtodo OOWS.................................................................................26Fig. 2.3 Fase de modelado conceptual en el mtodo OOWS....................................................................27

Fig. 2.4 Fase de modelado conceptual del mtodo OOWS 2.0.................................................................28

Fig. 2.5 Lenguaje de patrones JUST-UI del Modelo de Presentacin OO-Method ................................29

Fig. 2.6 Editor del Modelo de Presentacin en OlivaNOVA ...................................................................32

Fig. 2.7 Ejemplo de mapa navegacional OOWS.......................................................................................33

Fig. 2.8 Ejemplo de la definicin de una AIU en OOWS ........................................................................33

Fig. 3.1 Ejemplo de CTT para la ejecucin de un Servicio .......................................................................38

Fig. 3.2: Framework de referencia propuesto en el proyecto Chamaleon ..................................................41

Fig. 3.3 Patrn Rating representado en WebML de [Fraternali, Tisiet al. 2009].....................................45

Fig. 3.4 Proceso de desarrollo de RUX-Method segn [Linaje, Preciadoet al. 2007a].............................47

Fig. 3.5 Metamodelo de presentacin de OOH4RIA [Melia, Gomezet al. 2008]...................................48

Fig. 3.6 Ejemplo de modelo de orquestacin de OOH4RIA [Prez, Dazet al. 2008].............................49

Fig. 3.7 ADV definido en [Rossi, Urbietaet al.2008] ..............................................................................51

Fig. 4.1 User classpara el agente Researcher............................................................................................73

Fig. 4.2: Mapa de Interaccin para el usuario Researcher...........................................................................74

Fig. 4.3 Notacin para la especificacin de la PopulationAIU...................................................................75

Fig. 4.4 Ejemplo de una Population AIU...................................................................................................76

Fig. 4.5: Modelo de Interaccin Abstracto................................................................................................80

Fig. 4.6: Ejemplo de ndice ......................................................................................................................82

Fig. 4.7: Notacin para la navegacin por objeto.......................................................................................89

Fig. 4.8: Ejemplo de navegacin por objeto...............................................................................................90

Fig. 4.9: Ejemplo de navegacin relacional................................................................................................91

Fig. 4.10: Ejemplo de Filtro Navegacional................................................................................................93


8/223

8

Fig. 4.11: Notacin para el patrn Edicin de Instancia ...........................................................................94

Fig. 4.12: Ejemplo del patrn Edicin de Instancia ..................................................................................95

Fig. 5.1: Ejemplos de distintos widgets en EXT-JS.................................................................................104

Fig. 5.2: Metamodelo RIA: componentes de la IU .................................................................................106

Fig. 5.3 Metamodelo RIA: definicin de la interaccin dirigida por eventos de IU................................111

Fig. 5.4: Gramtica para la definicin deEvent Rules.............................................................................114

Fig. 5.5: Ejemplo de la definicin de unaEvent Rule..............................................................................115

Fig. 5.6: Core Weaving Metamodelpropuesto por [Didonet Del Fabro and Valduriez 2009] ..................117

Fig. 5.7: RIA Weaving Metamodel para OOWS 2.0 ................................................................................118

Fig. 5.8: Relacin entre los distintos niveles conceptuales.......................................................................120

Fig. 5.9: Edicin de un weaving modelcon Eclipse EMF .......................................................................121

Fig. 5.10: Proceso de modelado...............................................................................................................122

Fig. 5.11: Ejemplo de cdigo de IU en Flex............................................................................................125

Fig. 5.12: Ejemplo de cdigo deActionScript en Flex..............................................................................126

Fig. 6.1: Ejemplo del patrn Quick comment............................................................................................132

Fig. 6.2: Ejemplo del patrn Tag definition .............................................................................................133

Fig. 6.3: Ejemplo del patrnNotifications................................................................................................133

Fig. 6.4: Ejemplo del patrn Collaborative editing...................................................................................134

Fig. 6.5: Ejemplos del patrn Quick rating..............................................................................................134

Fig. 6.6: Ejemplo del patrn Reputation ..................................................................................................135

Fig. 6.7: Ejemplo del patrn Share Content.............................................................................................135

Fig. 6.8: Ejemplos del patrn Suggestions................................................................................................136

Fig. 6.9: Ejemplo del patrnInvite..........................................................................................................136

Fig. 6.10: Ejemplo del patrn Public Profile.............................................................................................137

Fig. 6.11: Ejemplo del patrnAvailability...............................................................................................137

Fig. 6.12: Ejemplo del patrn Ranking....................................................................................................138

Fig. 6.13: Ejemplo del patrn Favorite....................................................................................................138


9/223

9

Fig. 6.14: Ejemplo del patrn Subscription...............................................................................................139

Fig. 6.15: Porcentaje de aplicacin de cada patrn ..................................................................................141

Fig. 6.16 Modelos del patrn Quick comment...........................................................................................147

Fig. 6.17 Modelos del patrnNotification ...............................................................................................150

Fig. 6.18: Modelos para el patrn Suggestion ...........................................................................................152

Fig. 6.19: Modelos del patrn Public Profile............................................................................................154

Fig. 6.20: Modelos para el patrn Subscription ........................................................................................156

Fig. 6.21: Proceso de generacin del modelo del patrn Web 2.0...........................................................159

Fig. 6.22: Punto de extensin metodolgico para el patrn Quick Comment...........................................161

Fig. 6.23: Aplicacin del patrn Quick Comment en OOWS...................................................................162

Fig. 6.24: Modelo resultante del patrn Quick Comment.........................................................................163

Fig. 6.25 Punto de extensin metodolgico para el patrnNotification...................................................164

Fig. 6.26: Aplicacin del patrnNotification en OOWS.........................................................................165

Fig. 6.27: Modelo resultante del patrnNotification ...............................................................................166

Fig. 7.1: Vision General de23andMe......................................................................................................176

Fig. 7.2: Porcentajes de soporte a los escenarios......................................................................................179

Fig. 7.3: Modelo de objetos del escenario Compare Genes........................................................................181

Fig. 7.4: Population AIU del contexto Compare Genes..............................................................................182

Fig. 7.5: Service AIUsdel contexto Compare Genes...................................................................................183

Fig. 7.6: Interfaz del escenario Compare Genes.........................................................................................185

Fig. 7.7: Regla para recalcular la comparacin.........................................................................................186

Fig. 7.8: Reglas para aadir una nueva caracterstica gentica a comparar...............................................187

Fig. 7.9: Regla para mostrar informacin detallada .................................................................................187

Fig. 7.10: Interfaz del contexto23andMe community...............................................................................188

Fig. 7.11: Modelo de objetos del contexto23andMe community..............................................................189

Fig. 7.12: Modelo de interaccin para el contexto23andMe community..................................................191


10/223

10


11/223

11

ndice de TablasTabla 3.1 Comparativa de los mtodos de Ingeniera Web.......................................................................55

Tabla 4.1 : Comparativa primitivas conceptuales OO-Method/OOWS ..................................................69Tabla 4.2 : Comparativa primitivas conceptuales OOWS/OO-Method ..................................................70

Tabla 4.3. Plantilla para la especificacin de una Service AIU....................................................................77

Tabla 4.4. Ejemplo de una Service AIU.....................................................................................................77

Tabla 4.5. Plantilla para la definicin del patrn Vista Resumida .............................................................83

Tabla 4.6. Ejemplo del patrn Vista resumida...........................................................................................83

Tabla 4.7: Plantilla para la definicin del patrn Regla de Validacin....................................................87

Tabla 4.8: Ejemplo del patrn Regla de Validacin ...............................................................................87

Tabla 4.9 Ejemplo del patrn Inicializacin de argumento.......................................................................88

Tabla 4.10 Ejemplo de Navegacin de servicio .........................................................................................92

Tabla 4.11 Relacin del Modelo de Interaccin Abstracto con OOWS y OO-Method ..........................95

Tabla 5.1: Relaciones de weaving por defecto con el modelo de interaccin abstracto............................119

Tabla 6.1: Relacin entre los patrones y las webs analizadas ...................................................................140

Tabla 6.2 Notacin basada en CTT para representar el modelo de interaccin ......................................145

Tabla 7.1: Soporte de los escenarios en OOWS y OOWS 2.0 ...............................................................179

Tabla 7.2: Modelo de weaving para el contexto Compare Genes..............................................................184

Tabla 7.3: Diseo del experimento ..........................................................................................................197

Tabla 7.4: Relacin entre las mtricas y el cuestionario de evaluacin.....................................................201

Tabla 7.5: Orden temporal de las tareas ..................................................................................................201

Tabla 8.1 Publicaciones realizadas en el marco de la tesis .......................................................................210


12/223


13/223

13

1. Introduccin

1.1

Qu son las aplicaciones Web 2.0?

a Web se ha convertido por mritos propios en el medio de comunicacin por excelenciadel siglo XXI. Resulta difcil decir nada original para justificar el tremendo impacto quetiene y va a seguir teniendo en el devenir de nuestra civilizacin. Entre sus muchas

aportaciones, destaca la rapidez con la cual se intercambia la informacin que unida a laeliminacin de las barreras geogrficas, han convertido a Internet en un terreno frtil en el cuallas empresas pueden extender sus negocios. Como consecuencia ha proliferado el nmero deaplicaciones Web para la resolucin de las necesidades de las organizaciones. A diferencia de lasaplicaciones tradicionales desarrolladas para una plataforma tecnolgica concreta, lasaplicaciones Web potencialmente pueden llegar a cualquier tipo de dispositivo. Por lo tanto estenuevo paradigma de desarrollo se est utilizando cada vez ms para implementar aplicacionesgubernamentales, de enseanza a distancia o de gestin empresarial entre otras.

Son varias las ventajas que nos proporciona resolver la problemtica de una organizacin atravs de una aplicacin Web. En primer lugar para su utilizacin el usuario final slo necesitaconocer el uso de un navegador Web. Por lo tanto, no es necesario que asimile conocimientos de

instalacin o configuracin. En segundo lugar, debido a que el desarrollo Web se basaestndares aceptados (HTTP, HTML, XML, etc.) y tecnologas multiplataforma (Flash,JavaScript, etc.), se soluciona el problema de generar software para distintos sistemas operativoso dispositivos. La misma aplicacin Web puede ser utilizada tanto desde el navegador InternetExplorer de Windows como desde un smartphone con un navegador mvil. Por lo tanto sesimplifica notablemente el mantenimiento de la aplicacin, pues siempre se accede desde elmismo servidor y ante un cambio no es necesario instalar una nueva versin en todos losdispositivos.

Gracias a las ventajas de este nuevo paradigma de desarrollo, el nmero de aplicaciones Webha crecido de forma exponencial. Debido a esta rpida evolucin y a la complejidad tecnolgica

aadida, el desarrollo de aplicaciones Web se caracteriza por ser ms costoso y complejo que eldesarrollo tradicional de software. Adems, para agravar dicha situacin, la gran mayora de las

L


14/223

14

aplicaciones Web han sido desarrolladas sin seguir ningn tipo de metodologa. Comoconsecuencia se han detectado graves problemas de mantenimiento, calidad y reusabilidad.

A pesar de dichos problemas, las aplicaciones Web han continuado evolucionandotecnolgicamente para abarcar un mayor nmero de mbitos. Esta evolucin ha sido resumida

en un trmino que ha ganado rpidamente una amplia aceptacin: Web 2.0. Sin embargo,todava no existe una definicin ampliamente consensuada para el trmino Web 2.0.Fundamentalmente, porque en esencia la Web 2.0 comparte la misma arquitectura y protocolostecnolgicos que la Web 1.0. Es decir ambas se componen de un conjunto de documentosenlazados mediante hipervnculos que son accesibles a travs de Internet y comparten el uso delprotocolo HTTP.

El origen del concepto Web 2.0 guarda una estrecha relacin con la llamada crisis de laspuntocom que se produjo a finales de los aos 90. Dicha crisis fue producto de la excesiva yartificial revalorizacin que tuvieron las empresas de servicios de Internet. Esta crisis puso demanifiesto que cualquier negocio que se trasladase a la Web no tena por que ser viable desde el

punto de vista econmico. Tambin demostr que no bastaba con exponer un producto en laWeb para que el usuario lo comprase. En cierta medida, esta crisis tambin puso en tela dejuicio las elevadas expectativas puestas en la revolucin del comercio electrnico. Laconsecuencia fue la desaparicin en un corto espacio de tiempo de numerosos sitios Webdejando perdidas multimillonarias. Estaba claro que la Web era til para hacer negocios y queno estaba desfasada pero tambin era evidente que algo haba fallado. La prueba de ello es quehubo negocios de comercio electrnico que alcanzaron en ese periodo un notable xito y que anperduran comoEbay oAmazon.

Despus de esta crisis, otras aplicaciones Web que no estaban directamente relacionadas conel comercio electrnico adquirieron una elevada repercusin en Internet. El mximo exponentede estas aplicaciones Web es el buscador Google, pero tambin destacan Wikipedia,YouTube oms recientemente la red social Facebook. El indicador de su xito es completamente objetivo: elelevado trfico de usuarios que aglutinan. Adems guardan un caracterstica comn que las alejade la Web 1.0: son gratuitas para los usuarios y son ellos, en muchos casos, su principal activo.

El concepto Web 2.0 tal y como es hoy ampliamente entendido, ya que otros autores loutilizaron anteriormente con otros propsitos, es atribuido a Dale Dougherty y Craig Cline en elproceso de recopilacin de ideas para la que sera la primera conferencia sobre la Web 2.0. Elobjetivo de dicha conferencia era comprender y poner de manifiesto la transicin que se habaproducido en la Web. Cuando fue definido por primera vez el concepto de la Web 2.0 [Oreilly

2005], se realiz de manera ambigua ya que se defini en contraposicin a los modelos denegocio y las tecnologas provenientes de la Web 1.0 que haban provocado el fracaso. Comoconsecuencia, bajo el concepto de la Web 2.0 se han aglutinado una serie de conceptos ytecnologas, que en principio no guardan relacin entre si, como la usabilidad de las interfaces, elfomento de la participacin de los usuarios o los servicios Web. El denominador comn dedichos conceptos y tecnologas, es su papel determinante en el xito de las aplicaciones Web msrelevantes de los ltimos aos. Sin embargo, aquello que comenz siendo una simple palabrapara destacar a las Webs ms relevantes, se ha convertido en una nueva forma de enfocar tanto eldesarrollo Web como los modelos de negocio en Internet [Murugesan 2007].

No es sencillo proporcionar una definicin precisa del concepto Web 2.0. En esta tesis

doctoral definimos el concepto (destacado en negrita) desde dos facetas o aspectos:


15/223

15

a) Una faceta social, en la cual el usuario final pasa a ser el eje central de la aplicacin Web. En lossitios Web tradicionales, el usuario era un consumidor pasivo de la informacin quenormalmente definan los administradores. En la Web 2.0, es el usuario final quien se encargano slo de crear el contenido del sitio (definiciones en Wikipedia,videos en YouTube, etc.), sinoen valorar qu contenido es de mayor calidad y en establecer la categorizacin del mismo a travs

de anotaciones denominadas tags. Este cambio de rol ha propiciado el crecimiento exponencialde contenido en la Web en la forma de: opiniones en blogs, definiciones de conceptos en loswikis o videos y fotos en pginas personales. Asimismo, la tambin denominada Web Socialestablece una analoga con la Web tradicional enlazando en vez de documentos a usuarios. Deesta manera se han establecido virtualmente redes sociales, en las cuales los usuarios estnenlazados entre s por caractersticas que les definen en el mundo fsico (aficiones, habertrabajado juntos, lugares donde estudiaron, etc.).

b) Una faceta tecnolgica avanzada con el objetivo de facilitar la interaccin del usuario final conla aplicacin Web. Si analizamos las interfaces de los sitios Web 2.0 ms populares veremos queposeen un alto nivel de usabilidad. Para alcanzar dicho nivel, han sido indispensables una seriede tecnologas que han permitido desarrollar interfaces e interacciones ms elaboradas. El uso dedichas tecnologas ha dado lugar a las Rich Internet Applicationso RIA [Duhl 2003], aplicacionesque residen en un servidor Web pero en donde el proceso de la capa de presentacin es delegadoparcial o totalmente al navegador Web cliente. Entre las tecnologas RIA [Noda and Helwig2005] ms destacadas se encuentra: 1) AJAX, para obtener los datos del servidor bajo demandaevitando la recarga completa de una pgina, 2) frameworksde Javascript, para aadir lgica denegocio en el lado del cliente, y 3) las tecnologas RIA, para implementar interfaces grficasavanzadas que incluyen animaciones, contenido multimedia e interacciones complejas.

El cumplimiento en mayor o menor medida de ambas facetas es lo que otorga el status de Web 2.0

a una aplicacin en Internet. De esta forma, Google Mapsse cataloga como una Web 2.0 comoconsecuencia de su avanzada interfaz basada en AJAX y Javascript, aunque el contenidofundamental de la aplicacin, los mapas, no son creados por los usuarios. Por otro lado el sitioWeb 2.0 Twitter, herramienta para el denominado microblogging, no entrara en el dominio delas RIA. Sin embargo, su alto carcter social convierte a Twittertambin en un claro ejemplo deWeb 2.0.

Teniendo en cuenta que una aplicacin Web 2.0 no es ms que un producto software conunas caractersticas concretas, es viable utilizar las principios de la Ingeniera del Software paraatacar la problemtica de su desarrollo. Lamentablemente los mtodos de Ingeniera delSoftware tradicionales, no estn adaptados para resolver los requisitos especficos de las

aplicaciones Web 2.0. La Ingeniera Web [Murugesan, Deshpande et al. 2001] surge con elobjetivo de aplicar los fundamentos de la Ingeniera del Software sobre el desarrollo sistemticode aplicaciones Web, atendiendo a las caractersticas particulares propias de este tipo deaplicaciones. Por lo tanto se define como una disciplina especfica, que estudia los procesos,mtodos, tcnicas y recursos esenciales para el desarrollo de aplicaciones Web de calidad. Sinembargo, hasta ahora la Ingeniera Web se ha centrado en resolver los retos que han planteadoel desarrollo de aplicaciones Web 1.0. Por lo tanto el objetivo de esta tesis es del analizar comola Ingeniera Web debe evolucionar para soportar los principios propios de la Web 2.0. Endefinitiva: determinar como tienen que extenderse los mtodos de Ingeniera Web actuales conel fin de soportar el desarrollo de aplicaciones Web 2.0.


16/223

16

1.2

Motivacin

Aunque el procedimiento para otorgar a una aplicacin Web el estatus de 2.0 sea confuso, seobserva una clara tendencia a incluir diversas caractersticas Web 2.0 en el desarrollo Web. Porejemplo aplicaciones Web tradicionales como EBay o Amazon, estn incorporando tanto

interfaces ms ricas como una mayor implicacin del usuario en su proceso de negocio.

Tanto la Ingeniera Web como el Desarrollo de Software Dirigido por Modelos (DSDM)han proporcionado soluciones al desarrollo de aplicaciones Web. Como consecuencia de lacombinacin de ambas disciplinas, el entorno acadmico ha propuesto diversos mtodos deIngeniera Web en los cuales los modelos conceptuales son artefactos clave en el proceso dedesarrollo. Ejemplos de dichos mtodos son WebML [Ceri, Fraternali et al. 2000], UWE[Koch. 2000], OOH [Meli and Cachero 2004], OOHDM [Schwabe, Rossi et al. 1996] yOOWS [Fons, Pelechanoet al.2003] entre otros [Rossi, Pastoret al.2008].

En los ltimos aos, los mtodos de Ingeniera Web han proporcionado resultados

interesantes para el desarrollo de aplicaciones Web, donde la recuperacin de datos y lanavegacin a travs de la informacin son las interacciones principales con el usuario. Estosmtodos han estado fundamentalmente enfocados a los dominios Web que eran ms habitualeshasta ahora: aplicaciones de comercio electrnico (e-commerce) y aplicaciones con recuperacinintensiva de informacin (data-intensive).

Sin embargo, el desarrollo de aplicaciones Web ha continuado evolucionando dejandoobsoletos dichos mtodos en un breve espacio de tiempo. En las aplicaciones Web es cada vezms frecuente encontrar interfaces de carcter multimedia, contenido generado por los usuarios,interacciones complejas, etc.. caractersticas todas ellas que no se encuentran adecuadamentesoportadas por los mtodos de Ingeniera Web [Preciado, Linajeet al.2005]. Las carencias deestos mtodos no se encuentran en el anlisis de requisitos, ni en el enfoque dirigido pormodelos que proponen, ni en las estrategias para la implementacin o la generacin de cdigo.Fundamentalmente, las carencias se detectan en el nivel de modelado conceptual ya que losmodelos que se utilizan no poseen la suficiente expresividad. Por lo tanto dichos modelos tienenque evolucionar en consonancia a como lo han hecho las propias aplicaciones que representan.

La motivacin principal de esta tesis es resolver parte de la problemtica relacionada con laWeb 2.0 que actualmente no se encuentra cubierta por los mtodos de Ingeniera Web. Dichamotivacin principal es muy genrica, ya que la Web 2.0 ha introducido diversos aspectos queson candidatos relevantes a ser incluidos en dichos mtodos. Por ejemplo la creacin de mashups,

la especificacin y explotacin de las llamadas redes sociales, la incorporacin de contenidomultimedia o la definicin de las llamadas folksonomias. Por lo tanto ante la dificultad deabarcarlos todos en el marco de una tesis doctoral, se han seleccionado dos que proporcionan, anuestro juicio, las mejoras ms significativas:

1) Soporte al modelado avanzado de la interaccin:Tradicionalmente en los mtodos deIngeniera Web, los modelos principales han sido el modelo de datos o de dominio y el modelonavegacional. Si bien estos modelos continan siendo relevantes en el mbito de la Web 2.0, losmodelos de interaccin que definen la interfaz entre el usuario y el sistema no han sido definidoscon el mismo nivel de detalle. Las interfaces de usuario basadas en tecnologas RIA han puestode manifiesto las carencias de dichos modelos de interaccin. Por un lado no es posible modelar

la gran variedad de componentes grficos o widgetsque proporcionan dichas tecnologas. Porotra parte, las interacciones del usuario con los distintos componentes de la interfaz son ms


17/223

17

elaboradas y de mayor complejidad. Ambos aspectos tienen que ser contemplados, manteniendola coherencia con los modelos no tecnolgicos previamente definidos en el mbito de laIngeniera Web.

2) Fomento de la participacin del usuario: Una de las caractersticas fundamentales de una

aplicacin Web 2.0 es el alto grado de implicacin del usuario final para la creacin delcontenido. La relevancia del usuario final en el marco de una aplicacin Web 2.0 es tal, que elxito o fracaso de la misma depende de conseguir su colaboracin. Para conseguir dichaimplicacin se han popularizado una serie de prcticas exitosas que simplifican la interaccin conla aplicacin. Claros ejemplos de estas prcticas son, la edicin inmediata del texto que estmostrando una pgina Web o la evaluacin del grado de inters del contenido mediante unsimple enlace. Estas prcticas se aplican de forma tan recurrente en las aplicaciones Web 2.0,que han sido recogidas por diversos autores en forma de patrones de diseo. La gran mayora dedichos patrones si que pueden ser definidos mediante los modelos actuales de los mtodos deIngeniera Web. A pesar de ello en ningn mtodo de Ingeniera Web se ha definido de formaexplcita un mecanismo para su especificacin a nivel de modelado, de tal forma que tienen queser creados desde cero cada vez que el analista desea utilizarlos.

Incorporando ambos aspectos en un mtodo de Ingeniera Web dirigido por modelos, esfactible especificar y generar aplicaciones Web 2.0 que cumplan con dos de los requisitos msdemandados en este mbito.

1.3

Objetivos de la tesis

El objetivo general a resolver en esta tesis es el de incorporar las extensiones necesarias paraabordar el desarrollo dirigido por modelos de aplicaciones Web 2.0. Para acotar la problemtica,esta tesis se centra en dos subobjetivos fundamentales: 1) El modelado avanzado de lainteraccin incorporando la utilizacin de tecnologas RIA, y 2) La deteccin y formalizacin depatrones de interaccin frecuentes en las aplicaciones Web 2.0. Esta tesis justifica con precisinla necesidad de incluir ambos aspectos en los mtodos de Ingeniera Web. Las soluciones seproponen de manera genrica, sin estar ligadas a un mtodo concreto, para aportar una mejoraextensible al conjunto de mtodos propuestos por la Ingeniera Web. No obstante a fin devalidarlas convenientemente, son introducidas en el mtodo de Ingeniera Web OOWS,obteniendo un mtodo que puede ser utilizado para el desarrollo de aplicaciones Web 2.0. Este

nuevo mtodo recibe el nombre de OOWS 2.0. Estos objetivos generales nos llevan a formularlas siguientes preguntas objeto de investigacin:

1.

Qu expresividad conceptual tiene que proporcionar un mtodo de Ingeniera Webpara modelar la interaccin con el usuario al nivel requerido por las aplicaciones Web2.0?

2.

Cmo pueden ser expresadas en un mtodo de Ingeniera Web dirigido pormodelos, las practicas ms habituales de la Web 2.0 que fomentan la participacindel usuario final?

3.

Cules son los mecanismos necesarios para introducir las soluciones de las preguntasanteriores en el marco de un mtodo de Ingeniera Web dirigido por modelos?


18/223

18

Las soluciones propuestas para estas preguntas de investigacin se especifican acontinuacin.

1.4

Solucin Propuesta

Las tres contribuciones principales de esta tesis responden respectivamente a cada una de las trespreguntas de investigacin antes planteadas:

1.

Para llevar a cabo el proceso de modelado de la interaccin, se ha seguido la separacinen niveles de abstraccin propuesta en [Calvary, Coutaz et al. 2003]: 1) un nivelabstracto, donde se define un modelo de interaccin independiente de la plataformatecnolgica, y 2) un nivel concreto que refina el modelo de interaccin abstractointroduciendo informacin tecnolgica sobre la interfaz a desarrollar. Para definir el

nivel abstracto, se ha formalizado un Modelo de Interaccin Abstracto que mantiene laexpresividad conceptual definida en el mtodo OOWS y al cual se le incluye, laexpresividad conceptual del Modelo de Presentacin OO-Method [Pastor and Molina2007]. Por otra parte, el nivel concreto ha sido definido utilizando un metamodelo parala definicin de interfaces de usuario mediante tecnologas RIA. Para determinar lasentidades que forman parte de dicho metamodelo se ha realizado un anlisis de distintasinterfaces de usuario utilizadas en aplicaciones Web 2.0. Dicho metamodelo secompone de una serie de entidades abstractas que sirven de base para crear metamodelosespecficos de cada tecnologa RIA a introducir en el mtodo. A modo de ejemplo sepresenta un metamodelo para la tecnologa RIA Adobe Flex [Tapper, Labriola et al.

2008].2.

Para formalizar las prcticas mas habituales de la Web 2.0 que fomentan la colaboracindel usuario, se ha elaborado un catlogo de patrones utilizando modelos conceptuales.Con dicho objetivo se ha realizado un anlisis de diversos sitios Web 2.0 para encontrarque patrones Web 2.0 se aplican con mayor frecuencia. Como resultado del anlisis seha propuesto un catlogo compuesto de 14 patrones: Quick Comment, Tag Definition,Notification, Collaborative Editing, Quick Rating, Reputation, Share Content, Suggestion,Invite, Public Profile, Availability, Ranking, Favorites y Subscription. Adems de laespecificacin textual habitual, para cada patrn se ha proporcionado un modeloconceptual que especifica sus aspectos de funcionalidad y un modelo conceptual que

especifica la interaccin representada. Estos patrones a nivel de modelado han sidodefinidos en la presente tesis doctoral como patrones Web 2.0.

3.

Para integrar el metamodelo RIA en los mtodos de Ingeniera Web, se ha definido unaestrategia de integracin basada en la definicin de un weaving metamodel [Fabro,Bzivin et al. 2006] entre los metamodelos de un mtodo de Ingeniera Web y elmetamodelo RIA propuesto. La instanciacin de los weaving metamodels permiteestablecer para cada primitiva conceptual del mtodo, que componente tecnolgico deinterfaz ser utilizado. Tambin se ha definido una estrategia de integracin de lospatrones Web 2.0 basadas en transformaciones modelo a modelo. Esta estrategiaconsiste en la definicin de una transformacin que expresa el patrn Web 2.0 como un

modelo perteneciente a un mtodo de Ingeniera Web seleccionado. Como ejemplo deaplicacin se han proporcionado los modelos OOWS 2.0 de un conjunto de patrones.


19/223

19

Con el objetivo de validar los mecanismos propuestos, ambas contribuciones han sidointegradas en el mtodo de Ingeniera Web OOWS definiendo el nuevo mtodoOOWS 2.0. El resultado es un mtodo de Ingeniera Web con la capacidad de modelaraplicaciones Web 2.0 de calidad que contemplan aspectos avanzados de interaccin conel usuario.

1.5

mbito de aplicacin

El mbito de aplicacin de esta tesis est claramente acotado al desarrollo de aplicaciones Web2.0. Dado el amplio abanico de dominios que abarca la Web 2.0, nuestra propuesta es aplicablefundamentalmente en:

Web Sociales: aplicaciones en las cuales el eje central son los usuarios y las relaciones

que se producen entre ellos. Ejemplos de este dominio son las aplicaciones Web paraestablecer redes de contactos personales o laborales.

Entornos colaborativos: aplicaciones Web en las cuales la informacin es creada yrevisada por los propios usuarios. Los wikisy las webs de clasificacin de contenidos(noticias, videos, etc.) forman parte de este dominio.

Catlogos interactivos: aplicaciones Web en las cuales es fundamental crear unfuerte impacto visual al visitante sobre los productos/servicios ofertados. Los sitiosWeb de los fabricantes de productos de consumo son un claro ejemplo.

Aplicaciones con interaccin avanzada: aplicaciones con la complejidad interactivade los entornos de Escritorio que han sido migradas a la Web. Ejemplos de estedominio son las herramientas en lnea de creacin de documentos o de gestin deproyectos.

Migracin de aplicaciones Web 1.0:aplicaciones Web de comercio electrnico ode gestin de la informacin, que habindose desarrollado en el contexto tecnolgicode la Web 1.0, quieran ser migradas al mbito de la Web 2.0 debido a las ventajasexpuestas en esta tesis.

1.6

Estructura de la tesis doctoral

La estructura de la presente tesis doctoral es la siguiente:

El Captulo 2 presenta los fundamentos metodolgicos sobre los cuales se basa lapresente tesis. En este captulo se aborda la metodologa de investigacin empleada y seproporciona una visin general tanto del mtodo OOWS como del mtodo OOWS 2.0.

El Captulo 3 analiza el estado del arte relacionado con la presente tesis. Este estado delarte se ha abordado desde tres puntos de vista: mtodos de Ingeniera Web que han sido


20/223

20

extendidos para soportar caractersticas de la Web 2.0, trabajos en el mbito delmodelado de la interaccin y aproximaciones para definir patrones de aplicaciones Web2.0.

El Captulo 4 presenta el modelo de interaccin abstracto del mtodo OOWS 2.0. Este

nuevo modelo emerge a partir de los modelos de OO-Method y OOWS, siendo elncleo sobre el que se articula el proceso de modelado del mtodo. Se presentan condetalle las primitivas conceptuales que introduce este nuevo modelo.

El Captulo 5 presenta el modelo de interfaz RIA introducido en el mtodo OOWS 2.0.En este captulo se justifica en primer lugar la necesidad de este nuevo modelo. Acontinuacin se especfica tanto las primitivas conceptuales que lo componen como unaestrategia de integracin en el marco de un mtodo DSDM.

El Capitulo 6 introduce el concepto de patrn Web 2.0. En primer lugar en este captulose realiza un anlisis de un conjunto de aplicaciones Web 2.0 para determinar un

conjunto de patrones Web 2.0. A partir de los patrones seleccionados se detalla surepresentacin como modelos conceptuales. Por ltimo se describe una estrategia deintegracin con los mtodos de Ingeniera Web basada en transformaciones modelo amodelo.

El Captulo 7 presenta un evaluacin de la viabilidad del mtodo OOWS 2.0. Estaevaluacin se articula a travs de una demostracin de laboratorio basada en unaaplicacin Web 2.0 real. Utilizando esta aplicacin se han realizado tres tareas deevaluacin: 1) un anlisis de la mejora de la expresividad conceptual de OOWS 2.0 conrespecto a OOWS en el marco de la aplicacin seleccionada, 2) el modelado medianteOOWS 2.0 de dos escenarios de la aplicacin, y 3) un diseo experimental para evaluarlas mejoras de OOWS 2.0 sobre el mtodo OOWS.

El Captulo 8 presenta las conclusiones de la presente tesis, las lneas de trabajo futuro ylas publicaciones acadmicas relacionadas.


21/223

21

2. Fundamentos Metodolgicos

En el presente captulo se detalla los distintos aspectos metodolgicos en los cuales sefundamenta la presente tesis doctoral. En primer lugar se describe la metodologa deinvestigacin empleada en la seccin 2.1. A continuacin, en la seccin 2.2, se proporciona unavisin general del mtodo OOWS, en el cual se basa la presente tesis, y del mtodo OOWS 2.0,contribucin principal de la tesis doctoral. En particular se detallan las relaciones a nivelmetodolgico entre ambos mtodos. En la seccin 2.3, se describe el modelo de presentacin deOO-Method debido a que es una pieza clave para la especificacin del modelo de interaccinabstracto propuesto. Por ltimo, en la seccin 2.4, se introducen los modelos del mtodoOOWS puesto que estos modelos resultan clave para entender tanto dicho mtodo como las

contribuciones de la presente tesis.

2.1

Metodologa de Investigacin: Design Science

La hiptesis que esta tesis busca confirmar o refutar es si es viable extender los mtodos deIngeniera Web dirigidos por modelos para desarrollar aplicaciones Web mediante Interfaces de Usuariobasadas en tecnologas RIA y los patrones ms habituales en la Web 2.0.

En esta tesis se ha utilizado como metodologa de investigacin el paradigma denominadoDesign Science [March and Smith 1995].Este paradigma propone que la investigacin cientficase lleve a cabo mediante la creacin de artefactos que resulten innovadores en su campo. De estaforma, tanto el conocimiento y comprensin del problema a resolver como su solucin, seobtienen a travs de la construccin y posterior aplicacin de dichos artefactos. En concreto, noshemos basado en elframeworkconceptual para la investigacin en Sistemas de Informacin (SI) propuesto por [Hevner, March et al. 2004]. Dicho framework (ver Fig. 2.1) puede ser utilizadopara definir las distintas etapas de una investigacin basada en Design Science. Esteframeworksecompone de tres componentes fundamentales :

1.

El entorno (environment) define el espacio del problema en el cual se encuentra el

objeto de inters de la investigacin. En el dominio de la investigacin en SI, dichoentorno se compone de las personas, las organizaciones y las tecnologas SI


22/223

22

involucradas. Esto es debido a que los objetivos, tareas y problemas que definen lasnecesidades del negocio, son percibidas por las personas de la organizacin en base alas tecnologas utilizadas para llevarlas a cabo. Todos estos elementos conforman elproblema tal y como es percibido por el investigador. Siguiendo este procedimientose obtiene la relevancia en la investigacin, ya que el objetivo fundamental es el de

desarrollar soluciones tecnolgicas que traten problemas reales de una organizacin.

2.

El siguiente componente es la base de conocimiento (knowledge base), la cualproporciona los fundamentos y metodologas utilizados para llevar a cabo lainvestigacin. Por un lado, los resultados previos en investigacin sobre SI,proporcionan los fundamentos de la investigacin mientras que las metodologas, sonutilizadas para justificar y/o evaluar la investigacin. El rigor se consigue, por lotanto, seleccionando los fundamentos y metodologas que resuelven de formaadecuada el problema objeto de investigacin.

3.

Una vez definido el entorno y establecida la base de conocimiento, el siguiente

objetivo es el de crear y evaluar un artefacto (artifact)que cumpla las necesidades denegocio. En el contexto de la Design Science, un artefacto se define como unaherramienta, mtodo, modelo o instanciacin de otra solucin previa que sea tilpara resolver las necesidades detectadas. Por lo tanto un artefacto que resuelvaproblema inexistentes (no definidos en el entorno) carece de sentido.

Fig. 2.1 Framework de investigacin propuesto por [Hevner, March et al. 2004]

Como ltima etapa de la metodologa, las contribuciones de la investigacin son aplicadas alas necesidades del negocio en un entorno adecuado y adems, son aadidas a la base deconocimiento. Conforme los resultados son aadidos a la base de conocimiento, estos seconvierten en prcticas recomendadas para llevar a cabo investigaciones futuras. De esta forma,la construccin de un SI puede abordarse mediante la aplicacin de los elementos presentes en labase de conocimiento a problemas conocidos.

En el contexto de esta tesis, la metodologa Design Science se ha aplicado tal y como sedescribe a continuacin. En primer lugar nuestro entorno viene definido por los organizaciones


23/223

23

que desean incorporar caractersticas de la Web 2.0 a sus SI. Tal y como muestran distintosinformes [Bughin and Manyika 2007; SIIA 2008], alrededor del 75% de los responsables de SIencuestados, han incorporado o piensan incorporar en el futuro cercano caractersticas de laWeb 2.0 en su organizacin. Las personas que demandan dichas caractersticas sonfundamentalmente el personal de marketing, para fomentar la fidelidad del cliente con la

organizacin. La necesidad de negocio surge como consecuencia de la inexistencia en laactualidad de herramientas de desarrollo. Dicho anlisis del entorno es el que ha establecido lamotivacin de la presente tesis doctoral: proporcionar un mtodo de Ingeniera Web que soportelas caractersticas de la Web 2.0 requeridas por las organizaciones.

Para afrontar dicha necesidad del entorno, nuestra base de conocimiento se compone de losdistintos artefactos propuestos en el mbito de la Ingeniera Web, la Ingeniera del Software ypor la comunidad IPO (Interaccin Persona-Ordenador). Fundamentalmente, los artefactosseleccionados son mtodos de Ingeniera Web y modelos conceptuales que tratan el modeladode IU en ambientes Web. Para construir dicha base de conocimiento, se ha realizado un estudiodel estado del arte en el cual se describen las distintos trabajos que han abordado alguno de losproblemas planteados en la presente tesis mediante modelos conceptuales. Dicho estado del arteha permitido detectar las carencias en la base de conocimiento. Fundamentalmente, se hanencontrado varias aproximaciones que abordan de forma parcial el desarrollo de interfaces deusuario para RIA y extensiones a nivel de modelado de los mtodos de Ingeniera Web actuales.Sin embargo, pocos trabajos tratan la faceta social o colaborativa de la Web 2.0

Para resolver el problema de entorno planteado, los artefactos que se han desarrollado hansido los siguientes:

Un metamodelo de Interaccin Abstracto que captura y extiende la expresividadactual de los modelos de los mtodos OOWS y OO-Method.

Un metamodelo para la especificacin de interfaces de usuario en entornos RIA.

Un catlogo de patrones conceptuales de prcticas habituales en la Web 2.0.

Un mtodo de Ingeniera Web denominado OOWS 2.0 que incluye los tresartefactos anteriores.

Dichos artefactos se han definido en consonancia con la base de conocimiento,fundamentalmente con los mtodos de Ingeniera Web y de DSDM y en especial, con lastecnologas estndar para el desarrollo de modelos conceptuales (MOF y UML).

Para la validacin de cada uno de los artefactos se ha seguido una aproximacin diferente encada caso. En primer lugar para el metamodelo de Interaccin Abstracto no se ha realizado unavalidacin explicita, puesto que se compone de primitivas conceptuales previamente validadas enlos mtodos OOWS y OO-Method (pertenecientes a la base de conocimiento).

Para comprobar si el metamodelo RIA es lo suficientemente expresivo se ha seguido unavalidacin basada en escenarios. Para dicha validacin se han seleccionado una serie de interfacesde usuario provenientes de aplicaciones Web 2.0. Para cada una se han creado los modelos deinterfaz correspondientes.

Para definir el catlogo de patrones, se han visitado distintas aplicaciones Web 2.0 y se hanextrado las soluciones que enfatizan la colaboracin con el usuario final. Para seleccionar


24/223

24

aquellas a ser abstradas como patrones, se ha realizado un estudio para determinar su grado deaplicacin en un conjunto de aplicaciones Web 2.0. Las soluciones que son adoptadas en unmayor porcentaje, han sido definidas como patrones conceptuales e incluidas en el catlogo.

Por ltimo, se ha extendido el mtodo OOWS para validar la estrategia de integracin de

dichos artefactos y poder llevar a cabo su aplicacin. De esta manera se ha proporcionado unmtodo DSDM para aplicaciones Web 2.0. Este mtodo ha sido comparado con el mtodoOOWS para distinguir la mejora en la expresividad conceptual de los modelos realizados. Comoltimo paso, se ha realizado un estudio de la viabilidad del mtodo OOWS 2.0 como etapaprevia a su implementacin industrial.

2.2

Visin general del mtodo OOWS y del mtodo OOWS 2.0

El mtodo OOWS [Cors 2008] es un mtodo dirigido por modelos para el desarrollo deAplicaciones Web. Aunque es un mtodo en si mismo, tambin puede definirse como unaextensin metodolgica del mtodo OO-Method para tratar la problemtica especfica deldesarrollo de este tipo de aplicaciones. El mtodo como tal define una serie de fases paracapturar la expresividad necesaria para especificar una aplicacin Web. La principal ventaja deutilizar una aproximacin dirigida por modelos es que el mtodo no propone una fase deimplementacin, sino en su lugar define un proceso de generacin de cdigo a partir de dichosmodelos.

Para comprender mejor las distintas fases y artefactos que componen el mtodo se hadefinido el metamodelo del mtodo. Con dicho fin se ha utilizado la tcnica propuesta por[Weerd and Brinkkemper 2009] proveniente de la Ingeniera de Mtodos (Method Engineering).Esta tcnica se basa a su vez en la propuesta de [Saeki 2003]. La tcnica utiliza una combinacinde dos diagramas UML (ver Fig. 2.2):

1.

En la parte derecha del modelo, se utiliza una adaptacin del diagrama de actividades deUML para especificar el proceso del mtodo. Este diagrama describe las actividades ysub-actividades del mtodo junto a las transiciones entre ellas.

2.

En la parte izquierda del modelo, se utiliza una adaptacin del diagrama de clases deUML que modela los artefactos y relaciones entre ellos que se utilizan en cada una de las

actividades del mtodo. De esta forma se captura una vista de los distintos artefactos quese producen.

Ambos diagramas son integrados en nico modelo y relacionados entre s. Las actividades seenlazan con los distintos artefactos mediante flechas punteadas para indicar que en esa actividadespecfica se genera o utiliza el artefacto correspondiente. El modelo resultante es denominadoProcess-deliverable Diagram (PDD) donde cada fase se representa como un fragmentometodolgico (method fragment) acorde con la terminologa de la Ingeniera de Mtodos.

La Fig. 2.2 muestra el PDD principal del mtodo OOWS. En este modelo se observa que elmtodo se compone de tres fases principales y una opcional:

1. Requeriments Modelling: el mtodo OOWS define un tcnica especfica para la

captura de requisitos para aplicaciones Web. Esta tcnica propuesta por [Valderas, Fons


25/223

25

et al. 2005] se basa en la construccin de un modelo a partir de las necesidades delcliente y la misin de la aplicacin. Este modelo denominado Task-based Requirementsmodel describe los requisitos mediante un rbol de tareas que sigue la notacinConcurTaskTree (para ms detalles sobre esta notacin consultar la seccin 6.2). Cadarequisito es asociado a una tarea la cual incluye adems, una descripcin detallada de las

entidades que participan en la misma. La propuesta tambin presenta un proceso detransformacin basado en gramticas de grafos para obtener a partir de este modelo detareas, una versin preliminar de los modelos OOWS de la aplicacin (OOWS SkeletonModel).

2. Conceptual Modelling: esta es la fase principal del mtodo en la cual se aborda la

especificacin de los modelos conceptuales de la aplicacin Web. Por su relevancia esdescrita con mayor detalle a continuacin.

3. Models Compilation: una vez definidos los modelos, estos son utilizados como entrada

del compilador de modelos OOWS. Definimos el compilador de Modelos OOWS

como un conjunto de reglas de transformacin, definidas mediante el lenguaje XPand[OAW 2008], que transforman los modelos a cdigo ejecutable. Estas reglas generan apartir de una especificacin OOWS, una interfaz Web y la funcionalidad necesaria paraintegrarse con la lgica de negocio definida mediante OO-Method. El cdigo que segenera se basa en el framework WIF, implementado en PHP y descrito en [Valverde,Valderas et al. 2007], el cual tambin aborda la integracin con la funcionalidadgenerada con OLIVANOVA [S.A 2010]. El resultado de esta actividad es un prototipofuncional (Application Prototype) de la aplicacin Web.

4. Presentation Design: esta actividad opcional del mtodo, consiste en la definicin de unconjunto de plantillas CSS (

Stylesheet) para especificar los aspectos visuales (colores,

tipografa, etc.) de la aplicacin Web. Cada plantilla se basa en un conjunto de etiquetaspredefinidas que asocian una regla de estilo especfica a un elemento de la aplicacinWeb generada. En funcin de las etiquetas utilizadas se distinguen dos tipos deplantillas: 1) independientes del dominio, si las reglas de estilo se asocian a lasprimitivas conceptuales de OOWS/OO-Method o a los trminos que introduce elframework, y 2) dependientes del dominio, si las reglas de estilo se asocian a conceptospropios del dominio de la aplicacin descritos mediante el modelo de objetos.


26/223

26

Fig. 2.2: Metamodelo principal del mtodo OOWS

La fase de modelado conceptual del mtodo OOWS es a efectos prcticos donde se reside laexpresividad del mtodo. En esta fase se crea un modelo conceptual con la expresividadnecesaria que describe una aplicacin Web. El PDD de la Fig. 2.3 describe esta fase que se

compone de 4 actividades:

1. OO-Method Modelling: la primera actividad consiste en la construccin de losmodelos OO-Method: el modelo de objetos, el modelo funcional y el modelo dinmico.Estos tres modelos provienen del mtodo OO-Method y comparten la misma semnticaen ambos mtodos. La funcin de estos modelos es la de representar la informacin y lafuncionalidad de la aplicacin describiendo el conjunto de clases y como el estado de susobjetos cambia a travs de la ocurrencia de servicios. Desde el punto de vista delmodelado, el mtodo OOWS slo hace uso del modelo de objetos si bien los otros dosmodelos son fundamentales a la hora de generar la funcionalidad del sistema.

2.

User Modelling: las siguiente actividad es la construccin del diagrama de usuarios quedescribe a los usuarios que participan en la aplicacin. Este modelo se relaciona conaquellas clases del modelo de objetos OO-Method que han sido definidas como agentes.Este diagrama se describe con detalle en la seccin 2.4.

3. Navigation Modelling: el modelado de la navegacin describe como los distintosusuarios acceden al sistema. El conjunto de navegaciones definidas para un usuarioconforma su mapa navegacional (Navigational Map). Un mapa navegacional se componede un conjunto de contextos navegacionales en los cuales se describe la informacin yfuncionalidad ofertadas. Este modelo se describe con ms detalle en la seccin 2.4.

4.

Presentation Modelling: en esa actividad se define un modelo para determinar lapresentacin de la informacin disponible en los distintos contextos navegacionales.


27/223

27

Esta presentacin se describe mediante un conjunto de patrones que definen el modelo.Estos patrones se describen con ms detalle en la seccin 2.4.

Fig. 2.3 Fase de modelado conceptual en el mtodo OOWS

El resultado final de esta fase del mtodo OOWS es un modelo conceptual que engloba losmodelos descritos en las distintas actividades. Este modelo conceptual es utilizado como entradaen la fase de generacin de cdigo.

El mtodo OOWS 2.0 es una extensin del mtodo OOWS fundamentalmente a nivelconceptual, tal y como se justifica a lo largo de la tesis. Por dicha razn las fases principales delmtodo descritas en las Fig. 2.2 se mantienen. La variacin principal se produce en la fase demodelado conceptual en donde se introducen una serie de modelos para abordar de forma msefectiva el modelado de aplicaciones Web 2.0. Este conjunto de modelos conforman lascontribuciones de la presente tesis y son descritos en detalle en los captulos correspondientes. ElPDD que describe la fase de modelado conceptual del mtodo OOWS se muestra en la Fig. 2.4y se compone de dos actividades obligatorias y dos actividades opcionales:

1. OO-Method Modelling: esta actividad es idntica a la descrita en el caso del mtodoOOWS. Por lo tanto al igual que el mtodo anterior, el mtodo OOWS 2.0 tambinreutiliza los modelos definidos en OO-Method.

2. Interaction Modelling: en esta actividad se construye un modelo que representa lainteraccin entre el usuario y el sistema: el modelo de interaccin abstracto. Este modelosustituye al modelo de navegacin de OOWS, ya que no describe nicamente lanavegacin sino que se centra en los aspectos de la interaccin con el sistema. Sinembargo, reutiliza de OOWS los conceptos de mapa y contexto puesto que secompone de un mapa de interaccin descrito en base a un conjunto de contextos deinteraccin. Este modelo es descrito en el captulo 0.


28/223

28

3. Web 2.0 Patterns Modelling: en esta actividad el analista aplica opcionalmente unconjunto de patrones Web 2.0. Los patrones Web 2.0 son representaciones conceptualde problemas habituales que se producen en el desarrollo de aplicaciones Web 2.0. Estopatrones son transformados en una representacin del modelo de interaccin abstractoque soluciona la problemtica descrita por el patrn. El conjunto de patrones Web 2.0

disponibles y su mecanismo de aplicacin son descritos en el captulo 0.

4. RIA Interface Modelling: en esta actividad opcional el analista realiza un modelo de lainterfaz de la aplicacin. En el mtodo OOWS esta actividad no esta contemplada yaque a partir del modelo navegacional se genera una interfaz por defecto. En el mtodoOOWS 2.0 se define de forma explcita una actividad de modelado de una interfazbasada en una tecnologa RIA. La realizacin de esta actividad es opcional ya que elmtodo genera una versin por defecto del modelo de la interfaz RIA. La especificacinde esta interfaz se construye en base a dos modelos interrelacionados: un modelo deinterfaz RIA que describe los widgetsy el comportamiento ante los eventos de interfaz, yun modelo de weavingque relaciona los distintos widgetscon las primitivas conceptualesdel modelo de interaccin abstracto. Ambos modelos son descritos en detalle en elcaptulo 0.

Fig. 2.4 Fase de modelado conceptual del mtodo OOWS 2.0

Al igual que en el mtodo OOWS el resultado de esta actividad es un modelo conceptual,pero en este caso compuesto de: un conjunto de modelos OO-Method, un modelo deinteraccin abstracto, un modelo de weaving y un modelo de interfaz RIA. Este conjunto demodelos es utilizado en la fase de generacin de cdigo para la generacin de una RIAcompletamente funcional. Esta fase de generacin difiere de la presentada en el mtodoOOWS, sin embargo al quedar fuera del alcance de la presente tesis doctoral no es abordadaaqu.


29/223

29

2.3

El Modelo de Presentacin de OO-Method

El modelo de presentacin de OO-Method [Molina 2003] es un modelo para la construccinde IU orientadas a objetos. Este modelo se sustenta sobre el resto de modelos OO-Method(modelo de objetos, dinmico y funcional) para obtener las entidades del dominio relevantes a la

hora de construir la interfaz. De esta manera es posible asociar la interfaz con objetos deldominio para mostrar su informacin o con servicios de las clases para proveer funcionalidad.Los constructores bsicos del modelo son un conjunto de patrones conceptuales que abstraentanto una interaccin genrica como la IU para llevarla a cabo. El modelo se define en base apatrones debido a que estos ocultan al analista gran parte de la complejidad implcita de lainterfaz y permite crear los modelos ms fcilmente. El lenguaje de patrones en el cual se basa elmodelo de presentacin se denomina Just-UI [Molina, Meliaet al.2002].

Fig. 2.5 Lenguaje de patrones JUST-UI del Modelo de Presentacin OO-Method

El Modelo de Presentacin se estructura en una jerarqua de tres niveles tal y como semuestra en la Fig. 2.5. A continuacin se detallan las caractersticas de cada uno de estos niveles

Nivel 1

En este nivel nicamente se encuentra el patrn conceptual de rbol de Jerarqua deAcciones (AJA) o Hierarchical Action Tree (H.A.T). Este patrn organiza el acceso a lafuncionalidad por parte del usuario a travs de una abstraccin en forma de rbol. De estamanera, cada usuario que accede al sistema tiene asociado un rbol que se compone del conjunto

de patrones del siguiente nivel sobre los cuales tiene visibilidad.


30/223

30

Nivel 2

Este nivel est compuesto por las Unidades de Interaccin (UIs) o Interaction Unit. Una UIes una unidad de presentacin que abstrae tanto la presentacin visual de la interfaz, es decir qucomponentes grficos van a ser utilizados, como el comportamiento asociado, es decir la

comunicacin entre el usuario y la propia UI. El modelo de presentacin propone cuatro tiposde UI: 1) UI de Servicio (Service): representa un formulario para que el usuario introduzca losargumentos necesarios para la ejecucin de un servicio. 2) UI de Instancia (Instance): muestra lainformacin asociada al estado actual de un objeto, o en otras palabras el valor de sus atributos.3) UI de Poblacin (Population): muestra mediante un listado tabular el estado actual delconjunto de objetos pertenecientes a una clase. 4) UI Maestro/Detalle (Master-Detail): es unaUI compuesta de dos UI, ya sean de Poblacin o Instancia, definidas sobre sendas clases que seencuentran relacionadas estructuralmente. De esta forma, una UI aporta la informacin maestramientras que la otra muestra la informacin de detalle. De esta forma cuando el usuarioselecciona un objeto de la UI Maestra, se muestran todos los objetos relacionados con elseleccionado en la UI Detalle.

Nivel 3

En el ltimo nivel nos encontramos los Patrones Elementales (PE). Estos patrones permitenrestringir y precisar el comportamiento de las diferentes UI del nivel anterior a fin deproporcionar una mayor expresividad. Estos patrones son:

Entry (Introduccin): restringe el conjunto de valores de entrada que pueden serintroducidos al sistema filtrando valores incorrectos o guiando al usuario en suintroduccin mediante mscaras de edicin o mensajes de ayuda.

Defined Selection (Seleccin definida): proporciona un conjunto de valores predefinidosvlidos que el usuario puede seleccionar como valor de entrada.

Complementary Information (Informacin complementaria): muestra informacinadicional sobre una instancia con el fin de ayudar al usuario.

Argument Dependency (Dependencia): establece una relacin de dependencia entre dosdatos de entrada de tal forma que cuando uno de ellos es introducido, el otro cambia suvalor en funcin de una frmula lgica.

State Recovery (Recuperacin de estado): incializa el valor un conjunto de datos en

funcin del valor de los atributos de un objeto que es recuperado previamente.

Argument Grouping (Agrupacin de argumentos): conforme a un criterio definido,agrupa un conjunto de datos para simplificar su introduccin por parte del usuario.

Filter (Filtro): en una UI de poblacin, permite al usuario establecer una condicin debsqueda para obtener un conjunto acotado de informacin.

Order Criteria (Criterio de ordenacin): ordena los objetos recuperados mediante una UIde poblacin en funcin del valor de un atributo.

Display Set (Conjunto de visualizacin): define el conjunto de atributos que se muestranen una UI de poblacin.


31/223

31

Actions (Acciones): determina el conjunto de servicios que un usuario puede ejecutar enuna UI determinada.

Navigations (Navegacin): muestra en una nueva UI, un conjunto de informacinrelacionado con el objeto seleccionado por el usuario.

Adems de los patrones elementales originales propuestos por [Molina, Melia et al.2002],recientemente se han introducido un conjunto de patrones adicionales que forman parte de laherramienta industrial OLIVANOVA. Consultando [S.A. 2009] estos patrones son:

Editable Display Set(Conjunto de visualizacin editable): permite modificar el valor delos atributos de las instancias que se muestran en una poblacin y posteriormentealmacenar los cambios.

Conditional Navigation (Navegacin condicional): define una navegacin hacia una UIcomo consecuencia de la ejecucin de un servicio, siempre y cuando se cumpla una

frmula condicional.

Navigational Filtering (Filtrado navegacional): filtra la poblacin de una clase comoconsecuencia de una navegacin hacia una UI destino.

Population Preload (Precarga): indica que la poblacin tiene que ser cargada por defectocuando se muestra una UI.

Tree view (Disposicin en rbol): representa una UI Maestro-detalle como un rboldesplegable cuyos nodos es la informacin recuperada.

Outbound Arguments (Visualizacin de resultados): permite mostrar al usuario unconjunto de argumentos como resultado de la ejecucin de un servicio.

La herramienta OLIVANOVA proporciona un editor visual para crear el modelo depresentacin. Este editor se basa en un rbol cuyos primeros nodos son las clases que forman elesquema conceptual. Para cada clase se define qu UI utilizan la informacin de dicha clase. Acontinuacin a partir de cada UI se definen los patrones elementales que son utilizados pararestringir su comportamiento. En la Fig. 2.6 se muestra una captura de dicho editor. Se observala definicin de una IU Poblacin para la clase Contador, que tiene asociados los patroneselementales conjunto de visualizacin, criterio de ordenacin y filtro.


32/223

32

Fig. 2.6 Editor del Modelo de Presentacin en OlivaNOVA

2.4

Los modelos de navegacin y de presentacin de OOWS

El principal mecanismo conceptual del mtodo OOWS es el llamado modelo de navegacincuya misin es describir qu informacin del sistema es mostrada al usuario, la funcionalidad delmismo que puede ejecutar y que las vas disponibles para acceder a dichainformacin/funcionalidad. En OOWS, al igual que en otros mtodos que siguen unaaproximacin hipermedia, una aplicacin Web se estructura como una red de nodos que seencuentran enlazados entre s formando un grafo dirigido. De esta forma, el usuario en unmomento determinado se encuentra en un nodo con el cual interactuar.

En el modelo de navegacin los distintos tipos de usuarios se organizan mediante undiagrama de usuarios que muestra su rol en el sistema, su accesibilidad al mismo y las relaciones

existentes entre ellos. El modelo de navegacin se compone de un conjunto de mapas denavegacin que representan y estructuran la visin global del sistema para cada tipo de usuario,definiendo su navegacin permitida. El mapa de navegacin se representa directamente usandoun grafo dirigido en el cual los nodos son los contextos navegacionales y los arcos son los enlaces(o vnculos) de navegacin tal y como muestra la Fig. 2.7.


33/223

33

Fig. 2.7 Ejemplo de mapa navegacional OOWS

Un contexto navegacional esta formado por Unidades de Interaccin Abstractas o AbstractInformation Units(AIU) cada una de las cualesrepresenta una vista sobre un conjunto de datosy/o servicios. Son unidadesporque constituyen el elemento lgico bsico para la definicin delos contextos navegacionales. De interaccinporque representan una accin/respuesta por partedel usuario, una navegacin o la activacin de un servicio. Y por ltimo son abstractas,porqueslo se especifican qu datos y/o servicios se visualizarn en el contexto, pero no como sepresentarn.

Cada AIU (ver Fig. 2.8) est compuesta por un conjunto de clases navegacionales,estereotipadas con la palabra reservada view, que hacen referencia a clases identificadas en el

modelo de objetos. Con estas clases se define la visibilidad ofertada al usuario en un nodo, tantode los atributos de la clase como de los servicios que puede activar. Toda AIU tieneobligatoriamente una clase navegacional principal, llamada clase directora (ManagerClass), yopcionalmente otras que contribuyen a complementar la informacin de esta clase, llamadasclases complementarias (ComplementaryClass). Las clases navegacionales estn unidas entre spor relaciones binarias unidireccionales que son definidas sobre una relacin de agregacin o deherencia existente entre las dos clases en el modelo de objetos.

Fig. 2.8 Ejemplo de la definicin de una AIU en OOWS


34/223

34

En el modelo navegacional se definen dos tipos de relaciones entre clases navegacionales: 1)una relacin de dependencia de contexto (se representa grficamente mediante flechasdiscontinuas ver figura anterior), que indica una recuperacin de informacin relacionada de lasinstancias de la clase complementaria a travs de la relacin de agregacin o herencia sobre laque est definida la relacin, y 2) una relacin de contexto (grficamente, flechas continuas), que

es una relacin de dependencia de contexto que adems define una navegacin a un nodonavegacional destino, causando la aparicin de un vnculo de navegacin en el mapanavegacional asociado. Para que dicha navegacin sea posible, la clase directora del contextodestino debe ser la misma que la clase complementaria sobre la que se define la relacin decontexto. Los servicios pueden incluir enlaces de servicio, que indican el contexto destino que sealcanzar despus de la ejecucin del servicio.

Adems de las interacciones bsicas para la recuperacin de informacin y ejecucin de lafuncionalidad, OOWS dispone de mecanismos adicionales para la definicin de interaccionesms complejas. Estos mecanismos son:

ndices: proporciona un acceso indexadoa la informacin de la clase directora de unaAIU. Cuando un ndice es activado, se crea el conjunto de valores posibles que puedetener un atributo de la clase directora. Al seleccionar uno de estos valores por parte delusuario, se visualizan nicamente las instancias que posean dicho valor.

Filtros: permiten restringir el conjunto de objetos recuperados de la clase directora enfuncin de una frmula condicional basada sobre alguna atributo de esta clase. EnOOWS se definen dos tipos de filtros dependiendo de su comportamiento: 1)Dinmico, si el filtro es definido mediante una formula abierta, es decir, el valor delatributo sobre el cual se establece la condicin de filtrado no es especificado en lafrmula. Es el usuario quien completar la frmula en tiempo de ejecucinintroduciendo el valor, o 2) Esttico, si el filtro se define como una frmula cerrada detal forma que el usuario no puede cambiar el valor del atributo sobre el cual se filtran lasinstancias de la poblacin.

Vista de resultados: este mecanismo se puede aplicar opcionalmente cuando se utiliza unfiltro o un ndice. Permite definir una vista de informacin parcial del conjunto deinstancias recuperadas mediante el filtro o el ndice. De esta forma, la informacin semuestra al usuario de una forma ms amigable.

Operaciones de sesin: mecanismo que permite la ejecucin de un conjunto de

funcionalidad predefinida cuando el usuario inicia o cuando termina su sesin con elsistema.

Usuario conectado: este mecanismo permite acceder a la informacin del usuarioconectado a la aplicacin. Mediante el uso de este mecanismo se personaliza el acceso yla recuperacin de informacin teniendo en cuenta la informacin personal. Estainformacin es utilizada en otras primitivas conceptuales del modelo como las frmulasde filtro o las condiciones de navegacin.

Condiciones de navegacin: La navegacin capturada mediante las relaciones decontexto enlaza unvocamente dos contextos navegacionales. Sin embargo, dada la

naturaleza de las aplicaciones Web se hacen necesarios mecanismos que expresendinmicamente condiciones de navegacin que sean evaluadas en tiempo de ejecucin.


35/223

35

Estas condiciones especifican restricciones que tienen que satisfacerse para que seproduzca la navegacin.

Navegaciones con cambio de Usuario: el modelo navegacional no permite definirnavegaciones a un contexto o un subsistema del mapa navegacional para el cual el

usuario no tiene permisos. En los casos que se desea evitar este comportamiento, esposible definir una navegacin con cambio de usuario mediante la cual el usuarioconectado adquiere un rol que si tiene los permisos de acceso correspondientes. Estetipo de navegaciones tienen asociadas un nuevo proceso de identificacin para no violarlas restricciones de seguridad.

Una vez definido el modelo de navegacin que captura la semntica navegacional delsistema, debemos asociar caractersticas de presentacin al sistema. Esta es la funcin delmodelo de presentacin que se define en base a un conjunto de primitivas que especifican comose organiza visualmente la informacin al usuario. El modelo de presentacin de OOWS seencuentra ligado al modelo de navegacin ya que utiliza tambin los contextos navegacionales

para establecer las propiedades de presentacin. Por lo tanto, es una extensin del modelo denavegacin que enriquece este ltimo modelo con un conjunto de patrones de presentacin de lainformacin. Estos patrones son utilizado mediante la asociacin con los distintos elementosque forman una AIU de Poblacin. Los patrones de presentacin de informacin soportadosson:

Paginacin: Cuando se utiliza este patrn, el conjunto de instancias a recuperar en uncontexto navegacional es dividido en subconjuntos o pginas de un cardinalidaddeterminada de tal forma que nicamente se muestra uno de estos conjuntos al usuario.El patrn proporciona adems los mecanismos necesarios para que el usuario accedadirectamente a un conjunto de informacin.

Ordenacin:ordena la poblacin de una AIU segn el valor de uno o ms atributos delas clases navegacionales que la conforman. El patrn define tanto ordenacionesascendentes como descendentes.

Disposicin: este patrn describe la disposicin de la informacin en la AIU. EnOOWS se soportan cinco disposiciones posibles: tabular (vertical u horizontal), registro,rbol, texto y maestro-detalle.

Orden de aparicin (tabbing): especfica el orden en el cual son mostrados tantos losatributos como las operaciones definidas en una AIU, estableciendo una relacin deorden entre dichos elementos.

Mediante estos patrones de presentacin y la informacin de navegacin definida en elmodelo navegacional, OOWS captura los requisitos bsicos de interaccin para la generacinsistemtica posterior de la IU de una aplicacin Web.


36/223


37/223

37

3. Estado del Arte

En el marco de la tesis doctoral se propone la definicin de un nuevo modelo de interaccinabstracto sobre el cual se aplican el resto de contribuciones. Por lo tanto, en la seccin 3.1, se harealizado un breve resumen sobre los trabajos ms relevantes de este mbito pertenecientes a lacomunidad Interaccin Persona-Ordenador (IPO). A continuacin, en la seccin 3.2, se hananalizado los trabajos directamente relacionados con el desarrollo de aplicaciones Web 2.0. Esteapartado se ha estructurado en funcin de los mtodos de Ingeniera Web que han sidoextendidos para soportar distintos aspectos relacionados con este tipo de aplicaciones. Para cadamtodo, se han detallado los trabajos relacionados en dicho mbito. Las contribuciones secentran, fundamentalmente, en el modelado de interfaces RIA, del comportamiento de la

interfaz y la definicin y uso de patrones en el mbito de la Web 2.0. En consecuencia, en lapresente tesis no se va a analizar en que consisten dichos mtodos. Un estado del arte detalladosobre diversos mtodos de Ingeniera Web y las herramientas que les dan soporte, puedeconsultarse en el captulo dos de [Valverde 2007] o con mayor profundidad en [Rossi, Pastor etal.2008]. Adems se han tenido en consideracin otros trabajos que si bien no se encuentran enel mbito de los mtodos de Ingeniera Web, proporcionan soluciones interesantes en el marcodel desarrollo de aplicaciones Web 2.0. En este sentido, la seccin 3.3 describe un conjunto detrabajos relacionados con el desarrolla de RIA, mientras que la seccin 3.4, introduce variostrabajos que describen patrones habituales de las aplicaciones Web 2.0.

3.1

Trabajos relacionados con el modelado de la interaccin

A continuacin se analizan propuestas de diversos autores a la hora de modelar la interaccindesde las primeras fases de desarrollo del software. La mayora de estos trabajos abordan ladefinicin de la interfaz de usuario, pero parte de la expresividad propuesta se enmarca en ladefinicin de interaccin en la cual se basa la presente tesis. Un buen punto de partida, es eltrabajo de [Silva and Paton 2003] se proporciona un listado de entornos de modelado deinterfaces de usuario. En este trabajo se analiza un total de catorce mtodos de modelado deinterfaz en base a caractersticas como el proceso de desarrollo de la interfaz, los modelosconceptuales que proporcionan o los editores para el diseo e implementacin. Algunos


38/223

38

ejemplos referenciados en este trabajo son las herramientas Trident [Bodart, Hennebert et al.1994], Genius [Janssen, Weisbeckeret al.1993] y MOBI-D [Puerta and Maulsby 1997]. Estaltima aproximacin es especialmente interesante puesto que utiliza un modelo de tareas y unmodelo de dialogo que expresan de forma implcita la interaccin que representa la IU. Ademsenfatiza la comunicacin de los requisitos del usuario final con el desarrollador de la interfaz a

fin de garantizar que la interfaz plasme de forma concisa la interaccin esperada. Sin embargo laherramienta para construir los modelos se basa en un editor en forma de rbol y una notacintextual poco comprensibles. Por esta razn la construccin de la interfaz resulta compleja en laprctica.

Una notacin ampliamente utilizada en entornos acadmicos para definir la interaccin sonlos llamados ConcurTaskTrees o CTT propuestos por [Patern 2004]. Un CTT representa unadescomposicin jerrquica en forma de rbol de las tareas que el usuario realiza con la aplicacinpara alcanzar un objetivo. De esta manera cada tarea padre del rbol es descompuesta en variassubtareas hijas para describir la interaccin al nivel de detalle que desee el analista. La notacindefine cuatro tipos de tarea: 1) User Tasks:tareas que son llevadas por el usuario sin interaccionarcon el SI; 2) Application Tasks: tareas que son ejecutadas completamente por el sistema; 3)Interaction Tasks: tareas iniciadas por el usuario que involucran una interaccin con el SI; y 4)Abstract Tasks: tareas complejas formadas por la composicin de las anteriores.

Fig. 3.1 Ejemplo de CTT para la ejecucin de un Servicio

Adems, la notacin permite establecer relaciones temporales basadas en un conjunto deoperadores (interleaving, synchronization, enabling, enabling with information, deactivation,iteration, finite iteration, optional taskyrecursion) que son aplicados entre las tareas de un mismonivel. De esta forma se describe de forma no ambigua la secuencia de tareas que define lainteraccin representada por el CTT. Los CTT son una notacin muy popular en la comunidadHCI por ser sencillos de comprender y especificar. Adems ofrecen una semntica precisa

Documents

Borra Dorf Valverde