modelado de la agregación de portlets por medio de statecharts

XV Jornadas de Ingeniería del Software y Bases de Datos
JISBD 2006
José Riquelme - Pere Botella (Eds)
c CIMNE, Barcelona, 2006
MODELADO DE LA AGREGACIÓN DE PORTLETS POR MEDIO DE
STATECHARTS
Oscar Díaz, Arantza Irastorza, Maider Azanza, Felipe M. Villoria
Dpto. Lenguajes y Sistemas Informáticos (UPV/EHU)-San Sebastián-Spain
Palabras clave: ingeniería web, diseño de portales web, statecharts
Resumen. El portal proporciona integración a través del interfaz gráfico (front-end), mientras que
otras tecnologías soportan integración a través de los datos o de los procesos (back-end). La sindicación de portlets (aplicaciones front-end) sigue la estela de la sindicación de contenidos. El portal
sería un contenedor de portlets, para proporcionar aplicaciones de mayor calado. La agregación de
portlets necesita soluciones que permitan a los usuarios navegar libremente entre los portlets a la
manera "hypertextual". Este trabajo muestra el Modelo Hypermedia Basado en Statecharts donde la
semántica de los statecharts sirve para especificar tanto la organización estructural como la navegación dentro del portal.
1
Introducción
La importancia de los portales corporativos radica tanto en su facilidad para acceder a los datos,
como en ser la ventana a través de la cual se accede a terceras aplicaciones. Distintos estándares (ej.:
WSRP, JSR168) han permitido que se cuente con una forma común para incluir estas aplicaciones
en el ámbito del portal: los portlets [1]. Los portlets son aplicaciones dentro de un portal de forma
similar a como los servlets son aplicaciones en un servidor Web. La diferencia entre ambos es que
los portlets son aplicaciones completas que incluyen también la interfaz de usuario. Son muy semejantes a las aplicaciones de escritorio Windows, en el sentido de que un portlet devuelve fragmentos
de XHTML (o cualquier otro lenguaje de marcado) encuadrados dentro de un marco con distintos
controles genéricos (e.g. para reducir o ampliar).
Sin embargo, el valor añadido de un portal no es sólo proporcionar un punto de acceso común a
aplicaciones heterogéneas, sino que debería también incluir mecanismos para integrar dichas aplicaciones. En otras palabras, el portal se ofrece como un integrador de portlets que permite combinar
distintos portlets para la consecución de un objetivo más ambicioso, todo ello sin salir del portal.
Actualmente, esta agregación es prácticamente inexistente. Una página del portal puede contener
un conjunto de portlets cuyos fragmentos se pueden disponer en filas y/o columnas, minimizar, max1
Oscar Díaz, Arantza Irastorza, Maider Azanza, Felipe M. Villoria
imizar, o recolocar según las necesidades del usuario. Este tipo de agregación se conoce como "sideby-side". Su valor consiste en proporcionar un punto de acceso unificado al usuario, y en mostrar
agrupado el contenido de fuentes diversas.
En este enfoque, sin embargo, la navegación entre los distintos fragmentos de un portlet está completamente separada de la navegación entre las distintas páginas del portal. Y todos los portlets se
muestran simultáneamente al entrar en la página del portal.
Esta situación dificulta soportar tareas que exigen de la agregación funcional, y no sólo visual, de
los portlets. Sin embargo, las herramientas de workflow tradicionales imponen un control muy rígido
en las actividades y en los datos disponibles en cada instante. Por contraste, un "deskflow" debería
ser más relajado, los usuarios deberían poder navegar por las diferentes tareas aunque se hayan dado
algunas guías generales. En otras palabras, la integración back-end se adecua mejor a un enfoque de
workflow, donde se minimiza y se controla rigurosamente la intervención del usuario. Por contra, la
integración front-end se ajusta mejor a un enfoque hipertextual, donde el usuario puede deambular
libremente.
Por lo tanto, el desafío está en encontrar un formalismo lo bastante dúctil para especificar ambas
situaciones, la más rígida y la que permite cierta libertad. Este artículo se exponen las ventajas de
usar los statecharts [4, 3] con este propósito. En nuestra opinión, este formalismo ofrece una expresividad suficiente para captar la mayor parte de las situaciones, y evita la introducción de notaciones
y semánticas ad-hoc que exigen un esfuerzo de familiarización extra al diseñador. A esto hay que
unir, la existencia de herramientas de validación y verificación que estarían disponibles para su uso
también en los portales.
Por otro lado, muchas han sido las propuestas que desligan los aspectos de navegación de los aspectos de presentación en dos modelos separados. Sin embargo aquí, adoptamos una extensión a los
statecharts que usa su estructura y semántica operacional para especificar tanto la organización estructural como la semántica de la navegación entre portlets dentro del portal (HMBS-"Hypermedia Model
Based on Statecharts" [2]). Este artículo presenta como ejemplo un portal con seis portlets que se ha
implementado en la plataforma eXo, y disponible en la dirección http://www.onekin.org/academicBrowsing/.
A efectos de este artículo, modelar un portal implica describir: (1) la estructura del portal, es decir,
cómo se distribuye el contenido tanto entre las distintas páginas como dentro de una misma página, y
(2) la navegación en el portal, es decir, el orden en el que el contenido está disponible para el usuario.
El resto del artículo se estructura como sigue. La sección 2 introduce la idea de “deskflow” y su
diseño mediante statecharts. La seccion 3 aborda la utilización de los statecharts también para indicar
la estructura del portal y completarlo con el modelo de presentación. La sección 4 describe cómo se
generan las páginas del portal a partir de los modelos anteriores. Y finalmente, las conclusiones se
dan en la sección 5.
2
Oscar Díaz, Arantza Irastorza, Maider Azanza, Felipe M. Villoria
Figura 1: Statechart para el portal de ejemplo.
2
El deskflow del portal
Un portal define un espacio de trabajo, un compendio de tareas de front-end. Desde la perspectiva
del portal una tarea es una unidad de comportamiento: o se visualiza la tarea o no se visualiza.
Cómo cumpla la tarea con su cometido está fuera del ámbito del portal. La responsabilidad del
portal consiste en soportar una agregación entre las tareas que contiene, es decir, debe soportar el
“deskflow”.
Proponemos la utilización de los statecharts para especificar el deskflow. Los statecharts son un
formalismo visual para describir estados y transiciones de una manera modular [4]. Extienden el
formalismo clásico de los diagramas de transición de estados incorporando a los estados nociones
de jerarquía, ortogonalidad (concurrencia), un mecanismo de broadcast para comunicar componentes
concurrentes, composición, agregación y refinamientos. Específicamente, se usa una composición de
tipo OR cuando un estado se descompone en un conjunto de estados excluyentes entre sí mientras
que se usa una composición de tipo AND para descomponer un estado en subestados paralelos u
ortogonales. Cada región concurrente en un estado AND está limitada por una línea discontinua.
Como ejemplo, considérense las siguientes tareas que pueden llevarse a cabo en un portal y que
podríamos representar en un diagrama de casos de uso: búsqueda de artículos del IEEE, búsqueda de
artículos del ACM, búsqueda de manuscritos a través de citeseer, búsqueda de los trabajos publicados
de un determinado autor a través de aplicaciones como las del Sr. Ley, almacenamiento en el sistema
del.icio.us de las referencias halladas en la Web, recopilación de distintos parámetros de calidad de
una revista (ej.: su factor de impacto) o de un artículo a través del portal "ISI Web of Knowledge".
Desde la perspectiva del portal, todas estas son tareas atómicas, es decir, estados básicos del statechart. Estas tareas pueden organizarse en un deskflow, como se muestra en la figura 1. Aquí, el
diseñador del portal inicialmente considera dos estados: una persona puede estar buscando algo en
la Web o almacenando los resultados de las búsquedas en del.icio.us. En cualquier momento puede
3
Oscar Díaz, Arantza Irastorza, Maider Azanza, Felipe M. Villoria
pasar a la tarea ISIWoK para consultar el factor de impacto. Search es un estado abstracto que engloba
dos situaciones: búsqueda de un artículo o búsqueda de un autor. Los artículos se pueden buscar tanto
en IEEE como en ACM. Estas dos opciones se muestran simultáneamente y, por tanto, se representan
mediante un estado AND (línea discontinua). Por otra parte, la información sobre autores se puede
obtener en DBLP o en CiteSeer. Las dos tareas están disponibles al mismo tiempo, por lo que también
se modelan mediante un estado AND.
Por tanto, con el análisis del diagrama de casos de uso el diseñador detecta las diferentes tareas del
portal y el mecanismo del statechart le sirve para indicar la secuencia entre dichas tareas, las tareas
que pueden mostrarse en paralelo, etc. En definitiva, utiliza el statechart como medio para mostrar la
navegación inter-tarea en el portal.
En un momento dado, el sistema se encuentra en una determinada configuración de estados, es
decir, el conjunto de estados que están activos en dicho momento [4]. En pocas palabras, una configuración contiene un estado básico (ej.: ACMSearch) y los estados que lo contienen (PaperSearch,
Search y Browsing). Los subestados de un estado OR no pueden estar activos simultáneamente, mientras que los subestados de un estado AND pueden estar activos de forma simultánea siempre que el
estado que los contenga esté activo.
En nuestro ejemplo tenemos cuatro configuraciones de estados posibles:
configuración1: {Browsing, ISIWoK}
configuración2: {Browsing, DeliciousStore}
configuración3: {Browsing, Search, PaperSearch, IEEESearch, ACMSearch}
configuración4: {Browsing, Search, AuthorSearch, CiteSeerSearch, DBLPSearch}
Cada configuración indica los estados activos simultáneamente. Si asociamos una presentación a
cada estado, cada configuración de estados dará lugar a “una configuración de presentación”, que
será la versión gráfica de dicha configuración de estos estados. Como ejemplo, la figura 2 muestra la
configuración de presentación para {Browsing, Search, PaperSearch, IEEESearch, ACMSearch}. La
siguiente sección aborda este tema.
3
La estructura del portal
Con estructura del portal nos referimos al aspecto de presentación del deskflow. Para modelarlo,
adaptamos HMBS [2] a la configuración de los portales. Específicamente, HMBS extiende los statecharts con transformaciones para obtener primitivas de las aplicaciones de hipertexto. En esta sección
introducimos primero el modelo de presentación (p.e. aspectos relativos al color, tipo de letra, etc. en
la configuración de un portal), y en la siguiente describimos la transfomación de una configuración
de estados a “una configuración de presentación”.
4
Oscar Díaz, Arantza Irastorza, Maider Azanza, Felipe M. Villoria
Figura 2: “Configuración de presentación” asociada a la configuración de estados {Browsing, Search, PaperSearch,
IEEESearch, ACMSearch}.
Básicamente, el modelo de presentación se refiere a los artefactos GUI y a las estructuras usadas
para configurar las páginas del portal. En nuestro caso, los artefactos GUI son los portlets, anclas
(para poder realizar las transiciones) y textos (de ayuda o para mostrar información complementaria).
Para gestionar la estética y la estructura de estos artefactos usamos parámetros de estilo y parámetros
de estructura.
En cuanto a los parámetros de estilo, son los mismos que, con distintas variaciones, pueden ser
encontrados en entornos integrados para el desarrollo de portales, como eXo, Oracle Portal or IBM’s
Web Sphere1 . Entre ellos incluimos: background-color, background-image, border-style (entre sus
valores: none, dotted, dashed, etc.), border-color, border-width, font-family, color (es decir, el color
del tipo de letra utilizado), font-size, font-style (entre sus valores: normal, italic y oblique), text-align
(es decir, cómo se alinea el texto respecto al elemento).
En cuanto a la estructura, indica cómo se distribuirán los artefactos a lo largo del espacio de
presentación. Se especificará a través de una función de “mapping” o transformación que, dada una
configuración de estados, produzca una plantilla donde cada artefacto de presentación se coloque en
una celda de la plantilla. Así, esta plantilla estará ya preparada para ser mostrada con una etiqueta
HTML <table>. Por tanto, para el propósito del trabajo que presentamos en este artículo, el aspecto
de presentación relacionado con una configuración de estados será una página basada en tablas. Otras
1
http://www.exoplatform.org/ ; http:/www.oracle.com/appserver/portal_home.html; http://www.ibm.com/websphere/
5
Oscar Díaz, Arantza Irastorza, Maider Azanza, Felipe M. Villoria
opciones sería la utilización de marcos (frames) o tabuladores (tabs) como mecanismos de layout.
La descripción de cómo se distribuyen los artefactos a lo largo de las celdas de la tabla se realiza a
través de los siguientes parámetros de estructura:
transition. Indica cómo se realizarán las transiciones y sus posibles valores son anchor (p.e. un
botón), text, donde la transición se realiza haciendo clic en ciertas partes del texto subrayadas
(de modo similar a como se hace en los textos hypermedia), y both (cuando se quieren incluir
tanto anclas como texto).
distribution. Describe la política de colocación del conjunto de anclas dentro de la página del
portal. Sus opciones son together y detached. Con la opción together todas las anclas se colocan
juntas, independientes de las tareas con las que están relacionadas, mientras que con la opción
detached las anclas se colocan junto a la tarea o funcionalidad con la que están relacionadas.
position. Independientemente de que la distribución sea together o detached, las anclas pueden
colocarse en la parte superior, inferior, a la derecha o a la izquierda de la página o la funcionalidad relacionada.
textPosition. Similar al caso anterior, este parámetro indica la posición del texto respecto de la
página.
alignment. Los parámetros anteriores describían la relación entre las páginas del portal, las
anclas y el texto, pero el diseñador debe tomar otra decisión: la distribución de las diferentes
tareas o funcionalidades mostradas en la misma página. ¿Estarán una debajo de la otra, o una
al lado de la otra? En el primer caso, las funcionalidades forman una columna, y en el segundo,
forman una fila de tareas. Así, los valores de este parámetro son column y row.
presentationDef . Aparte de la distribución de las anclas o el lugar donde el diseñador colocará
la funcionalidad dentro de la página del portal, otra importante decisión será la apariencia (lookand-feel) del portal. Este parámetro tiene tres posibles valores: portal, para cuando la apariencia
del portal debe ser siempre la misma, page, para mantener la coherencia dentro de la página,
free, cuando el diseñador no quiere ninguna restricción sobre el estilo.
Todos estos parámetros determinan la presentación final de la página. Pero ello no debiera significar
que el diseñador tenga que configurar estos parámetros por cada una de las páginas del portal. De
hecho, asegurar una apariencia, look-and-feel, común a través de todas las páginas es uno de los
principales objetivos de los diseñadores de portales, para así mejorar la usabilidad y la interacción
con el usuario. Para lograrlo se han propuesto los skins, es decir, plantillas definidas a nivel de portal,
que establecen algunas propiedades de presentación y son heredadas por todas las páginas. Además de
asegurar la homogeneidad de la presentación, este mecanismo favorece el mantenimiento del portal,
6
Oscar Díaz, Arantza Irastorza, Maider Azanza, Felipe M. Villoria
porque (algunos) cambios en la presentación únicamente implicarán modificaciones del skin, en vez
de tener que modificar distintas páginas del portal.
Sin embargo, este mecanismo puede no tener la granularidad suficiente: la presentación se define
bien a nivel del portal o a nivel de página. No hay nada en medio. Para portales extensos, donde
las páginas pueden ser agrupadas basándonos en el contenido o en aspectos funcionales, podría ser
conveniente definir skins de grano más fino.
Nuestra propuesta es utilizar los statechart con este propósito. Tanto los estados como las transiciones tendrán un modelo de presentación complementario. En vez de asignar parámetros de presentación a las páginas, ahora estos parámetros están asociados a los estados, y su ámbito comprenderá a todos los subestados. Es decir, un conjunto de parámetros asignado a un estado E afectará
a cualquier artefacto asociado con cualquiera de los subestados de E (directa o indirectamente).
Un sub-estado podrá re-definir los parámetros de su estado padre.
Esta propuesta ofrece la generalidad requerida para ofrecer una apariencia común a lo largo de
todo el portal, mientras que al mismo tiempo da respuesta a la especificidad de ciertas tareas o grupos
de tareas donde se busca la singularidad de la presentación. Así, los skins disponibles hoy en día
en las herramientas de portales se corresponden con los parámetros de presentación definidos en el
estado más externo (e.g. Browsing) mientras que todavía es posible redefinir completamente este skin
para un estado atómico particular (e.g. ACMSearch).
La tabla 1 describe el modelo de presentación asociado al statechart de la figura 1. En la tabla 1
podemos observar que, a nivel del estado Browsing, el diseñador ha especificado todos los parámetros
de estructura y estilo para el portal (para facilitar la lectura los parámetros de estilo se han agrupado
en cuatro descriptores, dependiendo del tipo de artefacto al que afecten: funcionalidad o tarea, ancla,
texto). Así, por ejemplo, se ha decidido que en la parte superior de las páginas se muestren tanto
anclas como texto, y que el tipo de letra utilizado para mostrar la funcionalidad sea Times, mientras
que el de las anclas sea Arial. Por otra parte, a nivel del estado IEEESearch el tipo y tamaño de
letra se ha redefinido, por lo que la funcionalidad correspondiente a este estado se mostrará en letra
Courier de 14 puntos (mientras que la correspondiente al estado ACMSearch se muestra con el estilo
por defecto: Times de 12 puntos). Si la redefinición del tipo de letra se hubiera producido a nivel del
estado Search, que aglutina a cuatro de los estados básicos, la funcionalidad correspondiente a todos
ellos se hubiera mostrado en Courier en vez de Times. Por otra parte, a nivel del estado Browsing
también se ha especificado el estilo de los elementos anclas (anchors) del portal, indicando que se
mostrarán en línea sólida negra de 5 puntos. Así se muestran las anclas de la figura 2, excepto aquélla
que corresponde a la transición cuyo origen es el estado PaperSearch. Esta transición se muestra
con línea punteada de 7 puntos porque así se ha indicado en el modelo de presentación específico de
dicho estado (ver tabla 1). A los estados que faltan en la tabla no se les ha definido un modelo de
presentación específico, heredan el de su estado ’padre’.
Describir otro portal con la misma funcionalidad y navegación, pero distinta distribución y presentación sería tan sencillo como mantener el mismo modelo de deskflow (es decir, el statechart),
7
Oscar Díaz, Arantza Irastorza, Maider Azanza, Felipe M. Villoria
modelo de presentación
Estado
{ transition=both; distribution=detached; position=top; textPosition=top; presentationDef=free; alignment=row; }
Browsing
PortalAppDescriptor {backgroundColor=white; borderStyle=none; borderWidth=0px; borderColor=transparent; }
WindowAppDescriptor {borderStyle=solid; borderColor=orange; borderWidth=4px; backgroundColor=white; fontFamily=times;
fontSize=12pt; fontStyle=normal; color=black; textAlign=justify; }
AnchorAppDescriptor {borderStyle=solid; borderColor=black; borderWidth=5px; backgroundColor=white; fontFamily=arial;
fontSize=14pt; fontStyle=italic; color=black; textAlign=justify; }
TextAppDescriptor {backgroundColor=white; borderStyle=solid; borderWidth=1px; borderColor=red; fontFamily=arial; color=red;
fontSize=14pt; fontStyle=normal; textAlign=justify; }
WindowAppDescriptor{alignment=column; borderStyle=dotted; borderColor=blue; }
PaperSearch
AnchorAppDescriptor {borderStyle=dotted; borderWidth=7px; }
IEEESearch
WindowAppDescriptor {fontFamily=courier; fontSize=14pt;}
AuthorSearch
WindowAppDescriptor {alignment=column; position=bottom; }
ISIWok
WindowAppDescriptor { fontFamily=arial; fontSize=16pt; }
Tabla 1: Estados y sus modelos de presentación complementarios.
cambiando el modelo de presentación únicamente. Éste es un modelo abstracto que no obliga al
diseñador a saber de sintáxis de hojas de estilo, etc.
La siguiente sección profundiza en los detalles relativos a la obtención de “las configuraciones de
presentación” (es decir, páginas) a partir de las configuraciones de estados.
4
Generación de las páginas del portal
Una vez definido los modelos de deskflow (de navegación) y de presentación, necesitamos un
mecanismo que de las configuraciones de estados y sus modelos de presentación asociados genere las
configuraciones de presentación. La correspondencia entre los dos conceptos se establece a través de
tres funciones de “mapping”, a saber:
s2p (from states to pages) es la función que a partir de los estados de una configuración recupera los portlets o textos correspondientes. Sólo se consideran los estados básicos y los estados
compuestos de tipo AND. A los primeros les corresponden portlets (que serán los encargados
de las tareas o funcionalidades). En el ejemplo, a nuestros seis estados básicos (ISIWoK, DeliciousStore, IEEESearch, ACMSearch, CiteSeerSearch, DBLPSearch) les corresponden seis
portlets, isi, delicious, ieee, acm, citeseer y dblp, respectivamente. El único propósito de los
estados AND es el de expresar concurrencia en los statecharts. Así, un estado AND indica que
la información de los artefactos asociados a sus subestados será presentada simultáneamente.
Por tanto no les corresponde ningún artefacto de presentación explícito, pero sí una estructura
que sirve para recoger los artefactos de sus subestados y presentarlos en un formato adecuado
(por ejemplo, uno tras otro o uno debajo del otro).
8
Oscar Díaz, Arantza Irastorza, Maider Azanza, Felipe M. Villoria
t2a (from transitions to anchors) es una función que a partir de las transiciones salientes de los
estados activos, obtiene los artefactos ancla asociados. En el ejemplo, a las cinco transiciones,
les corresponden otras tantas anclas. Un ancla aparecerá una sola vez en una página del portal,
pero podría aparecer en más de una página.
a2e (from anchors to events) es una función que asocia a las anclas los eventos de statecharts
que controlan el disparo de las transiciones. Básicamente, es la inversa de t2a, y como se verá
más adelante, permite pasar de una configuración de presentación a la siguiente configuración
de estados. Una transición de statechart debe tener un único evento, aunque el mismo evento
puede aparecer en múltiples transiciones. De esta manera, se soporta la reutilización de componentes de enlace, porque las transiciones y los eventos pueden ser reutilizados para definir
anclas en diferentes contextos de navegación. Un ancla debe ser transformada en una transición
cuyo origen es uno de los estados de la configuración de estados asociada a la página. En la
figura 1, por ejemplo, a un ancla mostrada con el artefacto asociado al estado PaperSearch debería asociársele la transición que se dispara por medio del evento 2AuthorSearch. En la figura
2 podemos ver dicha ancla, dentro de una caja punteada en negro.
Tanto el statechart como las funciones de transformación ”mapping” son proporcionadas por el diseñador del portal. A partir de ese momento, es el motor del portal el que mantiene la presentación.
Supóngase que se está visualizando una determinada “configuración de presentación” (una página del
portal, p.e. la de la figura 2). Cuando un usuario hace clic sobre un ancla (p.e. 2Isi, la primera de las
tres), el sistema realiza las siguientes acciones:
1. Aplica la función a2e para generar el evento (2Isi en el statechart de la figura 1) que causó el
disparo de la transición asociada a dicha ancla.
2. Activa todos los estados que son destino para la transición disparada. Así se genera la nueva
configuración de estados ({Browsing, ISIWoK}). Para optimizar esta generación, el motor del
portal podría tener almacenadas todas las posibles configuraciones del statechart del portal.
3. Aplica la función s2p a la configuración de estados actual y la función t2a a las transiciones
asociadas a dicha configuración, para así obtener la siguiente página del portal (ver figura ??).
4. Envía esta página al navegador del usuario. Y con esto se termina el ciclo.
5
Conclusiones
La publicación de los estándares WSRP y JSR168 promete traer consigo la interoperabilidad entre
portlets. Esto acelerará la transición de la sindicación de contenidos a la sindicación de portlets. En
este contexto, la habilidad para agregar portlets será crucial para mejorar la experiencia del usuario.
9
Oscar Díaz, Arantza Irastorza, Maider Azanza, Felipe M. Villoria
Este artículo propone el uso de los statecharts extendidos, es decir, los HMBS statecharts, para
modelar portales "portlet-intensive". Además plantea una primera aproximación para el diseño de este
tipo de portales: (1) tras el análisis de los casos de uso, el diseñador obtiene las tareas del portal; (2)
buscará los componentes, es decir, los portlets que implementarán dichas tareas. Estos portlets podrán
ser internos o externos a la propia empresa; (3) estas tareas o portlets serán los que conformarán los
estados básicos de nuestro modelo de deskflow, es decir, el diseñador define la función de “mapping”
s2p; (4) el diseñador completará el modelo con las transiciones inter-estado y con el modelo de
presentación asociado a cada estado y/o transición. El diseñador no tendrá que preocuparse de la
construcción de las páginas, porque éstas serán generadas por el motor del portal a partir de los
modelos de deskflow y presentación y de la función s2p. Cómo se generan estas páginas de manera
automática queda fuera del objetivo del presente artículo.
Con este enfoque se separa el diseño del portal de su implementación en una plataforma específica,
y, también se separan los roles del diseñador de la navegación y del diseñador de la presentación.
Además este enfoque se beneficia de las ventajas que conlleva el uso de los statecharts así como de
las mejoras en la mantenibilidad y la modularidad en la presentación del portal.
Agradecimientos
Este trabajo se realiza dentro del proyecto TIN2005-05610 co-financiado por el MEC y los fondos
FEDER. Maider Azanza disfruta una beca predoctoral del Gobierno Vasco dentro del “Programa de
Formación de Investigadores”.
REFERENCIAS
[1] O. Díaz and J.J. Rodríguez.
Portlets as Web
tion.
Journal of Universal Computer Science,
http://www.jucs.org/jucs_10_4/portlets_as_web_components.
Components:
an Introduc10(4):454–472, Apr 2004.
[2] M.C. Ferreira de Oliveira, M.A. Santos Turine, and P.C. Masiero. A Statechart-Based Model
for Hypermedia Applications. ACM Transactions on Information Systems, 19(1):28–52, January
2001.
[3] D. Harel and A. Naamad. The STATEMATE Semantics of Statecharts. ACM Transactions on
Software Engineering and Methodology, 5(4):293–333, October 1996.
[4] D. Harel, A. Pnueli, J.P. Schmidt, and R. Sherman. On the Formal Semantics of Statecharts. In
2nd IEEE Symposium on Logic in Computer Science, pages 54–64, 1987.
10