Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta (LSI-2002-01)

Departamento de Lenguajes y Sistemas Informáticos Escuela Técnica Superior de Ingeniería Informática Universidad de Sevilla Avda Reina Mercedes, s/n. 41012 SEVILLA Fax : 95 455 71 39. Tlf: 95 455 71 39. E-mail: [email protected] Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta Doctorando: María José Escalona Cuaresma Directores: Manuel Mejías Risoto Jesús Torres Valderrama Sevilla, Octubre de 2001 HOJA DE CONTROL DE MODIFICACIONES Número Fecha Descripción Autores 0 10-2001 Desarrollo Inicial M.J.Escalona Índice 1. INTRODUCCIÓN............................................................................................................................................1 2. PLANTEAMIENTO DEL PROBLEMA ..................................................................................................4 3. RELEVANCIA DEL PROBLEMA ............................................................................................................5 4. ASPECTOS RESUELTOS Y POR RESOLVER....................................................................................5 5. COMPARATIVA DE PROPUESTAS .......................................................................................................7 5.1. INTRODUCCIÓN.........................................................................................................................................7 5.2. EJEMPLO.....................................................................................................................................................8 5.3. ESTUDIO DE LAS DIFERENTES PROPUESTAS..........................................................................................9 5.3.1 HDM- A Model-Based Approach to Hypertext Aplication Design................................................9 5.3.2. RMM- Relationship Management Methogology...........................................................................12 5.3.3. EORM- Enhanced Object Relationship Methodology.................................................................15 5.3.4. The MacWeb Hypermedia Development Enviroment..................................................................18 5.3.5. OOHDM- Object-Oriented Hypermedia Design Method...........................................................19 5.3.6. WSDM- Web Site Design Method...................................................................................................28 5.3.7. OO-Method y OO-Hmethod.............................................................................................................32 5.3.8. SOHDM- Scenario-based Objecto-oriented Hypermedia Design Methodology....................34 5.3.9. RNA: Relationship-Navigational Analisys.....................................................................................38 5.3.10. HFPM: Hypermedia Flexible Process Modeling Strategy.........................................................39 5.3.11. OO/Pattern Approach.......................................................................................................................42 5.3.12. El Proceso Unificado........................................................................................................................43 5.3.13. Building Web Applications with UML............................................................................................48 5.3.14. Specification and modeling of multimedia and hypermedia systems........................................50 5.3.15. A UML-Based Methodology for Hypermedia Design..................................................................57 5.4.OTRAS PROPUESTAS........................................................................................................................................60 5.5. ESTUDIO COMPARATIVO................................................................................................................................61 6. PROYECTO DE INVESTIGACIÓN ...........................................................................................................66 6.1. INTRODUCCIÓN................................................................................................................................................66 6.2. BASES DE LA PROPUESTA...............................................................................................................................67 6.3. PROPUESTA METODOLOGÍCA PARA EL DESARROLLO DE SISTEMAS DE INFORMACIÓN GLOBAL..........68 6.3.1. Ciclo de Vida.........................................................................................................................................68 6.3.2. Especificación de requisitos...............................................................................................................69 6.3.3. Análisis...................................................................................................................................................82 6.3.4. Diseño.....................................................................................................................................................85 6.3.5. Implementación.....................................................................................................................................92 6.3.6. Pruebas..................................................................................................................................................92 6.4. ESTADO ACTUAL, PUNTOS ABIERTOS Y TRABAJOS PUBLICADOS.............................................................93 7. REVISIÓN BIBLIOGRÁFICA.......................................................................................................................96 8. FOROS RELACIONADOS............................................................................................................................100 Índice de Figuras FIGURA 1: ASPECTOS DE LOS SISTEMAS DE INFORMACIÓN GLOBAL............................................4 FIGURA 2: PROCESO DE TRABAJO....................................................................................................................6 FIGURA 3: RELACIONES DE LOS ELEMENTOS DE HDM .......................................................................10 FIGURA 4: EJEMPLO DE MODELO HDM........................................................................................................11 FIGURA 5: PRIMITIVAS DEL MODELO RMDM ...........................................................................................13 FIGURA 6: DIAGRAMA DE SLICES PARA EL EJEMPLO ..........................................................................14 FIGURA 7: EJEMPLO DE MODELO DE ANÁLISIS DE EORM..................................................................16 FIGURA 8: EJEMPLO DE MODELO DE DISEÑO DE EORM......................................................................17 FIGURA 9: DEFINICIÓN DE LA CLASE ENLACE........................................................................................22 FIGURA 10: EJEMPLO DE DIAGRAMA DE CLASES NAVEGACIONALES .........................................23 FIGURA 11: EJEMPLO DE DESCRIPCIÓN DE CLASES NAVEGACIONALES....................................23 FIGURA 12: EJEMPLO DE CONTEXTO NAVEGACIONAL...................................................................................24 FIGURA 13: EJEMPLO DE ADV..........................................................................................................................26 FIGURA 14: EJEMPLO DE DIAGRAMA DE CONFIGURACIÓN..............................................................26 FIGURA 15: ESQUEMA DE FASES DE WSDM...............................................................................................29 FIGURA 16: REPRESENTACIÓN GRÁFICA DE LOS CONCEPTOS DE NAVEGACIÓN..................30 FIGURA 17: PROCESO PARA OBTENER EL MODELO DE NAVEGACIÓN........................................31 FIGURA 18: EJEMPLO DE DISEÑO NAVEGACIONAL DE WSDM .........................................................31 FIGURA 19: ARQUITECTURA DE SOHDM.....................................................................................................34 FIGURA 20: EJEMPLO DE ESCENARIO...........................................................................................................36 FIGURA 21: EJEMPLO DE MODELO DE DISEÑO NAVEGACIONAL DE SOHDM ..........................37 FIGURA 22: EJEMPLO DE CASO DE USO.......................................................................................................42 FIGURA 23: CICLO DE VIDA DEL PROCESO UNIFICADO......................................................................44 FIGURA 24: FASES DEL PROCESO UNIFICADO..........................................................................................45 FIGURA 25: ITERACIONES DEL PROCESO UNIFICADO..........................................................................46 FIGURA 26: ICONOS PROPOPUESTOS POR CONALLEN .........................................................................50 FIGURA 27: SINTAXIS DE DEFINICIÓN DE NODOS ..................................................................................52 FIGURA 28: EJEMPLO DE DEFINICIÓN DE NODO.....................................................................................53 FIGURA 29: ESTEREOTIPOS PARA LOS DIAGRAMAS DE CONTEXTO.............................................54 FIGURA 30: EJEMPLO DE DIAGRAMA DE CONTEXTO...........................................................................55 FIGURA 31: ESTEREOTIPOS PARA LA INTERFAZ.....................................................................................56 FIGURA 32: RECOLECCIÓN DE REQUISITOS ..............................................................................................71 FIGURA 33: EJEMPLO DE CASO DE USO.......................................................................................................78 FIGURA 34: DIAGRAMA DE CLASES DE ANÁLISIS..................................................................................83 FIGURA 35: DIAGRAMA DE ESTADOS PARA LOS BIENES MUEBLES ..............................................84 FIGURA 36: EJEMPLO DE PROTOTIPO DE INTERFAZ..............................................................................85 FIGURA 37: DIVISIÓN EN SUBSISTEMAS PARA EL EJEMPLO .............................................................88 Índice de Tablas TABLA 1: RESUMEN DE LAS PROPUESTAS...................................................................................................8 TABLA 2: FASE DE DISEÑO CONCEPTUAL DE OOHDM.........................................................................21 TABLA 3: FASE DE DISEÑO NAVEGACIONAL DE OOHDM...................................................................25 TABLA 4: FASE DE DISEÑO DE INTERFAZ ABSTRACTO DE OOHDM ..............................................27 TABLA 5: FASE DE IMPLEMENTACIÓN DE OOHDM................................................................................27 TABLA 6: ESTRUCTURA DE LA LISTA DE EVENTOS..............................................................................35 TABLA 7: EJEMPLO DE LISTA DE EVENTOS...............................................................................................35 TABLA 7: FASES RECOGIDAS EN CADA PROPUESTA ............................................................................63 TABLA 8: TÉCNICAS Y MODELOS USADOS EN LAS METODOLOGÍAS...........................................64 TABLA 9: RESUMEN DE ASPECTOS................................................................................................................65 TABLA 10: RESUMEN DE LA PROPUESTA METODOLÓGICA ..............................................................69 TABLA 11: EJEMPLO DE OBJETIVO DEL SISTEMA ..................................................................................72 TABLA 12: EJEMPLO DE REQUISITO DE ALMACENAMIENTO DE INFORMACIÓN....................73 TABLA 13: EJEMPLO DE DESCRIPCIÓN DE NATURALEZA ..................................................................74 TABLA 14: EJEMPLO DE DESCRIPCIÓN DE UN ACTOR BÁSICO ........................................................75 TABLA 15: DEFINICIÓN DE LA DISJUNCIÓN ENTRE ACTORES BÁSICOS......................................76 TABLA 16: ACTORES DERIVADOS ..................................................................................................................77 TABLA 17: EJEMPLO DE PATRÓN PARA UN CASO DE USO.................................................................78 TABLA 18: PATRÓN PARA LA RECOLECCIÓN DE PROTOTIPO DE VISUALIZACIÓN................80 TABLA 19: EJEMPLO DE ESTRUCTURA CONDICIONAL........................................................................81 TABLA 20: EJEMPLO DE REQUISITO NO FUNCIONAL............................................................................81 Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 1 1. Introducción Hoy en día las aplicaciones que se desarrollan son muy diferentes a las que se desarrollaban hace unos años. El desarrollo de las comunicaciones y la gran difusión de Internet han creado nuevas necesidades dentro de los sistemas software. En este sentido, muchas definiciones de sistemas se están dando dentro del mundo de la ingeniería del software: sistemas multimedia, sistemas hipermedia, aplicaciones web, sistemas de información global, etc. Este trabajo es el resultado de la investigación que se ha llevado a cabo para estudiar una posible metodología para el desarrollo de sistemas de información global. En él se hace un recorrido de todas las opciones que se están aplicando en este ámbito y se presenta los primeros inicios de una nueva propuesta que actualmente se está elaborando. Sin embargo, antes de comenzar a plantear el problema que nos va a ocupar el contenido de este trabajo, es necesario enmarcar el entorno de trabajo en el que nos vamos a mover. Para ello, es necesario hacer una serie de definiciones previas. Desde que el desarrollo de aplicaciones informáticas se empezó a considerar un proceso de ingeniería, muchas metodologías de desarrollo han ido naciendo con el fin de dar soporte al ciclo de desarrollo del proyecto. Entre estas, podemos destacar algunas como MÉTRICA, MERISE, SSADM y ya más recientes como OMT o el actual UML. Todos estas metodologías estaban orientadas desde sus comienzos al desarrollo sistemas para gestionar una información que se encuentra almacenada en una o varias bases de datos, distribuidas o no. Entre los aspectos que se tratan como más críticos en estas metodologías, los más importante son el almacenamiento y la recuperación adecuada de la información, así como que las posibilidades funcionales que ofrezcan sean las necesarias. Otro término que comienza a nacer es el de las aplicaciones multimedia. Mientras que las metodologías anteriores tratan con especial interés los aspectos de almacenamiento y funcionalidad, en las aplicaciones multimedia el objetivo esencial va a ser difundir información almacenada en diferentes medios (imágenes, vídeos, música, etc.) de manera que llegue al público no experto en informática de una forma sencilla, fácil e intuitiva. Son aplicaciones que nos preocupan tanto por las necesidades de almacenamiento, puesto que en muchos casos no tienen ni bases de datos asociadas, y la funcionalidad, como por la apariencia y el interfaz del sistema. El desarrollo de estos sistemas comienzan a realizarse sin que haya ninguna norma que se pueda tomar como marco de referencia para su desarrollo. Sin embargo, a principios de los 90, se comienza a estudiar la necesidad de una metodología que guíe a los desarrolladores y que asegure la calidad de los productos multimedia generados. Por esta razón, desde el año 93 comienzan a publicarse propuestas metodológicas y nuevos modelos para representar la problemática de estas aplicaciones: HDM [Garzoto 1993], RMM [Isakowitz 1995], EORM [Lange 1995], OOHDM [Rossi 1996], etc. Junto con todo esto, Internet va tomando cada vez más popularidad. Hoy en día Internet supone un excelente medio para obtener información de los más variados temas sin necesidad de movernos de casa. Internet nos permite, a través de interfaces sencillas, intuitivas y amigables, hacer desde una consulta a la cartelera de cine hasta comprar acciones en nuestra entidad bancaria. Sin embargo, esto no siempre ha sido así. En sus comienzos la Web nació como una red que conectaba a varias redes privadas, públicas y Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 2 de centros de investigación, con el objetivo de compartir información entre grupos de investigación localizados en diversos lugares. Cuando la red de redes comenzó a tomar popularidad, las páginas que se mostraban en los servidores de las organizaciones eran páginas estáticas que podríamos describir como documentos mostrados a través de Internet. Sin embargo, poco a poco y, a medida que va aumentando la popularidad de la red, las empresas y organizaciones comienzan a requerir que sus páginas tengan un cierto dinamismo que las haga más atractivas para el usuario. Este dinamismo, se introduce haciendo que las páginas sean cada vez más interactivas, permitiendo que el usuario no solo sea un sujeto pasivo en la página, sino que, comienza a interactuar mandando datos al servidor remoto y recibiendo respuestas de este. Poco a poco Internet adquiere popularidad y las organizaciones ven en ella una posibilidad de publicidad efectiva y de facilitar la comunicación con sus clientes. Comienza así la necesidad de incluir bases de datos y grandes volúmenes de información en la red. A finales de los 90, las páginas Web han dejado de ser páginas documentales puramente estáticas para dejar paso a páginas interactivas, en las que se incluye información en múltiples medios y con las que el usuario puede interactuar. En estas páginas se han unido los conceptos de hipertexto con los múltiples medios, dando origen a lo que se conoce como hipermedia. Además, la nueva generación de páginas Web está dotada de una gran funcionalidad. Ya no tenemos páginas que muestran y recogen datos, lo que actualmente se tiende a mostrar por Internet son complejas aplicaciones con grandes requisitos de almacenamiento y funcionalidad, acompañado de un complejo y llamativo interfaz, que engloba información en múltiple medios y enlaces no solo entre datos textuales, sino que, permite también enlaces entre datos multimedia. Son los llamados sistemas de información web, que están dando origen a complejos portales que se están ganando la atención del público actual. Debido a este gran avance y promovidos por las mismas inquietudes de otros entornos, desde el año 98 están empezando a nacer metodologías que van orientadas a la web y al desarrollo de estos sistemas de información. Las metodologías para la web nacen en la mayoría de los casos de otra metodología anterior, bien de una metodología clásica, como el caso de Conallen [Conallen 1999], basada en el Proceso Unificado y UML; o bien de una metodología para aplicaciones multimedia, como el caso de los nuevos desarrollos de OOHDM [Schwabe 2001]. Otro término importante que aparece también hoy en día es el concepto de biblioteca digital. Una biblioteca digital (BiDi) es una biblioteca que ha sido extendida y mejorada mediante la aplicación de la tecnología digital. Es la unión de ordenadores, sistemas de almacenamiento y redes de comunicaciones con el contenido y el software necesario para reproducir, emular y extender los servicios proporcionados por las bibliotecas convencionales. Una biblioteca digital debe cumplir todas las tareas de una biblioteca convencional y explotar las ventajas de la tecnología digital en el almacenamiento, la búsqueda y las comunicaciones, además de la integración de nuevos tipos de medios (textos, imágenes, sonidos, vídeos, animaciones, etc). La biblioteca digital proporciona a una comunidad de usuarios un acceso coherente a repositorios de información grandes y organizados. Las bibliotecas digitales son construidas (recogiendo y organizando la información) por una comunidad de usuarios y sus funcionalidades son acordes a las necesidades de información de dicha comunidad. Las posibilidades de los usuarios para acceder, reorganizar y utilizar este repositorio están Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 3 enriquecidas con las capacidades de la tecnología digital. También han aparecido propuestas para el desarrollo de aplicaciones basadas en BiDi [Escalona 2000a]. Como resumen a esto, podríamos decir que durante los últimos años han venido naciendo diferentes metodologías que se mueven en entornos concretos dando más importancia a los aspectos más importantes de los sistemas que tratan. En la multimedia, el tratamiento de los múltiples medios y el entorno visual es esencial, de ahí que las metodologías de la multimedia se centren en estos aspectos. Las metodologías de la web, van a estar más orientadas a aspectos de navegación y arquitecturas. Mientras que el resto de las metodologías más generales, el Proceso Unificado, OMT, etc. van a centrarse más en aspectos como el almacenamiento de la información y la funcionalidad. En la actualidad, las aplicaciones se desarrollan normalmente en entornos distribuidos, es muy común el que se distribuyan por internet y normalmente tienen asociados elementos multimedia e hypermedia en grandes bases de datos. Se caracterizan por tener grandes requisitos funcionales y de seguridad, múltiples usuarios y en muchos casos indefinidos y con diferentes grados de conocimiento. Estas aplicaciones se conocen como sistemas de información global, y son, por decirlo de alguna manera, un concepto mucho más genérico que engloba a las aplicaciones que se encuentran en los otros grupos. El sistema de información global puede verse como si fuera una aplicación multimedia, puesto que normalmente maneja información almacenado en múltiples medios. Pero cuando se distribuye a través de internet, se podría ver como un sistema de información web. Sin embargo, ninguna de las metodologías de estos ámbitos sería adecuada, puesto que no tratan los aspectos de almacenamiento y funcionalidad de manera adecuada, que en los sistemas de información web suelen ser bastante críticos. Los sistemas de información global almacenan grandes cantidades de información y requieren sistemas de seguridad muy potentes, así como una funcionalidad muy elaborada que asegure que los usuarios van a poder trabajar con esta información de manera adecuada. Para tratar estos aspectos, metodologías como el Proceso Unificado podrían ser un buen marco de referencia para su desarrollo. Por otro lado, y cuando su medio de transmisión es la web, cosa que suele ser muy común, el sistema de información global adquiere todas las características de un sistema de información en la web. Normalmente, estos sistemas deben tener una interfaz intuitiva y amigable que hacen uso de la multimedia para llegar más fácilmente al usuario. Así un sistema de información global podría verse como una aplicación multimedia. Pero además si analizamos la definición de biblioteca digital, ¿no podríamos decir que un sistema basado en bibliotecas digitales es un sistema de información global?. Por ser el sistema de información global el más genérico, este trabajo se mueve en este entorno. Aquí vamos a estudiar las propuestas metodológicas definidas para sistemas multimedia, sistemas de información web, etc. Con el fin de encontrar modelos e ideas consensuadas que nos permitan desarrollar una metodología para el desarrollo de los sistemas de información global. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 4 2. Planteamiento del problema Ya hemos analizado en el ámbito que nos vamos a mover: los sistemas de información global. El problema que se plantea resolver es el de elaborar un marco metodológico para el desarrollo de este tipo de sistemas. Para ello, antes es necesario estudiar qué debe ofrecer una metodología para el desarrollo de sistemas de información global. Un sistema de información global posee, como ya se ha comentado, grandes bases de información, importantes y complejos requisitos funcionales y deben ser seguras y eficaces. Debe permitir el trabajar con la información multimedia y ofrecer una interfaz amigable y adaptada al usuario, por la que sea fácil navegar1, como los sistemas multimedia. Pero, además, un sistema de información puede desarrollarse en muchos entornos arquitectónicos diferentes: la web, bases de datos federadas, etc. Una metodología para el desarrollo de sistemas de información global, debe ofrecer las herramientas y técnicas suficientes como para cubrir todos esos aspectos que se pueden encontrar en un sistema de este tipo. Así, en la figura 1 encontramos un esquema con las características que debe contemplar y estudiar el proceso metodológico de la propuesta. FIGURA 1: ASPECTOS DE LOS SISTEMAS DE INFORMACIÓN GLOBAL Pero, ¿qué debe ofrecer la metodología?. En el apartado 5 de este trabajo, se analizarán diferentes propuestas metodológicas para diferentes entornos. Ninguna de ellas va a adecuarse al cien por cien a los sistemas de información global, principalmente porque están orientados a un tipo de sistema concreto. Pero otro problema que vamos a observar muy a menudo es que estas metodologías están agrupadas en tres grandes grupos: ?? Las orientadas al proceso, indican qué secuencia de pasos hay que seguir para el desarrollo del sistema. 1 El concepto de navegación es más genérico que el propio de internet. Navegación en el entorno de los sistemas de información global se refiere a la posibilidad de manejar el cambio de pantallas del sistema. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 11 ??Enlaces de aplicación, sirven para conectar componentes y unidades. Son los más complejos de los tres pues pueden conectar elementos de unidades diferentes. Los enlaces de aplicación se organizan en tipos de enlace de aplicación o simplemente tipos de enlace. Los tipos de enlaces se caracterizan por un nombre, un conjunto de fuentes, que indica de dónde puede partirse en la navegación, y un destino, que indica hacia dónde va el enlace. Por último tiene un atributo especial que puede tomar los valores simétrico o asimétrico, para indicar si el enlace es en un único sentido o no. Como cualquier otro modelo de diseño, HDM distingue entre el concepto de esquema y de instancia del esquema. El esquema define la estructura general de la aplicación y la instancia son las unidades, perspectivas y enlaces concretos que cumplan con los requisitos establecidos en el modelo. En una aplicación multimedia es necesario plantearse, además, lo que HDM define como semántica de navegación. La semántica de navegación representa cómo se va a mostrar la información al usuario. Para ello, HDM define una semántica de navegación por defecto. En ésta se asume que al usuario se le muestra la información mediante nodos o unidades de forma que sólo un nodo está activo en cada momento. Asumiendo esta idea, los usuarios sólo serán conscientes de los enlaces que denominamos de perspectiva. Por ello, es necesario que todas las posibilidades de navegación que se quieran representar en HDM deben estar traducidos a este tipo de enlaces. En nuestro ejemplo, tendríamos una única entidad: el bien mueble. Esta entidad , al ser sencilla no tendrá componentes diferentes, pero sí unidades y perspectivas. En principio tendrá dos unidades: una que son los datos de identificación y otra que tendrá los datos de descripción. Estas unidades pueden tener diferentes perspectivas. En el modelo ejemplo que se muestra en la figura 4, hemos resaltado dos perspectivas de la unidad de descripción: una para los arqueólogos, que no incluiría a los autores, ni la fecha ni la certeza, y otra para el resto de los actores. En la figura se muestra además un enlace entre la unidad de identificación y la de descripción. Este es un enlace de perspectiva que nos indica que entre estas unidades se puede navegar. Se han omitido los atributos de las entidades para simplificar el dibujo. FIGURA 4: EJEMPLO DE MODELO HDM Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 12 2.Conclusiones Como puntos destacables de HDM se puede resaltar el hecho de que es el primer acercamiento a plantear el desarrollo de las aplicaciones multimedia de una manera formal. Fue el pionero en plantear el modelado las aplicaciones multimedia de manera que se estudiaran y diseñaran aspectos tan importantes como la navegación. En esta técnica se ve la necesidad de separar la información que se almacena, entidad, con la forma en la que se presenta al usuario, perspectiva. Esta idea la vamos a encontrar en la mayoría de las propuestas que veremos, pues resulta muy conveniente a la hora de trabajar con aplicaciones multimedia, y como veremos en el apartado 6, con sistemas de información global. Sin embargo, HDM no supone una metodología para el desarrollo de aplicaciones multimedia, es simplemente una técnica de modelado. Es cierto que los elementos definidos por HDM (entidades, perspectivas, enlaces, unidades, etc.) sirven para definir este tipo de aplicaciones, pero resultan insuficientes para guiar al diseñador en el proceso de desarrollo de las mismas. Otro problema esencial que se puede resaltar en HDM es que ha quedado un poco obsoleta, en el sentido de que actualmente las tendencias de diseño están encaminadas hacia el paradigma de la orientación a objetos. En base a este problema, de HDM han surgido nuevas propuestas como EORM u OOHDM, que asumiendo sus conceptos y objetivos, definen una metodología orientada objeto para el diseño de aplicaciones multimedia. Pero un aspecto que se echa en falta en un modelo de HDM es que no trata los aspectos de interfaz y de múltiples medios de una manera concreta. HDM asume que estos aspectos se tratarán en un nivel más bajo de desarrollo. En resumen, HDM va a sentar las bases para futuras propuestas de desarrollo, ofreciendo ideas como la separación de lo conceptual, información que se almacena, y de la presentación, información que se presenta. Es además el primer intento de normalizar el desarrollo de aplicaciones multimedia pero queda muy lejos de ser una propuesta metodológica para el desarrollo de sistemas de información global. 5.3.2. RMM- Relationship Management Methogology RMM es propuesta en 1995 por Tomas Izsakowitz, Arnold Kamis y Marios Kounfaris [Isakowitz 1995]. Se puede considerar una metodología pues asume las etapas de análisis y diseño. RMM propone un proceso basado en 7 fases o etapas en las que el diseñador va modelando la estructura de la aplicación y las posibilidades de navegación de la misma. La propuesta está basada en el modelo Entidad-Relación y en HDM. Partiendo de ellos define un nuevo modelo el RMDM, que propone un lenguaje que permitirá describir los objetos del dominio, sus interrelaciones y los mecanismos de navegación hipermedia de la aplicación. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 13 1.Conceptos básicos de RMM RMM asume las extensiones que HDM incluye en los clásicos E-R y añade un nuevo concepto que denomina slice. Un slice es un subconjunto de atributos de una entidad que van a ser presentados de forma agrupada al usuario. De esta forma, una aplicación estará formada por entidades cuyos atributos son agrupados en slices. En la figura 5 vemos cómo se representan los slices. Por otro lado, es necesario representar los enlaces. Aunque RMM toma a HDM como base, define sus propios enlaces y los divide en varios grupos: ??Enlaces no condicionales, pueden ser unidireccionales o bidireccionales. Serían los enlaces en los que al partir del origen se pasa al destino sin necesidad de que el usuario indique ninguna condición. ??Enlaces condicionales, en ellos el usuario tiene que indicar alguna condición específica. Dependiendo de dicha condición el usuario irá a un slice u otro. ??Rutas guiadas, se activan automáticamente ante un evento o pasado un tiempo, el usuario no debe hacer nada. Existe la posibilidad de mezclar varios de estos enlaces. Por ejemplo, podemos optar por varias rutas guiadas dependiendo de las condiciones que introduzca el usuario. En la figura 5 se muestra cómo representarían en el modelo Entidad-Relación estos conceptos. FIGURA 5: PRIMITIVAS DEL MODELO RMDM Basándose en todas estas ideas, en RMM se representa la aplicación mediante un modelo, denominado RMDM (Relationship Management Data Model). Este modelo es un enriquecimiento del modelo Entidad-Relación y permitirá representar a las aplicaciones multimedia. En este modelo podemos encontrar elementos propios de la propuesta del modelo Entidad-Relación (entidades, atributos, etc.) aunque con las extensiones de HDM y los nuevos conceptos definidos anteriormente (enlaces, rutas guiadas, slice, etc). En la figura 5 se pueden ver todos los iconos que se pueden encontrar en un modelo RMDM. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 14 2.Fases de RMM Como ya se ha comentado, RMM propone un proceso dividido en etapas para el desarrollo de las aplicaciones multimedia. En este apartado se verán muy brevemente estas fases y sus objetivos. Fase 1- Realizar el modelo E-R En esta fase se debe obtener un modelo Entidad-Relación del sistema, sin necesidad de entrar en detalles de navegación o de presentación al usuario. Se debe actuar de la misma forma que se actuaría para obtener un modelo E-R de una aplicación software clásica. Fase 2- Realizar los diseños de slice Para cada entidad detectada en la fase anterior, se debe definir un diagrama de slices. Esto es, se deben detectar los slices para esa entidad, es decir, cómo se van a presentar los atributos de la entidad al usuario. Se debe obtener un modelo compuesto por slices y enlaces (ya sean guiados, direccionales, etc), mediante la representación que se mostró en la figura 5. Así para nuestro ejemplo, habría una entidad que sería el bien mueble, que tendría asociados dos slices: uno para los datos de identificación (código, denominación, acceso, observaciones, ubicación habitual, ubicación temporal) y otro para los datos de descripción (tipologías, estilos, autores, períodos históricos, imágenes, cronología y certeza). Del slice de descripción partiría un enlace unidireccional al slice de identificación, lo que significa que se podrá navegar directamente. Desde el slice de identificación al de descripción lo que nace es un enlace condicional pues el usuario tendrá que indicar si es o no arqueólogo para navegar a dicho slice. En la figura 6 vemos el modelo para nuestro ejemplo. Nuevamente se han omitido los atributos para hacer más sencilla la figura. FIGURA 6: DIAGRAMA DE SLICES PARA EL EJEMPLO Con esta representación, la descripción del sistema no queda claro. Sería necesario acompañarlo por un diccionario de datos que indicara qué contiene cada slice y cuál es la condición del enlace condicional. En principio el formato de este diccionario quedaría a elección del grupo de trabajo. Fase 3- Diseñar la navegación Una vez que ya se han definido los slices, se debe diseñar cómo se pasará de una entidad a otra, es decir, hay que enriquecer el modelo Entidad-Relación obtenido en la primera fase con los enlaces entre entidades. En principio en nuestro modelo no sería necesario al tener una única entidad. El modelo RMDM de la aplicación será la unión del resultado de la fase 3 y de la fase 2. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 15 Fase 4- Definir el protocolo de conversión En esta fase se debe definir el proceso a seguir para pasar del modelo RMDM a la plataforma de desarrollo concreta. En principio no se propone ninguna técnica estándar a seguir para ello. Fase 5- Diseñar la interfaz En esta fase se diseñan las pantallas tal y como se van a mostrar al usuario. Por regla general cada slice se va a corresponder con una pantalla. En esta fase ya es necesario entrar en aspectos concretos del lenguaje de programación que se va a usar. Fase 6- Implementar la aplicación En base al protocolo establecido en la fase 4 y al modelo RMDM obtenido, se implementa el sistema. Fase 7- Probar la aplicación Una vez que se obtiene la aplicación ejecutable, se deben realizar las pruebas de funcionamiento a la misma. Para ello es necesario definir el test de prueba y estudiar sus resultados. Aunque EORM no ofrece ninguna técnica concreta a seguir para ello. 3.Conclusiones RMM sube un paso más con respecto a HDM. Propone una metodología basada en el modelo E-R y en HDM para representar las aplicaciones multimedia. Debido a esto es precisamente por lo que no ha tenido demasiada difusión. Es una técnica que se basa en el E-R cuando en su época (1995) todas las tendencias se dirigían a la orientación a objetos. Algo ventajoso y que hace interesante a RMM es que propone un proceso estructurado y definido a seguir para el desarrollo de estas aplicaciones. En este proceso, sin embargo, se echan en falta las primeras etapas a tener en cuenta en cualquier proceso de desarrollo software, como la captura de requisitos. Además, el proceso que ofrece es demasiado abierto en sus fases como para considerarse como una herramienta de desarrollo adecuada, puesto que en la única fase en la que indica una técnica es en la que se hace uso del modelo RMDM (fase 2). Las otras fases quedan abiertas a la opción del diseñador. 5.3.3. EORM- Enhanced Object Relationship Methodology 1.Conceptos básicos de EORM Al igual que OOHDM, que veremos más adelante, EORM [Lange 1995] es una de las metodologías de diseño de aplicaciones multimedia más referenciadas en todos los trabajos. Nace igualmente a partir de RMM y HDM pero se orienta ya al paradigma de la orientación a objetos. EORM propone un proceso iterativo que consiste en enriquecer un modelo de objetos para representar las relaciones existentes entre objetos (enlaces). Se estructura en tres fases: análisis, diseño y construcción. Veamos qué objetivos tienen cada una de ellas. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 16 2. Fases de EORM Fase 1- Análisis Realmente esta fase no puede denominarse análisis. Se correspondería más a un diseño de objetos, hablando en términos de OMT [Rumbaugh 1995]. Consiste en hacer un modelo orientado a objetos, según las pautas y nomenclatura de OMT para representar la aplicación. La nomenclatura de OMT no vamos a verla en este trabajo. OMT es una metodología de diseño clásico que ha servido como base para UML [Booch 1999] y el Proceso Unificado [Jacobson 1999]. Se ha obviado de este trabajo puesto que todo lo que enunciaba ha quedado obsoleto o ha sido asumido por UML, que es el que actualmente se utiliza. Sin embargo, las propuestas de OMT no sólo han sido tomadas para UML sino también para otras metodologías como EORM u OOHDM, como ya veremos. A pesar de que OMT ha sido la base de EORM y OOHDM, en las últimas versiones de estos se ha asumido la nomenclatura de UML y esta es la que vamos a usar en nuestro ejemplo. En esta primera etapa de análisis de EORM no se tendrán en cuenta aspectos como la navegación o la interfaz, dejándose ambas para etapas posteriores. En nuestro ejemplo, tendríamos un modelo de clases bastante sencillo. Lo vemos en la figura 7. Vemos que los datos de tipologías, imagenes, estilos, períodos y autores se modelan como clases que se relacionan con una clase principal BienMueble. FIGURA 7: EJEMPLO DE MODELO DE ANÁLISIS DE EORM Fase 2- Diseño Durante el diseño se procede a modificar el modelo de objetos obtenido en la fase anterior añadiendo semántica suficiente a las relaciones para representar los enlaces. Este modelo de objetos enriquecido se denomina EORM y en él se van a reflejar tanto la estructura de la información (modelo abstracto hipermedial compuesto por nodos y enlaces) como las posibilidades de navegación ofrecidas por el sistema. Para recoger esto último, existirá un repositorio o librería de clases de enlaces, donde se especificarán las posibles operaciones asociadas a cada enlace de un hiperdocumento. Estas operaciones serán del tipo crear, eliminar, siguiente, etc. Pero además en estas librerías Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 17 se recogerán los atributos del enlace: fecha de creación, forma de presentación en la pantalla, etc. Para estas librerías los autores de EORM dan una serie de tipos de enlaces ya predefinidos. A continuación se describen de forma sencilla. ??simpleLink: es un enlace dentro del mismo documento o la misma página. ??navigationalLink: es un mecanismo que representa un hiperenlace. Esta clase posee una función de backtracking que permite volver a la página origen. ??nodeToNode: es un enlace que une dos clases del modelo. ??spanToNode: este enlace une el contenido de un objeto con otro objeto. ??structureLink: es un conjunto de enlaces simples, por ejemplo, representa un menú. ??setLink: es un structureLink que da acceso a una colección de objetos sin importar el orden. ??listLink: es un structureLink que da acceso a una colección de objetos según un determinado orden. Así en nuestro ejemplo se definirían dos nodos: uno para los datos de descripción y otro para los datos de identificación. Entre ellos, habrá un enlace del tipo nodeToNode. Además las clases de tipología, autor, imagen, estilos y períodos históricos pasarán a tratarse como nodos y entre ellas y el nodo de descripción, existirán enlaces de tipo setLink, pues referenciará a lista no ordenadas de objetos de estas clases. Vemos cómo quedaría este modelo para el ejemplo en la figura 8. FIGURA 8: EJEMPLO DE MODELO DE DISEÑO DE EORM Fase 3- Construcción En esta fase se prepararía el código fuente para cada una de las clases y la interfaz gráfica de usuarios. No se da ninguna recomendación especial para ello. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 18 3. Conclusiones EORM es, como hemos visto, una metodología sencilla, que asume la orientación a objetos como paradigma para el desarrollo de aplicaciones multimedia. Con ello garantiza todas las ventajas que la orientación a objetos ofrece, pero además aumenta las posibilidades de reutilización en las aplicaciones, gracias a la definición del repositorio o librerías de clases enlace. EORM también es adecuada porque, siguiendo la idea inicial de HDM, separa la navegación de lo conceptual. Esto garantiza la reutilización y un mantenimiento más fácil. Si hay un cambio en la navegación, lo conceptual no se modifica. Por otro lado, la aplicación de la metodología EORM puede resultar bastante sencilla gracias al uso de ODMTool, una herramienta desarrollada por el propio autor de EORM. Esta herramienta se usa de forma conjunta con el generador comercial de interfaces gráficas de usuario, ONTOS Studio y con un sistema gestor de base de datos orientado a objetos, de manera que se permite el diseño interactivo de esquemas EORM y la generación automática de código, inicialmente en C++. A pesar de todas estas ventajas, a EORM se le pueden hacer ciertas críticas. Por un lado, el proceso metodológico que propone resulta insuficiente en muchos casos principalmente porque solo trata de manera específica los aspectos de almacenamiento y navegación, dejando a un lado temas como la funcionalidad del sistema o los aspectos de interfaz. Además, en ningún momento comenta las técnicas a seguir para obtener los modelos que propone o los productos que se deben generar en el desarrollo. EORM también deja a un lado un aspecto muy importante en la mayoría de las aplicaciones: la captura de requisitos. No sólo no ofrece ninguna propuesta sino que no indica ninguna que se pueda usar. En conclusión, EORM es la primera propuesta orientada a objetos. Es necesario tenerla en cuenta a la hora de realizar una propuesta por las ideas que ofrece y por los modelos que plantea, que resultan muy adecuados para representar la navegación y lo conceptual. Pero deja a un lado aspectos que son críticos en el ciclo de desarrollo. 5.3.4.The MacWeb Hypermedia Development Enviroment 1. Conceptos básicos de MacWeb Hypermedia Developement Enviroment El entorno de desarrollo hipermedia, MacWeb, propuesto por los hermanos Nanard en 1995 [Nanard 1995] no se puede considerar una propuesta metodológica propiamente dicha. En el entorno MacWeb, una aplicación hipermedia se desarrolla en base a la interfaz. Los autores de este entorno puntualizan en el hecho de que lo más importante de una aplicación web es la comunicación con el usuario. Por ello, centran todo el proceso de desarrollo en la interfaz. Como veremos en el siguiente apartado, el diseño de una aplicación hipermedia debe dividirse en dos grandes fases: el desarrollo del proceso mental y la realización de los pasos metodológicos. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 19 2. Fases de MacWeb El proceso mental incluye los siguientes pasos: ??Generación del material, consiste en conseguir toda la información, ya sea textual, gráfica, o de cualquier tipo, que va a mostrarse en la aplicación. ??Organizar y estructurar este material. ??Reorganizar el material y actualizarlo cuando sea necesario. ??Evaluación del material y de la estructuración realizada. El proceso de desarrollo engloba los pasos clásicos, como son: ??Desarrollo del modelo conceptual. ??Desarrollo del modelo navegacional. ??Desarrollo de la interfaz abstracta ??Implementación. ??Pruebas El orden en que se realizan estas fases depende de lo que el diseñador desee. En principio las tareas mentales y las de desarrollo se realizan en paralelo, aunque bien se podrían realizar las mentales y luego las de desarrollo. 3. Conclusiones Esta propuesta no ofrece ninguna nueva aportación en cuanto a técnicas o modelos, por lo que no vamos a aplicarla a nuestro ejemplo. El entorno de desarrollo de MacWeb propone el uso de técnicas clásicas de la orientación a objetos, como son la generalización y la instanciación para representar los aspectos de navegación. Junto con MacWeb, se construyó una herramienta que ayuda a realizar el proceso de desarrollo. Esta herramienta posee clases predefinidas como son los nodos o los enlaces. El entorno de desarrollo de MacWeb resulta interesante por la separación que propone entre los aspectos de contenido y desarrollo. Esta separación aparece en los desarrollos reales en la que los especialistas informáticos tienen que desarrollar una aplicación multimedia sobre un tema del que, en la mayoría de los casos no son expertos. Cada vez es más necesaria la colaboración entre los especialistas temáticos y los técnicos, por lo que es necesario tener en cuenta en el proceso de desarrollo ambos aspectos. Además es la primera propuesta que tiene en cuenta al usuario en el ciclo de desarrollo del sistema. 5.3.5. OOHDM- Object-Oriented Hypermedia Design Method OOHDM es una metodología de desarrollo propuesta por Rossi y Schwabe [Rossi 1996] para la elaboración de aplicaciones multimedia. OOHDM está basada en HDM, en el sentido de que toma muchas de las definiciones, sobre todo en los aspectos de navegación, planteadas en el modelo de HDM. Sin embargo, OOHDM supera con creces a su antecesor, ya que no es simplemente un lenguaje de modelado, sino que define unas pautas de trabajo, centrado principalmente en el diseño, para desarrollar aplicaciones multimedia de forma metodológica. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 20 OOHDM ha evolucionado bastante desde su nacimiento. Actualmente está siendo utilizado por sus autores para el desarrollo de aplicaciones en la web [Schwabe 2001]. 1. Conceptos básicos de OOHDM OOHDM como ya se ha comentado es una metodología de desarrollo para aplicaciones multimedia. Antes de comenzar a detallar cada una de las fases que propone, es necesario resaltar algunas de sus características. La primera de ellas es que OOHDM está basada en el paradigma de la orientación a objetos. En esto se diferencia de su antecesor HDM. A la hora de la representación de las clases y los diagramas, OOHDM utiliza la nomenclatura propuesta por OMT [Rumbaugh 1995], como ya se comentó al estudiar EORM. Sin embargo en las últimas versiones ya se ha asumido UML. Otra característica de OOHDM es que, a diferencia de HDM, no sólo propone un modelo para representar a las aplicaciones multimedia, sino que propone un proceso predeterminado para el que indica las actividades a realizar y los productos que se deben obtener en cada fase del desarrollo. Sin embargo, OOHDM no puede considerarse una metodología en el amplio sentido, ya que, aunque se detalla el proceso a seguir en lo que sería el diseño de la aplicación, no toma parte en otras fases como pueden ser la captura de requisitos o el análisis. Según OOHDM estas fases son idénticas a las que se deben realizar en la propuesta de OMT. Fundamentalmente OOHDM toma como partida el modelo de clases que se obtiene en la fase de diseño de objetos de OMT o, en sus últimas versiones, en el análisis del Proceso Unificado de UML. A este modelo lo denomina modelo conceptual. El proceso anterior a éste, es decir, el análisis y el diseño de sistemas, sería idéntico al que se realizaría en el desarrollo de un sistema clásico según OMT o UML. Partiendo de este modelo conceptual, OOHDM propone ir añadiendo características que permitan incorporar a esta representación del sistema todos los aspectos propios de las aplicaciones multimedia. En una segunda etapa de diseño, se parte de ese modelo conceptual y se añade a éste todos los aspectos de navegación, obteniéndose un nuevo modelo de clases denominado modelo navegacional. Por último, este modelo sirve como base para definir lo que en el argot de OOHDM se denomina modelo de interfaz abstracta. El modelo de interfaz abstracta representa la visión que del sistema tendrá cada usuario del mismo. A continuación vamos a ver un pequeño resumen de las fases de OOHDM, de sus objetivos y de los productos que resultan al aplicar cada una de ellas. 2. Fases de OOHDM En OOHDM se proponen 4 fases de desarrollo: ??Diseño Conceptual ??Diseño Navegacional ??Diseño de Interfaz Abstracto ??Implementación Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 27 Fase Diseño de interfaz abstracta Productos Objetos de interfaz abstracta, respuestas a eventos externos y transformaciones de interfaz Herramientas ADVs, Diagramas de configuración, ADV-Charts y patrones de diseño Mecanismos Mapeado entre los objetos de navegación y los objetos visibles Objetivo de diseño Modelado de los objetos perceptibles por el usuario y de cómo le afecta a la aplicación los eventos externos TABLA 4: FASE DE DISEÑO DE INTERFAZ ABSTRACTO DE OOHDM Fase 4- Implementación Una vez obtenido el modelo conceptual, el modelo de navegación y el modelo de interfaz abstracta, sólo queda llevar los objetos a un lenguaje concreto de programación, para obtener así la implementación ejecutable de la aplicación. En la tabla 5 vemos un resumen de esta fase. Fase Implementación Productos Aplicación ejecutable Herramientas El entorno del lenguaje de programación Mecanismos Los ofrecidos por el lenguaje Objetivo de diseño Obtener la aplicación ejecutable TABLA 5: FASE DE IMPLEMENTACIÓN DE OOHDM Para terminar, podríamos decir que los puntos claves de OOHDM se encuentran en: ??Contempla los objetos que representan la navegación como vistas de los objetos detallados en el modelo conceptual. ??Abstrae los conceptos básicos de la navegación: nodos, enlaces e índices y los organiza mediante el uso de los contextos de navegación, permitiendo así una organización adecuada de los mismos. ??Separa las características de interfaz de las características de navegación, con las ventajas que esto supone. 3. Conclusiones OOHDM es sin duda una de las metodologías que más aceptación ha tenido, y sigue teniendo, en el desarrollo de aplicaciones multimedia. Actualmente está sirviendo como base para el desarrollo de nuevas propuestas metodológicas para los sistemas de información web [Mandel 1999]. OOHDM es una propuesta basada en el diseño, que ofrece una serie de ideas que han sido asumidas por bastantes propuestas y que han dado muy buenos resultados. La primera de ellas es que hace una separación clara entre lo conceptual, lo navegacional y lo visual. Esta independencia hace que el mantenimiento de la aplicación sea mucho más sencillo. Además, es la primera propuesta que hace un estudio profundo de los aspectos de interfaz, esencial no solo en las aplicaciones multimedia, sino que es un punto crítico en cualquiera de los sistemas que se desarrollan actualmente. OOHDM hace uso también de la orientación a objetos y de un diagrama tan estandarizado como el de clases, para representar el aspecto de la navegación a través de las clases navegacionales: índices, enlaces y nodos. Esta idea ha dado muy buenos resultados y parece muy adecuada a la hora de trabajar. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 28 Sin embargo, y a pesar de esto, OOHDM presenta algunas deficiencias. OOHDM ha dejado fuera de su ámbito un aspecto esencial que es el tratamiento de la funcionalidad del sistema. El qué se puede hacer en el sistema y en qué momento de la navegación o de la interfaz se puede hacer, es algo que no trata y que lo deja como tarea de implementación. Además, OOHDM no ofrece ningún mecanismo para trabajar con múltiples actores. Por ejemplo, imaginemos que la interfaz y la navegación de la aplicación varia sustancialmente dependiendo de quién se conecte a la aplicación. El diagrama navegacional, los contextos navegacionales y los ADVs resultarían muy complejos para respresentar esta variabilidad. Otra propuesta de OOHDM que no parece adecuada es la de los contextos navegacionales. Hemos visto que para nuestro sencillo ejemplo, el contexto navegacional es complejo y ambiguo. Cuando el ejemplo se complica el resultado puede llegar a ser ilegible. En resumen, OOHDM nos ofrece una serie de ideas muy adecuadas a la hora de plantear una metodología de desarrollo que tenga en cuenta la navegación y la interfaz. Existen muchos ejemplos desarrollados mediante OOHDM que pueden ayudarnos a ver la viabilidad de estas ideas. Sin embargo, hay que limitar el uso de esta propuesta a aplicaciones multimedia o de la web sencillas en las que la complejidad funcional sea mínima. 5.3.6. WSDM- Web Site Design Method 1. Conceptos básicos de WSDM El Método para diseño de sitios web (WSDM) es una propuesta en la que el sistema se define en base a los grupos de usuarios. Fue propuesto por De Troyer y Leune en 1997 [De Troyer 1997] y se compone de cuatro fases. Los autores de WSDM dividen los sitios web en dos grupos: Kiosco web y Aplicación Web [Isakowitz 1995]. Las que pertenecen al primer tipo ofrecen al usuario una determinada información y les permite navegar hacia ella. Las aplicaciones web englobarían a aquellos sistemas de información interactivos cuya interfaz de usuario es un conjunto de páginas web. Tras esta división, los autores de WSDM especifican que su propuesta es una propuesta orientada a la primera de ellas, no resultando adecuada para las aplicaciones web. 2. Fases de WSDM El modelo de diseño de sitios web se divide en cuatro fases: modelo de usuario, diseño conceptual, diseño de la implementación e implementación. A su vez, el modelo de usuario se divide en dos subfases: clasificación y descripción. Por su parte el diseño conceptual se divide en otras dos subfases: modelado de objetos y diseño navegacional. En la figura 15 vemos la estructura del modelo. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 29 FIGURA 15: ESQUEMA DE FASES DE WSDM Fase 1- Modelado de usuarios En esta primera fase se intenta detectar los perfiles de usuarios que se van a presentar en la aplicación. Para ello, se deben realizar dos tareas: ?? Clasificación de usuarios: en este paso se deben identificar y clasificar a los usuarios que va a tener el sistema. Para ello, los autores de WSDM proponen que se estudie el entorno de la organización donde se vaya a implantar el sistema y los procesos que se vayan a generar. De esta forma, se debe generar un diagrama similar al del diagrama de contexto. ?? Descripción de los grupos de usuarios: en esta segunda etapa se describen con más detalles a los grupos de usuarios detectados en la etapa anterior. Para ello, se debe elaborar un diccionario de datos, en principio con formato libre, en el que se indique los requisitos de almacenamiento de información para cada grupo de usuarios y sus características. En nuestro ejemplo, esta fase daría como resultado la descripción de los grupos de actores que definimos en el apartado 5.2. Como no se propone ningún formato, quedémonos con la descripción informal que se hizo allí. Fase 2- Diseño Conceptual La fase de diseño conceptual puede recordar bastante a la metodología OOHDM, vista anteriormente. Sin embargo, vamos a detectar algunas diferencias. La principal es que en WSDM se hace una diferenciación de los grupos de usuarios desde el comienzo, mientras que en OOHDM se espera hasta las últimas fases del diseño para hablar de los mismos. Sin embargo, las dos metodologías proponen realizar primero un modelado conceptual y luego un modelado de navegación. Así, esta fase en WSDM se divide en las siguientes dos etapas: Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 30 ?? Modelado de objetos El objetivo de esta subfase es modelar formalmente los requisitos de información expresados en la etapa de descripción de la fase anterior. Para ello, se debe obtener un modelo de clases para cada grupo de usuarios, a cada modelo se le denominara diagrama de objetos de usuarios. Al conjunto de todos los diagramas de todos los usuarios se le denomina modelo de objetos de usuarios. La nomenclatura de clases se representa mediante la propuesta de OMT (en las últimas versiones ya se asume la de UML). Para nuestro ejemplo, el modelo de objetos sería similar al de clases que vimos en OOHDM y EORM, recogido en la figura 7. ?? Diseño navegacional Esta fase tiene como objetivo el conseguir un modelo para representar las posibilidades de navegación del sistema. El modelo propuesto por WSDM es bastante sencillo y se basa en representar la navegación a través de un conjunto de pistas de navegación. Una pista de navegación expresa cómo un usuario concreto puede navegar hacia una determinada información. El modelo es representado mediante un diagrama en el que pueden aparecer 4 elementos que se muestran en la figura 16. FIGURA 16: REPRESENTACIÓN GRÁFICA DE LOS CONCEPTOS DE NAVEGACIÓN Cada componente de información se corresponde con una perspectiva de los tipos de objetos (POT) descritos en la subfase anterior. Es decir, una visión particular de la información. Los componentes de información pueden estar relacionados entre ellos a través de enlaces. Los componentes de navegación son conjuntos de enlaces y las entidades externas representan una referencia hacia un elemento externo al sistema. En WSDM se propone un algoritmo para construir el modelo navegacional a partir del modelo de clases para un determinado usuario, cada uno de estos modelos es un contexto. Es interesante ver este algoritmo pues es el único proceso totalmente Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 31 estructurado que se da en las metodologías vistas hasta ahora para conseguir representar la navegación. Para cada contexto de usuario hay que realizar una serie de pasos que vemos en la figura 17. FIGURA 17: PROCESO PARA OBTENER EL MODELO DE NAVEGACIÓN Aplicándolo a nuestro ejemplo, tendríamos un componente de navegación para los datos de identificación y otro para los datos de descripción, enlazados entre sí, tal y como se ve en la figura 18. Como el primero toma datos de la clase Bien Mueble e Inmueble tiene dos componente de información. El segundo tiene más, puesto que toma datos de más clases. FIGURA 18: EJEMPLO DE DISEÑO NAVEGACIONAL DE WSDM Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 32 Fase 3- Diseño de la implementación Una vez definido el modelo es necesario diseñar la interfaz y el entorno de usuario del sistema. Para ello, los autores de WSDM no proponen nada. Únicamente referencian a las propuestas de December y Ginsberg [December 1995] para el desarrollo de interfaces. Fase 4- Implementación En esta fase se pretende conseguir la aplicación ejecutable final en base a los resultados de las fases anteriores. De nuevo tampoco se propone ninguna técnica en concreto para ello. 3. Conclusiones En principio la propuesta de WSDM puede ser bastante interesante en el sentido de que ofrece una nueva visión al tratamiento de los usuarios. Es una metodología totalmente orientada a diseñar la aplicación en base a los grupos de usuarios desde el principio. Sin embargo, no comenta nada sobre aspectos que pueden resultar importante partiendo de esta idea. Por ejemplo, puede ser que la misma información se presente a dos usuarios de forma diferente. En muchos casos puede resultar complejo para el implementador detectar que se trata de la misma información. Además, como sus propios autores indican, solo sirve para desarrollar kioscos web, es decir, aplicaciones que muestren información. Esta propuesta no trabaja aspectos como la funcionalidad, la seguridad, etc. necesarias en las aplicaciones web. Se centra solo en cómo presentar la información al usuario. 5.3.7. OO-Method y OO-Hmethod 1. Conceptos básicos de OO-Method OO-Method [Pastor 1997] es un método orientado a objetos desarrollado en la Universidad Politécnica de Valencia que fusiona el uso de un lenguaje de especificación formal (OASIS [Pastor 1992]) con una notación gráfica tomada de los estándares más usados. Esta aproximación aprovecha las buenas propiedades de los lenguajes de especificación formales con la experiencia acumulada de los métodos habitualmente usados en contextos de producción industrial de software. La metodología OO-Method ha evolucionado en los últimos trabajos en OO- HMethod [Gómez 2001]. Éste no es más que una ampliación de OO-Method en la que se añade un nuevo modelo para representar la interoperabilidad con los usuarios en sistemas web. Los principios básicos de OO-Method se concretan en que permite dar soporte a las nociones de modelización conceptual orientado a objetos y usar conceptos de lenguajes de especificación formales y orientados a objetos. Además, OO-Method posee un avanzado entorno de prototipación automática que incluye tanto la generación automática de una especificación formal y orientada a objetos en OASIS, como la prototipación funcional equivalente al modelo conceptual y la generación completa de código en entornos imperativos como Visual C++ o Delphi. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 33 2. Fases de OO-Method OO-Method ofrece un marco riguroso para la especificación de sistemas de información que incluye: ??La notación gráfica necesaria para construir el Modelo Conceptual. ??OASIS como un lenguaje de especificación formal. ??La definición de un preciso modelo de ejecución que guía la fase de implementación en el espacio de la solución. El Modelo Conceptual se compone a su vez en tres modelos: ?? El Modelo de Objetos, que utiliza lo que se denomina Diagrama de Configuración de Clases para definir y mostrar la estructura y comportamiento (atributos y operaciones) de todas las clases identificadas en el dominio del sistema. Sería similar al modelo conceptual de EORM u OOHDM (figura 7). ?? El Modelo Dinámico, en el que se hace uso de los Diagramas de Transición de Estados y de los Diagramas de Interacción de Objetos, para representar la vida de los objetos y la interacción que se produce entre ellos. ?? El Modelo Funcional, en el que, a través de una nomenclatura propia, se recoge la semántica asociada a los cambios de estado de forma fácil e intuitiva. Si en lugar de trabajar con OO-Method nos movemos en el ámbito de OO-HMethod, a este conjunto de modelos habrá que añadirle el Modelo de Ejecución de Interfaz que servirá para indicar cómo la intefraz y los módulos de la aplicación se comunican entre ellos. Esto se representa a través de lo que se denomina Diagrama de Acceso de Navegación. Una vez especificado el sistema, se desarrolla un Modelo de Ejecución que establece una representación del modelo conceptual en un entorno de desarrollo, atendiendo tanto a los aspectos dinámicos como estáticos, así como una estrategia de ejecución. Existe en OO-Method un proceso definido para realizar estas estrategias. Aplicar OO-HMethod u OO-Method a nuestro ejemplo, no resultaría de interés sin hacer uso de su herramienta y esto conllevaría un trabajo descriptivo que se sale del ámbito de este documento. La mayor aportación de estas técnicas es el soporte que el desarrollador encuentra en la herramienta diseñada para trabajar con él. 3. Conclusiones OO-Method es una técnica bastante adecuada y que cada día está teniendo mayor influencia en el campo del desarrollo de aplicaciones web. Ofrece una importante herramienta web cuyos esfuerzos de elaboración son muy loables. Sin embargo, OO-Method no aborda tareas como la especificación de requisitos y vuelve a ser una metodología orientada casi en su totalidad a la fase de diseño e implementación. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 34 5.3.8. SOHDM- Scenario-based Objecto-oriented Hypermedia Design Methodology Otra propuesta algo más reciente que las anteriores es la realizada por H. Lee, C. Lee y C. Yoo: SOHDM [Lee 1998]. Esta propuesta se compone de seis fases y se parece bastante a sus antecesoras RMM, OOHDM y EORM. Sin embargo, hay algo que hace diferente a esta metodología de las anteriores y es el hecho de que se basa en los escenarios para el desarrollo del sistema. 1. Conceptos básicos de SOHDM Como ya se ha comentado, SOHDM es una metodología para el desarrollo de aplicaciones multimedia que se divide en seis fases que hay que realizar de forma secuencial. Sin embargo, el proceso de desarrollo es un proceso cíclico en el sentido de que al realizar una fase se puede regresar a alguna de las anteriores para refinarla y adaptarla mejor. Como su propio nombre indica, SOHDM está basado en los escenarios para elaborar las aplicaciones multimedia. En su proceso, los escenarios se elaboran en la fase de análisis para capturar los requisitos funcionales del sistema y sirven como base para el resto del proceso. A pesar de que SOHDM se asemeja bastante a OOHDM y EORM, difiere de ellas en el sentido de que mientras que estas dos metodologías sólo trabajan en la fase de diseño, SOHDM engloba también la fase de análisis. 2. Fases de SOHDM Ya se ha comentado que SOHDM es un proceso compuesto por seis fases secuenciales. En la figura 19 se presenta un esquema en el que se detallan las fases y los productos obtenidos en cada una de ellas y cómo los productos obtenidos en una fase sirven como referencia para la fase siguiente. FIGURA 19: ARQUITECTURA DE SOHDM Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 35 Sin embargo, a pesar de que el modelo esté pensado como secuencial, permite volver atrás en cualquiera de las etapas del proceso. A continuación se presentarán cada una de estas fases. Fase 1- Análisis En la fase de análisis se debe realizar un estudio de las necesidades de la aplicación, del entorno de trabajo y de los actores. La finalidad principal de esta fase es conseguir los escenarios que representen las actividades que se pueden llevar a cabo en el sistema. Para ello, lo primero que se debe realizar es un diagrama de contexto tal y como se propone en diagramas de flujos de datos [Yourdon 1989]. En este diagrama de contexto es necesario detectar a las entidades externas que se comunican con el sistema, así como los eventos que provocan esa comunicación. Una vez detectados estos eventos, se debe elaborar lo que se denomina lista de eventos. La lista de eventos será una tabla con una estructura similar a la mostrada en la tabla 6. Nombre de la entidad externa Nombre del evento Evento 1 en el que participa la entidad ... Entidad externa 1 Evento n en el que participa la entidad ... ... Evento 1 en el que participa la entidad ... Entidad externa m Evento p en el que participa la entidad TABLA 6: ESTRUCTURA DE LA LISTA DE EVENTOS En esta tabla se detallan todas las entidades en la columna de la izquierda y en la columna de la derecha todos los eventos en los que cada una participa. Para nuestro ejemplo, la única entidad externa que tenemos es el usuario. Podríamos detectar, por ejemplo que se ve afectado por el evento de conectarse al sistema y el de petición de datos, quedando nuestra tabla como la que se muestra en la tabla 7. Nombre de la entidad externa Nombre del evento Conexión al sistema Usuario Petición de datos TABLA 7: EJEMPLO DE LISTA DE EVENTOS Partiendo de esta tabla, por cada evento diferente se debe elaborar un escenario. Éstos se van a representar mediante los denominados SACs2 (Scenario Activity Chart). En estos escenarios se va a describir el proceso de trabajo que se va a seguir en el sistema cuando se produzca la situación que el escenario representa. Por ejemplo, en la figura 20 nos encontramos un escenario en el que se describe cómo se produce la conexión al sistema del usuario. 2 Los SACs son una forma como cualquier otra de representar los escenarios en la documentación. Esta representación está fuera de los límites de este trabajo, pero se pueden encontrar descritos en [Lee 1998]. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 36 FIGURA 20: EJEMPLO DE ESCENARIO Fase 2- Modelado de objetos Los escenarios representados mediante SACs son usados para conseguir modelar los objetos del sistema. En la fase de modelado de objetos, los escenarios van a ser transformados en objetos según la propuesta de los CRC Cards (Class Responsability Collaboration) [Wirfs-Brock 1990]. Esta propuesta tiene como objetivo presentar un formato sencillo e informal para conseguir un diccionario de datos para las clases del sistema. En ellas cada clase tiene asociado una ficha (CRC Cards) en la que se almacena: su nombre, sus atributos, su superclase, sus subclases, sus componentes, las asociaciones en las que participa, las otras clases con las que colabora y los eventos detallados en los SACs de los que es responsable. Las CRC Cards irán acompañadas de un diagrama de clases, CSD (Class Structure Diagram), que representará gráficamente lo recogido en las CRC Cards. En principio la nomenclatura seguida fue la de OMT pero ya ha asumido la de UML. Nuevamente, para nuestro ejemplo, este modelo coincidiría con el de la figura 7. Fase 3- Diseño de vistas En la fase de diseño de vistas, los objetos serán reorganizados en unidades navegacionales. Una unidad navegacional representa una vista de los objetos del sistema. Las vistas van a estar muy relacionadas con el concepto de nodos de OOHDM. La vista es una agrupación de información que se presenta agrupada al usuario bajo un determinado criterio. En SOHDM, las vistas pueden ser: ??Vistas base; son aquellas que toman todos los datos que muestra de una única clase. ??Vistas de asociación; toma los datos de dos clases que se encuentran relacionadas mediante una asociación en el modelo de clases. ??Vistas de colaboración; toma los datos de clases que se encuentran relacionadas mediante una relación de colaboración. Fase 4- Diseño Navegacional En el diseño navegacional se van a definir los enlaces o hiperenlaces que existen entre las diferentes vistas. Aquí las vistas definidas en la fase anterior se relacionan a través de estructuras de acceso. El primer paso a realizar es definir lo que se conoce como nodos de estructuras de acceso (ASNs). Estos son nodos especiales como diccionarios, menús, etc. que sirven como punto de partida para la navegación. Una vez definidos los ASN, estos y las vistas definidas en la fase anterior, se conectan mediante flechas que indican el sentido de la Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 43 Fase 4- Realizar el diccionario de datos para modelo de clases En esta fase se debe documentar los modelos obtenidos en las dos fases anteriores. En principio el formato de este diccionario es libre. Fase 5- Diseño Navegacional En esta fase se debe enriquecer el modelo de clases con nuevas clases que permitan representar la navegación. Para ello, se definen una serie de patrones de diseño en los que se definen los nodos y los enlaces de forma similar a como se definieron en EORM o OOHDM. El resultado sería un modelo de clases navegacionales similar al de OOHDM. Así el de nuestro ejemplo sería equivalente al que se obtuvo en OOHDM y que se mostró en la figura 9. Fase 6- Implementación La fase de implementación tiene por objetivo el conseguir, basándose en el modelo navegacional, la aplicación ejecutable del sistema. 3. Conclusiones Esta metodología es bastante completa en el sentido de que hace referencia a la fase de análisis, diseño e implementación. Sin embargo no deja muy claro qué documentación hay que presentar y no hace ningún tipo de referencia a la interfaz. Sin embargo hay que resaltar que establece la necesidad de realizar un diccionario de datos para el modelo conceptual. Por ello, de HFPM podemos concluir en que es una propuesta que recoge todo el ciclo de vida del sistema mostrando así que esto es necesario. Sin embargo, no trata aspectos básicos como la interfaz ni indica qué hay que hacer en cada fase. Sólo recoge qué objetivos deben alcanzarse en cada una de ellas. 5.3.12. El Proceso Unificado 1. Conceptos básicos del Proceso Unificado Como ya se ha comentado, UML es una propuesta de lenguaje de modelado de datos realizada por Booch, Rumbaugh y Jacobson, entre otros. La primera versión de UML nace en 1997. UML es un lenguaje gráfico para modelar sistemas software según la orientación a objetos, en él se describen una serie de modelos que nos permiten representar diferentes aspectos de nuestros sistemas software. No es objetivo de este trabajo el describir las posibilidades de modelado que ofrece UML [Booch 1999] [Rumbaugh 1999]. En base a UML, los mismos autores realizan una propuesta de metodología denominada Proceso Unificado [Jacobson 1999], que es la que se verá en este documento. El Proceso Unificado comprende un conjunto de actividades que hay realizar para llevar a cabo el desarrollo de producto software. A continuación vamos a describir esta propuesta. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 44 2. Fases del Proceso Unificado El ciclo de vida del Proceso Unificado es el ciclo de vida que los autores creadores de UML proponen para el desarrollo. El ciclo de vida del Proceso Unificado es en la práctica un ciclo de vida en espiral. Sus características esenciales es que se trata de un ciclo de vida incremental e iterativo. Iterativo porque se producen varios ciclos en su desarrollo en cada uno de los cuales se concreta más el producto resultado del ciclo anterior. E incremental porque en cada ciclo, el producto resultante se va a adecuar más a las necesidades de los clientes. El ciclo de vida del Proceso Unificado asume que en la vida del proyecto existen una serie de ciclos, cada uno de los cuales tiene cuatro fases. Por cada una de las fases se pueden realizar varias iteraciones y en éstas a su vez se distinguen cinco flujos de trabajo. Vemos un esquema de ello en la figura 23. En esta figura se usa la propia notación de UML para representar la estructura del ciclo de vida del Proceso Unificado. FIGURA 23: CICLO DE VIDA DEL PROCESO UNIFICADO Tras cada ciclo, obtendremos un resultado final que será una versión del producto. Como ya hemos dicho, en cada ciclo existen 4 fases que se detallan en la figura 24. Como vemos, tras cada una de las fases obtenemos un resultado de fase. El resultado de la última fase va a coincidir con una versión del producto. A continuación se presenta un pequeño resumen de lo que hay que realizar en cada una de ellas. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 45 FIGURA 24: FASES DEL PROCESO UNIFICADO Fase 1-Fase de Inicio En ella las tareas que fundamentalmente se deben llevar a cabo son: ??Estudiar la viabilidad del ciclo. ??Identificar riesgos. ??Estimar costes y realizar la planificación. ??Perfilar la arquitectura del sistema. Fase 2-Fase de Elaboración En esta fase, debemos: ??Revisar la identificación de riesgos de la etapa anterior. ??Especificar los requisitos de usuario. ??Definir la arquitectura del sistema. ??Preparar el plan de Proyecto. ??Revisar la planificación y estimación de costes. ??Definir parámetros generales como calidad, fiabilidad, riegos, tiempos de respuesta, etc. Fase 3-Fase de Construcción En la fase de construcción, se debe: ??Completar la arquitectura. ??Obtener el código ejecutable. ??Obtener el producto beta. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 46 Fase 4-Fase de Transición La fase de transición es la última fase del ciclo y tras ella obtendremos una versión del producto. Sus tareas fundamentales son: ??Realizar pruebas beta y subsanar deficiencias. ??Formación del personal, mantenimiento y garantía. Por su parte, hemos dicho que en cada fase hay N iteraciones. Tras cada iteración se obtiene los que se conoce como producto interno. El producto interno es algo que, a diferencia de los resultados de fase, no suele darse al usuario. El esquema de las iteraciones lo vemos en la figura 25. FIGURA 25: ITERACIONES DEL PROCESO UNIFICADO Por su parte, en cada iteración hay cinco flujos de trabajo: requisitos, análisis, diseño, implementación y pruebas. Realmente es como si dentro de cada iteración elaborásemos un ciclo de vida secuencial, puesto que estos flujos de trabajo son similares a los propuestos por el ciclo de vida clásico. Los flujos de trabajo van a ir tomando más o menos importancia dependiendo de la fase en la que estemos trabajando. Veamos a continuación, muy brevemente, cuáles son los objetivos de cada uno de estos flujos de trabajo: ?? Captura de requisitos: el propósito general de este flujo de trabajo es dirigir el proceso de desarrollo hacia el sistema correcto. Para ello, UML propone el uso de los casos de uso [Jacobson 1995]. Básicamente destaca la necesidad de capturar los requisitos de almacenamiento, los requisitos funcionales y los requisitos no funcionales. ?? Análisis: se analizarán los requisitos descritos en el flujo anterior para refinarlos y estructurarlos. El propósito de hacer esto es alcanzar una comprensión mayor del problema permitiendo así que se pueda dar una visión de la estructura completa del Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 47 sistema. Esto se representa principalmente a través del diagrama de clases y del diagrama de paquetes [Booch 1999]. ?? Diseño: se debe dar forma al sistema en función del modelo de análisis y de los requisitos establecidos. En este flujo se determinará la arquitectura y la división en subsistemas, pero básicamente la idea es conseguir una representación abstracta del sistema que se acerque mucho a la implementación pero sin entrar en detalles de bajo nivel. ?? Implementación: partiendo del resultado de la fase de diseño, en la implementación hay que llevar a código entendible por la máquina, todas las características representadas y capturadas en los flujos anteriores. En definitiva se deben implementar los subsistemas y las clases, los interfaces y las relaciones, de manera que consigamos una aplicación que represente al sistema y cumpla los requisitos establecidos en el primer flujo de trabajo. ?? Pruebas: el objetivo fundamental es verificar el resultado de la implementación. Para ello, se debe diseñar un test de pruebas que examine la corrección de cada una de las unidades de programación. 3. Conclusiones Si se desea desarrollar un sistema de información global y se decide usar el Proceso Unificado descrito en el apartado anterior, se detectarán las carencias que presenta esta propuesta para representar aspectos como la interfaz de usuario, la multiplicidad de medios en los tipos de información o la complejidad de la navegación dentro del sistema. Esto se debe a que UML y el Proceso Unificado están orientados a trabajar esencialmente con la funcionalidad y los aspectos de almacenamiento de informacón Detectada esta carencia, diferentes grupos de investigación han intentado resolver el problema enriqueciendo a UML con nuevos recursos para poder representar estos aspectos propios de las aplicaciones en la web. Dentro de estos grupos, se pueden determinar dos tendencias. La primera de ellas englobaría a los investigadores que intentan enriquecer UML añadiendo nuevos esterotipos que permitan representar aspectos propios de las aplicaciones web. En este sentido vamos a estudiar la propuesta realizada por Conallen [Conallen 1999a] en el apartado 5.3.13. Por otro lado, existen otra serie de propuestas que, basadas en metodologías de desarrollo de sistemas multimedia, en especial OOHDM, intentan enriquecer a UML no a través de estereotipos, sino a través de nuevos modelos que permitan representar la multimedia y la navegación. Estas propuestas nacen fundamentalmente en Alemania y las analizaremos en el apartado 5.3.14. A pesar de que al intentar aplicar el Proceso Unificado al diseño de los sistemas de información global encontremos lagunas a la hora de expresar algunos aspectos, está claro que la nomenclatura de UML y su ciclo de vida es un estándar que está dando muy buenos resultados. De hecho, la mayoría de las propuestas que hemos analizado en este trabajo hacen uso de él. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 48 5.3.13. Building Web Applications with UML 1. Conceptos básicos de “Building Web Applications with UML” Como ya se ha comentado, de manos de Jim Conallen aparece una propuesta [Conallen 1999a] que no es más que una ampliación de UML para la web. Los creadores de UML reconocieron que UML no era una propuesta perfecta para todo los tipos de aplicaciones, así que junto a él definieron un camino formal para la definición de nuevos conceptos que permitieran cubrir necesidades en sistemas novedosos. Conallen ha hecho uso de esta propuesta y, observando las carencias que UML presentaba para diseñar aplicaciones en la web, realizó una propuesta para ampliar el lenguaje gráfico con nuevos estereotipos propios de internet y la web. Los estereotipos propuestos por Conallen usan unas representaciones gráfica que él mismo pone a disposición del interesado y que se pueden incluir en la herramienta Rational Rose. A continuación se detallarán estos estereotipos, aunque no se detallarán de forma exhaustiva. Si se desear ver la definición formal de éstos puede consultarse en la web: http://www.conallen.com/technologyCorner/webextension/WebExtension091.htm [Conallen 1999b]. ?? Clases Las clases que Conallen propone en su extensión son: a) Server Page: representa una página web que contiene uno o varios scripts que van a ser ejecutados por el servidor. Las operaciones de los objetos de esta clase representan las funciones de los scripts y sus atributos las variables que son visibles en el ámbito de la página. Su representación la vemos en el icono 1 de la figura 26. b) Client Page: una instancia de este tipo de clases es una página web escrita en HTML. Como cualquier página web es una mezcla de datos, presentación y lógica. Son páginas representadas y leídas por los navegadores. Puede poseer scripts, pero estos serán interpretados por los navegadores. En el icono 2 de la figura 26 vemos su representación. c) Form: una clase Form se traduce directamente a una etiqueta form en HTML. Representa a un conjunto de campos de entrada que podemos encontrarnos dentro de una página. Sus atributos se corresponderán con los atributos de los forms representados en la página web. No posee operaciones. Cualquier operación que interactúe con el Form será una propiedad de la página que lo contenga. Su representación la vemos en el icono 3 de la figura 26. d) Frame Set: un Frame Set es un contenedor de múltiples páginas web. Es decir un Frame Set va a contener páginas web u otros Frame Set. Éstos se traducen directamente a frameset de HTML. Vemos su representación en el icono 4 de la figura 26. e) Target: representa un compartimento en una ventana de un navegador donde puede ser interpretada una página web. Básicamente es un frame en una ventana definida por un frameset, aunque también podría ser una nueva instancia del propio navegador. Vemos en el icono 5 de la figura 26 cómo se representa. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 49 f) JavaScript: esta clase sirve para representar los objetos definidos por el usuario dentro de una página web mediante una aplicación JavaScript. Vemos su representación en el icono 6 de la figura 26. ?? Asociaciones a) Link: representa un enlace desde una página a otra. Se traduce directamente a una etiqueta de HTML del tipo anchor. b) Targeted Link: es similar al anterior pero aquí la página destino y la página origen es la misma. Nos movemos entre etiquetas dentro de la misma página. c) Frame Content: es una relación de agregación donde el contenedor es un objeto de la clase FrameSet y los contenidos son otras páginas. d) Submit: se da siempre entre un objeto de la clase Form y uno de la clase Server Page. Sirve para representar que ese Form interactúa con ese servidor. e) Builds: este tipo de asociaciones se da entre objetos de la clase Server Page y objetos de la clase Client Page. Sirve para identificar qué página servidor es responsable de la creación de una determinada página cliente. f) Redirect: es una asociación unidireccional. Sirve para representar que la página destino es cargada inmediatamente después de la página origen. g) Object: se establece entre una página cliente y un objeto que se encuentra en ella. h) IIOP (Internet Inter-Orb Protocol): es una relación especial que se produce entre objetos en el servidor y objetos en el cliente. Representa un mecanismo de comunicación (diferente a HTTP) para las comunicaciones entre el cliente y el servidor. i) RMI (Remote Method Invocation): RMI es un mecanismo de los Applets y los Beans de Java para mandar mensajes a otros Beans en otras máquinas. Básicamente esta relación se establece entre objetos Java Beans o Applets en el cliente y Java Beans en el servidor. ?? Atributos a) Input Element: es un atributo de la clase Form que se corresponde con campos de entrada en el Form de la página HTML. b) Select Element: es un atributo de la clase Form que representa un campo cuyo valor, o valores, pueden ser seleccionados a partir de los elementos de una lista. Básicamente se traduce a los controles ComboBox y ListBox. c) Text Area Component: es un atributo de la clase Form que representa a un área de texto. ?? Componentes a) Page: un componente Page representa a cualquier tipo de página web. El icono mediante el que se representa lo vemos en el icono 7 de la figura 26. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 50 FIGURA 26: ICONOS PROPOPUESTOS POR CONALLEN 2. Conclusiones Como ya se enunció, esta propuesta simplemente define estos nuevos estereotipos que se pueden incluir en las representaciones de los sistemas web. Sin embargo, y a pesar de que esta extensión de UML nos ofrece semántica para representar conceptos como las páginas web o los enlaces, no nos ofrece ninguna guía de cómo representar la información almacenada en múltiples medios, la navegación o la interfaz de usuario. Estos estereotipos son muy cercanos a la fase de implementación y recogen aspectos como el hecho de que un script este escrito en Java o no. Los sistemas de información global no son, sin embargo, diferentes sólo en el bajo diseño y en la implementación a los sistemas clásicos. Sus diferencias deben ser tratadas desde las primeras fases y esta extensión no nos ofrece herramientas suficientes para ello. 5.3.14. Specification and modeling of multimedia and hypermedia systems 1. Conceptos básicos de “Specification and modeling of multimedia and hypermedia systems” La segunda propuesta para la ampliación de UML que vamos a analizar difiere de la anterior en el sentido de que ofrece la descripción de nuevos modelos para representar los aspectos de las aplicaciones multimedia y de la web. Esta propuesta se basa en tres pilares: ??OOHDM [Schwabe 1995] (Object Oriented Hypermedia Design Model), que vimos en el apartado 5.3.5. ??YAON [Maier 1997] (Yet Another Object Notation), es una notación para desarrollar documentos gráficos que permite recoger las decisiones de implementación bajo el paradigma de la orientación a objetos. Está orientado principalmente a los sistemas distribuidos. ??EPK-fix [Knapp 1997], es una metodología de desarrollo para catálogos multimedia. En ella un catálogo se ve como una aplicación multimedia que se Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 51 desarrolla en base a cuatro componentes: la estructura, el layout, la dirección y los servicios. Cada componente interactivo es una representación de un producto de la base de datos de los productos del catálogo. Mediante la estructura se representa la forma de la base de datos, el esqueleto de la aplicación. Con el layout se describen los aspectos estáticos del catálogo (ventanas, frames, etc.) . Todos los aspectos de navegación, ya sea entre los elementos del propio catálogo como entre los elementos del layout, son representados mediante la dirección. Y por último a través de los servicios se representarán otras utilidades que ofrezca el sistema: menús de ayuda, enlaces de interés, etc. A pesar de que EPK-fix está totalmente orientado a la generación de catálogos multimedia, muchas de sus ideas han sido extendidas en la propuesta que se está analizando. 2. Fases de “Specification and modeling of multimedia and hypermedia systems” La extensión de UML que se va a presentar en este apartado, viene de manos de Nora Koch de la Universidad de Munich y Luis Mandel de la Industria de Tecnología Software de Alemania [Mandel 2000]. En esta propuesta, se detallan tres subetapas de diseño dentro del flujo de diseño: diseño conceptual, diseño navegacional y diseño de la presentación. En cada uno de ellos se proponen nuevos modelos y estereotipos que se verán a continuación. ?? Diseño Conceptual El principal objetivo del diseño conceptual es capturar el dominio semántico del problema sin entrar en aspectos de navegación o de interfaz. Las tareas básicas a realizar son: 1. Determinar las clases 2. Especificar los atributos y operaciones de las clases 3. Definir las estructuras jerárquicas 4. Determinar los subsistemas Básicamente se correspondería con la propuesta inicial de diseño del Proceso Unificado. El resultado es un diagrama de clases clásico que se denomina modelo conceptual. Así para nuestro ejemplo sería similar al que se vio en la figura 7. ?? Diseño Navegacional El diseño de la navegación supone un paso crítico en el diseño de cualquier aplicación hipermedia, incluso en las más simples. Con el diseño navegacional se va a representar la estructura de enlaces de la aplicación web. Para ello se van a construir dos modelos complementarios: el modelo de clases navegacionales y los diagramas de contextos. Estos modelos van a definir lo que se conocen como clases navegacionales. Las clases navegacionales pueden ser de tres tipos: nodos, que representan contenedores de clases; enlaces, que representan la posibilidad de navegar desde un nodo a otro; y estructuras de acceso, que sirven para representar menús, diccionarios, etc. A continuación se verán estas clases a medida que se describen los modelos. ?? Modelo de clases navegacionales: El modelo de clases navegacionales va a definir una vista del modelo conceptual definiendo qué clases del modelo conceptual pueden ser visitadas en la navegación. Este modelo se construye con un conjunto de clases de navegación y asociaciones entre ellas. Cada Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 52 clase y cada asociación del modelo navegacional se define en base a una clase o asociación del modelo conceptual. Se podría decir que el modelo de clases navegacionales es un subgrafo del modelo conceptual en el que se han eliminado algunas clases y atributos indiferentes para la navegación. El primer paso para construir este modelo es determinar qué clases del modelo conceptual van a aparecer en la navegación y cuáles de sus atributos van a ser visibles. Con esto se obtendrá un nuevo diagrama de clases en el que cada clase del modelo de clases navegacionales será un nodo que habrá que definir en base a las clases del modelo conceptual siguiendo la sintaxis mostrada en la figura 27. Donde: ??nombreNodo: es el nombre de la clase nodo que se está creando. ??nombreClase: es el nombre de la clase de la clase del modelo conceptual de la que el nodo toma información. ??atributo-i: representa al atributo i-ésimo del nodo. ??nombre-i y nombreVar-i: son alias que se asignan a las clases conceptuales o a los atributos de éstas para representarlos en la expresión de selección. ??expresiónLógica: es un predicado que depende de las variables y clases conceptuales. ??timeout: es un entero que especifica la cantidad de tiempo que se esperará para cargar la página. ??refresh: es un enlace a otro nodo que se carga cuando ha pasado el timeout. ??expires: indica la fecha en la que caduca la información contenida en el nodo. FIGURA 27: SINTAXIS DE DEFINICIÓN DE NODOS Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 59 Fase 3- Construir el modelo de estructura de navegación El modelo de estructura de navegación va a representar cómo se va a navegar a través del modelo navegacional. Sigue la idea del modelo de contextos navegacionales vistos en el apartado 5.3.14. Sin embargo, en esta propuesta se baja a un nivel más bajo de diseño y se utilizan los estereotipos vistos en la figura 31 para representar la estructura de la navegación. De esta forma, la estructura de navegación vendrá representada por un grafo dirigido en el que los nodos son índices, rutas, selecciones, menús o nodos. Para conseguir este grafo, se proponen igualmente una serie de pautas: 1. Para detectar los índices, rutas y selecciones se debe: 1.1. Considerar sólo aquellas asociaciones del modelo navegacional que tienen una cardinalidad mayor a 1. 1.2. Cada asociación de este tipo, llevará asociado una o más estructuras de acceso de tipo índices, rutas o selecciones. 2. Para detectar la necesidad de menús: 2.1. Considerar las clases navegacionales con más de una asociación como fuente 2.2. Asociar a estas clases un menú. 2.3. En el menú habrá tantas entradas como roles pueda tener la clase en las asociaciones. Puesto que esta propuesta está basada en la anterior, el resultado de aplicar este algoritmo a nuestro ejemplo daría como resultado el diagrama que se mostró en la figura 30. Fase 4- Construir el modelo de presentación Partiendo de los modelos anteriores, es necesario ya plantearse la estructura abstracta que tendrá la interfaz del sistema. En este paso, los autores de la propuesta dejan muy claro que no hay que representar qué se va a ver en la pantalla, sino la estructura de lo que se va a ver. No hay que entrar pues en detalles de la apariencia física como los colores o los tipos de letras. Para construir el modelo de presentación, Hennicker y Koch proponen que hay que decidir qué elementos de presentación se van a usar para representar las instancias de las clases navegacionales y los elementos de la estructura de navegación detectados en las pasos 2 y 3. Para ello, usan los estereotipos de Conallen presentados en el apartado 5.3.13. Como en casos anteriores, se ofrecen las pautas a seguir para conseguir este modelo: 1. Para cada clase navegacional es necesario construir una presentación, así como para cada estructura de navegación. 2. Elegir una estructura de navegación como raíz. 3. Representar las asociaciones de las clases navegacionales con elementos de navegación dentro de las representaciones hechas en el paso 1. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 60 3. Conclusiones El trabajo que acabamos de analizar es mucho más refinado que los anteriores. A pesar de no aportar nuevas ideas, puesto que se basa en los trabajos vistos en los apartados 5.3.13. y 5.3.14, sí que se puede destacar por varios aspectos. Por un lado, propone una secuencia de pasos y de guías a la hora de obtener los modelos. Esto lo acerca mucho más a lo que sería una propuesta metodológica. Por otro lado, incluye aspectos más alejados del diseño como es utilizar los casos de uso para capturar la funcionalidad del sistema. Sin embargo, no indica cómo conseguir que esos casos de uso capturen los conceptos necesarios para definir la navegación o la interfaz. Este es precisamente uno de los aspectos que se le puede criticar. Simplemente por el hecho de que se basa en las propuestas anteriores, se le pueden hacer las mismas críticas con respecto a la complejidad de sus modelos y al hecho de que no tiene en cuenta al usuario en el desarrollo de la interfaz. Por último, decir que esta propuesta está orientada totalmente al proceso. No indica en ningún momento qué hay que presentar al usuario o cuáles son los resultados finales del trabajo. Sólo indica los modelos a conseguir. 5.4.Otras propuestas Existen actualmente nuevas tendencias y nuevas propuestas en el entorno de la multimedia y de la web. Sin embargo, recoger todas en este documento sería algo inviable. Dentro de todas estas propuestas se han estudiado en los apartado anteriores las más relevantes. Sin embargo no podemos cerrar el capítulo sin mencionar otras tendencias que están naciendo y que están teniendo mucha difusión. El hecho de que estas no hayan sido estudiadas en profundidad es porque no aportan ideas nuevas sobre las anteriores o porque no hay demasiado publicado sobre las mismas. Así por ejemplo nos encontramos con WebML (Web Modeling Language) [Ceri 2001]. Esta propuesta viene de manos de Stefano Ceri, Piero Fraternali y Aldo Bongio de la Politécnica de Milano. Esta propuesta es interesante sobretodo porque lleva asociado una herramienta que permite implementar bajo XML todo lo que se desarrolla. Otro trabajo importante es el realizado por Paolo Atzeni y Paolo Merialdo de la Universidad de Roma y por Giasalvatores Mecca de la universidad de la Basilicata [Mecca 1999]. Este trabajo es el proyecto Araneus. Araneus es un modelo de datos específico para describir esquemas de aplicaciones con hipertextos. Está orientado en el mundo de las bases de datos y el modelo entidad relación. Otra propuesta de interés es OSM. Ésta nace de manos de Liddle, Embley y Woodfiel [Liddle 2001a]. OSM no es en sí una propuesta metodológica, es un modelo orientado a objetos que pretende ser lo suficientemente sólido como para dar soporte a todas las fases del ciclo de vida de un proyecto de desarrollo software (especificación, análisis, diseño, implementación y evolución). Está compuesto a su vez de tres submodelos: ??Modelo de objetos y relaciones entre ellos ??Modelo de comportamiento ??Modelo de presentación Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 61 Los componentes estructurales de OSM son objetos y relaciones entre ellos. Los objetos se relacionan mediante dos abstracciones: la generalización/especialización y la clasificación. Un objeto tiene una identidad única y es activo. Además puede actuar de forma concurrente con otros objetos. Las relaciones por su parte se agrupan en conjuntos de relaciones y pueden ser tratadas como objetos dándoles todas las propiedades que se podrían dar a éstos. El comportamiento viene represetando en OSM usando un diagrama de estados. Cada objeto tiene asociado un conjunto de estados. Para cambiar de estado se deben producir eventos que provoquen la transición de un estado a otro. Por último, la relación con el exterior es recogida mediante objetos de interacción. Un objeto puede sincronizarse y comunicarse con otros objetos mediante interacciones. En [Liddle 2001b] se puede encontrar un ejemplo de modelado de un sistema usando OSM. En realidad toma idea de varios modelos (modelo de clases, diagramas de estados, etc.) y propone sus nuevas formas de representar la estructura, el comportamiento y la interoperabilidad de los sistemas Pero lo más importante de OSM es que se puede traducir directamente a un lenguaje formal, OSM-Logic compuesto por fórmulas que sirven para representar a esos sistemas. Un importante beneficio de esta formalización es que se puede definir un modelo ejecutable a partir de un modelo OSM usando un razonamiento formal y lógico. Los autores de OSM presentan además una herramienta que nos permite conseguir este modelo ejecutable. 5.5. Estudio comparativo En este apartado se van a realizar una serie de comparaciones entre las propuestas estudiadas. Estas comparaciones nos servirán para analizar el grado de adecuación de estas metodologías a la hora de desarrollar un sistema de información global. Tomando las clásicas fases de todo proceso de desarrollo: especificación, análisis, diseño, codificación, pruebas y mantenimiento, la primera evaluación que vamos a realizar a las metodologías enunciadas nos indica cuáles de estas fases genéricas son tratadas en cada propuesta y cuáles de ellas pueden sernos útiles. Comenzando por la especificación de requisitos. La captura de requisitos es una fase que pocas propuestas tratan, solo HFPM, SOHDM y el Proceso Unificado hablan de ellas. Otras propuestas como OOHDM o EORM asumen que las propuestas de metodologías como OMT serían adecuadas para la captura de requisitos. Dentro de las técnicas que se ofrecen para realizar la captura de requisitos se ofrecen dos: los diagramas de casos de uso y los escenarios. Ambas resultan muy adecuadas para recoger las necesidades funcionales del sistema, pero no permiten especificar qué desea ver el usuario o cómo desea verlo. Como se ha venido diciendo, en los sistemas de información global la comunicación con el usuario es esencial para conseguir un buen resultado y las técnicas de casos de uso y los escenarios no resultan suficientes. Así, tras este estudio podemos concluir que es necesario establecer una propuesta para realizar la captura de requisitos que ofrezca la posibilidad de tener una comunicación fluida con el usuario para establecer correctamente las necesidades y objetivos del sistema. A la hora de plantear la comunicación y el estudio del entorno donde va a ser implantado el sistema, parece conveniente estudiar las propuestas que hace RNA. Si recordamos, esta propuesta no ofrecía mecanismos de diseño suficientes para el Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 62 desarrollo de todo el proceso y estaba orientada exclusivamente a realizar la especificación y el análisis de aplicaciones jurídicas en la web, pero estaba orientaba el desarrollo del proyecto al usuario. Sus ideas de estudiar el entorno de trabajo y las necesidades del sistema podría ser adecuada en una propuesta para el desarrollo de sistemas de información web. Si pasamos ahora a la fase de análisis, sí que encontramos más propuestas que recogen la necesidad de abordar esta fase de una manera más concreta. Es necesario que en esta fase se analicen y modelen todos los aspectos que van a ser críticos en los sistemas de información global. De las propuestas que encontramos, RNA y WSDM centran el análisis en el estudio de los grupos de usuarios, mientras que las otras se centran en realizar un modelo de clases a alto nivel para representar el modelo conceptual del sistema. Las dos ideas resultan adecuadas, pero ninguna es suficiente por sí misma. Los sistemas de información global pueden variar sustancialmente, sobretodo en su interfaz y en las posibilidades de trabajo, dependiendo de qué usuario sea el que trabaje en ese momento con él. También suelen ser sistemas que tienen una necesidad de almacenamiento interno de información muy compleja, por lo que es necesario estudiar y representar esta complejidad en las primeras fases del ciclo de vida y parece que el modelo de clases resulta una técnica adecuada para ello. Es necesario pues que en el análisis de un sistema de información web se estudie tanto el modelo conceptual como la variabilidad del sistema en función de los usuarios. Pero tampoco hay que dejar a un lado el estudio de la funcionalidad o de la interfaz, de la navegación o de la multimedia. Es por tanto necesario el realizar una propuesta capaz de analizar todos estos aspectos. La fase de diseño es la que se encuentra más desarrollada en todas estas propuestas. Todas ellas, excepto RMM y HDM, asumen el paradigma de la orientación a objetos, puesto que se ajusta más a las características de estos sistemas. Otra idea que es asumida por la mayoría de las propuestas es la necesidad de diferenciar en diseño la representación conceptual de los aspectos de navegación e interfaz. Planteemos el diseño conceptual. La gran mayoría de las propuestas utilizan los diagramas de clase para representar las necesidades de almacenamiento básicas del sistema, técnica que ha dado en todas ellas muy buenos resultados y que es adecuada asumir gracias también a lo estandarizada que está esta técnica. Con respecto al diseño navegacional, hay que diferenciar dos partes. Por un lado, la mayoría de las propuestas asumen la idea original de OOHDM y EORM de representar la navegación mediante un diagrama de clases. Sin embargo, cuando esta navegación varía en función del contexto en el que trabajemos, es necesario diferenciar cada uno de estos contextos. Las posibilidades de representar estos contextos son múltiples: los contextos navegacionales de OOHDM, las propuestas de Conallen y de Koch, etc. Sin embargo, todas estas resultan muy complejas en sistemas donde la navegación sea complicada. Es necesario, pues buscar alternativas de representación. Con respecto a la interfaz, casi todas las propuestas hacen hincapié en el uso de técnicas que representen la interfaz de forma abstracta y ven necesario la necesidad de representar tanto la estructura de las pantallas como su dinamismo. Sin embargo, estos modelos no parecen adecuados en su mayoría. Algunos de ellos, como los propuestos por Conallen y Koch son demasiados cercanos a la implementación y en muchos casos, sobretodo cuando las aplicaciones son complejas, es más fácil presentar la pantalla diseñada que el modelo. Otras propuestas como los ADV de OOHDM son demasiado ambiguas y no se indica muy bien el nivel de abstracción al que se debe llegar. Por ello, Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 63 es necesario normalizar la representación y marcar unas pautas que el diseñador pueda seguir para conseguir los prototipos. Algo que también se echa en falta en todas las propuestas es el plantear como necesario el estudio de la arquitectura del sistema o su división modular. Esto es debido a que las aplicaciones multimedia y de la web, que son las que ocupan a la mayoría de estas propuestas, son sencillas y no es necesario realizar este estudio. En los sistemas de información global es necesario plantearse estas actividades como esenciales en el diseño. Algo que también parece adecuado es el hacer uso de los patrones de diseño, que tanto se están usando actualmente. Sólo MacWeb hace referencia a esta técnica. El hacer uso de estos patrones puede llevar a la reutilización y tener un mantenimiento menos costoso del sistema. Con respecto a la implementación, son pocas las propuestas que no la referencia. Sin embargo, apenas ninguna de ella propone técnicas de implementación. Quizás las propuestas de Conallen y Koch se acercan un poco a esto pues sus modelos son tan cercanos a la implementación que es fácil obtener el código. También es interesante el trabajo de OO-Method y la herramienta que ofrece para trabajar con ella, que se encarga de generar el código. Las fases de prueba y mantenimiento son enunciadas en algunas propuestas, pero en ninguna de ellas se ofrecen técnicas o métodos a aplicar a la hora de realizar estas fases. Como resumen a esta idea, en la tabla 7 se han recogido todas las propuestas analizando en qué fases se centran cada una de ellas. Metodología Especific. Análisis Diseño Codificac. Pruebas Mantenim. HDM X RMM X X EORM X X MacWeb X X X OOHDM X X WSDM X X X OO-Method X X X X SOHDM X X X X X RNA X X HFPM X X X X X X OO/Pattern X X X X Proceso Unificado X X X X X Building Web Applications with UML X Specification and modeling of multimedia and hypermedia systems X A UML-Based Methodology for Hypermedia Design X X TABLA 7: FASES RECOGIDAS EN CADA PROPUESTA También se presenta en la tabla 8 un resumen de las técnicas propuestas y se indica qué metodologías la aplican. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 64 HDM RMM EORM MacWeb OOHDM WSDM ERD X X Modelo de clases X X X X Clases navegacionales: nodos, enlaces, etc. X X X Escenarios Técnicas GUI X X X X X Patrones de diseño X Casos de uso Técnicas y modelos propios X X OO-Method SOHDM RNA HFPM OO/Patterns ERD Modelo de clases X X X X Clases navegacionales: nodos, enlaces, etc. X X X X Escenarios X Técnicas GUI X X X Patrones de diseño X X Casos de uso X Técnicas y modelos propios X Proceso Unificado Building web applications with UML Specification an modeling of multiemedia and hypermedia systems A UML-Based Methodology for Hypermedia design ERD Modelo de clases X X X X Clases navegacionales: nodos, enlaces, etc. X X X Escenarios X X Técnicas GUI X X X X Patrones de diseño X X Casos de uso X X Técnicas y modelos propios X X TABLA 8: TÉCNICAS Y MODELOS USADOS EN LAS METODOLOGÍAS Puede verse que en las primeras propuestas la tendencia era de basarse en los ERD y que la tendencia ha evolucionado hacía el paradigma de la orientación a objetos. Vemos que en las últimas propuestas el uso de técnicas de captura de requisitos, como el uso de Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 65 escenarios o de casos de uso, se ha ido implantando. Esto ha sido debido a que, a medida que estas técnicas han evolucionado a sistemas más complejos, la necesidad de disponer de un mecanismo de definición de requisitos ha ido en aumento. Vemos también que hay bastantes modelos que proponen técnicas y modelos propios, aunque si analizamos el recorrido por todas las propuestas que hemos visto en el apartado anterior, veremos que son bastante similares. Por último, podríamos resaltar algunos aspectos importantes que parecen adecuados para el desarrollo de los sistemas de información global. Estos aspectos se podrían separar en: a) Una propuesta para sistemas de información global debe ofrecer mecanismos para recoger la variabilidad de la aplicación dependiendo del actor que lo utilice. En la primera columna de la siguiente tabla, vemos que sólo WSDM recoge este aspecto. b) En los sistemas de información global, para asegurar la reutilización y facilitar el mantenimiento, es adecuado separar los conceptos de diseño básico o diseño conceptual del diseño navegacional. Vemos en la segunda columna de la tabla 9 que este aspecto está recogido en más propuestas. c) Por la misma razón que en el apartado b, también resulta adecuado separar la navegación de la interfaz. En la tercera columna de la tabla 9, vemos que no todas las propuestas ofrecen esta posibilidad. d) Además, una propuesta para sistemas de información global debe ofrecer mecanismos para trabajar adecuadamente con la multimedia. Como se ve en la tabla 9, sólo las metodologías multimedia trabajan este aspecto. Metodología Variabilidad usuario Separación Conceptual- Navegación Separación Navegación- Interfaz Multimedia HDM X X RMM X X EORM X X MacWeb X X OOHDM X X X WSDM X X OO-Method X X SOHDM X X X RNA X HFPM X X OO/Pattern X Proceso Unificado X Building Web Applications with UML X Specification and modeling of multimedia and hypermedia systems X X A UML-Based Methodology for Hypermedia Design X X TABLA 9: RESUMEN DE ASPECTOS Para resaltar las ideas finales podemos indicar que: Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 66 ?? La gran mayoría de las propuestas usan técnicas de modelado orientado a objetos, algo bastante lógico pues la orientación a objetos resulta un paradigma bastante adecuado para el desarrollo de estas aplicaciones. ?? La gran mayoría de las propuestas se centran principalmente en diseño, la mayoría supone el análisis realizado o propone los casos de uso o los escenarios para realizarlos. ?? Un número muy alto de propuestas, indican que es necesaria la separación de la navegación y el diseño de la interfaz del diseño propiamente dicho. ?? Ninguna de ellas ofrece un marco de referencia para trabajar con los sistemas de información global, puesto que no cubren completamente el trabajo de todos los aspectos que caracterizan a este sistema. 6. Proyecto de investigación 6.1. Introducción Una vez vistas las tendencias actuales, se pueden concluir muchos aspectos. Por un lado, podemos observar la gran cantidad de modelos nuevos que aparecen moviéndose en torno a la misma problemática, sin que haya unanimidad ni siquiera en la definición de los términos. Los autores que se han estudiado coinciden sin embargo en algunos aspectos a destacar: ??La gran mayoría de las propuestas aceptan la orientación a objetos como un paradigma adecuado para el desarrollo de las aplicaciones en la web. Y dentro de ella, la nomenclatura de UML parece la más adecuada debido a que es la más ampliamente aceptada. ??Normalmente todos apoyan la necesidad de incluir aspectos de navegación e interfaz y la mayoría apuesta porque estos aspectos se trabajen de forma independiente. Esto da una mayor independencia entre los dos aspectos y permite mayor reusabilidad y mayor facilidad a la hora del mantenimiento tanto adaptativo como aumentativo. ??Todas asumen que los sistemas de desarrollo en la web tienen ciertos aspectos como son la multiplicidad de medios con los que se trabaja, el hiperespacio en el que se trabaja, la importancia de la interfaz adecuada e intuitiva, etc.; que hacen que estos sistemas sean más complejos que los sistemas clásicos por lo que es necesario la definición de nuevos modelos y nuevas técnicas que permitan capturar estas características. Sin embargo, se pueden encontrar algunos puntos que no quedan muy claros dentro de todas estas propuestas. El primero de ellos es que todos los autores en sus trabajos indican que en los sistemas de información la comunicación con los clientes debe ser más fluida y éste debe participar de forma más activa en el desarrollo del proyecto. Los sistemas de información global son sistemas complejos en los que su calidad se mide por la información que almacena y la presentación que hace de ésta. Por tanto, es necesario contar con la ayuda de un experto en la materia, el cliente, que guíe a los desarrolladores en el proceso [González 2001]. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 67 Pues bien, a pesar de que todos los autores asumen esta idea, la gran mayoría deja a un lado todos los aspectos de captura de requisitos. Algunos proponen técnicas como los casos de uso o los escenarios, pero sin aportar nada nuevo con respecto al uso de estas técnicas en este entorno y asumen que se aplican de la misma forma que en los sistemas clásicos. Al utilizar estas técnicas se echa en falta el apoyo de guías que nos ayuden a capturar la información que requerimos del usuario para tener un conocimiento adecuado del problema. Otro aspecto que se detecta es que hay metodologías que proponen un proceso de trabajo, más o menos completo, como HFPM y otras que proponen modelos para la representación del sistema, como OO-Method u OOHDM, pero ninguna de ellas ofrece una guía que indique qué hay que hacer en cada fase del proceso del desarrollo, qué hay que obtener y qué técnicas se pueden o se deben aplicar para ello. El trabajo que se propone realizar en este proyecto de investigación consiste precisamente en eso. Tomando las buenas ideas ya estudiadas por las propuestas que hemos ido analizando, vamos a definir un marco metodológico para sistemas de información global en el que se va a cubrir por completo el ciclo de vida del proyecto y en el que, para cada fase, el desarrollador va a tener una guía de cómo hacer las cosas, qué presentar al cliente y qué obtener después de cada fase. La propuesta en la que se pretende trabajar se fundamenta en la orientación a objetos y, tomando como base los razonamientos de los autores vistos hasta ahora, trata de forma especial los aspectos multimedia, de navegación y de interfaz, sin dejar a un lado los aspectos más clásicos de los sistemas software como son la funcionalidad o las necesidades de almacenamiento de información. A continuación se va a presentar una visión genérica de dicha propuesta en la se está trabajando actualmente. Tras esto se hará una evaluación de la misma y se presentará el estado en el que se encuentra la elaboración concreta de ésta. El trabajo de investigación está actualmente elaborándose, por lo que se encontrarán más desarrollados unos aspectos que otros. El proceso de trabajo que se está siguiendo en el desarrollo de la propuesta se basa en que una vez realizada la definición del ciclo de vida, se vayan estudiando los flujos de trabajo, de manera que para cada uno de ellos se analicen y proponga el proceso a seguir teniendo presente la experiencia de otros grupos de trabajo en el sector. Tras esto se hace una propuesta del producto a obtener y por último se hace una prueba real dentro del marco empresarial. Actualmente se está terminando el flujo de especificación y el flujo de análisis está en sus primeras fases. Los otros flujos de trabajo son meramente una propuesta que aún no ha sido pulida y que simplemente se introducen. 6.2. Bases de la propuesta Una vez analizada todas las propuestas, se han obtenido una serie de conclusiones que son ideas generales de todas ellas y que vamos a asumir en nuestra propuesta. El éxito que estas propuestas han tenido a la hora de utilizar estas ideas, avalan la decisión de tomarlas como adecuadas para nuestra propuesta. Por ello, nuestra metodología va a ser una metodología: - Orientada a objetos, - Que separa el aspecto de navegación del diseño básico, - Que separa la interfaz de la navegación. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 68 Nuestra propuesta debe además tener una serie de características añadidas: - Debe cubrir todo el ciclo de vida del proyecto. - Debe estar orientada al proceso, es decir, debe indicar qué hacer en cada momento del ciclo de vida. - Debe estar orientada al producto, es decir, en cada fase se indicará qué hay que obtener y el formato que deberá tener para ello. - Debe ser sencilla, sobretodo en sus primeras fases, para facilitar la participación del cliente y del usuario. - Debe ser completa, para cubrir todas las necesidades del desarrollador y ofrecer una semántica suficiente como para trabajar de forma adecuada todos los aspectos críticos que se han venido destacando de los sistemas de información global. Partiendo de estas premisas, en este documento se presenta una visión global de toda la metodología. El objetivo final es ir concretando cada una de las ideas que se indican de forma general en este resumen, hasta conseguir una propuesta completa y adecuada para este entorno. A continuación se va a presentar esta visión genérica, comenzando por una presentación del ciclo de vida. Tras esto se analizarán cada uno de los flujos de trabajo indicando sus objetivos, las técnicas que se usan y los productos a obtener en cada uno de ellos. Finalmente se hará una valoración general de la propuesta y se comentará el estado de desarrollo actual de la misma. 6.3. Propuesta metodologíca para el desarrollo de sistemas de información global 6.3.1. Ciclo de Vida Para definir el ciclo de vida de nuestra propuesta, partimos de la idea de dividir la vida del proyecto en flujos de trabajo. El ciclo de vida comprenderá un total de cinco flujos de trabajo: especificación, análisis, diseño, codificación y pruebas. En principio estos flujos de trabajo se realizarán de forma consecutiva, pero si nos basamos en la realidad de los proyectos software, desde un determinado flujo es necesario volver a flujos anteriores para redefinir nuevos aspectos. Por ello, nuestra propuesta será secuencial pero permitirá iterar y volver a flujos anteriores. En las propuestas que se han presentado, en el flujo de diseño se estudiarán tres aspectos diferentes: el diseño básico de la aplicación, el diseño de la navegación y el diseño de la interfaz. Asumiendo esta idea de estudiar los aspectos de navegación e interfaz de forma independiente, el flujo de diseño se va a dividir en nuestra propuesta en tres actividades: diseño básico, en el que se estudia el diseño conceptual del sistema; el diseño navegacional, en el que se estudia el sistema de navegación del sistema; y el diseño de interfaz abstracta, el que se estudian los aspectos de presentación e interacción con el usuario de forma abstracta. Esta división que aparece reflejada en muchas propuestas, también se ve reflejada en todos los flujos de trabajo de la metodología que se está presentando, no sólo en diseño. Así , ya desde los primeros flujos de trabajo se hace una separación entre lo que se almacena en el sistema, lo que se puede hacer con el sistema y de qué forma se va a presentar la información al usuario. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 75 aparecen en el sistema para nuestro caso son dos, una en base al perfil que pueden desempeñar en el sistema y otra en base al área de investigación que ocupen. En el primero de ellos nos encontramos tres roles básicos: ?? Los usuarios del centro investigador. Son los que más privilegios tienen, pueden dar de alta, modificar o consultar cualquier dato. Además son los encargados de validar la información del sistema. ?? Los catalogadores. Estos usuarios van a poder introducir información en el sistema, pero la información que introduzcan no se considerará definitiva hasta que no sea validada por un usuario de la organización investigador. En principio se pueden localizar en cualquier lugar del mundo. ?? Los usuarios por internet. Solo podrán realizar consultas sobre los datos. En la clasificación según el área de investigación nos encontramos a los arqueólogos, los etnólogos y los artistas. La diferencia entre unos y otros son los datos que ven. Por ejemplo, los datos sobre actividades solo interesan a los etnólogos, o los datos sobre iconografías solo interesan a los artistas. Una vez identificados los actores básicos, habría que definirlos y recogerlos en el documento de especificación de requisitos. Para ello, se utilizará nuevamente un patrón. Así por ejemplo para los arqueólogos podría ser la que se muestra a continuación en la tabla 14. AC-01 Arqueólogo Objetivos asociados OBJ-01: Gestionar los bienes muebles OBJ-05: Gestionar los perfiles investigadores Clasificación Este es uno de los posibles roles dentro del sistema cuando hacemos una clasificación de los actores en base al perfil investigador del actor. Descripción El sistema deberá prever el tratamiento de los usuarios que pertenecen al grupo descrito como arqueólogo que se refiere a personas que entran en el sistema mediante el perfil de investigador arqueólogo. TABLA 14: EJEMPLO DE DESCRIPCIÓN DE UN ACTOR BÁSICO Nuevamente este patrón es sólo una visión general del definido en la propuesta. Tras esta definición, se puede analizar la incompatibilidad de roles entre dichos actores, de tal forma que dos actores básicos declarados incompatibles entre sí no pueden formar parte como actores componentes de un mismo actor derivado. Dos actores básicos se dice que son incompatibles cuando sus roles asociados no pueden ser asumidos conjuntamente por ningún actor derivado. La incompatibilidad se puede presentar entre actores básicos del mismo grupo (mismo criterio de clasificación) o de grupos diferentes (diferentes criterios de clasificación). Para definir la incompatibilidad entre actores se utilizará una tabla de doble entrada como la mostrada en la tabla 15. Cada fila y cada columna corresponde a un actor básico, de manera que en cada fila se indicará las incompatibilidades que presente el actor correspondiente. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 76 Actores básicos Usuario del centro Catalogador Usuario internet Arqueólogo Artista Etnólogo Usuario del centro - X X Catalogador X - X Usuario internet X X - Arqueólogo - Artista - Etnólogo - TABLA 15: DEFINICIÓN DE LA DISJUNCIÓN ENTRE ACTORES BÁSICOS La disposición de actores por fila y columna se ordenará de igual forma en ambos casos, reflejando una estructura plana en la que no se diferencian los grupos de actores básicos referidos anteriormente. La identificación de dichos grupos solamente servirá a efectos de explicación del criterio por el que se identifica al actor. Se aconseja, por motivo de claridad, que los actores del mismo grupo aparezcan junto en las filas y columnas de la tabla anterior. En el ejemplo, las tres primeras posiciones la ocupan los resultados de la clasificación mediante su perfil en el sistema y las tres últimas los resultados de la clasificación mediante su carácter investigador. Una “X” en la intersección de una fila y una columna de la tabla indica que los actores correspondientes son incompatibles. El “-” indica la imposibilidad de indicar incompatibilidad entre un actor y él mismo. Así, se observa que en los resultados de la clasificación mediante el perfil, los actores son disjuntos. Mientras que en la clasificación según el carácter investigador no. De esta forma, podría haber un usuario que desempeñara los roles de etnólogo y arqueólogo, por ejemplo. Pero estas clasificaciones realmente proporcionan los actores básicos del sistema. Sin embargo, en el sistema de los bienes muebles, como en la mayoría de los sistemas de información global aparecen roles derivados de interés. Un actor derivado es todo actor que se puede definir a partir de los actores básicos o de otros actores derivados, como conjunción de los roles correspondientes a los actores componentes. El rol asociado a un actor derivado asumirá los roles correspondientes a los actores que lo componen. Así, para nuestro ejemplo, un usuario no tiene porqué ser etnólogo o artista. Puede tomar ambos roles a la vez. La diversidad de actores derivados va a tomar un interés especial a la hora de capturar los requisitos funcionales y los de interacción, puesto que por ejemplo, un actor que tome los roles de artista y etnólogo y sea un usuario del centro investigador a la vez, no verá los mismos datos ni podrá realizar las mismas operaciones, que un usuario de internet que sea arqueólogo. Para realizar la definición de los actores derivados se utilizará una tabla de doble entrada como la tabla 16. Cada columna corresponderá a un actor, básico o derivado, que forme parte de al menos un actor derivado. De esta forma, encontramos en las primeras columnas a los actores básicos y en las cuatro últimas a actores derivados definidos en la misma tabla. Así el actor ArqArEt representa a un usuario que actúa en el sistema como arqueólogo, como artista y como etnólogo. Cada fila corresponderá, como se ve, a un actor derivado. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 77 El símbolo “^” permite indicar que el rol correspondiente al actor de la columna forma parte del actor correspondiente a la fila. El “-” indica que un actor derivado no puede ser parte componente de él mismo. Así, un actor ArqEtC es un catalogador que actúa en el sistema como arqueólogo, etnólogo y con perfil de catalogador. Esta complejidad requiere un importante estudio sobre qué información se muestra y cómo se ve la información por cada uno de los actores. Por ello, esta definición de actores será crítica para definir los requisitos funcionales y de interacción ya que, lo que se puede hacer con el sistema y cómo se le van a presentar al usuario estos datos, va a depender directamente del tipo de usuario con el que estemos trabajando. Actor Arqueólogo Artista Etnólogo Usuario Centro Catalogador ArArq ArEt ArqEt ArqArEt ArArq ^ ^ - ArEt ^ ^ - ArqEt ^ ^ - ArqArEt ^ ^ ^ - ArArqU ^ ^ ArEtU ^ ^ ArqEtU ^ ^ ArqArEtU ^ ^ ArArqC ^ ^ ArEtC ^ ^ ArqEtC ^ ^ ArqArEtC ^ ^ TABLA 16: ACTORES DERIVADOS Otra de las relaciones que se pueden detectar entre los actores es la de generalización/especialización. Un actor especializado es todo actor que se puede definir a partir de los actores básicos o de otros actores especializados mediante una relación de generalización [Jacobson 1999]. El rol asociado a un actor especializado heredará los roles asociados a los actores de los que se especializa y podrá añadir semántica específica al rol que desempeña. La definición de los actores especializados se realizará mediante la notación de generalización de UML y según el patrón mostrado en la tabla 14 añadiéndole el campo hereda de en el que se indica el identificador del actor, ACT-X, del que hereda. En el ejemplo de los bienes muebles no aparece ninguno de estos casos, pero no es poco común encontrarlo en los sistemas de información global. Actividad 4: Identificar y definir los requisitos funcionales Los requisitos funcionales van a responder a la pregunta de ¿qué podrá hacer el sistema con la información que almacena?. Esta pregunta nos la responden los casos de uso, técnica que se usará para capturar estas necesidades. Estos diagramas se describen mediante una información gráfica (diagramas de casos de uso) y una información textual. En los casos de uso aparecen dos elementos importantes, el caso de uso en sí y Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 78 los actores. Los actores se definieron en la actividad anterior, así que aquí se hará referencia a esas definiciones. Para recoger la definición de los casos de uso parece adecuado el patrón propuesto en [Durán 2000] que se asumirá en esta propuesta. Sin embargo, en nuestra propuesta se hace la especificación de los casos de uso en base a los actores que se definieron en la etapa anterior. Es decir, al definir un caso de uso se indicará una lista de todos los actores que pueden ejecutar ese caso de uso. De esta forma se obtiene una visión funcional del sistema orientada a los actores. Para nuestro ejemplo de los bienes muebles vemos en la figura 33 uno de los casos de uso. Es el caso de uso que representa que un usuario da de alta un nuevo bien mueble. FIGURA 33: EJEMPLO DE CASO DE USO Para que la definición de este caso de uso sea completa, es necesario acompañarla de un patrón que lo defina de forma más concreta. El patrón asociado a este caso de uso se presenta en la tabla 17. RF-01 Dar de alta bienes muebles Objetivos asociados ?? OBJ-01: Gestionar los bienes muebles Descripción El sistema deberá comportarse tal y como se describe en el siguiente caso de uso cuando el usuario pulse la opción de dar de alta a los bienes Precondición El usuario debe estar dado de alta en el sistema Actores ?? AC-04: Usuario Centro ?? AC-05: Catalogador Paso Acción 1 Ejecutar el caso de uso de Entrar en la gestión de Bienes Muebles 2 El sistema da entrada al usuario 3 El usuario indica la provincia, el municipio y el inmueble en el que se ubica el bien 4 El sistema solicita la denominación 5 El usuario introduce la denominación 6 El sistema da de alta el bien asignando un nuevo código y permite al usuario editar todos los datos referentes al bien 7 El usuario introduce los datos que desee y solicita salir Secuencia normal 8 El sistema vuelve al menú inicial Postcondición ninguna Paso Acción 1 El usuario no está recogido en el sistema, por lo que se apaga el acceso al mismo Excepciones 5 El bien ya estaba dado de alta. Se emite un mensaje al usuario y se abandona la aplicación Frecuencia esperada 10 veces /mes TABLA 17: EJEMPLO DE PATRÓN PARA UN CASO DE USO En este ejemplo se puede ver cómo hay que asociar el caso de uso a una lista de objetivos y cómo hay que indicar la secuencia normal de trabajo que éste tiene. Además habrá que indicar qué roles pueden asumir el papel del actor que participa en él y las Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 79 precondiciones y postcondiciones que deben cumplirse antes y después de su ejecución. Así como las excepciones que se pueden producir durante su ejecución. Nuevamente también es este patrón más completo en la propuesta genérica. Como vemos aquí se indica nuevamente qué objetivos se cubren al realizar este caso de uso. Además se especifica de forma clara la secuencia de pasos a seguir para que se pueda realizar la operación de dar de alta un bien. Actividad 5: Identificar y definir los requisitos de interacción Llegados a este punto, ya se ha recogido qué hay que almacenar en el sistema, quién va a usar el sistema y qué se puede hacer en el sistema. Sin embargo, para los sistemas de información global, la interfaz es un aspecto crítico que es fundamental en el desarrollo. En el entorno actual, una aplicación no sólo debe ofrecer al usuario toda la información y funcionalidad que éste le pida, debe además darle esa información y funcionalidad en el momento apropiado y de la forma apropiada. El orden el que se muestre la información o la forma en que se muestre es un aspecto crucial. En esta actividad se van a definir lo que conoceremos como requisitos de interacción. Un requisito de interacción va a ser una forma de representar como se va a mostrar al usuario la información. Basándose en criterios establecidos por el cliente, los datos concretos de los requisitos de almacenamiento de información se van a mostrar agrupados en diferentes prototipos de visualización. Además, cada uno de estos requisitos de interacción llevará asociado una funcionalidad. La funcionalidad vendrá dada por cada uno de los requisitos funcionales que se puedan ejecutar en ese requisito de interacción. Los requisitos de interacción van a estar compuestos por dos aspectos: los criterios de búsqueda y los prototipos de visualización. Los primeros van a usar un lenguaje seminatural en el que se va a recoger cómo el usuario quiere recuperar la información. Para ello, se usará una propuesta de lenguaje denominado BNL (Bounded Natural Language) [Brisaboa 1999], que mediante la definición de frases indicará como el usuario va a cuestionar al sistema. Los segundos van a definir cómo se mostrará la información al usuario y la funcionalidad que tiene asociada esa muestra de información. Para definir estos requisitos en el documento de requisitos, se hará uso de dos patrones: uno para las preguntas y otro para los prototipos de visualización. Los primeros recogerán las frases escritas en BNL, presentarlos obligaría a explicar esta técnica, que queda un poco fuera del objetivo del documento. Un ejemplo de patrón para los prototipos de visualización se recoge en la tabla 18. Este es el prototipo de visualización describe como se va a interactuar con el usuario para mostrarle los datos de un bien mueble. Se va a recoger qué datos se les mostrará y como puede entrar y salir de la pantalla de alta de un bien. Además se indica qué actores podrán ver la pantalla y qué datos verá cada uno. El campo actor/es es quizás uno de los más relevantes. En él se recoge la lista de los identificadores de actores que podrán hacer uso del requisito. Estos actores pueden ser derivados o básicos, pero han debido de ser definidos en la actividad 3. Aquí como vemos pueden hacer uso del requisito los arqueólogos, los etnólogos, los artistas, los Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 80 catalogadores, los usuarios de internet o los usuarios del centro. Cualquier actor que tenga al menos alguno de estos roles podrá interactuar en este requisito. PV-01 Pantalla de datos de un bien mueble Objetivos asociados OBJ-01: Gestión de los bienes muebles Actor/es AC-01: Arqueólogo AC-02: Etnólogo AC-03: Artista AC-04: Catalogador AC-05: Usuario del Centro AC-06: Usuario de internet Descripción El sistema deberá permitir la visualización de los datos concretos que se muestran a continuación y la navegación expresada. Condición El código debe estar dado de alta o ser nulo Frases ?? PR-01 Funcionalidad asociada Si Actor = Catalogador o Actor = Usuario del Centro ?? RF-01: Dar de alta bienes Información visualizada ?? RA-01.Código del bien ?? RA-01.Denominación ?? RA-01.Otra denominación ?? RA-01.Titulado/Representado ?? RA-01.Ubicación habitual ?? RA-01.Ubicación temporal ?? RA-01.Acceso ?? RA-01.Cronología ?? RA-01.Certeza ?? RA-01.Imágenes ?? RA-01.Períodos Históricos ?? RA-01.Estilo ?? RA-01.Tipologías Si Autor = Artista ?? RA-01.Autor Salidas PV-12 Entradas PV-12 PV-11 TABLA 18: PATRÓN PARA LA RECOLECCIÓN DE PROTOTIPO DE VISUALIZACIÓN Otro campo interesante es el de frases. Aquí hay una variación en base a si el prototipo es para un único actor o para varios. Si es para uno solo, se indican las frases teniendo en cuenta que las frases debieron ser definidas para el actor en cuestión, pero si hay varios actores puede ser que las frases difieran de uno a otro. Es este caso, en este campo se colocará una sentencia condicional que indique como sería el campo para cada actor.Por ejemplo podríamos pensar en un caso de prototipo para los actores AC- 01, AC-02, AC-03 y AC-04 cuyas frases difieren para los dos primeros y son iguales para los dos últimos, el patrón quedaría como se muestra en la tabla 19. El campo de las condiciones permite indicar las condiciones que los datos mostrados en el requisito de interacción van a cumplir. Se definen basándose en los valores de los parámetros de entrada. La definición de estos datos puede hacerse en lenguaje natural o en un lenguaje más formal que sea definido por la organización. Igual que en el campo anterior, este campo se puede enriquecer con expresiones condicionales que permitan individualizar el campo para cada actor, de la misma forma que el caso de los parámetros de entrada. En la funcionalidad asociada se recoge cada uno de los requisitos funcionales que se van a poder ejecutar desde el requisito de interacción. Este campo, como en los Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 81 anteriores, puede estar condicionado a los parámetros de entrada que haya o a los actores definidos. En nuestro ejemplo vemos que si tenemos un catalogador o un usuario del centro podrán ejecutar el requisito de dar de alta un nuevo bien. El campo más relevante del patrón es el de información visualizada. En él se mostrarán, en orden de aparición, cada uno de los datos que el requisito va a mostrar. Para ello, se hace referencia al requisito de almacenamiento que lo guarda y al dato concreto de éste que se muestra. Igualmente, estas referencias a los datos concretos se podrán enriquecer con estructuras condicionales que permitan recoger las pequeñas diferencias entre los actores. Los campos de salida y de entrada recogen desde qué otros requisitos de interacción se puede llegar al que se define en el patrón y a qué otros se puede ir desde éste respectivamente. Con esto se tiene definida la navegación por el sistema. En nuestro ejemplo desde este requisito podríamos navegar al catalogado como RI-12 y a él podríamos acceder desde el RI-11 y el RI-12, que deberán ser definidos en el documento de requisitos. Actores ACT-01 ACT-02 ACT-03 ACT-04 Descripción El sistema deberá permitir la visualización de los datos concretos que se muestran a continuación y la navegación expresada. Parámetros de entrada SI (actor = AC-01) <Frases para el actor AC-01> ACT-01> SI (actor = AC-02) <Frases para el actor AC-02> EN OTRO CASO <Frases para el resto de actores> TABLA 19: EJEMPLO DE ESTRUCTURA CONDICIONAL Actividad 6: Identificar y definir los requisitos no funcionales Para completar la especificación de requisitos, es necesario revisar de nuevo los objetivos para determinar otros requisitos que por su carácter no hayan sido catalogados anteriormente. Algunos de estos requisitos serán los requisitos de comunicaciones, de fiabilidad, etc. Para recoger estos requisitos se hará uso de lo indicado en la Metodología para la Elicitación de Requisitos[Durán 2000]. En ésta, los requisitos aparecen nuevamente definidos mediante un patrón que recoge toda la información necesaria para describirlos.En la tabla 20 vemos un ejemplo para los bienes muebles en el que se recoge la necesidad de que el sistema permita hacer backup. RNF-01 Copia de seguridad Objetivos asociados OBJ-05: Conseguir un sistema estable y seguro para la catalogación de los bienes Descripción El sistema deberá ofrecer la posibilidad de realizar backups periódicos de la información, así como la recuperación en caso de pérdidas de la información. Comentarios Este requisito es esencial porque hay información reservada de los bienes TABLA 20: EJEMPLO DE REQUISITO NO FUNCIONAL Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 82 6.3.3. Análisis El flujo de trabajo de análisis de sistema tiene esencialmente tres diferencias con respecto a la mayoría de las propuestas. Éstas son, como ya hemos enunciado: los diferentes medios de almacenamiento de información, la importancia de la interfaz y los aspectos navegacionales. Por ello, habrá que incluir el estudio de estos aspectos en el análisis para después pasarlos e incluirlos en el diseño. De esta forma, en análisis debemos conseguir un modelo de clases que represente al sistema. Este modelo irá acompañado por un modelo dinámico cuando resulte necesario, así como por una estructuración en paquetes cuando su complejidad sea alta. Además, en análisis se hará un refinamiento de los casos de uso para concretizarlos y asignar responsabilidades y participaciones de las clases de análisis. También se consolidará la navegación y se propondrán los primeros prototipos de interfaz. De forma esquematizada, el flujo de trabajo de análisis debería asumir las siguientes actividades: ?? Actividad 1: Construir un modelo conceptual de análisis. o Tarea 1.1- Identificar y definir las clases del sistema. o Tarea 1.2- Agrupar las clases del modelo en paquetes y establecer relaciones entre ellos si es necesario. o Tarea 1.3- Realizar el refinamiento de los casos de uso para concretizarlos y asignar responsabilidades y participación en ellos de las clases de análisis. o Tarea 1.4- Definir el modelo dinámico de las clases de análisis ?? Actividad 2: Refinar el modelo de navegación del sistema. ?? Actividad 3: Definir los prototipos de interfaz. A continuación vamos a ver cada una de estas actividades. Sin embargo, hay que tener en cuenta que este flujo de trabajo esta actualmente en fase de desarrollo. Por ello, la aplicación al ejemplo y la definición de estas actividades no va a estar tan detallada como las del flujo anterior. Actividad 1: Construir el modelo conceptual del sistema Partiendo de los requisitos de almacenamiento de información y de la definición de los actores, se debe realizar el modelo conceptual del sistema. Esto consiste en realizar un modelo de clases, que mediante la nomenclatura de UML represente la estructura conceptual de la aplicación. Los patrones de los requisitos de almacenamiento de información y de definición de naturaleza de los medios, definidos en la actividad 1 del flujo de definición de requisitos, es una definición estructura que está pensada para que, a partir de ella se pueda obtener de una forma mecánica, el modelo conceptual del sistema. No vamos a entrar aquí a definir cada una de las pautas a seguir para conseguir este modelo a partir de nuestros patrones definidos, pero podemos indicar que a groso modo, cada requisito de almacenamiento y cada naturaleza va a traducirse a una clase, cuyos atributos van a ser los datos concretos. Además a partir de estos datos, cuando su naturaleza sea otro requisito, una nueva naturaleza o cuando su cardinalidad sea mayor a 1, se van a definir las asociaciones entre estas clases. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 83 Una vez conseguido, como se ha comentado, el modelo de clases básico, se debe estudiar éste para detectar si es necesaria la división en paquetes del mismo. Además, será necesario estudiar los casos de uso que se vieron en el flujo de especificación de requisitos, para definir los métodos asociados a cada clase. También existirán en la metodología que estamos desarrollando pautas para conseguir esta definición. Realizando estas tareas y tomando únicamente la definición del requisito de almacenamiento RA-01 que vimos en el apartado anterior, podríamos obtener un modelo de clases similar al que se muestra a continuación en la figura 34. Estudiando cada requisito del sistema iríamos consiguiendo ampliar este modelo. FIGURA 34: DIAGRAMA DE CLASES DE ANÁLISIS También a partir de los casos de uso, se puede detectar aquellas clases que tienen asociado un determinado dinamismo. El dinamismo de cada clase que tenga asociado un modelo dinámico vendrá recogido en el documento de análisis a través de un diagrama de estados [Jacobson 1995]. En la figura 35 vemos el que correspondería a la clase bien mueble de nuestro ejemplo Al igual que en el flujo de trabajo de especificación de requisitos, el flujo de análisis lleva asociado un documento en el que se recogen los resultados de éste. En dicho documento se recogen no solo los diagramas de clases, de paquetes y de diagramas de estados, sino que además se debe recoger un diccionario de datos que elimine la ambigüedad que puede aparecer en estos modelos. En la metodología se presentará también el formato de este diccionario. No vamos a entrar en definirlo por la generalidad de este documento. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 84 FIGURA 35: DIAGRAMA DE ESTADOS PARA LOS BIENES MUEBLES Actividad 2: Refinar el modelo de navegación del sistema Cuando ya se ha representado el modelo conceptual del sistema, es necesario estudiar y refinar el modelo navegacional del sistema que estamos definiendo. En los requisitos de interacción se capturó cómo se va a mostrar la información al usuario y cómo se puede navegar a través de estos módulos de información. Sin embargo, para que la estructura de la navegación sea consistente debe cubrir una serie de aspectos. Por ejemplo, el usuario debe tener la posibilidad de llegar a toda esta información desde un punto que podríamos definir como pantalla inicial. Se debe garantizar que la navegación es consistente. Para ello, en esta actividad se definen lo que se denominarán nodos y clases de navegación. Los nodos serán elementos que contienen información sobre un determinado aspecto. Prácticamente se van a corresponder con cada requisito de interacción. Por su parte, las clases de navegación van a ser elementos que van a conectar los diferentes nodos que se definan. Van a ser por ejemplo menús, diccionarios o rutas que indiquen cómo va a conectarse la información, definiendo así la estructura de navegación del sistema. Para definir estos elementos nuevamente se va a ser uso de los patrones de manera que quedarán definidos de forma estructurada y completa. Además, la metodología ofrecerá una serie de pasos para conseguir estos elementos. Una vez definidos estos elementos, habrá que estudiar la consistencia del modelo de navegación. Para eso también se propondrán técnicas que de forma metódica permiten asegurar esta consistencia, indicando si el modelo es completo y adecuado a las necesidades. Actividad 3: Generar los prototipos de interfaz Partiendo de los requisitos de interacción y de los elementos de navegación definidos en la actividad anterior se va a hacer una definición de la interfaz de la aplicación. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 91 Actividad 3: Diseñar la interfaz abstracta Una vez que se tienen diseñado los aspectos de navegación, pasamos a la especificación de los aspectos de interfaz. El hecho de separar los aspectos de navegación de los aspectos de interfaz permite diseñar distintos interfaces para un mismo modelo navegacional. El diseño de la interfaz abstracta se refiere a revisar los prototipos que se han definido en la fase de análisis y enriquecerlos con todos los nuevos aspectos de diseño conceptual y navegacional. Para el diseño de la interfaz abstracta se propone el uso de las vistas abstractas de datos [Cowan 1995] (ADVs). Las ADVs son objetos que tienen un estado y un interfaz. Son objetos abstractos que sólo representan el estado y la interfaz, sin hacer referencia a la implementación. Mediante el uso de los ADVs representaremos la estructura de la interfaz, cada ADV representa la interfaz que se muestra al usuario de un objeto de navegación, de una parte de un objeto del modelo navegacional o de un conjunto de ellos. Sin embargo, entre los ADVs y las clases del modelo navegacional que tengamos en nuestro sistema del subflujo anterior, se establecen relaciones que hay que recoger. Para expresar estas relaciones se usará el diagrama de configuración y los diccionarios de datos de los ADVs. Si a todo esto añadimos que debemos recoger el dinamismo que hace cambiar las interfaces, es decir, como cada ADV responde a los eventos externos, aparece la necesidad de usar una nueva técnica que nos permita recoger el dinamismo del sistema de interfaces. Esta técnica la constituyen los diagramas de estado. Esta es la idea general que se propone para esta actividad. Sin embargo hay algunos aspectos que hay que revisar en ella. Por un lado, un punto abierto al estudio de los ADVs es la necesidad de normalizar la nomenclatura usada para representarlos. La propuesta metodológica, en su versión final, debe incluir una normalización de esta nomenclatura así como las pautas a seguir para conseguir los ADVs en función de los prototipos de análisis y los modelos de diseño conseguidos en el diseño conceptual y navegacional. En principio el resultado sería algo similar a los prototipos de interfaz del análisis, pero aquí ya recogeríamos aspectos funcionales y la estructura de la navegación estaría más retocada con los aspectos del diseño navegacional. Los ADVs, además irán acompañada de un diccionario de datos y un diagrama que se denomina diagrama de configuración, en los que se indicara qué actor o actores pueden hacer uso de ella y la relación que existe entre los atributos, enlaces y aspectos funcionales que aparecen en ella y entre el modelo navegacional. La nomenclatura de este diagrama y de los diccionarios de datos es otro aspecto que debe ofrecer la metodología y que aún no está desarrollado. El diseño de las ADVs representa la estructura dinámica de la intefaz. Sin embargo existe la necesidad de recoger como el usuario interactúa con el sistema. Por ello, es necesario enriquecer este diseño con las máquinas de estado de las ADVs y de las clases navegacionales que se vean afectados por la interacción con el usuario. Esto nos serviría para representar cómo cada uno de estos ADVs reaccionan ante los eventos y cómo afecta esto al sistema navegacional establecido. Aunque los diagramas de estados es ya una técnica consolidada para la representación del dinamismo, es necesario que la metodología estudie la adecuación al diseño de interfaz abstracta en los sistemas de información global. Esta es otra tarea de las que queda pendiente. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 92 6.3.5. Implementación Llegar a un programa ejecutable tras la realización de las fases anteriores no es algo complejo. En este flujo de trabajo, la tarea fundamental es conseguir un programa ejecutable que implemente a los modelos conseguidos en diseño. En el flujo de implementación se deben implementar la arquitectura, las clases y los subsistemas, integrándolos para conseguir el sistema final. Además hay que implementar el sistema de navegación definido y los prototipos abstractos diseñados. Una tarea esencial a tener en cuenta en este flujo es decidir en qué entorno habrá que realizar la implementación. Algunas veces este aspecto viene definido en la especificación de requisitos pero en otros casos no se sabe en qué lenguaje se trabajará hasta que no se ha diseñado el sistema. Una vez definido el entorno y con las especificidades del diseño, la tarea de la implementación se convierte prácticamente en traducir a código lo que se ha diseñado. Así por ejemplo, del diseño básico se extrae información sobre la arquitectura del sistema, los sistemas de almacenamiento a usar y la estructura de la base de datos que se le asociará. Con el diseño de la interfaz abstracta y el diseño de la navegación se puede conocer qué pantallas hay que realizar, los eventos que la afectan, quién puede trabajar con ellas y cómo se puede acceder y salir de cada una de estas pantallas. Sí que habría que aplicar técnicas para hacer el diseño visual de estas pantallas, pero nada más. Además, como en el flujo de diseño se propone el uso de patrones de diseño estándar, podemos saber y aplicar técnicas conocidas para conseguir el código asociado a estos patrones. Este flujo de trabajo es uno de los menos desarrollados aún. Hasta el punto de que aún no se han definido las actividades a realizar. 6.3.6. Pruebas Uno de los aspectos no contemplados en un elevado número de propuestas metodológicas es el que tiene relación con la definición de las pruebas que se han de realizar a un sistema para garantizar que el mismo responde a la definición de requisitos que para él se hizo. Aunque la definición concreta de las pruebas que se deben aplicar a un sistema deberá concretarse en el momento de realizar su diseño, toda propuesta metodológica debe definir las posibles estrategias a seguir, las técnicas a utilizar para realizarlas y el momento de hacer uso de cada una de ellas. En el marco de la propuesta para el desarrollo de sistemas de información global que se está presentando, en el flujo de pruebas se debe elaborar, diseñar e implementar el plan de pruebas. Este plan de pruebas no solo debe recoger las pruebas a realizar, además debe indicar el orden de realización. Una vez realizado, hay que ejecutar el plan de pruebas y elaborar una memoria de resultados del mismo. Igual que el flujo anterior, el flujo de pruebas tampoco está muy desarrollado aún. La idea es que se ofrezca también las actividades a desarrollar y los productos a obtener para conseguir ese plan de pruebas y el resultado de su ejecución. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 93 6.4. Estado actual, puntos abiertos y trabajos publicados La propuesta metodológica en la que se está trabajando está aún en sus comienzos. Nuestro trabajo comenzó realizando un estudio de la situación actual. Para ello, contactamos con personas que se estaban moviendo en el tema asistiendo a congresos específicos en este ámbito y analizando los trabajos publicados. Una vez conocida la necesidad, se comenzó a trabajar en definir esta propuesta. La primera definición de la propuesta [Escalona 2000a] era una visión general de necesidades basada principalmente en los trabajos de Rossi y Schwabe en OOHDM y del Proceso Unificado. Siguiendo el orden lógico, comenzamos con el primer flujo de trabajo, la especificación de requisitos. Para definirlo, estudiamos propuestas como las enunciadas de Durán o de Robertson. Así ha surgido una primera definición de fase. Esta propuesta de definición de requisitos ha dado origen a algunos trabajos que han sido enviados a diferentes congresos. Actualmente estamos cerrando la fase de especificación y hemos comenzado con la fase de análisis en la que estamos definiendo las actividades y técnicas a aplicar. Es necesario comentar que actualmente estamos trabajando conjuntamente con la Universidad de A Coruña de manera que la metodología pueda complementarse con los trabajos que ellos están realizando en temas de arquitectura [Brisaboa 2001]. Estamos usando y basándonos en trabajos paralelos dentro del propio grupo MADEIRA como son los trabajos en definición de interfaz [González 2001], de búsquedas eficientes [Gasca 2001] o de definición de arquitecturas [Cordero 2000]. También hemos visto desde el principio la necesidad de no definir una propuesta que al final no tenga aplicabilidad en el entorno industrial. Por ello, se están desarrollando trabajos a través de la organización FIDETIA (www.fidetia.us.es) en dos proyectos en los que estamos aplicando y mejorando nuestras propuestas. Estos proyectos cubren ámbitos tanto en empresas públicas, como es el caso del Instituto Andaluz de Patrimonio Histórico, como en empresas privadas, como es el caso de Sadiel. Actualmente en estos entornos empresariales hemos puesto en práctica exclusivamente la fase de especificación. Los resultados nos han servido para mejorar la propuesta y acercarla más a la realidad. En definitiva hemos observado que la propuesta ha sido bastante bien acogida tanto por los clientes como por el resto de programadores, analistas y diseñadores del sistema. Nuestro objetivo es el de terminar de definir nuestra metodología en cada uno de sus flujos de trabajos y seguir teniendo esta colaboración con las empresas para acercar la propuesta a los entornos profesionales. Otro punto que actualmente se está realizando es el desarrollo de una herramienta CASE que ayude al seguimiento de la propuesta y valide los modelos realizados. Para finalizar con este apartado, recogemos a continuación las publicaciones que actualmente tenemos en el tema. Algunas de ellas coinciden con las recogidas en la bibliografía pues han sido tomadas como referencia para la realización de este trabajo. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 94 Publicaciones en revistas ??M.J. Escalona, J.Torres, M.Mejías. “Aplicación de los sistemas de tratamiento de bibliotecas digitales al Sistema de Información del Patrimonio Histórico Andaluz”. Boletín Trimestral del Instituto Andaluz de Patrimonio Histórico, Sevilla, Septiembre 2000. Centrándonos en las bibliotecas digitales, un tipo concreto de aplicación son los sistemas para el tratamiento de bibliotecas digitales. Este trabajo propone desarrollar un sistemas para el tratamiento de bibliotecas digitales a un caso concreto para el que se definen las necesidades a cubrir: el sistema de información del patrimonio histórico de Andalucía. ??J.M. Cordero, M.J. Escalona, J. Torres, M.Mejías, R.M. Gasca. “Aplicación de los sistemas de tratamiento de bibliotecas digitales a la gestión de Patrimonio Histórico”. Número monográfico. Estudios Turísticos Nº 146. Pags. 37-47. Instituto de Estudios Turísticos. Madrid, Diciembre 2000. Este trabajo se orienta en el ámbito de las bibliotecas digitales como caso concreto de sistema de información global. Es un trabajo conjunto en el que se plantea el uso de una arquitectura basada en la tecnología XML para desarrollar una biblioteca digital del patrimonio histórico de Andalucía. Fue seleccionado por esta revista tras su publicación en el congreso Turitec. Publicaciones en congresos y reports internos ?? M.J. Escalona, J.Torres, M.Mejías “Propuesta de metodología para el desarrollo de sistemas para el tratamiento de bibliotecas digitales”, Report Interno, 2-2000 del Departamento de Lenguajes y sistemas Informáticos. Universidad de Sevilla. Sevilla, Junio 2000. Este trabajo fue el primero que publicamos. Se trata de un documento en el que se hizo una primera aproximación global de la propuesta basada fundamentalmente en las propuestas del Proceso Unificado y OOHDM. ??J.M. Cordero, M.J. Escalona, J. Torres, M.Mejías, R.M. Gasca. “Aplicación de los sistemas de tratamiento de bibliotecas digitales a la gestión de Patrimonio Histórico”. Congreso de Turismo y Tecnologías de la Información y las Comunicaciones: Nuevas Tecnologías y Patrimonio. Madrid, Octubre 2000. Este trabajo se orienta en el ámbito de las bibliotecas digitales como caso concreto de sistema de información global. Es un trabajo conjunto en el que se plantea el uso de una arquitectura basada en la tecnología XML para desarrollar una biblioteca digital del patrimonio histórico de Andalucía. ?? M.J. Escalona, M.Mejías, J.Torres. “Aproximación metodológica al desarrollo de sistemas para el tratamiento de bibliotecas digitales”. V Jornadas de Ingeniería del Software. Valladolid, Noviembre 2000. La aproximación metodológica que se presenta en este trabajo es un resumen de la propuesta que actualmente se está desarrollando. Ya no está tan influenciada por el Proceso Unificado y OOHDM y es mucho más concreta en muchos aspectos. Está centrada exclusivamente en las bibliotecas digitales pero sirvió como base para el planteamiento de la propuesta general que se está elaborando actualmente. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 95 ?? J.Torres, M.Mejías, M.J. Escalona, J.A. Ortega, J.M. Cordero. “Diseño del Modelo Navegacional para Sistemas de Tratamiento en Bibliotecas Digitales” I Jornadas de Bibliotecas Digitales. Valladolid, Noviembre 2000. Este trabajo ya se centra con más detalle en un aspecto concreto, el de la navegación. En este artículo se presentaron las técnicas para diseñar de forma adecuada las necesidades de navegación en un sistema para el tratamiento de bibliotecas digitales. Las ideas que se presentaron en este artículo eran lo suficientemente genéricas como para ser extendidas a los sistemas de información global. ?? M.J. Escalona, M.Mejías, J.Torres, J.M. Cordero, M.González. “Aplicación Integrada de la Biblioteca Digital del Patrimonio Histórico Andaluz”. I Jornadas de Bibliotecas Digitales. Valladolid, Noviembre 2000. Este trabajo presentó la aplicación de nuestra propuesta metodológica para el desarrollo de sistemas basados en bibliotecas digitales a un caso concreto y real. Se pretendía aplicarla al desarrollo de un sistema que integrase toda la información sobre el patrimonio histórico de Andalucía. ?? M. Mejías, M.J. Escalona, J.Torres. “Captura de requisitos navegacionales y de interfaz abstracta para los sistemas de tratamiento de bibliotecas digitales”. IV Jornadas Científicas en Tecnologías de la Información. Cádiz, Noviembre 2000. Siguiendo el camino lógico, el primer flujo de trabajo con el que trabajamos fue la captura de requisitos. Este artículo presentó la propuesta que planteábamos para capturar y definir los requisitos de navegación e interfaz en los sistemas para el tratamiento de bibliotecas digitales. ?? M.J. Escalona, M.Mejías, J.Torres, A.Reina. “Propuesta metodológica para el desarrollo de sistemas para el tratamiento de bibliotecas digitales”. I Jornadas Dolmen. Sevilla, Junio 2001. El grupo de investigación en el que participamos, se mueve dentro del grupo Dolmen. Este artículo es una visión general de la propuesta que hemos presentado en este trabajo de investigación. Aunque allí la presentamos en el marco de las bibliotecas digitales, actualmente ha evolucionado hacia los sistemas de información global. ?? M.González, M.Mejías, M.J. Escalona, R.Martínez, J.A. Ortega. “Interacción con los Usuarios en bibliotecas digitales”. I Jornadas Dolmen. Sevilla, Junio 2001. Este artículo, también presentado en las jornadas del grupo de investigación, trata de justificar la importancia que la interacción tiene en los sistemas para el tratamiento de bibliotecas digitales y la necesidad de contar con ellos en el proceso de desarrollo. ??R.M. Gasca, M.J.Escalona, J.A. Ortega, M.Mejías, J.Torres.”Aplicación de la programación con restricciones a la elaboración automática de itinerarios culturales”. Congreso de Turismo y Tecnologías de la Información y las Comunicaciones: Nuevas Tecnologías y Patrimonio. Madrid, Octubre 2001. Este es un trabajo conjunto con el grupo de trabajo que estudia los sistemas de recuperación de información dentro del grupo de investigación. Aplicando la programación con restricciones a la definición de requisitos que nosotros hicimos sobre el sistema de información del Instituto Andaluz de Patrimonio Histórico, se define un programa para generar automáticamente itinerarios culturales a través de internet. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 96 ??M.J. Escalona, M. Mejías, J.Torres, A. Reina Quintero, J.M. Cordero. “Requisitos de almacenamiento de información e identificación de actores para una biblioteca digital de bienes muebles”. II Jornadas de bibliotecas digitales. Ciudad Real, Noviembre 2001. Este artículo, mucho más reciente que los anteriores, aplica las propuestas que se han presentado en el apartado 6.3.2 para la definición y descripción de actores del sistema a un problema real. Este problema real es el de los bienes muebles que hemos venido analizando en este trabajo. ??N.R. Brisaboa, M.J. Escalona, M. Mejías, A.S. Places, F.J. Rodríguez, J. Torres. “Sistema de consulta vía Web?para el Instituto Andaluz de Patrimonio Histórico”. II Jornadas de bibliotecas digitales. Ciudad Real, Noviembre 2001. El artículo que presentamos aquí, fue el resultado de un trabajo conjunto realizado con la Universidad de A Coruña. El trabajo se basó en aplicar la metodología que estamos desarrollando y la arquitectura para bibliotecas digitales que ellos están planteando para estudiar su compatibilidad en un sistema real, el del Instituto Andaluz de Patrimonio Histórico. Actualmente estos trabajos de colaboración se siguen realizando. ??M.J. Escalona, M.Mejías, J.Torres. “Getting requirements in web information systems”. Fourteenth International Conference "Software & Systems Engineering & their Applications". Paris, Diciembre 2001. Este es el último trabajo que hemos publicado. En el se presenta el flujo de trabajo de especificación de requisitos tal y como se ha presentado en este documento. 7. Revisión Bibliográfica [Bieber 1998] M. Bieber, R. Galnares and Q. Lu. Web enginering and flexible hypermedia. The 2nd Workshop on Adaptative Hypertext and Hypermedia, Hypertext 1998. [Blaha 1988] M.R. Blaha. Relational database design using a object-oriented methodology. Commun, ACM, Vol 31, Nº4, 1988, pp. 414-427 [Booch 1999] G. Booch, J. Rumbaugh, I. Jacobson. Unified Modeling Language User Guide. Ed. Addison-Wesley, 1999. [Brisaboa 1999] N. Brisaboa. M.J. Durán, C. Lalín, J.R. López, J.R. Paramá, .R. Penabad, A.S. Places, Arquitectura para Bibliotecas Virtuales, 1999. [Brisaboa 2001] N.R. Brisaboa, M.J. Escalona, M. Mejías, A.S. Places, F.J. Rodríguez, J.Torres. Sistema de consulta vía Web? para el Instituto Andaluz de Patrimonio Histórico. II Jornadas de bibliotecas digitales. Ciudad Real, Noviembre 2001. [Caneiro 1994] L.M.F. Caneiro, M.H.Coffin, D.D. Coewan, C.J.P.L. Lucena. ADVcHARTS A Visual Formalism for Higgly Interactive Systems. in M.D. Harrison, C.Johnson, eds, Software Engineering in Human-Computer Interaction, Cambridfe University Press, 1994. [Ceri 1999] S. Ceri, P.Fraternali and S. Paraboschi. Desing Principles for Data- Intensive Web Sites. SIMOG Record, 28: 84-89, 03 1999. ? ? Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 97 [Ceri 2001] S. Ceri, P. Fraternali, A. Bongio. Web Modeling Language (WebML): a modeling language for designing Web sities. First international workshop on Web-Oriented Software Technology. Valencia, Junio 2001. [Cockburn 1997] A. Cockburn. Structuring Use Cases with Goals. Journal of Object-Oriented Programming, 1997. [Coleman 1992] D.Coleman, F.Hayes, S.Bear. Introducing Objectcharts or How to use Statecarts in Object-Oriented Design. IEEE Transaction on software Engineering, 18(1), January, 1992. [Conallen 1999a] J. Conallen. Building Web Applications with UML. Addison Wesley 1999. [Conallen 1999b] J. Conallen. UML Extension for Web Applications 0.91. Disponible en http://www.conallen.com/technologyCorner/webextension/WebExtension09 1.htm [Cordero 2000] J.M. Cordero, M.J. Escalona, J. Torres, M.Mejías, R.M. Gasca. Aplicación de los sistemas de tratamiento de bibliotecas digitales a la gestión de Patrimonio Histórico. Congreso de Turismo y Tecnologías de la Información y las Comunicaciones: Nuevas Tecnologías y Patrimonio. Madrid, Octubre 2000. [Cowan 1995] D.D.Cowan, D.J.P.Lucena, Abstract Data Views. An Interface Specification Concept to Enyhance Desingn for Reuse. IEEE Transactions on Software Engineering. 18(1), 9-18, January 1995. [De Troyer 1997] O.M.F. De Troyer, C.J. Leune. WSDM: A User Centered Design Method for Web Sites. Tilburg University, Infolab. 1997 [Durán 2000] A. Durán. Un Entorno Metodológico de Ingeniería de Requisitos para Sistemas de Información. Tesis Doctoral. Departamento de Lenguajes y Sistemas Informáticos. Universidad de Sevilla. Septiembre 2000. [Escalona 2000a] M.J. Escalona, J.Torres, M.Mejías. Propuesta de metodología para el desarrollo de sistemas para el tratamiento de bibliotecas digitales, Report Interno, 2-2000 del Departamento de Lenguajes y sistemas Informáticos. Universidad de Sevilla. Sevilla, Junio 2000. [Escalona 2000b] M.J. Escalona, J.Torres, M.Mejías. Aplicación de los sistemas de tratamiento de bibliotecas digitales al Sistema de Información del Patrimonio Histórico Andaluz. Boletín Trimestral del Instituto Andaluz de Patrimonio Histórico, Sevilla, Septiembre 2000. [Escalona 2000c] M.J. Escalona, M.Mejías, J.Torres. Aproximación metodológica al desarrollo de sistemas para el tratamiento de bibliotecas digitales. V Jornadas de Ingeniería del Software. Valladolid, Noviembre 2000. [Escalona 2000d] M.J. Escalona, M.Mejías, J.Torres, J.M. Cordero, M.González. Aplicación Integrada de la Biblioteca Digital del Patrimonio Histórico Andaluz. I Jornadas de Bibliotecas Digitales. Valladolid, Noviembre 2000. [Escalona 2001a] M.J. Escalona, M.Mejías, J.Torres, A.Reina. Propuesta metodológica para el desarrollo de sistemas para el tratamiento de bibliotecas digitales. I Jornadas Dolmen. Sevilla, Junio 2001. [Escalona 2001b] M.J. Escalona, M. Mejías, J.Torres, A. Reina Quintero, J.M. Cordero. Requisitos de almacenamiento de información e identificación de actores para una biblioteca digital de bienes muebles. II Jornadas de bibliotecas digitales. Ciudad Real, Noviembre 2001. [Firesmith 1997] D.G.Firesmith. Uses Cases: The Pros and Cons. 1997. [Fong 1995] J. Fong. Mapping extended entity relationship model to object modeling techique. SIGMOD Record, Vol. 24, Nº3, Septiembre 1995, pp. 18-22. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 98 [Garzoto 1993] F. Garzoto, D.Schwae and P.Paolini HDM-A Model Based Approach to Hypermedia Aplication Design. ACM Trnasactions on Information System, 11 (1), Jan 1993, pp 1-26. [Gasca 2001] R.M. Gasca, M.J.Escalona, J.A. Ortega, M.Mejías, J.Torres. Aplicación de la programación con restricciones a la elaboración automática de itinerarios culturales. Congreso de Turismo y Tecnologías de la Información y las Comunicaciones: Nuevas Tecnologías y Patrimonio. Madrid, Octubre 2001. [Greco 1998] D. Greco, M. Eskelinen, C. Funckhouser, M.Luesebrink, J.Rosenberg Actual & Potential Hypertext & Hypermedia. ACM Digital Library. June 20- 24, 1998. [Gómez 2001] J. Gómez, C. Cachero and O.Pastor. Extending a conceptual Modelling Approach to Web Application Design. First international workshop on Web- Oriented Software Technology. Valencia, Junio 2001. [González 2001] M. González, M. Mejías, M.J. Escalona, R.Martínez, J.A. Ortega. Interacción con los Usuarios en bibliotecas digitales. I Jornadas Dolmen. Sevilla, Junio 2001. [Harrison 1993] W. Harrison, H. Ossher. Subjects-Oriented Programming (a critique of pure objects). In Proceeding of the Conference on Object-Oriented Programming Systems, Languajes and Applications (OOPSLA’93), pp. 411-428, Washington, September 1993. [Hennicker 2001] R. Hennicker, N. Koch. A UML-based Methology for hypermedia Design. First international workshop on Web-Oriented Software Technology. Valencia, Junio 2001. [Hoch 1999] M. Hoch, D. Schwabe. Group interaction in a surround screen environment. Inst. for Visual Media ZKM, Karlsruhe, Germany. IEEE Computer Animation, 1999 [IBM OOTC 1997] IBM OOTC. Developing Object Oriented Software. IBM Object Oriented Technology Center. Prentice-Hall 1997 [IEEE 1993] IEEE Recommended Practice for Software Requirements Specifications. IEEE/ANSI Standard 830-1993, Institute of Electronical and Electronics Engineers, 1993 [Izakowirz 1995] T. Izakowitz, E.Stohr, P. Balasubramaniam: RMM:A metodology for structured hypermedia design. Comm. Of ACM, October 1995, pp.34-35 [Jacobson 1995] I. Jacobson. Modeling with use cases-Formalizing use-case modelling. Journal of Object-Oriented Programming, June 1995 [Jacobson 1999] I. Jacobson, G. Booch, J. Rumbaugh. The Unifed Software Development Process. Ed. Addison-Wesley, 1999. [Knapp 1997] A. Knapp, N. Koch, M. Wirsing. & others. EPK-fix: Methods and Tools for engineering electronic product catalogues. Interactive Distributed Multimedia Systems and Telecommunication Services, Lecture Notes in computer Science 1309, pages 1999-209. Springer-Verlag Berlin- Heidelberg, September 1997. [Lange 1995] D.B. Lange. An Object-Oriented Design Approach for Devloping Hipermedia Information Systems. Research Report RT00112, IBM Research, Tokyo Research Laboratory, Japón, 1995. [Lee 1998] H. Lee, C. Lee, C. Yoo. A Scenario-based objec-oriented methodology for developing hypermedia information systems. Procesings of 31st Annual Conferecne on Systems Science. Eds. Sprague R. [Lesk 1997] M. Lesk. Practical Libraries: Books, Bytes & Bucks. Morgan Kaufmann. 1997. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 99 [Liddle 2001a] S.W. Liddle, D.W. Embley, S.N. Woodfiel. A seamless model for Objectoriented systens development. First international workshop on Web- Oriented Software Technology. Valencia, Junio 2001. [Liddle 2001b] S.W. Liddle, D.W. Embley, S.N. Woodfiel. An Active, Object-Oriented, Model-Equivalent Programming Language. First international workshop on Web-Oriented Software Technology. Valencia, Junio 2001. [Maier 1997] C. Maier, L. Mandel. YAON- a Static Diagram Technique for the Development of Electronic Product Catalogue Proceedings of the Symposium on Software Technology, SADIO, August 1997. [Mandel 2000] L. Mandel, A.Helmerich, L.A. Olsina, G.Rossi, M.Wirsing, N.Koch. Hyper- UML. Specification and modeling of multimedia an Hypermedia Applications in Dystributed systems. Agosto 2000. [MAP 1995] MAP. Metodología de Planificación y Desarrollo de Sistemas de Información. MÉTICA Versión 2.1: Guía de Referencia. Tecnos/ Ministerio para las Administraciones Públicas 1995. [Martínez 1997] J.M. Martínez, J.R.Hilera, J. Martínez, J.A. Gutiérrez. Orientación a Objetos en la Documentación Hipermedia. Universidad de Alcalá de Henares, Departamento de Ciencias de la Computación. [Mecca 1999] G. Mecca, P. Atzeni, V. Crescenzi. The ARANEUS Guide to Web-Site Development. Technical Report, Universidad de Roma, 03 1999. [Mejías 2000] M. Mejías, M.J. Escalona, J.Torres. Captura de requisitos navegacionales y de interfaz abstracta para los sistemas de tratamiento de bibliotecas digitales. IV Jornadas Científicas en Tecnologías de la Información. Cádiz, Noviembre 2000. [Nanard 1995] J. Nanard, M. Nanard. Hypertext design enviroments and the hypertext design process. Communication of the ACM, August 1995. Vol 38(8), 49- 56. 1995. [Olsina 1998] L. Olsina. Building a Web-based information system applying the hypermedia flexible process modeling strategy. 1 st International workshop on Hypermedia Development, Hypertext 1998. [Pastor 1992] O. Pastor, F. Hayes and S. Bear. OASIS: An object-Oriented Specification Languaje. CAiSE’92 International Conference, volume 593 of LNCS, pages 948-363. Springer-Velag, 1992. [Pastor 1997] O. Pastor, E.Insfran, V. Pelechano, J.Romero and J. Merseguer. OOMETHOD: An OO Software Production Enviroment Combining Conventional and Forma Methods. CAiSE’97. International Conference on Advanced Information Systems, 1997. [Piattini 1996] M.G. Piattini, J.A. Calvo-Manzano, J.Cervera y L.Fernández. Análisis y Diseño detallado de Aplicación Informáticas de Gestión. ra-ma 1996 [Raghavan 1994] S. Raghavan, G. Zelesnik y G. Ford. Lectures Notes of Requirements Elicitacitation. Educational Materials CMU/SEI-94-EM-10 1994 [Rossi 1996] G. Rossi. An Object Oriented Method for Designing Hipermedia Applications. PHD Thesis, Departamento de Informática, PUC-Rio, Brazil, 1996. [Rossi 1997] G. Rossi, D. Schwabe, A. Garrido: Design Reuse in Hipermedia Applications Development. Proceedings of ACM International Conference on Hypertext (Hypertext`97), Southampton, April 7-11, 1997. ACM Press. [Rumbaugh 1991] J. Rumbaugh. Modelado y Diseño Orientado a Objetos. Ed. Prentice Hall, 1991. [Rumbaugh 1999] J. Rumbaugh, I. Jacobson, G. Booch. The Unified Modeling Language Reference Manual. Ed. Addison-Wesley, 1999. Metodologías para el desarrollo de sistemas de información global: análisis comparativo y propuesta María José Escalona Cuaresma Página 100 [Scheneider 1998] G. Schneider y J.P. Winteers. Applying Use Cases: a ractical Guide. Addison Wesley 1998. [Schwabe 1995] D.Schwabe, G.Rossi. The Object-Oriented Hipermedia Design Model. Communications of the ACM, 38(8), August, 1995, pp.45-46 [Thomson 1998] J. Thomson, J. Greer and J. Cooke. Algorithmically detectable design patterns for hypermedia collections. Workshop on Hypermedia development Process, Methods and Models. Hypermedia 1998. [Torres 2000] J.Torres, M.Mejías, M.J. Escalona, J.A. Ortega, J.M. Cordero. Diseño del Modelo Navegacional para Sistemas de Tratamiento en Bibliotecas Digitales. I Jornadas de Bibliotecas Digitales. Valladolid, Noviembre 2000. [Robertson 2000] J. Robertson and S. Robertson. VOLERE. Requirements Specification Templates. 2000 [Vinze 2001] A.S. Vinze.Globalization of the Business Enterprise Effects and Impacs of Information Technology. Departament of Business Analysis. Texas A&M University. [Wirfs-Brock 1990] R. Wirfs-Brock, L. Wilkerson & P. Wiener. Desingning Object-oriented Software. Prentice-Hall 1990. [Witten 1996] I. Witten, C. Nevill-Manning, S. Cunningham. Building a Digital Library for Computer Science Research: Technical Issues. Proceedings of the 19th Australesian Computer Science Conference. 1996. [WWW 2000] World Wide Web Consortium. www.w3c.org, 2000. [Yourdon 1989] Yourdon E. Modern Structured Analysis. Prentice-Hall 1989. 8. Foros relacionados Debido a la generalidad de los sistemas de información global, existen muchos foros y páginas de interés para estos sistemas. A nivel de grupos de trabajo son especialmente interesantes: ??A nivel nacional ?? El grupo de trabajo del proyecto Dolmen. Es un grupo de trabajo formado por un total de seis universidades españolas entre ellas las de Sevilla. ?? El grupo de trabajo de la red de Bibliotecas Digitales. En esta también participan diversas universidades españolas, como la de Valencia, la Coruña y la de Sevilla. ??A nivel internacional ??A nivel internacional sería impensable nombrar a todos los grupos de trabajo que existen que trabajan en el entorno de la ingeniería del software orientados a sistemas de información global. Pero sería destacable el comentar el grupo de trabajo que ha surgido en torno al desarrollo de metodologías para la web. En este grupo, que aún no tiene un nombre definido, se encuentras personas como Gustavo Rossi o Daniel Schwabe, autores de OOHDM; Oscar Pastor, autor de OO- Method; Franca Garzo, autora de RMM; Luis Olsina, autor de HFPM; u