Renaissance: sistema de documentación de proyectos

Texto completo

(1)RENAISSANCE – SISTEMA DE DOCUMENTACION DE PROYECTOS. CARLOS ALBERTO MUÑOZ RESTREPO. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN BOGOTA 2003.

(2) RENAISSANCE – SISTEMA DE DOCUMENTACION DE PROYECTOS. CARLOS ALBERTO MUÑOZ RESTREPO. Tesis de Grado para optar por el título de Ingeniero de Sistemas y Computación. Doctora Rubby Casallas, Asesora. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN BOGOTA 2003.

(3) CONTENIDO. Pág. INTRODUCCIÓN. 6. 1. PLANTEAMIENTO DEL PROBLEMA. 11. 1.1 ALMACENAMIENTO VERSIONADO DE LA INFORMACIÓN. 11. 1.2 SEPARACIÓN ENTRE LA PRESENTACIÓN Y LOS DATOS PRESENTADOS. 12. 1.3 LOCALIZACIÓN DE LA INFORMACIÓN. 12. 1.4 INICIO SINCRONIZADO DEL PROYECTO. 13. 2. PROPUESTA DE SOLUCIÓN. 14. 2.1 ESTRATEGIA. 15. 2.1.1 Automatización de Procesos. 15. 2.1.1 Generación de Espacios de Trabajo Distribuídos. 16. 2.2 CASOS DE USO. 18. 2.3 DISEÑO. 24. 2.3.1 Componentes. 24. 2.3.2 Diagrama de Clases. 27. 3. CONCLUSIONES. 29. ANEXOS. 32. BIBLIOGRAFÍA. 40.

(4) LISTA DE TABLAS. Pág. Tabla 2.1 Requerimiento # 1 de la Aplicación. 19. Tabla 2.2 Requerimiento # 2 de la Aplicación. 20. Tabla 2.3 Requerimiento # 3 de la Aplicación. 21. Tabla 2.4 Requerimiento # 4 de la Aplicación. 22. Tabla 2.5 Requerimiento # 5 de la Aplicación. 23.

(5) LISTA DE FIGURAS. Pág. Figura 2.1 Diagrama de Casos de Uso. 18. Figura 2.2 Proceso de Actualización de la Información. 24. Figura 2.3 Proceso de Generación de Espacios de Trabajo Distribuídos. 25. Figura 2.4 Funcionamiento del Módulo de Planeación. 26. Figura 2.5 Diagrama de Clases de la Aplicación. 28.

(6) ISC-2003-1-34. INTRODUCCIÓN. Uno de los problemas a los que se ven enfrentados los equipos de desarrollo de software con mayor frecuencia a la hora de llevar a cabo un proyecto es el de mantener documentado el proyecto. Esta tarea contempla ciertos requisitos mínimos: la información debe ser actual, y disponible. La actualidad de la información puede llegar a ser una cuestión de disciplina dentro del grupo de desarrollo, mientras la disponibilidad se puede llegar a convertir en un problema técnico. De cualquier manera, ambos son elementos necesarios para la documentación de cualquier proyecto de esta área.. La documentación en los Proyectos de Software. El desarrollo de software es una actividad complicada, rigurosa, y que requiere de equipos enteros de trabajo, realizando diferentes actividades simultáneamente, cooperando unos con otros, equivocándose y replanteando estrategias. Esta lista de labores puede llegar a ser tan extensa como las definiciones mismas de los proyectos en desarrollo. Es por esto que la documentación en los proyectos de desarrollo de software toma mayor importancia cada día, y empieza a tornarse en un requisito indispensable para la calidad de los proyectos y productos implementados.. 6.

(7) ISC-2003-1-34. La documentación de un proyecto entero no se mantiene estática durante todo el ciclo de vida del proyecto; cambia con cada decisión que se toma, con cada requerimiento que cambia, e incluso con cada uno de los inevitables retrasos que sufren los grupos de análisis y desarrollo. Cualquier cambio en el proceso de desarrollo o en el producto mismo, genera un cambio en la documentación, que debe ser en todo momento, un reflejo del estado actual del proyecto en todos sus aspectos. La documentación de un proyecto puede llegar a ser larga y tediosa; muchos grupos de desarrollo encargan a personas a esta tarea exclusivamente, mientras otros prefieren que los propios miembros del grupo le dediquen parte del tiempo a esta tarea, ya que son ellos quienes mejor conocen el proyecto. De cualquier forma, la documentación se ve representada en horas de trabajo del proyecto.. La documentación no sólo sirve para presentar un esquema del estado actual de un proyecto, también sirve como depósito de actividades realizadas, sus resultados, sus problemas y las respectivas soluciones. El proceso de desarrollo de software. siempre estará invadido de inconvenientes y problemas técnicos;. pero al tener documentación sobre los problemas solucionados en un proyecto, es probable que se reduzca el tiempo invertido en la solución de problemas, en problemas subsiguientes. Se puede decir lo mismo de los tiempos invertidos en el proyecto. Al tener documentados los tiempos (y cualquier otro recurso para tal efecto) de cierto proyecto, es posible mejorar la precisión al calcular el uso del tiempo en proyectos futuros. 7.

(8) ISC-2003-1-34. Almacenamiento de la Documentación. Una vez se soluciona la incógnita de cómo y cuando llevar documentación para un proyecto, es posible llegar a la pregunta de dónde guardar dichos documentos. Un aspecto importante para tener en cuenta a la hora de documentar, es que se puede requerir revertir los cambios realizados a un proyecto en algún momento, convirtiendo en implícitas y obligatorias las reversiones a la documentación. Igualmente la documentación formal y en formatos estándares puede llegar a ser bastante. amplia,. y. por. consiguiente,. consumirá. bastantes. recursos. de. almacenamiento.. Además de los miembros del grupo de desarrollo, pueden existir muchos individuos interesados en ver la documentación de un proyecto de desarrollo a cualquier hora y en cualquier lugar, como por ejemplo directores de proyecto, clientes, vendedores, etc. Por esto es necesario que el almacenamiento de los repositorios sea seguro pero a la vez asequible por cualquier persona autorizada desde cualquier lugar.. 8.

(9) ISC-2003-1-34. Presentación de la Información Documentada. Como se mencionó anteriormente, la documentación puede ser requerida por diferentes tipos de individuos o grupos. Es por esto que también debe poder ser presentada en diferentes formatos: un cliente puede requerir un informe de la documentación en medio digital, mientras un director de proyecto puede requerirlo impreso de manera ordenada para revisarlo. De acuerdo a esto, la documentación debe poder ser presentada de maneras diferentes, pero tener una copia de la documentación en cada formato requerido presenta problemas no sólo en cuanto al tiempo que se toma en realizar un cambio (debe ser efectuado en todas las diferentes copias), sino también en cuanto a la posibilidad de tener que presentar la información en un formato nuevo del cual no se tenía copia anteriormente.. Es por esto que en el proceso de documentación como tal se requiere una manera versátil de presentación de la información que sea manipulable y modificable.. Información pertinente en la Documentación de un Proyecto. Un proyecto puede llegar a estar tan documentado como se quiera. En la documentación pueden estar incluídos hasta los más pequeños detalles sobre el proyecto, o puede ser una visión general del proyecto, donde no se tengan en cuenta algunos detalles técnicos o incluso los pormenores del proceso llevado a 9.

(10) ISC-2003-1-34. cabo por el grupo de desarrollo. Por esto, es necesario establecer un proceso que contemple las etapas y pasos del desarrollo que estarán incluídos en la documentación.. Sin embargo, existen ciertos aspectos del proyecto que son considerados como relevantes y necesarios en cualquier esquema de documentación formal. Dichos aspectos son la documentación técnica del proyecto (diagramas de clases, secuencia, requerimientos, casos de uso, etc), algún registro del grupo de desarrollo con su información pertinente y las etapas del proceso de desarrollo.. 10.

(11) ISC-2003-1-34. 1.. PLANTEAMIENTO DEL PROBLEMA. El objetivo principal de éste proyecto es el de solucionar algunos de los inconvenientes mencionados anteriormente, y que se pueden presentar a la hora de documentar un proyecto de desarrollo de software.. 1.1. ALMACENAMIENTO VERSIONADO DE LA INFORMACIÓN. El primer aspecto que se debe atacar, es el del almacenamiento de la documentación. Se debe tener un sitio centralizado y seguro donde queden almacenados todos y cada uno de los documentos del proyecto. Dicho sitio, debe poder ser actualizable con facilidad, y debe permitir cierta navegación entre versiones antiguas de la documentación, para poder reversar cambios, o comparar con estados antiguos del proyecto de desarrollo.. El almacenamiento también debe ser totalmente independiente del lugar físico donde se encuentre. Debe poder ser accedido desde cualquier punto con conexión a la red, sin perder las características mínimas de seguridad requeridas para el tipo de información que se está almacenando.. 11.

(12) ISC-2003-1-34. 1.2. SEPARACIÓN. ENTRE. LA. PRESENTACIÓN. Y. LOS. DATOS. PRESENTADOS. Sería muy impráctico tener una versión diferente de la documentación del proyecto para cada una de las formas en las que se deba presentar. Por esto, es necesario separar los datos a presentar, de todas sus posibles formas de presentación. El proceso de transformar los datos crudos, a un formato presentable y que cumpla con ciertos requisitos, a su vez puede llegar a ser tedioso y extenso. Dicho proceso también debe ser disminuido en tiempo y preferiblemente, automatizado.. Los datos almacenados deben estar en un formato liviano, portable, y que no tenga relación alguna con la manera de presentarlos.. 1.3. LOCALIZACIÓN DE LA INFORMACIÓN. Otro de los problemas que se quiere abordar es la localización y la disponibilidad de la información. Los datos de la documentación deben poder estar distribuidos físicamente del lugar de trabajo del grupo de desarrollo, pero sin embargo deben poder ser consultados en cualquier momento y desde cualquier lugar. Es por esto que el proyecto pretende encontrar una solución al transporte de la documentación para su presentación inmediata y en su estado actual sin tener que pasar por. 12.

(13) ISC-2003-1-34. procesos tediosos de extracción, transformación, y manipulación los datos antes de ser presentados.. 1.4. INICIO SINCRONIZADO DEL PROYECTO. Todo proyecto de desarrollo de software debe iniciar con ciertos lineamientos básicos. estructurales que debe seguir a lo largo del mismo. Uno de estos. lineamientos es la estructura de archivos sobre la cual se va a trabajar, y debe haber un miembro del grupo, un líder, que tenga la última palabra en este aspecto.. 13.

(14) ISC-2003-1-34. 2.. PROPUESTA DE SOLUCIÓN. La solución propuesta en este proyecto es la de generar una aplicación que automatice algunos de los procesos que se deben llevar a cabo a la hora de documentar un proyecto de desarrollo de software. Una solución que se base sobre tecnologías existentes para retirar a los desarrolladores, o en dado caso a cualquier individuo encargado de las tareas de documentación, algunas de las responsabilidades de mantenimiento de la documentación del proyecto.. Este proyecto se basa en un desarrollo anterior: un plugin para el editor JEdit que genera la documentación para un proceso de desarrollo en un proceso preestablecido1. Los documentos generados son la base para éste proyecto, ya que están en formato XML, y serán transformados a través de XSL para llegar a un estado final de la documentación publicable vía web. El proyecto mencionado, genera archivos con la definición de un proceso de desarrollo de software preestablecido, genera los archivos XSL para transformar a XMLDocbook, y tiene los archivos XSL necesarios para transformar a HTML. Es de éste punto de donde parte el desarrollo de la solución.. 1. “Herramienta para el desarrollo de documentos de ingeniería de software implementada bajo jEdit”, Jairo Martinez. 14.

(15) ISC-2003-1-34. Uno de los objetivos finales del proyecto, es generar una herramienta de manejo de documentación para ser usada en el curso de Ingeniería de software de la Universidad de Los Andes, donde los estudiantes del curso evaluarán la herramienta y harán comentarios para generar la retroalimentación respectiva.. 2.1. ESTRATEGIA. 2.1.1 Automatización de Procesos. Se utilizó el formato XML como el medio para almacenar los datos normalizados, definiendo un modelo de datos que contuviera lo necesario para documentar el proceso de software. Para llevar un seguimiento del estado de la documentación del proceso, se utilizó CVS (Concurrent Versión System) como repositorio de las versiones de los documentos, y finalmente como medio de presentación se utilizó la Web, debido a su facilidad de acceso remoto.. La aplicación no sólo separa el proceso de recolección de información documental sobre el proceso de desarrollo y la transformación a un formato HTML de la misma, sino que también automatiza la segunda. El usuario sólo debe indicar el repositorio CVS donde residen los documentos XML, y la aplicación se encarga de la extracción, transformación, y movilización de los mismos hacia el sitio Web donde van a ser visibles, para generar las páginas HTML, y en un futuro, cualquier 15.

(16) ISC-2003-1-34. formato permitido por DocBook. Debe aclararse que tanto la aplicación, como el servidor con el repositorio CVS, y el servidor web donde se presentará la documentación transformada, pueden estar físicamente separados.. 2.1.2. Generación de Espacios de Trabajo Distribuidos. Basándose en algunas de las ideas usadas anteriormente en la solución, se decide que la configuración inicial de la estructura de archivos que manejará el proyecto debe quedar en manos del líder del proyecto, y es él quien autoriza y efectúa la inicialización de los espacios de trabajo que van a ser usados por los miembros del grupo.. La aplicación de nuevo usa XML para definir los espacios de trabajo que se usarán en el proyecto. Dada su estructura arborescente, el formato XML resulta adecuado para definir una estructura de directorios sobre un sistema de archivos.. La solución planteada presenta un módulo de selección de proyecto, donde según la información contenida en un archivo descriptor escrito en XML, genera los espacios de trabajo distribuidos para cada uno de los integrantes del grupo. La lista de dichos. integrantes también se encuentra almacenada en un archivo. descriptor como el mencionado anteriormente.. 16.

(17) ISC-2003-1-34. Como la creación de los espacios distribuidos debe ser realizada sobre diferentes máquinas. Se decidió implementar una solución que hiciera uso de las capacidades documentales del protocolo WebDAV2, el cual tiene funcionalidad de crear recursos, ya sean directorios o archivos, en diferentes máquinas simultáneamente. Dado el protocolo que se usará, es importante resaltar que la solución requiere que cualquier equipo en la lista descriptora del grupo de trabajo, debe estar corriendo un servidor que implemente el protocolo. WebDAV. Las. pruebas fueron realizadas con Apache Tomcat versión 4.1.18 de distribución libre.. Igualmente, y paralelamente a la creación inicial de los espacios de trabajo, se quiso proveer un módulo pequeño que facilite la inserción del espacio de trabajo inicial en el depósito CVS del proyecto. Se creó un script para ser usado con la herramienta ANT, completamente customizable para cualquier tipo de depósito en el que se automatiza esta tarea. Adicionalmente, se incluyeron en este módulo herramientas que pueden llegar a ser necesarias para algunos tipos de repositorios como lo es la herramienta plink, que permite abrir conexiones seguras hacia algunos servidores CVS que solo permiten conectarse a ellos de esta manera.. 2. WEBDAV (Web-Based Distributed Authoring and Versioning): Protocolo de extension de funcionalidad de HTTP.. 17.

(18) ISC-2003-1-34. 2.2. CASOS DE USO. En la figura 2.1 se muestra el diagrama de casos de uso construido para la solución.. Figura 2.1 Diagrama de Casos de Uso. 18.

(19) ISC-2003-1-34. A continuación se explica con mayor detalle cada uno de los casos de uso.. Identificador: R1. Indispensable/Deseable: Indispensable. Prioridad: Media. Nombre Caso de Uso: Generar Estructura de Directorios Inicial Resumen: El líder del grupo debe generar una estructura de trabajo inicial y dejarla en el repositorio CVS para que los demás miembros del grupo puedan verla. Esta estructura no se limita a la documentación, sino a todo lo que debe guardarse en el repositorio. Curso Básico Eventos:. 1. El usuario configura el archivo XML con los datos adecuados para el repositorio, y con la ruta de acceso a sus estructura de directorios creada localmente. 2. El usuario corre la herramienta ANT con el archivo de configuración modificado anteriormente. 3. La herramienta hace un commit inicial al repositorio con la estructura determinada por el usuario.. Caminos Alternativos: Caminos de Excepción:. 1. La herramienta no puede almacenar los datos en el repositorio debido a un error de configuración.. Puntos de Extensión:. Ninguno. Autor: Fecha:. Carlos Alberto Muñoz 15 Enero 2003. Tabla 2.1 Requerimiento # 1 de la Aplicación. 19.

(20) ISC-2003-1-34. Identificador: R2. Indispensable/Deseable: Indispensable. Prioridad: Alta. Nombre Caso de Uso: Generar Espacios de trabajo Resumen: El líder del grupo debe generar dinámicamente los espacios de trabajo ( la estructura de directorios) sobre todas las estaciones de trabajo de cada uno de los integrantes del grupo Curso Básico Eventos:. 1. El usuario configura el archivo XML con los datos adecuados para cada una de las estaciones de trabajo de los miembros del grupo y localiza este archivo en el directorio específico donde la aplicación lo leerá. 2. El usuario accede a la página de inicio para generar los espacios de trabajo y selecciona el proyecto a generar. 3. La herramienta genera los espacios de trabajo en cada una de las estaciones de trabajo.. Caminos Alternativos: Caminos de Excepción:. 1. La aplicación no puede generar el espacio de trabajo en alguna de las estaciones de trabajo, por consiguiente continua.. Puntos de Extensión:. Ninguno. Autor: Fecha:. Carlos Alberto Muñoz 15 Enero 2003. Tabla 2.2 Requerimiento # 2 de la Aplicación. 20.

(21) ISC-2003-1-34. Identificador: R3. Indispensable/Deseable: Indispensable. Prioridad: Alta. Nombre Caso de Uso: Ver documentación en línea Resumen: Cualquier usuario con acceso a la aplicación debe poder ver la última versión de la documentación desde cualquier lugar, usando su browser de internet. Curso Básico Eventos:. 1. El usuario simplemente digita la ubicación URL donde debe estar una versión en HTML de la documentación.. Caminos Alternativos: Caminos de Excepción:. 1. Todavía no se ha generado la primera versión HTML de la documentación. El usuario debe informar al líder del grupo para que la genere.. Puntos de Extensión:. Ninguno. Autor: Fecha:. Carlos Alberto Muñoz 15 Enero 2003. Tabla 2.3 Requerimiento # 3 de la Aplicación. 21.

(22) ISC-2003-1-34. Identificador: R4. Indispensable/Deseable: Indispensable. Prioridad: Alta. Nombre Caso de Uso: Copiado Remoto de la Documentación Resumen: La aplicación debe ser capaz de copiar la documentación generada a cualquier servidor web con soporte al protocolo webdav, y que tenga los permisos apropiados de escritura. Curso Básico Eventos:. 1. La aplicación lee el archivo de configuración del proyecto y copia los archivos y directorios de la documentación al servidor configurado.. Caminos Alternativos:. 1. El servidor web es el mismo donde se encuentra la información, en cuyo caso hay que configurarlo con propiedades webdav.. Caminos de Excepción:. 1. El servidor de destino no está configurado para soportar conexiones webdav.. Puntos de Extensión:. Ninguno. Autor: Fecha:. Carlos Alberto Muñoz 15 Enero 2003. Tabla 2.4 Requerimiento # 4 de la Aplicación. 22.

(23) ISC-2003-1-34. Identificador: R5. Indispensable/Deseable: Indispensable. Prioridad: Alta. Nombre Caso de Uso: Actualizar Documentación Resumen: El líder del grupo debe poder actualizar la documentación del proyecto automáticamente, generando una copia en HTML y ubicándola en el servidor web del proyecto para que pueda ser visible por todos los demás miembros del grupo. Curso Básico Eventos:. Caminos Alternativos: Caminos de Excepción: Puntos de Extensión: Autor: Fecha:. 1. El usuario configura el archivo XML de la aplicación donde se encuentran los datos del proyecto, incluidos la localización del repositorio CVS, y la localización del servidor Web de destino. 2. El usuario accede a la pagina de selección de proyecto para seleccionar el proyecto a actualizar. 3. La aplicación extrae los datos temporal y localmente del repositorio CVS. 4. La aplicación transforma los datos XML en un formato XMLDocbook. 5. La aplicación transforma los datos de XMLDocbook a HTML. 6. La aplicación mueve los datos hacia el servidor web vía WebDAV.. 1. Si el proyecto no existe, la aplicación informa al usuario. 2. Si hay un error al transformar los datos, la aplicación informa al usuario del error. 1. El copiado de los archivos al servidor web obedece a la misma especificación del requerimiento R4. Carlos Alberto Muñoz 15 Enero 2003. Tabla 2.5 Requerimiento # 5 de la Aplicación. 23.

(24) ISC-2003-1-34. 2.3. DISEÑO. 2.3.1 Componentes. La aplicación tiene dos componentes esenciales que son los que manejan la actualización completa de la documentación más reciente hacia el servidor web, y la generación de los espacios de trabajo distribuidos. Adicionalmente, se cuenta con el componente de generación la inserción inicial de la estructura de directorios al repositorio CVS.. •. El componente de actualización es el más complejo de los componentes, permitiendo automatizar varias tareas en una sola. Es el componente que permite hacer extracción del repositorio CVS, la transformación de los documentos a un formato HTML, y su localización en el servidor web del proyecto. La figura 2.2 muestra el proceso que lleva a cabo el componente de actualización.. Figura 2.2. Proceso de Actualización de la Información. 24.

(25) ISC-2003-1-34. •. El componente de generación de espacios de trabajo aunque menos complicado, también automatiza y coordina la tarea de. generar los. espacios de trabajo para cada uno de los integrantes del grupo. La lista de integrantes del grupo es totalmente customizable a partir de un archivo XML de configuración de la aplicación. La figura 2.3 muestra el funcionamiento del componente de generación de grupos de trabajo.. Figura 2.3. •. Proceso de generación de espacios de trabajo distribuidos. El componente de planeación, el cual está basado en el protocolo WebDAV y la herramienta Microsoft Excel para permitir generar un depósito de. 25.

(26) ISC-2003-1-34. archivos de planeación que pueden ser modificados por los usuarios según sus permisos. Éste componente se basa en las plantillas de planeación del curso de Ingeniería de Software de la Universidad de Los Andes, y consiste en la ubicación de los archivos en el servidor WebDAV, donde cada usuario, impondrá un candado sobre el archivo que le corresponde (de acuerdo a su rol en el equipo). Dicho candado se mantendrá a lo largo del desarrollo del proyecto. El líder del proyecto genera un candado similar sobre un documento integrador y a través de un proceso automatizado (macro) genera un consolidado de la planeación de todo el grupo. La figura 2.4 muestra el funcionamiento del componente de planeación.. Figura 2.4. Funcionamiento del módulo de Planeación. 26.

(27) ISC-2003-1-34. •. Finalmente, el componente de generación inicial de la estructura de directorios, que se basa en la herramienta ANT para proveer la total automatización y configuración de los llamados a comandos CVS, y algunas otras herramientas de ayuda para posibles situaciones específicas de uso del protocolo CVS, como lo son la seguridad por medio de conexiones ssh.. 2.3.2. Diagrama de Clases. La figura 2.5 muestra el diagrama de clases de la aplicación.. Figura 2.5. Diagrama de clases de la aplicación. 27.

(28) ISC-2003-1-34. 28.

(29) ISC-2003-1-34. 3.. CONCLUSIONES. Durante el desarrollo del proyecto se lograron hacer varias observaciones sobre los procesos que se querían automatizar, y de acuerdo a ellas, se construyó la aplicación para dar un mayor alcance al proyecto.. Como primera medida se quiso reducir el tiempo empleado para construir, actualizar, y presentar la documentación de un proyecto. Esto se logra a gran medida debido a que se empleó un medio de almacenamiento de versiones, como lo es CVS, para mantener un histórico de la documentación, para no perder cambios realizados anteriormente, y para poder obtener eficazmente la versión más actual de los documentos.. Se separó el contenido documental de la presentación, haciendo uso de los archivos XML, y las transformaciones XSL para generar dicho contenido en diferentes formatos. El documentador solo debe preocuparse por suministrar la información, y la aplicación realiza los pasos necesarios para divulgarla vía un servidor web, donde cualquier miembro del grupo puede tener acceso a ella.. Baja ese orden de ideas, el uso del estándar DocBook, permite mantener los documentos en un estado en el que pueden ser convertidos a cualquier otro formato de presentación incluidos RTF, PDF, entre otros. 29.

(30) ISC-2003-1-34. Por otro lado, el módulo de generación de espacios distribuidos otorga cierto nivel de control sobre la forma en que se va desarrollar el proyecto, y no dar vía libre a cada uno de los desarrolladores para que construya una estructura de paquetes como crean conveniente. Solo el líder del grupo, después de reunirse con el grupo y discutir el tema, tiene la facultad para hacer las modificaciones y generar en cada una de las estaciones de trabajo la estructura de directorios a la cual se debe acomodar todo el grupo.. El uso del protocolo WebDAV dentro la solución propuesta, permite un intercambio de archivos por medio de internet, lo cual facilita la distribución física de los recursos que usa la aplicación.. El producto final desarrollado, es un producto genérico con la flexibilidad suficiente para manejar desde pequeños y simples proyectos, hasta proyectos a gran escala mas complejos. La aplicación requiere que el usuario tenga conocimientos en XSL, CVS, y las demás tecnologías usadas en el proyecto, si éste quiere usar la funcionalidad a su mayor capacidad.. En general, la aplicación, aunque no es una solución completa hacia el manejo distribuido de todos los procesos que se llevan a cabo en un grupo de desarrollo de software, si hace un gran avance hacia el ideal de poder tener grupos completamente distribuidos físicamente al permitir documentar el proyecto desde 30.

(31) ISC-2003-1-34. cualquier lugar a cualquier hora, y no solo mantener la historia de los cambios realizados, sino también mantener a todo usuario del sistema actualizado.. 31. el grupo, y en general a cualquier.

(32) ISC-2003-1-34. ANEXOS. Anexo 1 – Descripción de las Tecnologías usadas. XML. Extensible Markup Language o XML, es un lenguaje diseñado para proveer un método de identificación de información completamente adaptable. Se denomina extensible porque no tiene un formato fijo como HTML. Por el contrario, XML es un metalenguaje – un lenguaje para describir otros lenguajes – el cual permite el diseño de lenguajes para innumerables tipos de lenguajes derivados. Lo anterior debido a que esta escrito en SGML3.. XML es un proyecto de W3C y el desarrollo de la especificación está siendo supervisado por su grupo de trabajo sobre xml: un grupo de colaboradores y expertos en varios campos, que ofrecen comentarios vía correo electrónico.. XML presenta las siguientes características3:. 3 3. •. Simple: Provee una especificación corta.. •. Es un estándar abierto.. http://www.w3.org/XML/ http://www.w3.org/XML/. 32.

(33) ISC-2003-1-34. •. Está construido sobre la experiencia de muchas personas que han venido trabajando con este tipo de lenguajes.. •. Extensible: permite la creación de elementos dentro del lenguaje.. •. Neutral: Al ser un estándar abierto, no existe un propietario de XML.. •. Internacional: XML soporta caracteres en todas las lenguas existentes, así como un método para indicar el lenguaje en que está escrito cada documento.. •. Manejable: Provee métodos para forzar las estructuras en los documentos como lo son los DTD, explicados a continuación.. DTD4. Un DTD puede ser considerado como la gramática de un XML. Especifica que estructura puede tener un tipo de documento XML específico. Es un conjunto de regulaciones que especifican el uso de XML. Define los elementos permitidos, los atributos para dichos elementos, y sus valores permitidos. Contiene también definiciones sobre que elementos están permitidos dentro de otros elementos y de que manera.. 4. http://www.w3.org/XML/. 33.

(34) ISC-2003-1-34. Un elemento especial, el !DOCTYPE, al comienzo de un archivo XML especifica el tipo de documento que es, y la localización del DTD. Una vez se interpreta el documento XML (por medio de un parser), se validará que el contenido del documento siga los lineamientos descritos en su archivo DTD.. XSL. XSL (XML Stylesheet Language ) es un lenguaje para definir transformaciones. Una hoja de estilos XSL, es un archivo que describe como desplegar un documento XML de un tipo dado. Además, proporciona un lenguaje de transformaciones (XSLT), el cual ofrece inicialmente medios para realizar operaciones complicadas de estilo como la generación de tablas de contenido e índices, pero que cada vez se usa más como lenguaje genérico de transformaciones a documentos XML. XSLT es usado para propósitos diferentes que no están relacionados con XSL; por ejemplo, la generación de páginas HTML basándose en los datos contenidos en un documento XML. Además, ofrece también opciones avanzadas de estilo, llamadas Objetos de Formato, descritas en el documento DTD de los archivos XML a procesar5.. 5. http://www.w3.org/Style/XSL/. 34.

(35) ISC-2003-1-34. Funcionamiento de XSL5. El proceso de aplicar hojas de estilo requiere de uno o varios documentos XML que contienen los datos que la hoja de estilos va a desplegar, y la hoja de estilos misma, que describe como se desplegará un documento de un tipo dado.. El documento XML no contiene información alguna de presentación; dicha información está contenida en la hoja de estilos únicamente. Esta separación entre información y presentación permite el despliegue de los datos en medios diferentes, así como la fácil selección de los datos a mostrar sin modificar los datos mismos.. Una hoja de estilos puede ser usada para transformar cualquier instancia de DTD para la cual fue diseñada. Las definiciones de hojas de estilo XSL deben estar escritas completamente en XML.. Por último, para realizar satisfactoriamente la transformación, se necesita un procesador XSLT, que puede ser cualquier aplicación que reciba los archivos de datos y de hoja de estilos, los interprete, aplique la transformación, y finalmente presente el resultado obtenido.. 6. http://www.w3.org/Style/XSL/. 35.

(36) ISC-2003-1-34. DocBook6. DocBook es un conjunto de definiciones XML muy popular, usado para describir libros, artículos, y otros documentos en prosa, particularmente documentación técnica. Las definiciones DocBook incluyen diversos elementos que son usados a diario en la construcción de dichos documentos como párrafos, títulos, capítulos, referencias, etc. Estas definiciones están construidas usando sintaxis nativa de XML, y como HTML, son un ejemplo de un lenguaje de marcado.. Dadas las hojas de estilo apropiadas, un documento conforme con la especificación DocBook puede ser transformado a diversos formatos como texto plano, HTML, Microsoft Word, e incluso PDF.. WebDAV 7. Webdav es una extensión del protocolo HTTP que pretende ofrecer las herramientas de versionamiento necesarias para hacer del Web, un medio colaborativo con capacidades de escritura.. 7 8. http://www.docbook.org/ http://www.webdav.org/. 36.

(37) ISC-2003-1-34. La funcionalidad mas importante de Webdav incluye:. •. Candados (control de concurrencia): Candados de larga duración, ya sean compartidos o exclusivos, solucionan el problema de varios colaboradores intentando modificar el mismo recurso al mismo tiempo. Para lograr una colaboración robusta a gran escala, la duración de los candados es independiente de las conexiones de red, solucionando así el problema de las conexiones caídas en el momento de la modificación de un recurso.. •. Propiedades: Propiedades definidas en XML proveen un almacenamiento de datos arbitrarios, como una lista de autores para un recurso específico. Estas propiedades pueden ser obtenidas, modificadas y eliminadas con el protocolo.. •. Manipulación de Espacios de nombres: Dado que los recursos deben ser copiados o movidos a través del ciclo de vida de un sitio web, el protocolo soporta dichas operaciones. Las colecciones, similares a los sistemas de archivos, pueden ser creadas y desplegadas.. La funcionalidad en desarrollo sobre Webdav incluye:. •. Colecciones avanzadas: Soporte adicional para colecciones ordenadas, donde el servidor mantenga un solo ordenamiento persistente de los URLs. 37.

(38) ISC-2003-1-34. de una colección. También agrega soporte para recursos referenciales, recursos que sirven como uniones simbólicas en un sistema de archivos, permitiendo la creación de una redirección a otro recurso. •. Control de Versiones y Administración de Configuraciones: Sistema de control de versiones que provea operaciones de check-in, check-out, y listado de historial de versiones. Se espera también que el protocolo permita tener acceso directo a versiones anteriores de un documento. Construida directamente sobre la capa de control de versiones estaría la capa de Administración de configuración, que permite operaciones sobre versiones de colecciones de recursos.. •. Control de Acceso: Habilidad de crear y eliminar listas de acceso. Esto permitiría a los colaboradores agregar o eliminar a otros colaboradores de la lista de acceso a un recurso. Esta actividad puede llegar convertirse no solo en un sistema de control de acceso para Webdav sino para el web en general.. Slide9. Slide es un Proyecto Jakarta, como lo es el servidor Tomcat, compuesto por varios módulos usando WebDAV. El proyecto Slide incluye: 9. http://jakarta.apache.org/slide/. 38.

(39) ISC-2003-1-34. •. Un sistema de manejo de contenido, con un API en Java.. •. Un Servlet que implementa el protocolo WebDAV. (Éste servlet es usado dentro del proyecto de tesis como herramienta para realizar todos los requerimientos WebDAV).. •. Libería WebDAV cliente en Java.. •. Cliente de línea de comandos WebDAV.. •. Componentes Swing integrados con facilidades WebDAV.. El módulo de Acceso a WebDAV ofrecido por Slide (implementado en un servlet, y usado en éste proyecto) encapsula toda la funcionalidad que ofrece el protocolo en un componente que es familiar a cualquier desarrollador en Java: un servlet.. 39.

(40) ISC-2003-1-34. BIBLIOGRAFÍA. •. MARTÍNEZ, Jairo “Herramienta para el desarrollo de documentos de ingeniería de software implementada bajo jEdit”, Universidad de Los Andes.. 40.

(41)