un vistazo al oohdm

8/3/2019 Un Vistazo Al OOHDM

1/15

- Captulo 3 -

8

Captulo 3

HERRAMIENTAS DE DISEO

3.1 Un vistazo al OOHDM

El Object-Oriented Hypermedia Design Method [Schwabe98a] y [OOHDM00], es un enfoquebasado en modelos para construir grandes aplicaciones de hipermedia. Este enfoque ha sido utilizadopara el diseo de diferentes tipos de aplicaciones tales como: sitios Web y sistemas de informacin,kioscos interactivos, presentaciones de multimedia, etc.

OOHDM comprende cuatro actividades diferentes denominadas: Diseo Conceptual Conceptual Design; Diseo de Navegacin Navegational Design; Diseo de Interfaz Abstracta Abstract Interface Design e Implementacin Implementation. Durante cada actividad un

conjunto de modelos orientados a objetos que describen aspectos de diseo en particular es construidoo enriquecido por la iteracin previa. Considerara los diseos conceptual, de navegacin y de interfazcomo actividades separadas no solamente nos permite concentrarnos en diferentes aspectos, de uno enuno, sino principalmente obtener un framework para razonar sobre el proceso de diseo,encapsulando experiencia de diseo especfica a cada actividad. [Rossi99c].

La figura3.1 ofrece un bosquejo de las actividades y los modelos que resultan de las mismas enOOHDM [Schwabe98b].

MODELO DE INTERFAZ(PRESENTACIN )

MODELO DE NAVEGACIN

MODELO CONCEPTUAL

OBJECT ORIENTED VIEWS VISTAS

SOBRE EL

MODELO CONCEPTUAL

DIVISI

SERVICIO mamamamamamama

Figura 3.1: Actividades y modelos en OOHDM


2/15

- Captulo 3 -

9

Las primitivas de diseo se pueden reflejar fcilmente sobre lenguajes o entornos deimplementacin no orientados a objetos (tales como HTML o Toolbook). Consecuentemente,OOHDM puede ser usado sin tener en cuenta si el sistema objetivo es un entorno orientado a objetos

puro o un hbrido (tales como los que usualmente se encuentran en Internet) [Schwabe99].

3.1.1 Descripcin de sus actividades

MODELADO CONCEPTUALEl objetivo de la actividad de diseo conceptual es construir un modelo del dominio de la

aplicacin, empleando los principios de modelado orientado a objetos y usando una notacin similar aUML [UML97]. El producto de esta etapa es un esquema de clases construido por subsistemas, clasesy relaciones. La diferencia ms notable con UML es el uso de atributos multivaluados y la indicacinexplcita del sentido de direccin en las relaciones. Las jerarquas agregacin ygeneralizacin/especializacin se usan como mecanismos de abstraccin [Rossi99c].

El modelado conceptual tiene el propsito de capturar las semnticas del dominio lo msneutralmente posible, con poco o nada sobre aspectos referidos a los tipos de usuarios y tareas.Cuando la aplicacin involucra algn comportamiento sofisticado dentro de los objetos conceptuales,esta puede evolucionar a un modelo objeto dentro del entorno de implementacin. No obstante, puedeser implementado fcilmente en las plataformas Web actuales combinando, por ejemplo, una base dedatos relacional con ciertos procedimientos almacenados. Destacable es, que el modelo conceptual

puede no reflejar el hecho de que la aplicacin ser implementada en un entorno WWW, ya que elmodelo clave de aplicacin se construir durante la actividad de diseo de navegacin. Esta visin

permite usar la misma estrategia para implementar aplicaciones legacy en la Web (captulo2,tem2.4), considerando sus modelos conceptuales como el producto de esta actividad OOHDM[Rossi99c].

Las clases en el modelo conceptual se reflejarn en nodos en el modelo de navegacin usando un

mecanismo de vistas y las relaciones se usarn para definir links entre los nodos. Pero adems, podrn existir otros links que no se corresponden directamente con relaciones en el modeloconceptual, sino que pueden surgir en respuesta a requerimientos de navegacin.

La figura3.2 ofrece parte de un Esquema Conceptual de un sitio Web para el estudio de abogadosWinners. Las perspectivas (atributos multivaluados) se indican enumerando los posibles tipos, con un+ prximo al tipo por defecto. Por ejemplo en la clase Abogado, antecedentes: [Text+, Photo:

Image] significa que el atributo antecedentes tiene una perspectiva de texto (siempre presente) ypuede tener adems, una perspectiva de imagen conteniendo una foto. Lo mismo vale para el atributodescripcin de la clase Juicio.

Figura 3.2: Esquema conceptual correspondiente al sitio Web del estudio de abogados Winners

1..*

clasifica

1

aCargo

0..* 1..*JUICIO

idJuicio: Stringcaratula: Stringdescripcin: [Texto+ , Photo: Image]

ABOGADO

nomAbo: Stringantecedentes: [ Text+ , Photo: Image]

TIPOJUICIOnomTipo: Stringdescripcin: Stringtribunales: Set of String


3/15

- Captulo 3 -

10

DISEO DE NAVEGACINEn OOHDM, una aplicacin se visualiza como una vista de navegacin sobre el modelo conceptual.

Esta caracterstica refleja una de las mayores innovaciones del enfoque OOHDM, el cual reconoce quelos objetos que el usuario navega no son los objetos conceptuales, sino otro tipo de objetos que sonconstruidos de uno o ms objetos conceptuales [Schwabe99].

El modelo de navegacin se expresa en dos esquemas:Esquema de Clases de Navegacin Navigational Class Schema

Este esquema es el encargado de definir los objetos navegables de una aplicacin de hipermediay sus clases reflejan la vista seleccionada sobre el dominio de aplicacin. En OOHDM existe unconjunto de tipos predefinidos de clases de navegacin: nodos, links, anchors y estructuras deacceso. La semntica de los nodos, links y anchors es la usual de las aplicaciones dehipermedia, y las estructuras de acceso, tales como ndices, representan posibles formas decomenzar la navegacin y acceder los nodos [Rossi99c] y [Schwabe98a].La figura3.3 ofrece el Esquema de Clases de Navegacin del sitio Web para el estudio deabogados Winners, cuyo Modelo Conceptual ilustra la figura3.2. Las clases de navegacin(llamadas nodos) se indican como clases con una caja cuadrada en la esquina superior derecha.Observar en este diseo que:

los atributos multivaluados en el esquema conceptual han sido representados sobrediferentes atributos de las clases de navegacin (nodos) Juicio y Abogado;

el nodo Juicio es actualmente un vista sobre las clases conceptuales Juicio y TipoJuicio; el nodo Juicio incluye un atributo nomTipoJuicio cuyo valor es tomado del atributo

nomTipo de la clase conceptual TipoJuicio, ms todos los otros atributos propios de la claseconceptual Juicio;

el nodo Juicio ofrece una lista de anchors a el/los nodo/s de su/s abogado/s; el nodo Abogado ofrece un ndice a el/los nodo/s de su/s juicio/s; el link entre los nodos Abogado y Juicio est definido sobre la relacin Abogado aCargo

Juicio.

Es importante destacar que el enfoque OOHDM permite definir una estructura de navegacindiferente para cada perfil de usuario, que reflejar los objetos y relaciones en el esquemaconceptual, de acuerdo con las tareas que este tipo de usuario deba ejecutar. Es decir, quediferentes aplicaciones (sobre el mismo dominio) pueden contener diferentes topologas deenlace links, de acuerdo al perfil del usuario [Rossi99c]. Por ejemplo, el sitio Web para elestudio de abogados, puede incluir la informacin del tipo de juicio para los expertos (abogados),y no incluir esta informacin para el resto de los usuarios casuales.La diferencia ms notable entre el enfoque OOHDM y los dems que usan mecanismos devisualizacin de objetos, es que mientras los ltimos consideran las pginas Web principalmentecomo interfaces de usuario, que son construidas de la observacin de objetos conceptuales, en

Figura 3.3: Esquema de Clase de Navegacin correspondiente al sitio Webdel estudio de abogados Winners

aCargo

0..* 1..*JUICIO

idJuicio: Stringcaratula: Stringdescripcin: Text+photo: Image*nomTipoJuicio: t.nomTipo where t: TipoJuicio and

t clasifica Juicio(self)abogado/sDelJuicio: list of anchor ( a: Abogado

where a aCargo Juicio(self) )

ABOGADO

nomAbo: Stringantecedentes: Text+photo: Image*ndiceJuiciosAbogado: IdxJuicios by Abogado(self)


4/15

- Captulo 3 -

11

OOHDM se propicia claramente un representacin explcita de los objetos de navegacin (nodosy links) durante el diseo [Rossi99c].

Esquema de Contexto de Navegacin Navigational Context SchemaEn OOHDM, la principal primitiva de estructuracin del espacio de navegacin es la nocin decontexto de navegacin. Un contexto de navegacin es un conjunto de: nodos, links, clases de

contexto, otros contextos de navegacin anidados y estructuras de acceso asociadas. Puede serdefinido por comprensin o por extensin, es decir, ya sea definiendo una propiedad comn atodos los nodos y links que el contexto posee, o mediante la enumeracin de todos susmiembros. En resumen, un contexto se compone de: los elementos que contiene; laespecificacin de su estructura interna de navegacin; un punto de entrada; restricciones deacceso en trminos de clases de usuarios y operaciones; y estructuras de acceso asociadas.Existen seis diferentes formas de definir contextos a las cuales es posible asociar estructuras deacceso (ndices).Debido a que este tem, aspira a ser solamente una presentacin que sintetice las principalesideas subyacentes al enfoque OOHDM, para ms detalles sobre tipos de contextos y estructurasde acceso, cartas CRC, etc., remitirse a [Rossi99c][Scwabe98a, 99].

La figura3.4 ofrece el Esquema de Contexto de Navegacin del sitio Web para el estudio de

abogados Winners, cuyos esquemas Conceptual y de Clase de Navegacin ilustran lasfiguras3.2. y 3.3 respectivamente.Observar en este diseo que el men principal (home page del estudio Winners) tiene loscuatro diferentes ndices siguientes:

Abogados que permite acceder a una lista alfabtica de los abogados del estudio, la cualpuede ser atravesada en algn orden; este men puede ser accedido desde cualquier puntode la aplicacin;

Juicios que permite acceder a los juicios que lleva el estudio por idJuicio (cdigo deidentificacin del juicio);

Cartulas que permite acceder a los juicios del estudio agrupados porcartula; Tipos que permite acceder a los juicios del estudio por TipoJuicio;

Figura 3.4 : Esquema de Contexto de Navegacin correspondiente al sitio Webdel estudio de abogados Winners

MENUHOME PAGE

ESTUDIO

Abogado

by nomAboABOGADOS

CARTULAS

JUICIOS

TIPOS

Juicio

by TipoJuicio

by cartula

by idJuicio

by Abogado


5/15

- Captulo 3 -

12

Observar adems que: los juicios pueden tambin agruparse de acuerdo con el abogado que este a cargo de ellos;

este contexto solamente puede ser accedido desde otro contexto, tal como Abogados; el smbolo indica que los ndices Abogados y Juicios pueden ser accedidos desde

cualquier nodo de la aplicacin [Rossi99a], (captulo3 tem3.2, Patrn de Diseo de

Hipermedia Landmark).

DISEO DE INTERFAZ ABSTRACTAEn la actividad de Diseo de la Interfaz Abstracta se especifica cules objetos de interfaz el usuario

percibir y cmo la interfaz se comportar. Para cada atributo de nodo (ya sean contenidos oanchors) se debe definir su apariencia. Por medio de la distincin entre diseo de navegacin einterfaz se pueden construir interfaces distintas para la misma aplicacin y paralelamente alcanzarindependencia de implementacin [Rossi99c].

La especificacin de la Interfaz Abstracta incluye la forma en la cual los diferentes objetos denavegacin lucirn, cuales objetos de interfaz activarn la navegacin, la forma en la cual los objetosde interfaz de multimedia estarn sincronizados y qu transformaciones de interfaz tendrn lugar

[Schwabe99].Es importante enfatizar que la construccin de un modelo formal de la interfaz de las aplicaciones

Web es una actividad que gratifica, ya que las interfaces de usuario tienden a cambiar ms rpidamenteque las topologas de navegacin. Por lo tanto, claramente se necesita una especificacin de diseo

precisa que permita afrontar los cambios suavemente [Rossi99c].

IMPLEMENTACINDurante la actividad de Implementacin, reflejamos los objetos conceptuales, de navegacin y de

interfaz, sobre el entorno de ejecucin destinatario. Cuando el entorno de implementacin no estotalmente orientado a objeto, tenemos que reflejar los objetos conceptuales, de navegacin y deinterfaz abstracta sobre objetos concretos, es decir, aquellos disponibles en el entorno deimplementacin seleccionado. Esto puede requerir definir pginas HTML (o, por ejemplo, objetosToolbook en entornos no basados en la Web), cdigo en cierto lenguaje, preguntas a bases de datosrelacionales, etc. Observar que an en entornos orientados a objeto, puede no existir diferenciassignificativas entre objetos conceptuales y de navegacin, los cuales actuarn como modelos deinterfaces Smalltalk. Mientras tanto, en un entorno ms hbrido, los objetos conceptuales se reflejarnen un almacenamiento persistente (archivos y bases de datos relacionales) y los objetos de navegaciny de interfaz se implementarn como pginas Web convencionales [Rossi99c].

3.1.2 Resumen del enfoque

La figura3.5 ofrece una tabla que sintetiza los aspectos ms relevantes del enfoque OOHDM[Schwabe98b], tambin disponible en http://www.telemidia.puc-rio.br/oohdm/oohdm.html :


6/15

- Captulo 3 -

13

ACTIVIDADES PRODUCTOS FORMALISMOS MECANISMOS ASPECTOSDE DISEO

CAPTURADE

REQUERIMIENTOS

CASOS DE USO,ANOTACIONES.

ESCENARIOS,DIAGRAMAS DEINTERACCIN DEUSUARIO USERINTERACTION

DIAGRAMS-UIDS -,PATRONES DE DISEO.

ANLISIS DEESCENARIOS Y CASOSDE USO,ENTREVISTAS,

UIDSCORRESPONDIENTES

AL MODELOCONCEPTUAL.

CAPTURA LOSREQUERIMIENTOS DELOS STAKEHOLDERSPARA LA APLICACIN.

MODELADO

CONCEPTUALCLASES,

SUBSISTEMAS,RELACIONES,

PERSPECTIVAS DEATRIBUTOS.

CONSTRUCTORES DEMODELADO

ORIENTADOS AOBJETO (CLASES,

RELACIONES,CASOSDE USO),PATRONES

DE DISEO.

CLASIFICACIN,AGREGACIN,

GENERALIZACIN YESPECIALIZACIN.

MODELA LASEMNTICA DEL

DOMINIO DEAPLICACIN.

DISEODE

NAVEGACIN

NODOS,LINKS,ESTRUCTURAS DE

ACCESO,CONTEXTOSDENAVEGACIN,

TRANSFORMACIONESDENAVEGACIN.

VISTAS ORIENTADAS AOBJETO;DIAGRAMAS

DE ESTADOORIENTADOS A

OBJETO;CLASES DECONTEXTO;ESCENARIOS

CENTRADOS EN ELUSUARIO; PATRONES

DE DISEO.

CLASIFICACIN,AGREGACIN,

GENERALIZACIN /ESPECIALIZACIN.

TIENE EN CUENTAPERFIL DEL USUARIO Y

TAREA.ENFASISSOBRE LOS ASPECTOS

COGNITIVOS.CONSTRUYE LAESTRUCTURA DE

NAVEGACIN DE LAAPLICACIN.

DISEODE

INTERFAZABSTRACTA

OBJETOS DE INTERFAZABSTRACTA,

RESPUESTAS AEVENTOS EXTERNOS,TRANSFORMACIONES

DE INTERFAZ.

VISTAS DE DATOSABSTRACTA

ABSTRACT DATAVIEWS-ADVS -;

DIAGRAMAS DECONFIGURACIN;

DIAGRAMAS ADV;PATRONES DE DISEO.

CORRESPONDENCIAENTRE OBJETOS DENAVEGACIN Y

OBJETOSPERCEPTIBLES.COMPOSICIN Y

GENERALIZACIN /ESPECIALIZACIN.

MODELA LOS OBJETOSPERCEPTIBLES,

IMPLEMENTANDO LAS

METAPHORSSELECCIONADAS.

DESCRIBE INTERFAZPARA OBJETOS DE

NAVEGACIN.DEFINE

LA PRESENTACIN,LAY-OUT, DE LOSOBJETOS DE INTERFAZ.

IMPLEMENTACIN APLICACINEJECUTABLECORRIENDO

AQUELLOSSOPORTADOS POR EL

ENTORNO OBJETIVO,DESTINATARIO DE LA

APLICACIN.

AQUELLOS PROVISTOSPOR EL ENTORNO

OBJETIVO,DESTINATARIO DE LA

APLICACIN.

PERFORMANCE,COMPLETITUD.

Figura 3.5: Resumen de la metodologa OOHDM


7/15

- Captulo 3 -

14

3.2 Patrones para Aplicaciones Web

La idea de patrones fue originalmente desarrollada por Christopher Alexander en el campo de laarquitectura urbanstica [Alexander77] y fue adaptada al software orientado a objeto algunos aosdespus [Gamma95]. Un patrn muestra un problema de diseo recurrente conjuntamente con una

buena solucin para dicho problema. Es un instrumento eficaz, que permite registrar experiencia dediseo y razonar sobre el proceso de diseo. Se describe exponiendo su intencin, el problema al queapunta y la solucin abstracta a dicho problema. Los patrones complementan los mtodos de diseomostrando soluciones que van ms all del uso naive de las primitivas de los mtodos. Mejoran lacomunicacin entre los diseadores al enriquecer el vocabulario de diseo, con trminos que expresanestructuras no triviales. Los patrones formalizan soluciones bien conocidas, de tal manera que losdiseadores novatos pueden sacar provecho del conocimiento de los expertos [Rossi00a]. En sntesis,los patrones registran experiencia de diseo enunciando en forma abstracta, problemas recurrentes ysoluciones probadas a dichos problemas recurrentes de diseo. Son herramientas extraordinarias paracapturar, transmitir y reutilizar experiencia de diseo. Cuando un grupo de patrones cubre todos los

problemas de diseo de un dominio en particular y existe un conjunto de reglas que nos permite aplicardichos patrones siguiendo cierto orden parcial, este grupo se denomina lenguaje de patrones, patternlanguage.

En los ltimos aos, la comunidad de hipermedia ha recabado y documentado patrones que cubrendiferentes aspectos en el campo de las aplicaciones Web: para diseo de topologas de navegacin[Rossi99a, 99b] y [Garrido97], (captulo3 tem3.2.1); para diseo de interfaz [Rossi97, 00b]; para usoespecfico en el campo de las aplicaciones e-commerce [Rossi00c]; para incorporar capacidad de

bsqueda [Lyardet99]; etc. En todos estos casos, los patrones han sido documentados usando una plantilla, template, similar a la utilizada por Alexander. De hecho, los patrones para aplicacionesWeb son similares a los patrones urbansticos originales, ya que expresan estructuras recurrentes paraconstruir espacios de navegacin aprovechables y muestran soluciones de diseo que auxilian alusuario a encontrar el camino a travs del hiperespacio [Rossi00a].

Por otra parte y como una consecuencia de la creciente sofisticacin de los sitios Web, impulsadapor la competencia despiadada entre sitios por atraer visitantes, la personalizacin se convierte en unacuestin muy importante en la Internet. El diseo de aplicaciones Web personalizadas puede implicartratar con asuntos diferentes y se puede convertir en un problema abrumador debido a su complejidad.Esta actividad puede significar construir distintas interfaces (personalizadas a un artefacto en

particular), suministrar topologas diferentes de navegacin para personas diferentes, recomendarproductos especficos de acuerdo a las preferencias de los usuarios, implementar polticas de preciosdiferenciadas, etc. Todas estas facetas de la personalizacin comparten la necesidad de modelar al

usuario y sus preferencias, construir perfiles, encontrar algoritmos para opciones de linking mejores.etc., y adems integrar estas en un diseo cohesivo [Schwabe02].

Sin embargo, es importante destacar que de la exploracin y construccin de aplicaciones Web personalizadas, la comunidad de hipermedia ha identificado estructuras de diseo recurrentes que le permitieron registrar un nuevo grupo de patrones: patrones para el diseo de aplicaciones Webpersonalizadas [Rossi01a, 01b], [Schwabe02], [Bumer00], (captulo3 tem3.2.2).

A continuacin, tem3.2.1 e tem3.2.2, se presenta una sntesis sobre los patrones de navegacin yde personalizacin que resultan de inters para esta tesis, los cuales forman parte de un extensocatlogo de patrones de hipermedia.


8/15

- Captulo 3 -

15

3.2.1 Patrones de navegacin

El diseo de la estructura de navegacin de una aplicacin Web requiere, no solamente definirnodos significativos y conectarlos juiciosamente reflejando las relaciones semnticas en el dominio deaplicacin, sino tambin ayudar al usuario a encontrar la informacin deseada hacindolo sentir

confortable mientras navega [Rossi99a].El hecho de contar con herramientas de orientacin (mapas) o de atajos (ndices) es importante, sin

embargo, a la hora de disear la topologa de navegacin para una aplicacin Web, existen problemasms delicados que requieren especial atencin y apropiada respuesta. En este sentido, los patrones denavegacin proveen soluciones que permiten mejorar notablemente las estrategias de navegacin.

La figura3.6 presenta una sntesis sobre los patrones de navegacin, sealando su nombre, suintencin e indicando referencias bibliogrficas a las que es posible remitirse para profundizar sobre eltema.

PATRN INTENCIN OTRASREFERENCIAS

SET-BASEDNAVIGATION

ORGANIZA LA INFORMACIN EN CONJUNTOS SETS DE TEMDE INFORMACIN RELACIONADOS.

PROVEE CAPACIDAD DE NAVEGACIN INTER/ INTRACONJUNTOS.

BRINDA AL USUARIO SUB-ESPACIOS DE NAVEGACIN MSCERRADOS QUE PUEDEN SER FCILMENTE NAVEGADOS.

[ROSSI99B][ROSSI99A]

NEWS PROVEE FCIL ACCESO A NUEVOS TEM DE INFORMACIN AMEDIDA QUE EL WIS CRECE.PERMITE DESTACAR LAS NOVEDADES DEL SITIO.

[ROSSI99B][ROSSI99A][ROSSI99D]

LANDMARK PROVEE ACCESO DIRECTO A SUB-SISTEMAS CRTICOS(DIFERENTES E INCLUSIVE NO RELACIONADOS) EN EL WIS.

POSIBILITA EL DISEO DE ACCESOS DIRECTOS (CONJUNTOS DELANDMARKS) QUE SEAN VISIBLES DESDE TODOS LOS NODOS

DE LA RED.PERMITE DEFINIR DIFERENTES NIVELES DE ACCESOS DIRECTOS

(CONJUNTOS DE LANDMARKS ORGANIZADOSJERRQUICAMENTE) DE ACUERDO CON EL REA DEL SITIO QUE

SE EST VISITANDO.

[ROSSI99B][ROSSI99A][ROSSI00A]

PORTAL PERMITE EL DISEO DE HOMES COMO AGREGADOS DEDIFERENTES TEM DE INFORMACIN (QUE PUEDEN O NO ESTAR

SEMNTICAMENTE CONECTADOS),ANCHORS YESTRUCTURAS DE ACCESO.

BRINDA UNA SOLUCIN DE DISEO OPORTUNISTA PARAINCREMENTAR EL NMERO DE VISITANTES DEL SITIO.


SHOPPING

BASKET

MANTIENE REGISTRO DE LAS SELECCIONES QUE EFECTA EL

USUARIO DURANTE LA NAVEGACIN, HACIENDO ESTASSELECCIONES PERSISTENTES PARA PROCESARLAS DESPUSCUANDO EL USUARIO LO DECIDE.

[ROSSI99B]

[ROSSI00A]


9/15

- Captulo 3 -

16

ACTIVE

REFERENCEDEFINE NDICES COMO HERRAMIENTAS DE ORIENTACIN

ACTIVAS EN SUB-REAS DE TODO EL HIPERESPACIO.HACE QUE ESTOS NDICES CO-EXISTAN CON LOS OBJETOS

OBJETIVO.


NODE INCONTEXT

PERSONALIZA LA REPRESENTACIN DE LOS OBJETOS DEACUERDO AL CONJUNTO DENTRO DEL CUAL ESTN SIENDO

ACCEDIDOS.PERMITE QUE EL MISMO OBJETO APAREZCA EN DIFERENTESCONJUNTOS, MODIFICANDO SU APARIENCIA Y CONEXIONES CONOTROS OBJETOS DE ACUERDO AL CONJUNTO EN CURSO.


3.2.2 Patrones de personalizacinLa construccin de aplicaciones Web personalizadas, es decir aquellas aplicaciones que son

sensibles a las necesidades individuales de cada usuario o grupo de usuarios, es una tarea desafiante.Involucra toda una mirada de tecnologas diferentes que van desde simples vistas de bases de datoshasta agentes de software y algoritmos de filtro y colaboracin. La personalizacin se ha vueltosumamente popular e indispensable en reas tales como el comercio electrnico, y podemos encontrarcientos de aplicaciones que reclaman ser totalmente personalizadas a diferentes perfiles de usuarios oindividuos [Rossi01a].

Como sucede con otras caractersticas Web, existe una gran variedad de tecnologas y sistemas

disponibles, pero poca o ninguna atencin se le ha prestado al proceso de diseo y modelado deaplicaciones Web personalizadas. Sin embargo, ya sealamos, que la comunidad de hipermedia harecabado y documentado patrones de personalizacin que caracterizan las diferentes situacionesusualmente presentes en las aplicaciones Web actuales [Rossi01a, 01b], [Schwabe02], [Bumer00].Adems, se ha demostrado que es posible representar estos patrones dentro de estructuras de diseoconcretas, por ejemplo, el framework que provee el enfoque OOHDM [Schwabe02].

La figura3.7 presenta una sntesis sobre algunos de los patrones de personalizacin, sealando sunombre, su intencin, el mecanismo con el cual se puede modelar la solucin de diseo que propone yun ejemplo prctico, e indicando adems referencias bibliogrficas a las que es posible remitirse para

profundizar sobre el tema. Debido a que el diseo de interfaz esta fuera del alcance de este trabajo, no

se incluye la personalizacin de interfaz.

Figura 3.6: Patrones de Navegacin


10/15


11/15

- Captulo 3 -

18

STRUCTURE LIGA EL ESPACIO DE

NAVEGACIN A LOS

ASPECTOS EN LOS QUE

EL USUARIO EST

INTERESADO.

AGREGACIN RECURSIVADE LAS CLASES DE

NAVEGACIN.

AGREGACIN SIMILAR EN

EL MODELOCONCEPTUAL.

RELACIONES ENTRE ESASCLASES Y LOS OBJETOS

USUARIO.

PORTALES DEINFORMACIN (TALES

COMONETSCAPE,YAHOO,CNN, ETC.)

QUE PROVEEN

CARACTERSTICASMYPORTAL.

[SCHWABE02][ROSSI01A][ROSSI01B]

BEHAVIOR ADAPTA ELCOMPORTAMIENTO DE

LA APLICACIN AL

USUARIO QUE LA

DISPARA.

CLASES DE NAVEGACIN;CONTEXTOS;

CLASES EN CONTEXTOINCONTEXT CLASSES;

FILTROS;

MODELO DE USUARIOEXPLCITO.

DESACOPLAMIENTO DEALGORITMOS DEL

MODELO DE APLICACIN.

DIFERENTESPROCEDIMIENTOS DE

COBRO EN LOS

ALMACENES VIRTUALES,DE ACUERDO A LA

HISTORIA PREVIA.

DIFERENTES ALGORITMOSDE RECOMENDACIONES DE

ACUERDO A CADA

USUARIO.

[SCHWABE02]

CLIENT-SIDE PERMITE A UNAAPLICACIN WEB

PROVEER

INFORMACIN

PERSONALIZADA

DIFERENTE CUANDO ESACCEDIDA DESDE

SITIOS DE CLIENTE

DIFERENTES.

VISTO DESDE LOS SITIOSDE CLIENTE ESTE PATRN

ES SIMILAR A

STRUCTURE Y LINK ;

SIN EMBARGO DESDE ELLADO DEL PROVEEDOR

DEL SERVICIO REFLEJA EL

MISMO

DESACOPLAMIENTO QUE

EL PATRN DE DISEO

OBSERVER [GAMMA95].

APLICACIONES QUEPROVEEN

PERSONALIZACINREMOTA, PERMITINDOLE

A SUS CLIENTES

PERSONALIZAR SERVICIOS(TALES COMO CNN,

BLOOMBERG,AMAZON,ETC.)

[ROSSI01A]

ROLE OBJECT ADAPTA UN OBJETO ALAS DIFERENTES

NECESIDADES DEL

USUARIO MEDIANTE

LA INCORPORACIN DEOBJETOS ROL, CADA

UNO REPRESENTANDO

UN ROL QUE EL OBJETO

DEBE JUGAR EN EL

CONTEXTO DEL

USUARIO.

MODELO DE USUARIOEXPLCITO CON

ROLES /PERFILES.

INCORPORANDO LAESTRUCTURA DE CLASES

DEL ROLE OBJECT EN ELMODELO CONCEPTUAL.

APLICACIONES EN LASCUALES CADA USUARIO

PUEDE JUGAR DIFERENTES

ROLES /PERFILES.

[BUMER00]

Figura 3.7: Patrones de Personalizacin


12/15

- Captulo 3 -

19

3.3 Qu es un UID?

Un User Interaction Diagram (UID) [Vilain00], es una herramienta grfica para representar lainteraccin entre el usuario y el sistema.

Recordar que, se denomina interaccin a la actividad de comunicacin que tiene lugar entre elusuario y el sistema, mediante la cual es posible identificar la informacin manipulada por el sistema yla funcionalidad que el sistema debe ofrecer.

Los UIDs han probado ser un instrumento sumamente efectivo para recopilar requerimientos, yaque ellos describen el intercambio de informacin usuario/sistema. Adems, permiten trabajar en unalto grado de abstraccin, ya que no toman en consideracin los aspectos especficos de interfaz deusuario y los detalles de diseo. Esta tcnica grfica, retrata con claridad la informacin de interaccinque textualmente describe el caso de uso.

3.3.1 Aportes al modelado de aplicaciones WebUn diseo exitoso comienza con una recopilacin de requerimientos adecuada de los usuarios y

otros stakeholders. Para identificar los roles/perfiles y tareas del usuario, el diseador interacta conel dominio para identificar los roles/perfiles que juega el usuario y las tareas que la aplicacin soporta.Un usuario puede jugar varios roles/perfiles, debajo del cual intercambia informacin con laaplicacin; para cada rol/perfil se deben identificar las tareas que la aplicacin Web debe soportar[Gell00a].

La mayora de los mtodos de diseo de hipermedia (y Web) actuales, inclusive las ltimasversiones del enfoque OOHDM [OOHDM00], proveen al diseador con modelos y una notacin

correspondiente para especificar el diseo y la implementacin de las aplicaciones. Pero en generaltodos estos mtodos ofrecen al diseador muy poca ayuda de cmo deber interactuar con todos losstakeholders involucrados, capturando sus requerimientos y eventualmente desarrollando el diseoactual.

Por su parte, el Unified Modeling Language (UML) [UML97], visualiza la interaccin como elintercambio de mensajes entre los objetos del sistema y el Use Case [Jacobson94], si bien describetextualmente la interaccin entre el usuario y el sistema, resulta poco eficiente en el proceso devalidacin con los usuarios, principalmente porque carece de precisin y sntesis.

Una notacin grfica como el User Interaction Diagram (UID), no sufre las desventajas de una

descripcin textual, permitiendo retratar en forma concisa y altamente explcita la recopilacin derequerimientos y facilitando la realimentacin con los stakeholders de la aplicacin.

3.3.2 Notacin

La figura3.8 incluye la notacin para los diferentes tipos de informacin en la representacin de lainteraccin usuario/sistema con UIDs.


13/15

- Captulo 3 -

20

TIPO DE INFORMACIN DESCRIPCIN REPRESENTACIN GRFICA

INTERACCININICIAL

REPRESENTA EL INICIO DE LAINTERACCIN ENTRE EL USUARIO Y

EL SISTEMA.

INTERACCIN REPRESENTA UNA INTERACCINENTRE EL USUARIO Y EL SISTEMA.LA INFORMACIN DADA POR ELUSUARIO Y RETORNADA POR EL

SISTEMA SE MUESTRA ADENTRO DELA ELIPSIS.

INTERACCINOPCIONAL

REPRESENTA UNA INTERACCIN QUEDEPENDE DE LA INTERACCIN

PREVIA.DE ACUERDO CON EL RESULTADO DE

LA INTERACCIN PREVIA, ESTAINTERACCIN PUEDE O NO OCURRIR.

SI NO OCURRE, LA SALIDA DE LAINTERACCIN PREVIA SER

DIRECTAMENTE LA ENTRADA DE LA

SIGUIENTE INTERACCIN.

INTERACCIONESALTERNATIVAS

ESTA REPRESENTACIN ES USADACUANDO EXISTEN DOS SALIDAS

ALTERNATIVAS DESDE UNA

INTERACCIN.LA INTERACCIN SUBSECUENTEDEPENDE DE LOS ELEMENTOS U

OPERACIN SELECCIONADOS POR EL

USUARIO.

ENTRADADE

DATOS

REPRESENTA DATOS OBLIGATORIOSINGRESADOS POR EL USUARIO.

ENTRADAOPCIONAL

DEDATOS

REPRESENTA DATOS OPCIONALESINGRESADOS POR EL USUARIO.

ELEMENTOY SUS

ITEMS DE DATOS

REPRESENTA UN ELEMENTO Y SUSTEM DE DATOS.LOS TEM DE DATOS SON

OPCIONALES.

ELEMENTO( TEM DE DATOS )


14/15

- Captulo 3 -

21

CONJUNTO

DEELEMENTO

REPRESENTA UN CONJUNTO DEELEMENTO.

LOS TEM DE DATOS ASOCIADOS ALELEMENTO SON TAMBIN

PRESENTADOS.

ELEMENTO( TEM DE DATOS )

ELEMENTOESPECFICO

REPRESENTA EL ELEMENTOESPECFICO SELECCIONADO O

INGRESADO POR EL USUARIO EN LA

INTERACCIN PREVIA.

ELEMENTO X

TEXTO REPRESENTA ALGUNOS DATOSADICIONALES QUE PARTICIPAN DE LA

INTERACCIN.

XXXX

TEXTOOPCIONAL REPRESENTA ALGUNOS DATOSOPCIONALES QUE PARTICIPAN DE LA

INTERACCIN.XXXX *

NUEVAINTERACCIN

REPRESENTA UNA NUEVAINTERACCIN QUE OCURRE DESPUS

DE QUE EL USUARIO HA INGRESADO

LOS DATOS Y EL SISTEMA HA

RETORNADO OTRA INFORMACIN EN

LA INTERACCIN PREVIA.

SELECCIN DENELEMENTOS

Y

NUEVAINTERACCIN

REPRESENTA QUE PREVIO A LANUEVA INTERACCIN,

N ELEMENTOSDEBEN SER SELECCIONADOS.

INVOCACIN DE LAOPERACIN Z

Y

NUEVA

INTERACCIN


LA OPERACIN ZDEBE SER INVOCADA.


EINVOCACIN DE LA

OPERACIN ZY

NUEVAINTERACCIN


N ELEMENTOSDEBEN SER SELECCIONADOS

Y LA OPERACIN ZDEBE SER INVOCADA

N

( Z )

N ( Z )


15/15

- Captulo 3 -

22


EINVOCACIN DE LA

OPERACIN Z

REPRESENTA QUEN ELEMENTOS

PUEDEN SER SELECCIONADOS

Y LA OPERACIN ZINVOCADA.

INVOCACIN DE LAOPERACIN Z

REPRESENTA QUELA OPERACIN Z

PUEDE SER INVOCADA.LA INVOCACIN ES OPCIONAL.

Es importante destacar, que con posterioridad a la utilizacin de los UIDs en esta tesis, la notacin

de esta herramienta grfica evolucion, incrementando su expresividad y por lo tanto facilitando larepresentacin de la interaccin usuario/sistema [Vilain02].

3.4 Herramientas de diseo y reingeniera

Las herramientas de diseo citadas en este captulo, facilitan la manipulacin de la complejidadinherente a las aplicaciones Web. Cada una en su terreno, ha demostrado exitosamente su eficacia,dando respuesta a las exigencias que demanda la nueva generacin de aplicaciones Web.

Hoy nadie puede dudar de la necesidad de disear aplicando sistemticamente los principios de la

ingeniera de software y de la ingeniera de Web (captulo2, tem2.3), en pos de que las aplicacionesresultantes tengan chance de ser fcilmente mantenidas y modificadas. Pero la herencia existe y de untiempo a esta parte, la realidad nos ha estado enfrentando a toda una generacin de aplicacioneslegacies (captulo2 tem2.4), coexistiendo con la nueva generacin de aplicaciones Web.

Afrontar esta problemtica, ha forzado y sigue forzando al desarrollo de nuevos enfoquessistemticos que provean herramientas de rediseo. Dentro de este contexto, la reingeniera es

protagnica y cobra da a da renovada vigencia.

N ( Z )

( Z )

Figura 3.8: User Interaction Diagram - Notacin -

un vistazo al oohdm

Documents