Definición de actores en sistemas de gestión de patrimonio histórico

222 PH Boletín 40/41 Tendencias: Reflexiones y Experiencias Definición de actores en sistemas de gestión de patrimonio histórico Mª José Escalona Manuel Mejías Jesús Torres Departamento de Lenguajes y Sistemas Informáticos Universidad de Sevilla Resumen El desarrollo de un sistema de información de patrimonio histórico puede ser una tarea muy compleja en la que se suele mezclar la necesidad de disponer y gestionar una base de datos importante con una funcionalidad compleja y distribuido todo ello mediante una interfaz que se debe ajustar en cada momento a las necesidades del usuario. Bajo el proyecto de investigación MADEIRA (Metodología y Arquitectura para la Difusión Electrónica de Información por la Red)1se está desarrollando una propuesta metodológica que sirva como marco de desarrollo para poder realizar todo el ciclo de vida de estos sistemas de información. Este trabajo se centra en presentar cómo, según la propuesta, se deben definir a los actores que participan en el sistema, así como en resaltar la importancia de esta definición y su repercusión en el resto del desarrollo. Para ver su aplicación en el entorno de patrimonio histórico, se ha aplicado dicha propuesta en el sistema de información del patrimonio mueble del Instituto Andaluz de Patrimonio Histórico. Palabras clave Gestión del patrimonio / Técnicas informáticas / Metodologías de desarrollo / Software / Ingeniería del software / Usuarios Introducción Los actuales sistemas de información global son sistemas híbridos en los que se mezclan las necesidades que presentan los clásicos sistemas de gestión, como son la necesidad de gestionar grandes bases de datos distribuidas de una forma segura o de ofrecer al usuario la funcionalidad apropiada para mantenerla. Pero los sistemas de información global poseen otras características, como son la necesidad de una interfaz sencilla y adecuada a cada uno de los roles de actores que se puedan dar en el sistema, características que los asemejan a las aplicaciones multimedia. Lo que sí que es evidente es que para desarrollar un sistema de este tipo es necesario disponer de una metodología que sirva como marco de referencia para su realización. Dentro del proyecto MADEIRA se está desarrollando una propuesta metodológica para este tipo de aplicaciones2. Basados en esta propuesta, que se presentará en el apartado 2, este trabajo se centra en la especificación de requisitos, cuya estructura se presentará en el apartado 3. Una vez introducida la fase de especificación, el trabajo se centra ya en el apartado 4 en definir cómo se propone realizar la definición y clasificación de actores del sistema en esta propuesta para el sistema de información del patrimonio mueble del Instituto Andaluz de Patrimonio Histórico. En el apartado 5, se analizará la importancia de esta actividad en actividades posteriores del desarrollo. Por último, se presentarán las conclusiones y trabajos futuros. Propuesta metodológica para el desarrollo de sistemas de información global Hasta hace pocos años, los sistemas de información se podrían clasificar en dos grandes grupos, los sistemas de gestión y los sistemas multimedia. Ambos tipos de aplicaciones se separaban fácilmente y simplemente por su aspecto visual y funcional se podía diferenciar cuáles eran de un grupo u otro. En los sistemas de gestión imperaba la importancia de la funcionalidad. Normalmente eran sistemas muy orientados al proceso de trabajo y solían depender de una base de datos, más o menos compleja. Por su parte, los sistemas multimedia estaban orientados a mostrar información mediante un interfaz llamativo, sencillo y vistoso. En cada uno de estos grupos se han propuesto con el paso de los años metodologías de desarrollo orientadas a cubrir sus aspectos más críticos. En el primero de ellos se encuentran propuestas como SSADM, MERISE, MÉTRICA, o las actuales orientadas a objetos, donde UML y el Proceso Unificado son sus representantes de mayor impacto. En los entornos multimedia nacen propuestas como HDM (A Model Based Approach to Hypermedia Aplication Design)3y más adelante algunas orientadas a objeto como OOHDM (Object Oriented Hypermedia Design Model)4o SOHDM (A Scenariobased objec-oriented methodology for developing hypermedia information systems)5, que orientan su interés en capturar los aspectos de la interfaz de interacción con el sistema, con propuestas como el uso de ADVs (Abstract Data Views), o aspectos de navegación. PH Boletín 40/41 223 Tendencias: Reflexiones y Experiencias Cuando nacen los sistemas de información global, la perspectiva cambia. En estos sistemas normalmente se encuentra una potencia funcional importante, acompañado de bases de datos complejas, en las que normalmente hay, además, información multimedia: sonido, audio, etc. En esto, los sistemas de información global se pueden asemejar a los sistemas clásicos. Pero, por otro lado, los sistemas de información global tienen un aspecto crítico que es la importancia de la interfaz y de los aspectos de navegación, con lo que se asemejan a una aplicación multimedia. Esta doble virtualidad de los sistemas de información hipermedia6hace que, cuando se plantea el desarrollo de este tipo de aplicaciones, ninguna de las propuestas metodológicas se adecue de forma correcta a sus necesidades. Por esta razón están surgiendo nuevas propuestas metodológicas para desarrollar estos sistemas de información de una forma metódica. Sin embargo, todas estas propuestas se orientan fundamentalmente a la fase de diseño, obviando fases anteriores como el análisis o la captura de requisitos. Por otro lado, ninguna de estas propuestas tienen en cuenta dos aspectos importantes que son los que principalmente se destacan en nuestro trabajo. Los sistemas de información global son sistemas complejos, como ya se ha comentado, y para su elaboración se requiere que el grupo de desarrolladores sea experto en el contenido del sistema. Este el caso del sistema de información del patrimonio mueble del Instituto Andaluz de Patrimonio Histórico. La necesidad de ofrecer a cada tipo de usuario lo que en cada momento necesita y le interesa ver, es un aspecto crítico que hay que tener en cuenta en el desarrollo. Evidentemente, un grupo de técnicos no tiene conocimientos suficientes como para indicar qué información sobre el patrimonio mueble interesa a un arqueólogo, a un artista o a un etnólogo. La definición de la visualización de la información requiere que los expertos en patrimonio y el equipo de desarrollo del sistema trabajen conjuntamente para conseguir una interfaz adecuada. Esta necesidad de trabajo conjunto obliga a usar una metodología de trabajo que sea lo suficientemente potente para que el equipo informático pueda obtener toda la información que necesita. Pero a la vez debe ser lo suficientemente sencilla para que los expertos en patrimonio puedan entender lo que se está definiendo. A continuación se presenta la propuesta desarrollada en MADEIRA para la definición y captura de requisitos. Especificación de requisitos Centrándose en el flujo de trabajo de especificación de requisitos, se ha desarrollado una propuesta en la que se detallan las actividades y tareas a realizar para conseguir capturar y definir todas las necesidades de estos sistemas. Además en esta propuesta se detallan y presentan todas las técnicas a utilizar para ello. De forma resumida, en la tabla número 1 se presenta esquematizada esta propuesta. El flujo de trabajo de especificación de requisitos se inicia definiendo el entorno de trabajo y los objetivos que se pretenden alcanzar con la realización del sistema. Esta tarea va a ser esencial a lo largo de toda la especificación de requisitos pues va a servir como base para realizar todas las demás. Cualquier requisito que se defina en la especificación tendrá como finalidad el conseguir que en el sistema se alcance alguno de estos objetivos. Tras la definición de objetivos, se deben capturar y definir aquellos requisitos de almacenamiento de información que el sistema debe ofrecer. Es decir, debemos responder a la pregunta de qué información tiene que gestionar el sistema. En la definición de estos requisitos será necesario capturar cuál es la naturaleza de los datos que se están capturando. La naturaleza se refiere al tipo del dato. Esto nos permite capturar desde las primeras fases del desarrollo los aspectos multimedia de la aplicación. Cuando se está definiendo la naturaleza de los datos puede que haya datos con naturaleza básica, como pueden ser el texto, la imagen, etc., y puede haber otros cuya naturaleza sea algo novedoso. Estas naturalezas que se salen de las naturalezas clásicas son las que se definirán en la tarea 2.2. Definidas las necesidades de almacenamiento, se entra en la definición de los actores del sistema. Un actor representa a una entidad externa, ya sea usuario u otro sistema, que interactúa con el sistema que se está definiendo. Este trabajo presenta esta actividad en concreto por lo que no se va a entrar en este Tabla 1: Relación de actividades y tareas de la especificación de requisitos Actividades y tareas Actividad 1Definir los objetivos y el entorno de trabajo Tarea 1.1-Conocer el dominio del problema Tarea 1.2Recopilar información sobre las necesidades Tarea 1.3Definir los objetivos del sistema Actividad 2Definir los requisitos de almacenamiento de información Tarea 2.1Definir los requisitos de almacenamiento de información Tarea 2.2Definir las nuevas naturalezas de datos Actividad 3Definir los actores del sistema Tarea 3.1Definir los actores básicos del sistema Tarea 3.2Definir la generalización de actores Tarea 3.3Definir la incompatibilidad de actores Tarea 3.4Definir los actores derivados del sistema Actividad 4Definir los requisitos funcionales Tarea 4.1Definir los requisitos funcionales Actividad 5Definir los requisitos de interacción Tarea 5.1Definir los requisitos de interacción Actividad 6Definir los requisitos no funcionales Tarea 6.1Definir los requisitos no funcionales 224 PH Boletín 40/41 Tendencias: Reflexiones y Experiencias apartado en mucho detalle. Sólo decir que en esta tarea se definirán y clasificarán los roles que pueden jugar los actores del sistema y las relaciones que se pueden producir entre ellos. La definición de los actores es uno de los aspectos más críticos de la especificación de requisitos. Las siguientes actividades van a realizarse en función a la definición de actores que se hace en la actividad 3. Así cuando en la actividad 4 hay que definir la funcionalidad del sistema, ésta se define en base a los actores. Los requisitos funcionales se van a recoger mediante la técnica de los casos de uso y se debe indicar qué actores van a poder participar en cada uno de esos casos de uso definidos. La actividad 5 tiene como objetivo el recoger cómo se presenta la información, cómo se navega a través del sistema y en qué momento de esa navegación se puede ejecutar un determinado caso de uso. Nuevamente, cada vez que se recoja un requisito de interacción se debe indicar qué actor o actores de los definidos en la tarea 3 tiene acceso a él. La última actividad tiene por objetivo el recoger otros aspectos que no se hayan recogido en actividades anteriores. Entre estos aspectos se podrían encontrar las necesidades de seguridad, de salvaguarda, etc. Definición de actores Una vez presentada de forma breve la propuesta para la especificación de requisitos, se puede llegar a la conclusión de que la definición de actores supone un aspecto crítico dentro de ella. La definición de las otras actividades se va a hacer en base al resultado de la actividad de definición de actores. En este apartado se estudiará de forma detallada esta actividad y se verá el resultado de su aplicación en el sistema de información del patrimonio mueble del Instituto Andaluz de Patrimonio Histórico. El sistema de información de Patrimonio Histórico es un sistema con una gran base de datos asociada en la que existe información textual, los datos que identifican y describen a los bienes; información gráfica, como las fotos de los bienes; o información documental, como la bibliografía asociada a los bienes. Es por tanto un sistema multimedia en el que es necesario cumplir grandes necesidades funcionales para la gestión de la información y que requiere una interfaz sencilla y amigable para ello. Se trata por tanto de un sistema de información global. A la hora de plantearse los actores que aparecen en este sistema, encontramos diferentes clasificaciones de estos. Así, según el perfil funcional, en el sistema podemos encontrar tres roles: • El personal del IAPH. Son los que más prioridad tienen, pueden dar de alta, modificar o consultar cualquier dato. Además son los encargados de validar la información del sistema. • Los catalogadores. Son los que introducen la información en el sistema. Pueden ubicarse en cualquier lugar, pero la información que introduzcan en el sistema no se considerará definitiva hasta que no sea validada por un administrador. • Los usuarios por Internet. Sólo podrán realizar consultas sobre los datos. Si ahora se plantea el clasificar a los actores según la rama investigadora a la que pertenezcan se definen 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 los períodos históricos sólo interesan a los que entren como arqueólogos y artistas, o los datos sobre iconografías son para los artistas. Mientras que un mismo actor sólo puede tomar un perfil de la primera clasificación, un mismo actor puede entrar en el sistema como arqueólogo y etnólogo a la vez. Es decir, en la primera clasificación los roles son disjuntos, en la segunda no. Una vez presentado el problema, analicemos cada una de las tareas a realizar. Tarea 3.1Definir los actores básicos del sistema Un actor básico es todo actor que se puede identificar de forma individual atendiendo a algún tipo de criterio o punto de vista a la hora de interaccionar con el sistema software. La experiencia dice que a la hora de identificar los actores básicos que interactúan con un sistema software, pueden existir diferentes criterios o puntos de vista para hacerlo. La aplicación de cada uno de ellos resultará en la identificación de un grupo determinado de actores básicos. Cada actor básico corresponderá a un rol individualizado de interacción con el sistema software. Para definir estos actores en el documento de requisitos, se hará uso del patrón recogido en la tabla 2. En este patrón, los campos que aparecen con el carácter “*” pueden ser omitidos en sistemas sencillos cuando el técnico no los estime oportunos. Tabla 2: Patrón para la descripción de actores básicos AC-<ID> <Nombre descriptivo del actor> Versión* <Número de la versión> <Fecha de la versión> Autores* Nombre autor: <Nombre del autor>... Fuentes* Nombre autor: <Nombre del autor>... Objetivos asociados OBJ-X <nombre descriptivo del objetivo>... Clasificación* Este es uno de los posibles roles dentro del sistema cuando hacemos una clasificación de los actores en base a <descripción de la clasificación> Descripción El sistema deberá prever el tratamiento de los usuarios que pertenecen al grupo descrito como <nombre descriptivo> y que se refiere a personas que <descripción del grupo de personas que representa> Importancia* <Importancia de la existencia del actor> Urgencia* <Urgencia de la existencia del actor> Estado* <Estado de la definición del actor> Estabilidad* <Estabilidad de la definición del actor> Comentarios* <Comentarios adicionales sobre el actor> PH Boletín 40/41 225 Tendencias: Reflexiones y Experiencias En el sistema planteado como ejemplo, se encuentran seis actores básicos: el personal del IAPH, los catalogadores y los usuarios de Internet, en función de la clasificación según el perfil y en función al nivel investigador se tiene a los arqueólogos, los etnólogos y los artistas. De esta forma, por cada uno de estos actores habría que definir un patrón similar al anterior. En la tabla 3 vemos el correspondiente al arqueólogo (se han eliminado los campos opcionales para hacer más sencilla la definición). Tarea 3.2Definir la generalización de actores Cuando se están definiendo los actores se pueden establecer relaciones jerárquicas entre ellos de manera que un actor B puede heredar de una actor A. En este caso se dice que el actor B es una especialización del actor A o que el actor A es una generalización del actor B. De esta forma, el actor B heredaría todas las características del actor A. Así si más adelante se define que un caso de uso puede ser ejecutado por el actor, indirectamente también se estará indicando que el actor B puede realizarlo. En este sentido, la definición de generalización/especialización que aquí se hace es similar a la definición de Jacobson, Booch y Rumbaugh7, y se representa usando la misma nomenclatura, tal y como se recoge en la figura 1. La definición de los actores especializados se realizará mediante la notación de el patrón mostrado en la tabla 2 añadiéndole el campo hereda de en el que se indica el identificador del actor, AC-X, del que hereda. Aunque en el sistema de información del patrimonio mueble no se produce este caso para ningún actor, no está de más dejar la opción de que en un momento dado se pueda ampliar dicho grupo de actores. De esta forma, el sistema quedaría abierto a modificaciones futuras para ampliar su ámbito de trabajo. Tarea 3.3Definir la incompatibilidad de actores Una vez identificados los actores básicos, incluidas las especializaciones, 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). El definir la incompatibilidad entre actores va a ser esencial para fases posteriores y tendrá especial importancia en la tarea 3.4 de esta actividad como se verá en el apartado 4.4. Para definir la incompatibilidad entre actores se utilizará una matriz similar a la indicada en la tabla 4. 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. 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 el actor. Se aconseja, por motivo de claridad, que los actores del mismo grupo aparezcan junto en las filas y columnas de la tabla anterior. Una “X” en la intersección de una fila y una columna de la tabla indica que los actores correspondientes son incompatibles. Por ejemplo, un usuario que se conecte al sistema puede conectarse a la vez como arqueólogo y etnólogo, pero no como catalogador y usuario de Internet. El “-” indica la imposibilidad de indicar incompatibilidad entre un actor y él mismo. Tabla 3: Patrón para la descripción de los arqueólogos AC-05 Arqueólogo Objetivos asociados OBJ-03: Realizar la gestión de los investigadores según su área de investigación Clasificación Este es uno de los posibles roles dentro del sistema cuando hacemos una clasificación de los actores en base al área de investigación a la que pueden pertenecer los usuarios Descripción El sistema deberá prever el tratamiento de los usuarios que pertenecen al grupo descrito como arqueólogo y que se refiere a personas que utilizan el sistema para gestionar o consultar información arqueológico de los bienes. Tabla 4: Matriz de descripción de la incompatibilidad de actores Actores básicos Personal Catalogador Usuario Arqueólogo Artista Etnólogo del IAPH Internet Personal del IAPH –X X Catalogador –X Usuario Internet – Arqueólogo – Artista – Etnólogo – Figura 1: Generalización de actores 226 PH Boletín 40/41 Tendencias: Reflexiones y Experiencias Tarea 3.4Definir los actores derivados del sistema Además de los actores básicos existen los actores derivados. 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. La definición de los actores derivados será muy útil en fases posteriores. Así si se desea definir un requisito de interacción a los que tendrán acceso los etnólogos y arqueólogos no será necesario hacer referencia a los dos, sino que se referenciará al actor derivado que se define en esta tarea. Para recoger a los actores derivados, se usa nuevamente una tabla de dos entradas. La del ejemplo de los bienes muebles será la que se muestra en la tabla 5. Cada columna corresponderá a un actor, básico o derivado, que forme parte de al menos un actor derivado. Cada fila corresponderá a un actor derivado. El símbolo “^” permite indicar que el actor correspondiente a la columna forma parte del actor correspondiente a la fila. El “-” indica que un actor derivado no puede ser parte componente de él mismo. Por ejemplo, el actor ArArq es un actor que entra en el sistema con la caracterización de Arqueólogo y Artista a la vez. A nivel de interfaz, esto va a significar que este usuario verá la información que interesa tanto a artistas como a arqueólogos. De la misma forma se definen todos los demás actores derivados. Importancia de la definición de actores A lo largo del trabajo, se ha presentado cómo se puede realizar la actividad de definición y clasificación de actores dentro de la captura de requisitos de un sistema de información global y en concreto se ha presentado dicha definición para el sistema de información de bienes muebles del IAPH. A medida que se ha ido presentando se ha ido introduciendo la importancia que esta definición va a tener en otras actividades del flujo de especificación. Así, los casos de uso, que nos van a servir para definir la funcionalidad del sistema, se van a realizar pensando en un recurso funcional que necesita uno o más de un actor de los definidos. En los requisitos de interacción se definirán las necesidades de interfaz y de navegación que el sistema necesita ofrecer a uno o más de un actor de los definidos. Pero la definición de los actores también va a ser un punto de referencia para la realización de los flujos de trabajo siguientes y va a ser tenida en cuenta en todo el proceso de desarrollo de un sistema informático. Así, por ejemplo, cuando se vaya a diseñar la interfaz, se tendrá en cuenta los actores definidos para hacer una interfaz adecuada a cada uno de ellos. Conclusiones En este trabajo se ha presentado la propuesta metodológica para el desarrollo de los sistemas de información global que se está desarrollando dentro del grupo de investigación MADEIRA. Tras la presentación de esta propuesta se ha presentado la definición de actividades y tareas que se recomiendan para realizar la especificación de requisitos de estos sistemas. Dentro de estas actividades, el trabajo se centra en presentar la actividad de definición y clasificación de actores y se ha planteado el resultado de aplicar dicha actividad en el sistema de información del Patrimonio Mueble del Instituto Andaluz de Patrimonio Histórico. Por último se ha introducido la importancia de la captura de actores dentro del desarrollo de un sistema de información global. Estudiando el resultado presentado para el Sistema de Información del Patrimonio Mueble, se puede concluir diciendo que a nivel informático el tener correctamente definidos los posibles actores de un sistema, sus incompatibilidades y relaciones, es esencial para elaborar un sistema que se adecue a las necesidades de cada uno de ellos. Pero por otro lado, observando los resultados mostrados, se puede ver que la propuesta presentada ofrece modelos sencillos y definiciones que, aún siendo bastante precisas para los técnicos informáticos, es también bastante fácil de entender por las personas no expertas en informática, pudiendo así cumplirse el objetivo de facilitar la comunicación entre el equipo informático de desarrollo y el grupo de expertos temáticos. En este caso, el personal del IAPH experto en patrimonio. Tabla 5: Actores derivados Actor Arqueólogo Artista Etnologo Usuario IAPH Catalogador ArArq ArEt ArqEt ArqArEt ArArq ^ ^ - ArEt ^ ^ - ArqEt ^ ^ - ArqArEt ^ ^ ^ - ArArqU ^ ^ ArEtU ^ ^ ArqEtU ^ ^ ArqArEtU ^ ^ ArArqC ^ ^ ArEtC ^ ^ ArqEtC ^ ^ ArqArEtC ^ ^ PH Boletín 40/41 227 Tendencias: Reflexiones y Experiencias 1. G. Booch, J. Rumbaugh, I. Jacobson: Unified Modeling Language User Guide. Ed. Addison-Wesley, 1999. 2. J. Conallen: “UML Extension for web applications” www.conallen.com/technologyCorner/webextension/faq.htm 3. A. Durán: "Un Entorno Metodológico de Ingeniería de Requisitos para Sistemas de Información". Tesis Doctoral, septiembre 2000 4. O.M.F. De Troyer, C.J. Leune: “WSDM: “A User Centered Design Method for Web Sites”. Tilburg University, Infolab, 1997 5. 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, junio 2000 6. 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, noviembre 2000 7. F. Garzoto, D. Schwabe and P. Paolini: HDM-A Model Based Approach to Hypermedia Application Design. ACM Transactions on Information System, 11 (1), Jan 1993, pp 1-26 8. I. Jacobson, G. Booch, J. Rumbaugh: “The Unifed Software Development Process”. Ed. Addison-Wesley, 1999 9. Lee H., Lee C. & Yoo C.: “A Scenario-based objec-oriented methodology for developing hypermedia information systems”. Procesings of 31st Annual Conference on Systems Science. Eds. Sprague R. 10. 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 11. G. Rossi: “An Object Oreinted Method for Designing Hypermedia Applications”. PHD Thesis, Departamento de Informática, PUC_Rio, Brazil, 1997 1. El proyecto MADEIRA pertenece al proyecto coordinado DOLMEN subvencionado por el Ministerio de Ciencia y Tecnología y los fondos FEDER (TIC2000-1673-C06-03) 2. 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, junio 2000 3. Garzoto, D. Schwabe and P. Paolini: HDM-A Model Based Approach to Hypermedia Application Design. ACM Transactions on Information System, 11 (1), Jan 1993, pp 1-26 4. G. Rossi: “An Object Oriented Method for Designing Hypermedia Applications”. PHD Thesis, Departamento de Informática, PUC_Rio, Brazil, 1997 5. Lee H., Lee C. & Yoo C.: “A Scenario-based object-oriented methodology for developing hypermedia information systems”. Processings of 31st Annual Conference on Systems Science. Eds. Sprague R. 6. 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, noviembre 2000 7. I. Jacobson, G. Booch, J. Rumbaugh: “The Unified Software Development Process”. Ed. Addison-Wesley, 1999 8. El proyecto MADEIRA pertenece al proyecto coordinado DOLMEN subvencionado por el Ministerio de Ciencia y Tecnología y los fondos FEDER (TIC2000-1673-C06-03) 9. El proyecto MADEIRA pertenece al proyecto coordinado DOLMEN subvencionado por el Ministerio de Ciencia y Tecnología y los fondos FEDER (TIC2000-1673-C06-03) Referencias bibliográficas Notas View publication statsView publication stats