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
8/3/2019 Un Vistazo Al 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
8/3/2019 Un Vistazo Al OOHDM
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)
8/3/2019 Un Vistazo Al OOHDM
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
8/3/2019 Un Vistazo Al OOHDM
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 :
8/3/2019 Un Vistazo Al OOHDM
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
8/3/2019 Un Vistazo Al 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/3/2019 Un Vistazo Al OOHDM
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.
[ROSSI99B][ROSSI00A]
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]
8/3/2019 Un Vistazo Al OOHDM
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.
[ROSSI99B][ROSSI00A]
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.
[ROSSI99B][ROSSI00A]
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
8/3/2019 Un Vistazo Al OOHDM
10/15
8/3/2019 Un Vistazo Al OOHDM
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
8/3/2019 Un Vistazo Al OOHDM
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.
8/3/2019 Un Vistazo Al OOHDM
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 )
8/3/2019 Un Vistazo Al OOHDM
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
REPRESENTA QUE PREVIO A LANUEVA INTERACCIN,
LA OPERACIN ZDEBE SER INVOCADA.
SELECCIN DENELEMENTOS
EINVOCACIN DE LA
OPERACIN ZY
NUEVAINTERACCIN
REPRESENTA QUE PREVIO A LANUEVA INTERACCIN,
N ELEMENTOSDEBEN SER SELECCIONADOS
Y LA OPERACIN ZDEBE SER INVOCADA
N
( Z )
N ( Z )
8/3/2019 Un Vistazo Al OOHDM
15/15
- Captulo 3 -
22
SELECCIN DENELEMENTOS
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 -
Top Related