See

discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/228794986

Aplicacin de un Mtodo de Modelado de

Aplicaciones WEB para el desarrollo de un
Portal Web Universitario.
Article

CITATIONS

READS

109

5 authors, including:
Pedro Valderas

Marta Ruiz

Universitat Politcnica de Valncia

Universitat Politcnica de Valncia

51 PUBLICATIONS 401 CITATIONS

14 PUBLICATIONS 73 CITATIONS

SEE PROFILE

SEE PROFILE

Manoli Albert

Vicente Pelechano

Universitat Politcnica de Valncia

Universitat Politcnica de Valncia

26 PUBLICATIONS 194 CITATIONS

190 PUBLICATIONS 1,833 CITATIONS

SEE PROFILE

All in-text references underlined in blue are linked to publications on ResearchGate,

letting you access and read them immediately.

SEE PROFILE

Available from: Pedro Valderas

Retrieved on: 12 October 2016

Aplicacin de un Mtodo de Modelado de Aplicaciones WEB para el

desarrollo de un Portal Web Universitario.
Pedro Valderas, Marta Ruiz, Joan Fons, Manoli Albert y Vicente Pelechano
Departamento de Sistemas Informticos y Computacin
Universidad Politcnica de Valencia
Camino de Vera s/n
46022 Valencia, Espaa
{pvalderas,mruiz,jjfons,malbert,pele}@dsic.upv.es

Resumen
Este artculo (1) presenta una aproximacin para el modelado orientado a objetos de soluciones Web
que proporciona mecanismos para la especificacin de sistemas de informacin dinmicos hipermediales y
de comercio electrnico, (2) propone una estrategia para la generacin automtica de aplicaciones Web a
partir de estas especificaciones conceptuales y finalmente (3) presenta un caso de estudio real en el que se ha
aplicado el mtodo para el desarrollo de un portal web para un departamento universitario.

1. Introduccin
Hoy en da, con la rpida expansin de Internet y los avances en el rea de las tecnologas Web, han
aparecido un nuevo tipo de aplicaciones en estos entornos, cada vez ms complejas y dinmicas, comnmente
conocidas como aplicaciones Web [6] . Adems, debido al acelerado crecimiento y la alta competitividad
de las actividades comerciales en la Red, estos sistemas son construidos en periodos temporales muy cortos,
sin el apoyo de herramientas de trabajo adecuadas y utilizando soluciones ad-hoc, lo que est llevando a
construir sistemas software de baja calidad y de difcil mantenimiento y evolucin.
En los ltimos aos han surgido gran cantidad de aproximaciones metodolgicas (OOHDM [1], WebML
[2] , UWE [14], WSDM [5], AutoWeb [4] , etc.) que intentan ayudar en la sistematizacin de la construccin
de soluciones en ambientes Web, proporcionando mecanismos de abstraccin que faciliten la
conceptualizacin y el desarrollo de estos sistemas. Estos mecanismos permiten especificar caractersticas
hipermediales, (hiper (navegacin) + media (multimedia)) y funcionales, dando soporte a la gestin de
usuarios (diferentes tipos, adaptacin, personalizacin, etc.). Adems, se estn intentando definir marcos de
trabajo integrados que proporcionen herramientas adecuadas para dar soporte a la construccin de estos
sistemas en todas sus fases. Como resultado de estos trabajos, surge lo que tambin hoy en da est acuado
como Ingeniera Web [3].
Nuestra intencin es definir un mtodo de desarrollo que permita especificar sistemas software para
ambientes Web que (1) capture las necesidades de estos sistemas web mediante especificaciones conceptuales
y (2) permita obtener prototipos operacionales a partir de estas especificaciones de manera automtica. Para
conseguirlo, hemos extendido un mtodo OO existente, OO-Method [7], que permite capturar las propiedades
funcionales del sistema que se consideran relevantes para construir una especificacin textual OO y formal de
manera automtica. En este contexto se han concentrado muchos esfuerzos hacia el desarrollo de nuevos
modelos para enriquecer este mtodo de produccin de software orientado a objetos con la expresividad
necesaria para especificar caractersticas navegacionales y de presentacin de informacin orientadas a las
aplicaciones Web. Estas especificaciones formales OO (con caractersticas hipermediales) constituyen un
repositorio de informacin de alto nivel del sistema que ser utilizado como entrada a un compilador de
modelos conceptuales, que utilizando una estrategia de traduccin basada en patrones (de la especificacin a
la implementacin), hacen posible la construccin de una implementacin operacional, generando un
prototipo del sistema completo (incluyendo caractersticas estticas y dinmicas) en la plataforma destino del
sistema. Esta extensin del mtodo OO-Method con capacidades navegacionales y de presentacin es lo que
llamamos OOWS [8] [9] (Object Oriented Web Solution).

En este trabajo se presenta OOWS, detallando el proceso de construccin de un sistema Web,

determinando los pasos a seguir para construir el modelo conceptual y la aplicacin web a partir de sta
especificacin. Para ello se presenta una aplicacin del mtodo para el desarrollo de un portal web para un
departamento universitario. Este portal est orientado a la divulgacin de informacin docente, investigadora
y de actividades de un departamento universitario, adems de proporcionar herramientas de gestin a sus
miembros.
La principal contribucin de este trabajo consiste en el hecho de aplicar un mtodo de produccin
automtica de aplicaciones Web como OOWS, para el modelado, diseo, implementacin e implantacin de
una aplicacin Web real para la gestin de un departamento universitario (www.dsic.upv.es). Adems, el
enfrentarnos a un caso de estudio real nos ha permitido detectar nuevas caractersticas navegacionales
contribuyendo al refinamiento y mejora del mtodo mediante la definicin de nuevas primitivas.
El presente documento se divide en cinco secciones. En la seccin 2, se presenta un caso de estudio de un
portal Web departamental. A partir de su especificacin conceptual en la seccin 3 se comenta el mtodo
OOWS para el modelado de aplicaciones Web y se proponen nuevas primitivas de modelado para extenderlo.
En la seccin 4 se presenta la estrategia de generacin basada una arquitectura de tres capas (interfaz web,
aplicacin y persistencia). En concreto, en este artculo se discute un proceso para la obtencin de la capa de
interfaz web de usuario de forma sistemtica a partir de las especificaciones construidas en la seccin 3.
Finalmente, en la seccin 5 se comentan las conclusiones y los trabajos futuros.

2. Portal Web de un Departamento Universitario

Actualmente se est desarrollando una aplicacin Web para dar soporte a las necesidades
operativas/funcionales para el Departamento de Sistemas Informticos y Computacin de la Universidad
Politcnica de Valencia, en Espaa. Esta aplicacin sirve como medio de difusin de informacin
institucional, acadmica y de investigacin de dicho departamento, tanto para los propios miembros del
departamento como para internautas que deseen consultar actividades del departamento.
Debe permitir que los miembros del departamento (personal), en funcin de sus obligaciones y
necesidades, exploren y mantengan su informacin. Deber posibilitar que los alumnos matriculados de
asignaturas y cursos del departamento, consulten informacin docente sobre las mismas y sobre sus
profesores. Adems de esta informacin docente, el sistema debe proporcionar informacin sobre las
diferentes lneas de investigacin realizadas por los grupos investigadores del departamento, la gestin de
personal a estos grupos (profesores y becarios), los proyectos investigadores en funcionamiento, etc.
Finalmente debe servir como mecanismo de gestin y difusin de informacin institucional: posibilitar la
gestin de la infraestructura del departamento por los responsables tcnicos, gestin de documentos,
instancias, etc. por los miembros administrativos, toma de decisiones y planificacin (gestin de PODs,
asignacin de recursos investigadores, etc.) a los miembros del grupo directivo y a los miembros del
departamento la gestin de su informacin personal (datos personales, presupuestos, docencia asignada, etc.).

3. Modelado Conceptual de aplicaciones Web

En esta seccin se presentan los diferentes pasos que hay que llevar a cabo para especificar los requisitos
de funcionalidad, navegacin y presentacin de una aplicacin Web, centrndonos sobre todo en los dos
ltimos. Siguiendo el proceso propuesto por el mtodo OOWS en esta etapa debemos obtener una
especificacin completa del sistema software para la web. Para ello, esta etapa se divide en dos:
1.
2.

Elicitacin de los requisitos funcionales del sistema. Utilizando una aproximacin basada en casos
de uso [10] se propone un proceso guiado semi-automtico de obtencin de esquemas conceptuales
(Diagrama de Clases, Modelo Dinmico y Funcional) de OO-Method [10]1.
Especificacin de navegacin y presentacin de informacin. Mediante nuevos modelos aadidos a
OO-Method se captura la semntica navegacional de las aplicaciones web (Modelo de Navegacin) y
de presentacin de informacin (Modelo de Presentacin).

Este artculo se centra en el modelado de navegacin y presentacin de informacin. No se dar mayor

detalle en cmo obtener los dems modelos. Sin embargo, se presentar el Diagrama de Clases debido a su

Este trabajo est siendo fruto de una fuerte investigacin en nuestro grupo de investigacin, ya que no se trata de un problema trivial.

relevancia para la definicin de aspectos navegacionales. Las siguientes secciones presentan cada uno de estos
modelos usando el caso de estudio del portal web.

3.1. Diagrama de Clases del Portal Web.

En esta seccin se presenta parte del diagrama de clases construido para el portal Web departamental.
En l se muestran las clases necesarias para modelar la informacin sobre el departamento, sus miembros y
sus grupos de investigacin.
Miembro Departamento

Departamento
-Investigacin
1

-Nombre
-Contacto
-Telfono
-Fax
-Reglamento
-Infraestrcutura

-Miembros

-Nombre
-Apellidos
-Inicial_Ap
-Nombre Completo
-Categoria
-Telfono
-Correo Electrnico
-Fotografa

-Despacho
1

Despacho
-Cdigo
-Extensin
-Tipo

Tutora
1

-Docencia

-Da
-Hora Inicio
-Hora Fin

*
-Tutoras

Asignatura
-Cdigo
-Nombre
-Crditos Teora
-Crditos Prctica
-Ciclo

*
-Tutorias

Profesor

-Profesores

Tcnico

Becario

Administracin

*
-

-Asignaturas

Grupo de Investigacin
Lnea de Investigacin
-Nombre
-Descripcin

-Nombre
-Presentacin
-Direccin Postal
-Pgina Web

- *

-Profesores
1
-Becarios
1

-Lineas de investigacin

Figura 1. Vista parcial del diagrama de clases del portal Web departamental.

3.2. Modelado de la Navegacin

En este punto, debemos captar los requisitos de navegacin de la aplicacin. Para ello, se introduce el
Modelo de Navegacin que permite dar una vista navegacional (mapa navegacional) sobre el Diagrama de
Clases de OO-Method para cada tipo de usuario que pueda interactuar con el sistema. Esta vista proporcionar
una estructura de accesibilidad (definiendo el conjunto posible de caminos de navegacin) en funcin del tipo
de usuario. As la semntica navegacional de las aplicaciones Web se captura en funcin de cada agente del
sistema identificado, permitiendo una personalizacin a nivel de modelado conceptual [12] del acceso en
funcin de las necesidades de cada tipo de usuario. Para construir este modelo, debemos realizar 2 tareas:
1.
2.

Clasificacin e Identificacin de usuarios. Se realiza un estudio de los diferentes potenciales tipos de

usuario que pueden interactuar con el sistema y sus interrelaciones.
Construccin de los Mapas Navegacionales. Para cada usuario detectado, se construye su vista
navegacional del sistema (basado en el Diagrama de Clases definido previamente).

3.3.1. Clasificacin e identificacin de usuarios

En esta etapa se construye un diagrama de agentes (usuarios), donde se especifiquen qu tipos de
usuarios van a poder interactuar con el sistema, qu interrelaciones existen entre ellos y cul va a ser su modo
de acceso al sistema.
En primer lugar debemos estudiar cules son los potenciales tipos de usuarios interactivos con el sistema
y crear un agente en este diagrama. Una vez detectados, se debe realizar un estudio para detectar
interrelaciones entre ellos buscando propiedades comunes (acceso a funcionalidad comn, visibilidad de la
misma informacin, etc.) creando una taxonoma de usuarios que nos permitir reutilizar especificaciones
navegacionales segn [11]. Finalmente, cada tipo de agente puede ser de dos clases distintas:

Agentes instanciables. Los agentes de este tipo constituirn los usuarios que la aplicacin Web
reconocer. Pueden ser de dos tipos: (1) aquellos que necesitan identificarse en el sistema (representados
con el smbolo ) y (2) aquellos que pueden conectarse al sistema sin identificarse (smbolo ?).

Agentes abstractos. Este tipo de agente representa a agentes sin instancias directas. Es utilizado para
llevar a cabo los mecanismos de especializacin.
En la figura 2 se pueden apreciar los usuarios detectados para el portal
web: los Internautas anonimos, que corresponden con los usuarios que no
pertenecen al personal del departamento (y no requieren identificacin);
los Miembros del Departamento (agente abstracto) que tienen todos los
privilegios de los internautas (de ah su especializacin) y poseen adems
nuevas propiedades navegacionales; y por ltimo los Profesores,
Becarios, Personal Administracin, Tcnicos y Equipo Directivo. Todos
estos usuarios requerirn identificacin para usar el sistema y compartirn
todos ellos los mismos privilegios como miembros del departamento. Sin
embargo, cada uno tendr propiedades navegacionales diferentes al
definir su mapa navegacional propio.

Internauta

Is a

Miembro Departamento

Is a

1.2.1

Profesor

Becario

P. Administracin

Tcnico

Directivo

Figura 2. Diagrama de
usuarios del portal Web
departamental.

Construccin de los Mapas Navegacionales

La siguiente fase consiste en construir los mapas navegacionales,

uno por cada agente (usuario). Estos mapas se definen mediante un grafo
dirigido en el que los nodos representan unidades de interaccin con el
usuario (grficamente representado mediante paquete UML [13]) y los
arcos representan los caminos navegacionales vlidos entre nodos
(representados mediante flechas).

Internauta

{Tcnico, P. Administracin, Becario, Profesor}

H
E

<< subsystem >>

<< subsystem >>

<< subsystem >>

<< subsystem >>

<< subsystem >>

<< context >>

<< context >>

DEPARTAMENTO

DOCENCIA

DIRECTORIO

INVESTIGACIN

INTRANET

ENLACES

DSIC INFO

Figura 3. Mapa navegacional del agente internauta.

La figura 3, muestra el mapa navegacional del agente internauta. Este mapa define su vista del sistema
que le proporciona acceso a un conjunto de nodos navegacionales donde podr obtener informacin sobre el
Departamento, Docencia, Directorio (de Personal), Investigacin, Intranet (acceso a funcionalidad de
gestin), Enlaces de inters e Informacin (de Contacto) del Departamento.
Cada uno de estos nodos, donde el usuario interacta con el sistema, se corresponde con un contexto
navegacional. Los contextos navegacionales (estereotipados con la palabra reservada context) permiten
definir una vista sobre informacin y funcionalidad definida en el diagrama de clases. Pueden ser de dos
tipos:
-

de Exploracin (etiquetados con una E) representan nodos alcanzables desde cualquier otro nodo
(ver figura 3, contexto enlaces). Este tipo de contexto define unos enlaces de navegacin implcitos
(lneas discontinuas) que surgen del agente hasta el contexto. Uno de estos enlaces pueden marcarse
como default o home (con la etiqueta H), indicando que este contexto ser alcanzado directamente
cuando el usuario se conecte al sistema (contexto DSIC info de la figura 3).
de Secuencia (etiquetados con una S) aquellos que slo pueden alcanzarse a travs de un
determinado camino de navegacin.

En el diseo de aplicaciones Web complejas surge la necesidad de poder organizar o estructurar los
distintos contextos navegacionales que se hayan definido. Para ello introducimos una nueva primitiva, el
subsistema de navegacin. Los subsistemas de navegacin (estereotipados con la palabra reservada
subsystem) permiten realizar una agrupacin lgica de contextos navegacionales u otros subsistemas de

navegacin que estn estrechamente relacionados entre s y que comparten propiedades navegacionales (ver
figura 3, subsistemas departamento, docencia, directorio, investigacin e intranet). De la misma manera que
los contextos navegacionales, los subsistemas de navegacin pueden ser de dos tipos, de Exploracin o de
Secuencia, segn su alcanzabilidad.
Los enlaces navegacionales (arcos del grafo) representan la alcanzabilidad entre nodos navegacionales,
indicando los caminos navegacionales vlidos por el sistema para un determinado usuario. Las nuevas
caractersticas navegacionales detectadas al construir el portal web departamental nos han conducido a refinar
dicha primitiva. En concreto, ha sido necesario definirle una nueva propiedad, el cambio de rol (grficamente
representada mediante un actor UML sobre el enlace navegacional) , que nos permite modelar un cambio de
tipo de agente interactivo con el sistema para poder acceder al nodo destino. En la figura 3, para acceder a la
intranet, el usuario deber identificarse como tcnico, personal de administracin, becario o profesor.
Decimos que es necesario que se identifique ya que para acceder al subsistema intranet, debe cambiar a un
tipo de agente que en el diagrama de agentes se ha modelado como instanciable previa identificacin.

Internauta

<< context >>

<< context >>

<< context >>

PERSONAL

COLABORADORES

MAPA SEDE DSIC

S
<< context >>
TUTORAS

Figura 4. Estructura del subsistema directorio.

En la figura 4 se muestra el contenido del subsistema directorio. Este subsistema contiene tres contextos
de exploracin mediante los cuales se ofrece informacin sobre el personal del departamento (personal),
sobre colaboradores que estn actualmente trabajando en el departamento (colaboradores) y un mapa de la
distribucin de despachos en el edificio (mapa sede dsic). Adems, para los profesores del departamento es
posible consultar informacin sobre sus tutoras desde el contexto personal accediendo al contexto (de
secuencia) tutoras.
Una vez se ha definido la navegacin de cada uno de los agentes detectados, mediante sus respectivos mapas
navegacionales, el siguiente paso a realizar consiste en la definicin de los contextos navegacionales.
E

S
<< Context >>

<< Context >>

Personal
view
Miembro Departamento
-Fotografa
-Nombre Completo
-Correo Electrnico

Consultas y Tutoras

view
Profesor

[Tutoras]

Tutoras
view
Profesor
-Fotografa
-Nombre Completo

Asignatura
-Nombre

view
Despacho
-Cdigo
-Extensin

Tutora

ATTRIBUTE INDEX Letra_apellido

ATTRIBUTES Nombre, Apellidos, Correo
LINK-ATTRIBUTES Inicial_Ap
DISTINCT VALUES

FILTER Apellido
ATTRIBUTE Apellidos
TYPE APROXIMATE

Figura 5. Definicin contexto personal.

-Da
-Hora Inicio
-Hora Fin

Figura 6. Definicin contexto tutoras.

En las figuras 5 y 6 se observa la definicin de los contextos personal y tutoras respectivamente. En el

contexto personal se muestra informacin relativa a los miembros del departamento (fotografa, nombre y
correo electrnico) as como del despacho de cada uno (cdigo y extensin). Tambin se le permite al usuario
acceder al contexto tutoras donde podr consultar la informacin acerca de las tutoras del miembro del
departamento seleccionado (asignatura, da, hora inicio y fin).
Un contexto navegacional est compuesto por un conjunto de clases navegacionales, estereotipadas con
la palabra reservada view que hacen referencia a clases identificadas en el diagrama de clases. En el
ejemplo de la figura 5 se puede observar las clases navegacionales miembro departamento, despacho y
profesor. El contexto de la figura 6 esta compuesto por las clases profesor, asignatura y tutora. Con ellas se
puede definir la visibilidad (vista) ofertada al agente en este nodo, tanto de los atributos de la clase como de
los servicios que puede activar. En un contexto navegacional debe aparecer al menos una clase navegacional
principal, llamada clase directora (miembro departamento en el contexto de la figura 5 y profesor en el de la
figura 6) y opcionalmente otras que complementan la informacin de esta clase, llamadas clases
complementarias (clases despacho y profesor en la figura 5, asignatura y tutora en la figura 6). Las clases
navegacionales estn unidas entre s por relaciones binarias unidireccionales que pueden ser definidas sobre
una relacin de agregacin o de especializacin/generalizacin existente entre las dos clases en el diagrama de
clases2. Se pueden definir dos tipos de relaciones entre clases navegacionales: (1) relacin de dependencia
de contexto (se representa grficamente mediante flechas discontinuas) que indica una recuperacin de
informacin relacionada de las instancias de la clase complementaria a travs de la relacin de agregacin o
especializacin/generalizacin sobre la que est definida la relacin (relacin miembro departamentodespacho en la figura 5, profesor-asignatura, asignatura-tutora en la figura 6) y (2) relacin de contexto
(grficamente se representa mediante flechas continuas) es una relacin de dependencia de contexto que
adems define una navegacin a un contexto navegacional destino, causando la aparicin de un vnculo de
navegacin en el mapa navegacional asociado (relacin miembro departamento-profesor en la figura 5). Para
definir este tipo de relaciones es necesario indicar el contexto destino de la navegacin (atributo destino,
representado como [contexto destino]), qu elemento (un atributo de la clase directora o una simple cadena
de texto) se va a utilizar como ancla para activar la navegacin al contexto destino (atributo de enlace,
especificado en la parte superior de la relacin y el rol de la relacin de agregacin o herencia que estamos
utilizando (atributo de rol, representado como /rol/).
Usando las primitivas descritas anteriormente es posible especificar completamente los requisitos de
navegacin de las aplicaciones Web. Sin embargo, y debido al carcter de Internet, nos har falta especificar
algunas propiedades adicionales de diseo para facilitar el acceso a la informacin deseada. Estas propiedades
tienen que ver con la incorporacin de estructuras de acceso y la definicin de mecanismos de bsqueda de la
poblacin dentro de un contexto. Estas caractersticas se abordan a continuacin.
Diseo Navegacional Avanzado. Una vez construidos los mapas navegacionales se pueden definir
mecanismos adicionales que estructuren el acceso y permitan realizar bsquedas de informacin dentro de un
contexto navegacional. Ambos mecanismos permitirn explorar y facilitar el acceso a la misma informacin,
sin necesidad de implicar navegacin. Estas caractersticas se recogen en la zona de caractersticas
navegacionales avanzadas de un contexto de navegacin (ver zona inferior de la figura 5). Estos mecanismos
son los siguientes:
1.

Un ndice proporciona un acceso indexado (por alguna propiedad propia o de un objeto relacionado)
a los objetos principales del contexto (objetos de la clase directora). Los ndices crean una lista de
informacin resumida permitiendo al usuario elegir una instancia de la lista. Esta seleccin provoca
que el tem elegido se convierta en la instancia activa del contexto navegacional. En nuestra
aproximacin existen dos tipos de ndices: (1) ndices de atributos (ATRIBUTES-INDEX) que se
definen sobre uno o varios atributos de la clase directora y (2) ndices de relacin (RELATIONINDEX), que se definen sobre uno o varios atributos de una clase relacionada en el diagrama de
clases con la clase directora del contexto. En este caso, se crear un ndice con todos los valores de
atributos de los objetos de la clase relacionada. Si existe ms de una relacin entre la clase directora
y la clase del ndice ser necesario especificar un atributo de rol para eliminar la ambigedad. En
ambos tipos de ndices es necesario que al menos uno de los atributos sobre los que se define sea
especificado como atributo de enlace (atributo/s que servir/n para activar el ndice). Por otro lado,

No puede existir ninguna clase navegacional en un contexto que no est relacionada con ninguna otra clase navegacional.

se puede indicar que no aparezcan duplicados (DISTINCT VALUES) para que slo se recuperen los
valores distintos.
En la figura 5 se ha definido un ndice (letra_apellido) para obtener los miembros del departamento
cuyo primer apellido empiece por una letra especfica.
2.

Mecanismos de bsqueda, expresados como filtros de informacin. Estos filtros permiten restringir
el espacio de objetos de la clase directora recuperados en funcin de una condicin sobre alguna
propiedad de la clase directora u obtenida por una relacin entre clases. Esta expresin se puede
especificar en tiempo de modelado o puede ser introducida por el usuario en tiempo de ejecucin. Se
pueden definir tres tipos: exacto (devuelve el conjunto de instancias de la clase directora cuyo valor
de atributo coincida exactamente con el valor indicado), aproximado (devuelve el conjunto de
instancias de la clase directora cuyo valor de atributo sea semejante al valor indicado) y rango
(devuelve el conjunto de instancias de la clase directora cuyo valor de atributo est entre un par de
valores mximo y mnimo).

En la Figura 5 se ha definido un filtro aproximado para buscar miembros del departamento por los
apellidos. Como en el filtro no se ha definido una condicin de poblacin, la aplicacin deber pedir al
usuario que proporcione en tiempo de ejecucin un valor para el nombre del atributo.
3.2.3. Modelado de la Presentacin
Una vez definido el modelo de navegacin debemos especificar las caractersticas de presentacin del
sistema. Para este propsito se introduce el Modelo de Presentacin, que complementa la informacin
capturada en el modelo de navegacin para la creacin de interfaces Web con informacin de presentacin
(layout). Este modelo utiliza los nodos o contextos navegacionales como entidades bsicas para definir las
propiedades de presentacin de informacin.
La manera de especificar los requisitos de presentacin se basa en el uso de patrones de presentacin
simples que se podrn asociar a los distintos elementos que forman un nodo de navegacin. Existirn
propiedades de presentacin que podrn ser aplicadas a nivel de un contexto de navegacin, a nivel de
estructuras de acceso y/o mecanismos de bsquedas (filtros), y a relaciones (navegacionales) entre clases. Los
patrones de presentacin de informacin que se pueden especificar son:
1.

Paginacin de informacin. Este patrn permite capturar la semntica de scrolling lgico de

informacin. Cuando se especifica paginacin, el conjunto de instancias que deben ser presentadas
sern troceadas en bloques lgicos, de manera que slo uno de los bloques es visible al mismo
tiempo. Se proporcionarn mecanismos para avanzar y retroceder entre las distintas pginas lgicas
obtenidas. Sobre este patrn se podrn definir las siguientes propiedades: (1) Modo de acceso, cuyo
valor puede ser secuencial (proporciona acceso al siguiente, al anterior, al primero y al ltimo bloque
lgico) o aleatorio (proporciona al usuario la posibilidad de acceder directamente a cualquier bloque
lgico), (2) Cardinalidad, que puede ser esttica (cuando los bloques lgicos siempre tienen el
mismo nmero de objetos) o dinmica (cuando se permite al usuario modificar el nmero de objetos
de un bloque lgico en tiempo de ejecucin) y (3) Circularidad, que permite que el conjunto de
bloques lgicos se comporte como un buffer circular en el caso de que est activada. Esta
informacin de paginacin puede ser aplicada tanto a la clase directora como a una relacin
navegacional o un ndice o filtro.

2.

Ordenacin. Este patrn permite definir una ordenacin de la poblacin de una clase segn el valor
de uno o ms atributos sobre los que se aplica. La ordenacin puede ser: ascendente (asc) o
descendente (desc). Este patrn se puede aplicar a clases navegacionales, indicando cmo se van a
ordenar las instancias de la clase (los atributos sobre los que se ordene deben aparecer especificados
en el contexto) y a estructuras de ndices o filtros de bsqueda, ordenando los resultados obtenidos
por alguno/s de los atributo/s especificado/s por estos mecanismos.

3.

Presentacin de Instancias. Existen cuatro tipos: registro, tabular, maestro-detalle (pudiendo

indicar en ste ltimo caso cmo presentar el elemento detalle, recursivamente) y rbol. Se pueden
aplicar a la clase directora y a las relaciones de navegacin

<< Context >>

<< Context >>

Personal
<<view>>
Miembro Departamento

Tutoras

Pattern: Register

<<view>>
Profesor

Pattern: Register

<<view>>
Profesor
Pattern: Tabular

<<view>>
Asignatura
Pattern: Master-Detail

Pattern: Register

Pagination Info:
Cardinality: Static, 4
Sequential
<<view>>
Despacho
Pattern: Register

Pattern: Register

Pattern: Register

<<view>>
Tutora
Pattern: Register
ATTRIBUTE INDEX letra_apellido
Ordering: ASC

Figura 7. Presentacin del contexto personal.

Figura 8. Presentacin del contexto tutoras.

En la figura 7 se muestran los requisitos de presentacin especificados para el contexto navegacional

personal. Tanto a la clase directora (miembro departamento) como a las relaciones de navegacin y clases
complementarias se les ha especificado un patrn de tipo registro. Por otro lado en cada pantalla se
visualizar un bloque lgico formado siempre (cardinalidad esttica) por cuatro instancias. Para acceder a
los diferentes bloques lgicos se proporciona un acceso secuencial, es decir, se proporciona acceso al
primer bloque, al anterior, al siguiente y al ltimo. En la figura 8, se puede observar la presentacin
especificada para el contexto tutoras. En este caso se mostrar la informacin de la clase directora mediante
el patrn tabular. A la relacin profesor-asignatura se le aplicar un patrn maestro-detalle y al detalle, es
decir, a la clase complementaria asignatura, un patrn de registro. La relacin asignatura-tutora presentar
un patrn registro y por ltimo, la informacin de la clase complementaria tutora se mostrar mediante un
patrn registro.
Con estos patrones de presentacin de informacin, combinados con la informacin de navegacin
definida en el modelo de navegacin, podemos capturar los requisitos bsicos para la construccin de
interfaces del sistema Web. La informacin especificada se utilizar por el generador (compilador) para
generar las distintas interfaces para cada tipo de usuario, dentro de la arquitectura de aplicacin Web que
propone el mtodo OOWS.

4. Implementacin de aplicaciones Web a partir del modelo Conceptual

Para realizar la implementacin de aplicaciones Web a partir del modelo conceptual realizado,
proponemos una arquitectura de tres capas. Este tipo de arquitectura nos permite estructurar claramente las
aplicaciones Web facilitando la adaptabilidad y extensibilidad de las mismas y ofrece una mayor
escalabilidad. Es aconsejable utilizar este tipo de arquitectura en aplicaciones de gran tamao y con un gran
nmero de usuarios trabajando concurrentemente teniendo en consideracin la escalabilidad frente a los
requisitos de ejecucin. Las tres capas en las que se divide la arquitectura que proponemos se describen a
continuacin:
Capa de presentacin. Incluye la interfaz grfica de usuario (en este caso, pginas Web y
componentes visuales) para interactuar con el usuario (visualizando informacin, proporcionando
acceso a servicios y facilitando la navegacin).
Capa de aplicacin. Esta capa implementa la lgica de negocio y la funcionalidad de consulta.
Capa de persistencia. Esta capa implementa la persistencia y el acceso a datos ocultando a las
capas superiores detalles de los repositorios de informacin.
En este trabajo nos hemos centrado en presentar las extensiones de OO-Method (OOWS) que permiten
modelar requisitos de navegacin y presentacin. Estos requisitos influyen directamente en la implementacin
de la capa de presentacin, por ello vamos a centrarnos exclusivamente en cmo obtener esta capa a partir de
los modelos introducidos.

4.1. Implementacin de la capa de presentacin

Partiendo del modelo de navegacin, es posible obtener de forma sistemtica un esqueleto de una
aplicacin Web formado por un conjunto de pginas Web interconectadas entre s. Este conjunto de pginas
Web define la interfaz de usuario de la aplicacin Web para la navegacin, la visualizacin y el acceso a su
funcionalidad e informacin. Aadiendo a esta informacin la especificacin construida en el modelo de
presentacin podr definirse un modo de visualizacin de esta informacin. Para construir este conjunto de
pginas, se ha optado por utilizar HTML/CSS. El motivo principal de utilizar esta tecnologa ha sido la
flexibilidad que nos aportan las hojas de estilo CSS para cambiar caractersticas estticas de las aplicaciones
Web una vez construidas. A continuacin, se muestra como ejemplo la forma en la que se obtienen las
pginas Web para el tipo de usuario internauta.
Inicialmente se construye la pgina de inicio o Home (contexto DSIC_info). Esta pgina debe recuperar
informacin de contacto sobre el departamento. Adems, cada pgina deber proporcionar acceso a todos los
contextos y subsistemas de exploracin. La figura 9 muestra el aspecto de la pgina de inicio del portal Web
departamental.

Figura 9. Pgina de inicio del portal Web departamental.

A continuacin por cada contexto navegacional o subsistema definido en el mapa de navegacin se crea una
pgina Web. Para la construccin de las pginas Web, las dividimos en dos zonas lgicas:
- La zona de informacin presenta la vista del sistema definida por el contexto (la zona central derecha de
la pgina Web). En el caso de un subsistema slo aparecen los enlaces que dan acceso a los nodos
especificados en su estructura. La especificacin realizada en el modelo de presentacin es aplicada para
obtener el formato de esta zona de la siguiente forma: primero, se recuperan las instancias de la clase
directora especificando (si esta definido) el criterio de ordenacin y la informacin de paginacin. A
continuacin, esta informacin es mostrada segn su patrn de presentacin. Las instancias obtenidas a
partir de las relaciones navegacionales siguen la misma estrategia. Adems, para cada relacin de contexto
se implementa un enlace (utilizando el atributo de enlace como ancla) a la pgina Web que representa el
contexto destino.
- La zona navegacional proporciona la informacin navegacional al usuario: dnde se encuentra, como ha
llegado hasta all y donde puede ir. Para construir esta zona se debe proporcionar enlaces que apunten a
todas las pginas construidas a partir de contextos o subsistemas de exploracin. Adems los ndices y
mecanismos de bsqueda deben ser implementados en esta zona. En la zona superior de la pgina Web
debera tambin incluir informacin navegacional, mostrando dnde se encuentra actualmente el usuario.
Los subsistemas nicamente modelan una agrupacin lgica de contextos. Por tanto, las pginas
generadas a partir de ellos contendrn nicamente la implementacin de un men a partir del cual poder
acceder a cada uno de los contextos de exploracin contenidos en el subsistema. En el caso del subsistema
directorio se implementar una pgina que ofrezca al usuario la posibilidad de acceder a las pginas
correspondientes a los contextos personal, colaboradores y mapa sede dsic.
En la figura 10 se muestra las pginas que se implementan a partir de los contextos navegacionales
contenidos en el subsistema directorio.

Figura 10. Pginas generadas a partir del subsistema directorio.

Las pginas construidas a partir de los contextos navegacionales debern ofrecer al usuario la
informacin especificada en la definicin del contexto. La obtencin de esta informacin se realizar
mediante la funcionalidad de consulta de la capa de aplicacin. En la figura 11 se puede observar la pgina
construida a partir del contexto personal. En dicha pgina aparece la informacin sobre los miembros del
departamento.

Figura 11. Pgina Web del contexto personal.

La zona de informacin (ver seccin 1, figura 11) se implementa segn el modelo de presentacin:
Paginacin
- se muestran cuatro instancias (instancia en seccin 2) del miembro departamento (cardinalidad 4)
- el nmero de instancias, cuatro, no puede ser modificado por el usuario (cardinalidad esttica)
- con acceso al bloque lgico siguiente y anterior, adems de al primero y al ltimo (acceso
secuencial) (seccin 7).
Formato
El formato que se le da a la informacin, depende del patrn asignado a cada una de las primitivas que
definen el contexto. El proceso para darle formato a la informacin se describe a continuacin:
- aplicamos el patrn registro a los atributos de la clase directora
- aplicamos el patrn registro a la relacin navegacional miembro departamentodespacho
- aplicamos el patrn registro a los atributos de la clase cobertura despacho.
- se implementa el enlace producido por la relacin de contexto miembro departamento-profesor
(Consultas y Tutoras). Dicho enlace slo aparecer en aquellas instancias de la clase miembro

departamento que pertenezcan a la clase especializada profesor ya que son las nicas que pueden
navegar por la relacin de asociacin profesor-tutora (ver diagrama de clases de la figura 1).
En cuanto a la zona de navegacin (secciones 3,4,5 y 6), ha sido implementada de la siguiente forma:
- men navegacional (seccin 3) formado por todos los enlaces a los contextos o subsistemas de
exploracin (departamento, directorio, docencia, investigacin, intranet, enlaces, personal,
colaboradores y mapa sede dsic) en la parte izquierda de la pgina Web
- filtro de bsqueda (seccin 4) definido para encontrar a miembros del departamento por sus apellidos
tambin en la parte izquierda de la pgina Web
- los ndices que pueden ser activados (seccin 5) estn implementados tambin en la zona superiorderecha de la pgina
- el camino recorrido por el usuario (seccin 6) se especifica en la zona superior-derecha.
Cuando un usuario desde la pgina Web de la figura 11 seleccione el enlace Consultas y Tutoras
asociado a algn miembro del departamento alcanzar la pgina que se muestra en la figura 12 (contexto
tutoras ver figuras 6 y 8). Al seleccionar este enlace el usuario est activando la relacin de contexto
miembro departamento-profesor y provocando una navegacin con informacin contextual desde el contexto
personal al contexto tutoras. La informacin contextual que viaja de un contexto a otro corresponde con la
instancia del miembro departamento seleccionado. Una vez en el contexto destino, se mostrar la informacin
especificada en su definicin para la instancia que ha recibido.

Figura 12. Pgina Web del contexto tutoras.

En la pgina de esta figura, se muestra la fotografa y el nombre de una instancia de la clase profesor y la
informacin sobre las tutoras relacionada con esta instancia segn se ha especificado en la definicin del
contexto tutoras (ver figura 8). Para presentar esta informacin, primero se aplica el patrn de presentacin
tabular a los atributos de la clase directora. A continuacin a la relacin navegacional profesor asignatura
se le aplica un patrn maestro detalle, donde el maestro corresponde con la informacin de la clase directora
y el detalle con la informacin que recupera la clase complementaria asignatura. En enlace entre la
informacin del maestro y la aportada por el detalle se implementa mostrando el nombre que presenta la
relacin en el diagrama de clases (Asignaturas, ver relacin profesor-asignatura en la figura 1).
Seguidamente se muestra la informacin de la clase asignatura mediante un patrn registro. A continuacin
se le aplica un patrn registro a la relacin asignatura-tutora y por ltimo a los atributos de la clase
cobertura tutora se muestran mediante un patrn de presentacin registro.

5. Conclusiones y trabajos futuros

En este artculo hemos presentado una propuesta metodolgica para la construccin de aplicaciones Web
dentro un marco de trabajo OO en ambientes de compilacin automtica de modelos. Este marco definido
integra formalmente diferentes modelos para dar un soporte completo a la especificacin de este tipo de
sistemas software, adems de definir un proceso metodolgico guiado. El trabajo realizado ha consistido en
extender un mtodo formal existente OO (OO-Method), dotndolo de la expresividad necesaria para construir
soluciones Web. Esta expresividad ha sido capturada en: un Modelo de Navegacin que captura la estructura
navegacional asociada a cada usuario del sistema, proporcionando el acceso a la informacin, y a la

funcionalidad, permitiendo definir estructuras de acceso y mecanismos de bsqueda que faciliten el acceso a
la informacin deseada; un Modelo de Presentacin, que refleja las caractersticas esenciales de presentacin
de informacin de los nodos navegacionales mediante (unos pocos) patrones bsicos de presentacin.
Se han propuesto nuevas primitivas (subsistema, cambio de rol, tipos de agentes en diagrama de agentes,
etc.) y se han incorporado dentro del mtodo OOWS. Se ha aplicado el mtodo a un caso de estudio real, que
contina siendo desarrollado, siguiendo el proceso propuesto de construccin de un sistema Web.
Adicionalmente, se han realizado trabajos orientados a dar soporte a la introduccin de caractersticas de
personalizacin a nivel de modelado conceptual y la definicin de operadores conceptuales orientados al
reso conceptual. Los resultados de la aplicacin de un paradigma de programacin automtica de cdigo
(OOWS) han provocado que las continuas modificaciones en los requisitos del sistema se hallan realizado de
manera ms adecuada ya que slo ha sido necesario modificar la especificacin y generar el prototipo.
Actualmente se est rediseando la estrategia de generacin de cdigo para adaptarla a una arquitectura
software basada y orientada en servicios Web.

Reconocimientos. Este trabajo ha sido parcialmente subvencionado por el proyecto VII.18 WEST del programa
CYTEC, el proyecto MCYT con ref. TIC2001-3530-C02-01 y por la Universitat Politcnica de Valncia, Espaa.

Referencias
[1] Schwabe D., Rossi G. and Barbosa D.J. Systematic Hypermedia Application Design with OOHDM. Proc. ACM
Conference on Hypertext. pp.166. 1996.
[2] Ceri S., Fraternali P., Bongio A. Web Modeling Language (WebML): a Modeling Language for Designing Web Sites.
In WWW9, Vol. 33 (1-6), pp 137-157. Computer Networks, 2000.
[3] Muruguesan, S., Desphande, Y.: Web Engineering. Software Engineering and Web Application Development.
Springer LNCS Hot Topics (2001).
[4] Paolini P. and Fraternali P. A Model-Driven Development of Web Applications: the Autoweb System. ACM
Transactions on Office Information Systems, 2000, Vol. 18, Number 4.
[5] De Troyer O. and Leune C. WSDM: A user-centered design method for Web sites. In Proc. of the 7th International
World Wide Web Conference, 1997.
[6] Baresi L., Garzotto F., Paolini P. From Web Sites to Web Applications: New Issues for Conceptual Modeling. ER2000
Workshop on Conceptual Modeling and the Web, LNCS 1921. Springer-Verlag, 2000.
[7] Pastor O., Gmez J., Insfrn E. and Pelechano V. The OO-Method Approach for Information Systems Modelling:
From Object-Oriented Conceptual Modeling to Automated Programming. Information Systems. Elsevier Science. Vol.
26, pp 507-534, Number 7, 2001.
[8] Pastor O., Abrahao S., and Fons J. J. An Object-Oriented approach to automate web applications development. In 2nd
International Conference on Electronic Commerce and Web Technologies (EC-Web'01), Springer-Verlag, LNCS 2115.
ISBN: 3-540-42517-9. Munich, Germany, Septiembre, 2001
[9] Pastor O., Abrahao S., and Fons J. Building E-Commerce Applications from Object-Oriented Conceptual Models.
Newsletter of the ACM SIGecom Exchanges, volume 2.2,ACM Press, pp. 24-32. June, 2001
[10] Insfrn E., Pastor O., Wieringa R. Requirements Engineering-Based Conceptual Modelling. Requirements
Engineering (RE02). Springer-Verlag. ISSN: 0947-3602 (printed version) ISSN: 1433-010X (electronic version), pp.6172. March 2002.
[11] Fons, J., Valderas, P., Pastor, O. Specialization in Navigational Models. Argentine Conference on Computer Science
and Operacional Research. Subserie ICWE, Iberoamerican Conference on Web Engineering. Volume 31 of Anales JAIO.,
SantaFe, Argentina (2002) 16-31 ISSN: 1666-6526.
[12] Abrahao S., Fons J., Gonzalez M. and Pastor O. Conceptual Modeling of Personalized Web Aplications. In 2nd
International Conference on Adaptive Hipermedia and Adaptive Web Based Systems, Malaga, Spain, 2002.
[13] Object Management Group. Unified Modeling Language Specification Version 1.4 draft. Technical report,
www.omg.org, February 2001.
[14] Koch, N., Wirsing, M.: Software Engineering for Adpatative Hypermedia Applications. In: 3rd Workshop on
Adaptative Hypertext and Hypermedia (2001).