Entorno Web 2.0 para El Diseño de Diagramas de Interconexión de Objetos

UNIVERSIDAD DE OVIEDO
ESCUELA UNIVERSITARIA DE INGENIERA TCNICA EN INFORMTICA DE OVIEDO
PROYECTO FIN DE CARRERA
ENTORNO WEB 2.0 PARA EL DISEO DE DIAGRAMAS DE INTERCONEXIN DE OBJETOS
DIRECTOR: Jos Emilio Labra Gayo AUTOR: Jos Barranquero Tolosa
Universidad de Oviedo E.U.I.T.I.O. Entorno Web 2.0 para el Diseo de Diagramas de Interconexin de Objetos
PALABRAS CLAVE
Diagrama Diseo Editor Interconexin Objeto Entorno Colaborativo Web Semntica AJAX Grficos Vectoriales GraphML Modelo-Vista-Controlador Struts
RESUMEN
La aplicacin consta de dos partes: cliente y servidor. La parte servidor se desarrollar mediante el patrn Modelo-VistaControlador (MVC) junto con el empleo de diversas tecnologas de Web Semntica que aporten extensibilidad y simplifiquen en la medida de lo posible el diseo del modelo de datos y de comportamiento que servir de lenguaje comn entre el cliente y el servidor. En cuanto a la parte cliente el objetivo es que sea completamente independiente de la parte servidor y a ser posible independiente del navegador; preferiblemente ser desarrollada mediante AJAX con el fin de lograr un entorno visual ms amigable para el usuario, similar a las aplicaciones tpicas de escritorio, que adems no requiera ninguna instalacin adicional por parte del usuario. Tambin se valorar la viabilidad de implementar un entorno colaborativo dnde varios usuarios puedan interaccionar simultneamente sobre el mismo diagrama de forma similar a las posibilidades que ofrece una pizarra compartida. Respecto a los requisitos funcionales, bsicamente se espera conseguir la misma funcionalidad que cualquier otra aplicacin de diseo de diagramas, circuitos, redes, etc. Aadiendo la posibilidad de disear nuevos objetos y tecnologas segn las necesidades de los usuarios del entorno. La principal ventaja reside en la ubicuidad y disponibilidad propias de un entorno de este tipo, que permite que el usuario acceda a sus contenidos, guarde sus progresos y comparta sus diagramas desde cualquier ordenador con conexin a Internet.
HISTRICO DE VERSIONES
Versin Fecha Resumen de los cambios producidos
0.00 0.01 0.02 0.03 0.05 1.00 1.01
28/01/2007 19/02/2007 12/05/2007 28/05/2007 09/07/2007 20/08/2007 26/08/2007
Estructura y formato. Estudio de viabilidad. Tecnologas, libreras y herramientas. Prototipos preliminares del cliente. Anlisis y Diseo preliminares. Primer borrador completo. Versin definitiva de este documento.
TABLA DE CONTENIDOS
PALABRAS CLAVE.................................................................................................... 2 RESUMEN.................................................................................................................. 4 HISTRICO DE VERSIONES ...................................................................................... 6 TABLA DE CONTENIDOS .......................................................................................... 8 NDICE DE FIGURAS ............................................................................................... 12 NDICE DE TABLAS ................................................................................................. 14 CAPTULO 1: MEMORIA ......................................................................................... 18
1.1. Agradecimientos .......................................................................................................19 1.2. Objetivos .....................................................................................................................20 1.3. Motivacin ..................................................................................................................21 1.4. Estructura de la Documentacin...........................................................................22 1.5. Evolucin del Proyecto ............................................................................................23 1.6. Tecnologas.................................................................................................................24
1.6.1. XML............................................................................................................................... 25 1.6.2. XML Schema............................................................................................................... 27 1.6.3. GraphML ..................................................................................................................... 28 1.6.4. JavaScript ................................................................................................................... 29 1.6.5. AJAX y JSON............................................................................................................... 31 1.6.6. CSS ............................................................................................................................... 33 1.6.7. JEE ................................................................................................................................ 34 1.6.8. Struts ............................................................................................................................. 35
1.7. Libreras y Herramientas............................................................................................37

1.7.1. Dojo Toolkit.................................................................................................................. 38 1.7.2. SAX ............................................................................................................................... 40 1.7.3. JUNG ............................................................................................................................ 41 1.7.4. Eclipse Web Tools Platform ...................................................................................... 42 1.7.5. Visual Paradigm ......................................................................................................... 43 1.7.6. GIMP ............................................................................................................................ 44
CAPTULO 2: ESTUDIO DE VIABILIDAD................................................................... 46

2.1. Definicin del Alcance del Sistema.......................................................................47
2.1.1. Descripcin Inicial del Sistema................................................................................ 48 2.1.2. Objetivos Iniciales del Sistema ................................................................................ 49 2.1.3. Objetivos del Estudio de Viabilidad ....................................................................... 50 2.1.4. Alcance del Estudio de Viabilidad ........................................................................ 51 2.2.1. Descripcin de los Sistemas Existentes .................................................................. 53 2.2.2. Diagnstico de la Situacin Actual ....................................................................... 59 2.3.1. Identificacin de las Directrices Generales.......................................................... 61 2.3.2. Identificacin de las Directrices Tcnicas ............................................................ 62 2.3.3. Identificacin de Requisitos Funcionales.............................................................. 63
2.2. Estudio de la Situacin Actual ................................................................................52
2.3. Requisitos Iniciales del Sistema ...............................................................................60
2.4. Alternativas de Solucin...........................................................................................65

2.4.1. Estudio de Alternativas de Solucin....................................................................... 66 2.4.2. Planificacin de Alternativas de Solucin ............................................................ 67 2.5.1. Clasificacin de los Sistemas Evaluados ............................................................... 69
2.5. Ampliaciones del Estudio de Viabilidad ...............................................................68
CAPTULO 3: ANLISIS ........................................................................................... 76

3.1. Modelo de Requerimientos .....................................................................................77
3.1.1. Especificacin Textual...............................................................................................78 3.1.2. Especificacin de Requerimientos Funcionales...................................................79 3.1.3. Especificacin de Requerimientos No Funcionales.............................................81 3.2.1. Actores .........................................................................................................................84 3.2.2. Casos de Uso...............................................................................................................85 3.3.1. Identificacin de Clases Asociadas a Casos de Uso ........................................104 3.3.2. Diagrama de Clases (Preliminar) ..........................................................................107 3.3.3. Descripcin de Clases (Preliminar) .......................................................................108 3.4.1. Especificacin de Principios Generales...............................................................116 3.4.2. Especificacin de Formatos Individuales ............................................................117 3.4.3. Especificacin del Comportamiento Dinmico ................................................120
3.2. Especificacin de Casos de Uso ............................................................................83
3.3. Anlisis de Clases.................................................................................................... 103
3.4. Definicin de Interfaces de Usuario.................................................................... 115
3.5. Plan de Aceptacin .............................................................................................. 121

3.5.1. Fase 1: Construccin de Prototipos Bsicos........................................................122 3.5.2. Fase 2: Diseo Detallado del Sistema ..................................................................123 3.5.3. Fase 3: Construccin del Prototipo Final..............................................................124 3.6.1. Prototipo 1: Interconexin de Componentes .....................................................126 3.6.2. Prototipo 2: Formato de la Interfaz de Usuario ...................................................127 3.6.3. Prototipo 3: Integracin de capas del Sistema..................................................128
3.6. Prototipos.................................................................................................................. 125
CAPTULO 4: DISEO ........................................................................................... 130

4.1. Patrones de Diseo ................................................................................................ 131
4.1.1. Patrn Modelo-Vista-Controlador (MVC)............................................................132 4.1.2. Otros patrones empleados ....................................................................................133
4.2. Diagramas de Clases............................................................................................. 134

4.2.1. Diagrama de Paquetes ..........................................................................................135 4.2.2. Paquete model.....................................................................................................136 4.2.3. Paquete model.persistence ...............................................................................137 4.2.4. Paquete model.graphml ....................................................................................138 4.2.5. Paquete common................................................................................................139 4.2.6. Paquete controller ...............................................................................................140 4.2.7. Paquete view ........................................................................................................141 4.3.1. Interaccin Vista Controlador ............................................................................143 4.3.2. Interaccin Modelo Persistencia........................................................................144 4.3.3. Procesar archivo GraphML ....................................................................................145
4.3. Diagramas de Secuencia..................................................................................... 142
4.4. Diagrama Entidad-Relacin................................................................................. 146 4.5. Diccionario de Datos ............................................................................................. 147

4.5.1. Paquete model.....................................................................................................148 4.5.2. Paquete model.persistence ...............................................................................151 4.5.3. Paquete model.graphml ....................................................................................158 4.5.4. Paquete common................................................................................................162 4.5.5. Paquete controller ...............................................................................................166 4.5.6. Paquete view ........................................................................................................173
4.6. Diagrama de Componentes................................................................................ 176
CAPTULO 5: CONSTRUCCIN............................................................................ 178

5.1. Ficheros de Configuracin ....................................................................................179
5.1.1. web.xml ..................................................................................................................... 180 5.1.2. struts-config.xml ....................................................................................................... 183 5.1.3. validation.xml ........................................................................................................... 189 5.1.4. tiles-defs.xml.............................................................................................................. 192 5.1.5. build.xml .................................................................................................................... 195 5.1.6. MessageResources.properties .............................................................................. 201 5.2.1. Paquete model .................................................................................................... 204 5.2.2. Paquete model.persistence .............................................................................. 210 5.2.3. Paquete model.graphml.................................................................................... 229 5.2.4. Paquete common ............................................................................................... 247 5.2.5. Paquete controller............................................................................................... 261 5.2.6. Paquete view ....................................................................................................... 279 5.2.7. Recursos adicionales .............................................................................................. 294
5.2. Cdigo Fuente .........................................................................................................203
CAPTULO 6: MANUALES ..................................................................................... 322

6.1. Manual de Instalacin............................................................................................323
6.1.1. Requisitos Mnimos................................................................................................... 324 6.1.2. Instalacin y despliegue ........................................................................................ 325 6.2.1. Gestin de Usuarios................................................................................................. 327 6.2.2. Gestin de Diagramas ........................................................................................... 330 6.2.3. Edicin de Diagramas ............................................................................................ 334
6.2. Manual de Usuario ..................................................................................................326
CAPTULO 7: CONCLUSIONES ............................................................................. 336

7.1. Resultados .................................................................................................................337 7.2. Entregables ...............................................................................................................340 7.3. Ampliaciones............................................................................................................341
GLOSARIO ........................................................................................................... 344 BIBLIOGRAFA...................................................................................................... 346 NDICE ALFABTICO ............................................................................................ 350
10
11
NDICE DE FIGURAS
Fig. 2-1. Espacio de simulacin de DomoSim-TPC .....................................................54 Fig. 2-2. Arquitectura de DomoSim-TPC .......................................................................54 Fig. 2-3. Crear componente en DomoEdit ..................................................................55 Fig. 2-4. Diseo de ejercicios en DomoEdit..................................................................55 Fig. 2-5. Chequear conexin en DomoApplet ...........................................................56 Fig. 2-6. Solucin de un ejercicio en DomoApplet.....................................................56 Fig. 3-1. Diagrama de Casos de Uso.............................................................................83 Fig. 3-2. Diagrama de Clases (Preliminar) ..................................................................107 Fig. 3-3. Estructura General de la Interfaz de Usuario..............................................115 Fig. 3-4. Interfaz de Usuario 1: Gestionar Diagramas (R1) .......................................117 Fig. 3-5. Interfaz de Usuario 2: Disear Diagramas (R2) ...........................................117 Fig. 3-6. Interfaz de Usuario 3: Gestionar Componentes (R3).................................118 Fig. 3-7. Interfaz de Usuario 4: Disear Componentes (R4).....................................118 Fig. 3-8. Interfaz de Usuario 5: Gestionar Cuentas de Usuario (R5) .......................119 Fig. 3-9. Modelo de Navegacin de la Interfaz de Usuario ...................................120 Fig. 3-10. Prototipo 1: Interconexin de Componentes ..........................................126 Fig. 3-11. Prototipo 2: Formato de la Interfaz de Usuario ........................................127 Fig. 3-12. Prototipo 3: Integracin de capas del Sistema .......................................128 Fig. 4-1. Diagrama de Paquetes ..................................................................................135 Fig. 4-2. Paquete model.............................................................................................136 Fig. 4-3. Paquete model.persistence.......................................................................137 Fig. 4-4. Paquete model.graphml ............................................................................138 Fig. 4-5. Paquete common........................................................................................139 Fig. 4-6. Paquete controller .......................................................................................140 Fig. 4-7. Paquete view ................................................................................................141 Fig. 4-8. Interaccin Vista Controlador .....................................................................143 Fig. 4-9. Interaccin Modelo Persistencia ...............................................................144 Fig. 4-10. Procesar archivo GraphML ..........................................................................145 Fig. 4-11. Diagrama Entidad-Relacin ........................................................................146 Fig. 4-12. Diagrama de Componentes.......................................................................176 Fig. 7-1. Formulario de conexin ..................................................................................327 Fig. 7-2. Crear usuario.....................................................................................................328 Fig. 7-3. Datos de la cuenta de usuario .....................................................................329 Fig. 7-4. Crear diagrama ...............................................................................................330 Fig. 7-5. Consultar diagramas .......................................................................................331 Fig. 7-6. Gestionar permisos sobre diagramas ..........................................................332 Fig. 7-7. Edicin de diagramas.....................................................................................334
12
13
NDICE DE TABLAS
Tabla 3.2-1. Actor 1: Usuario Registrado.......................................................................84 Tabla 3.2-2. Actor 2: Propietario.....................................................................................84 Tabla 3.2-3. Actor 3: Colaborador.................................................................................84 Tabla 3.2-4. Caso de Uso 1: Gestionar Diagramas (R1) ............................................85 Tabla 3.2-5. Escenario 1.1: Alta, baja y modificacin de diagramas (R1.1) .........85 Tabla 3.2-6. Escenario 1.2: Buscar diagramas (R1.2)..................................................86 Tabla 3.2-7. Escenario 1.3: Publicar / compartir diagramas (R1.3) .........................86 Tabla 3.2-8. Escenario 1.4: Control de versiones de los diagramas (R1.4).............87 Tabla 3.2-9. Caso de Uso 2: Disear Diagramas (R2).................................................88 Tabla 3.2-10. Escenario 2.1: Definir dimensiones del rea de diseo (R2.1) .........88 Tabla 3.2-11. Escenario 2.2: Aadir y eliminar componentes (R2.2) .......................89 Tabla 3.2-12. Escenario 2.3: Realizar conexiones entre componentes (R2.3).......89 Tabla 3.2-13. Escenario 2.4: Aplicar transformaciones bsicas (R2.4)....................90 Tabla 3.2-14. Escenario 2.5: Cortar, copiar y pegar (R2.5) .......................................90 Tabla 3.2-15. Escenario 2.6: Historial de deshacer / rehacer (R2.6)........................91 Tabla 3.2-16. Escenario 2.7: Guardar, exportar e importar (R2.7) ...........................91 Tabla 3.2-17. Escenario 2.8: Colaborar mediante pizarra compartida (R2.8) ......92 Tabla 3.2-18. Caso de Uso 3: Gestionar Componentes (R3) ....................................93 Tabla 3.2-19. Escenario 3.1: Alta, baja y modificacin de componentes (R3.1) .93 Tabla 3.2-20. Escenario 3.2: Buscar componentes (R3.2) .........................................94 Tabla 3.2-21. Escenario 3.3: Publicar / compartir componentes (R3.3) .................94 Tabla 3.2-22. Escenario 3.4: Control de versiones de los componentes (R3.4) ....95 Tabla 3.2-23. Caso de Uso 4: Disear Componentes (R4) ........................................96 Tabla 3.2-24. Escenario 4.1: Definir dimensiones del componente (R4.1) .............96 Tabla 3.2-25. Escenario 4.2: Aadir y eliminar formas bsicas (R4.2) .....................97 Tabla 3.2-26. Escenario 4.3: Definir zonas de interconexin (R4.3) .........................97 Tabla 3.2-27. Escenario 4.4: Aplicar transformaciones bsicas (R4.4)....................98 Tabla 3.2-28. Escenario 4.5: Cortar, copiar y pegar (R4.5) .......................................98 Tabla 3.2-29. Escenario 4.6: Historial de deshacer / rehacer (R4.6)........................99 Tabla 3.2-30. Escenario 4.7: Guardar, exportar e importar (R4.7) ...........................99 Tabla 3.2-31. Caso de Uso 5: Gestionar Cuentas de Usuario (R5).........................100 Tabla 3.2-32. Escenario 5.1: Alta, baja y modificacin de usuarios (R5.1) ..........100 Tabla 3.2-33. Escenario 5.2: Validar usuario (R5.2) ...................................................101 Tabla 3.2-34. Escenario 5.3: Buscar usuarios (R5.3)...................................................101 Tabla 3.2-35. Escenario 5.4: Consultar estadsticas y puntuaciones (R5.4) .........102
14
Tabla 3.3-1. Anlisis del Caso de Uso 1: Gestionar Diagramas (R1)..................... 104 Tabla 3.3-2. Anlisis del Caso de Uso 2: Disear Diagramas (R2) ..........................104 Tabla 3.3-3. Anlisis del Caso de Uso 3: Gestionar Componentes (R3) ...............105 Tabla 3.3-4. Anlisis del Caso de Uso 4: Disear Componentes (R4)....................105 Tabla 3.3-5. Anlisis del Caso de Uso 5: Gestionar Usuarios (R5) ...........................106 Tabla 3.3-6. Clase DiagramManager (Modelo)........................................................108 Tabla 3.3-7. Clase Diagram (Modelo).........................................................................108 Tabla 3.3-8. Clase ComponentManager (Modelo) .................................................109 Tabla 3.3-9. Clase Component (Modelo) ..................................................................109 Tabla 3.3-10. Clase UserManager (Modelo) ..............................................................109 Tabla 3.3-11. Clase User (Modelo) ...............................................................................110 Tabla 3.3-12. Clase DiagramManager (Vista) ...........................................................111 Tabla 3.3-13. Clase DiagramEditor (Vista)..................................................................111 Tabla 3.3-14. Clase ComponentManager (Vista) ....................................................112 Tabla 3.3-15. Clase ComponentEditor (Vista) ...........................................................112 Tabla 3.3-16. Clase UserManager (Vista) ...................................................................112 Tabla 3.3-17. Clase DiagramDynaActionForm (Vista) .............................................113 Tabla 3.3-18. Clase ComponentDynaActionForm (Vista).......................................113 Tabla 3.3-19. Clase UserDynaActionForm (Vista)......................................................113 Tabla 3.6-1. Prototipo 1: Interconexin de Componentes .....................................126 Tabla 3.6-2. Prototipo 2: Formato de la Interfaz de Usuario ...................................127 Tabla 3.6-3. Integracin de capas del Sistema ........................................................128
15
Tabla 4.6-1. Clase ModelFacade ................................................................................148 Tabla 4.6-2. Clase DiagramManager..........................................................................149 Tabla 4.6-3. Clase UserManager ..................................................................................150 Tabla 4.6-4. Clase PersistenceFacade........................................................................151 Tabla 4.6-5. Clase DAOFactory ....................................................................................152 Tabla 4.6-6. Interfaz DiagramDAO...............................................................................153 Tabla 4.6-7. Interfaz UserDAO .......................................................................................154 Tabla 4.6-8. Clase OracleDAOFactory .......................................................................155 Tabla 4.6-9. Clase OracleDiagramDAO .....................................................................156 Tabla 4.6-10. Clase OracleUserDAO ...........................................................................157 Tabla 4.6-11. Clase GraphMLFile..................................................................................158 Tabla 4.6-12. Clase GraphMLDefaultHandler............................................................159 Tabla 4.6-13. Clase GraphMLErrorHandler .................................................................160 Tabla 4.6-14. Clase GraphMLSerializer........................................................................161 Tabla 4.6-15. Clase JSONSerializer ...............................................................................162 Tabla 4.6-16. Clase DiagramBean ...............................................................................163 Tabla 4.6-17. Clase DiagramPrivilegeBean................................................................164 Tabla 4.6-18. Clase DiagramChangeBean................................................................164 Tabla 4.6-19. Clase TinyUserBean.................................................................................165 Tabla 4.6-20. Clase UserBean .......................................................................................165 Tabla 4.6-21. Clase FilterLogin.......................................................................................166 Tabla 4.6-22. Clase AddDiagramAction.....................................................................167 Tabla 4.6-23. Clase QueryDiagramAction .................................................................167 Tabla 4.6-24. Clase DestroyDiagramAction...............................................................167 Tabla 4.6-25. Clase QueryDiagramChangeAction ..................................................168 Tabla 4.6-26. Clase CommitDiagramChangeAction...............................................168 Tabla 4.6-27. Clase LoadDiagramAction ...................................................................169 Tabla 4.6-28. Clase QueryAllDiagramsAction ...........................................................169 Tabla 4.6-29. Clase QueryDiagramPrivilegesAction.................................................169 Tabla 4.6-30. Clase ChangeDiagramPrivilegeAction ..............................................170 Tabla 4.6-31. Clase AddUserAction .............................................................................171 Tabla 4.6-32. Clase QueryUserAction..........................................................................171 Tabla 4.6-33. Clase QueryAllUsersAction ....................................................................171 Tabla 4.6-34. Clase LoginAction...................................................................................172 Tabla 4.6-35. Clase LoginCounterAction....................................................................172 Tabla 4.6-36. Clase ExitAction.......................................................................................172 Tabla 4.6-37. Clase DiagramEditor ..............................................................................173 Tabla 4.6-38. Clase Node ..............................................................................................174 Tabla 4.6-39. Clase Link ..................................................................................................175 Tabla 7.1-1. Requisitos hardware .................................................................................324 Tabla 7.1-2. Requisitos software ...................................................................................324
16
17
CAPTULO 1: MEMORIA
Este primer captulo se dedica a la descripcin general del proyecto realizado, basada en los objetivos que se persiguen alcanzar y la motivacin que justifica el planteamiento del mismo. Se expone brevemente la estructura general de este documento, as como la evolucin del proyecto a lo largo de su ciclo de vida. Finalmente se describen en mayor detalle las tecnologas, libreras y herramientas estudiadas y que han servido de soporte al proyecto.
18
1.1. Agradecimientos
Este proyecto nunca podra haberse encarado sin el apoyo de todas las personas que supieron darme nimos en los momentos ms duros. En primer lugar a mi director Jos Emilio Labra Gayo por su inestimable visin prctica del problema y su enfoque didctico y humano de esta experiencia. A mi compaera Sheila Mndez Nez por compartir esta recta final conmigo y mostrarme su apoyo incondicional durante todo este tiempo. A mi hermano y mis padres por la confianza que han depositado siempre en mi esfuerzo y mis inquietudes.
19
1.2. Objetivos
El objetivo principal de este proyecto es el desarrollo de un prototipo lo ms completo y funcional posible de un entrono de diseo de diagramas de interconexin de objetos a travs de Internet. Se busca una aplicacin escalable que admita ampliaciones continuas, sin necesidad de remodelar las funcionalidades desarrolladas previamente. Para lo cual se emplea el patrn de diseo MVC que garantiza cierta independencia entre las diferentes capas del sistema y favorece la separacin de responsabilidades. En principio el sistema est pensado como una aplicacin Web que permita a los usuarios acceder a su funcionalidad desde cualquier ordenador con conexin a Internet, facilitando en la medida de lo posible la internacionalizacin de los recursos y la usabilidad y accesibilidad de los mismos. Como objetivo especfico, se espera poder emplear tecnologas Web 2.0, como AJAX y JSON, que aporten un grado mucho ms elevado de interactividad al cliente Web, tratando de aproximar la experiencia del usuario a la de las aplicaciones tpicas de escritorio. Tambin se espera encontrar un vocabulario XML que encaje con los requisitos del sistema, evitando desarrollar recursos ya existentes, siempre y cuando tampoco suponga una barrera en la consecucin del resto de los objetivos presentados. Dadas las necesidades de escalabilidad funcional del sistema sera muy conveniente desarrollar un lenguaje especfico del dominio, permitiendo a los usuarios disear nuevos componentes bien directamente o bien mediante algn editor diseado a tal efecto. Otro de los objetivos tcnicos especficos es conseguir desarrollar un entorno independiente del navegador utilizado, basado en estndares del W3C y en tcnicas y patrones AJAX ampliamente utilizados, preferiblemente mediante alguna librera o herramienta de cdigo libre. Se tendrn en cuenta las necesidades de seguridad y control de accesos requeridos por el sistema de cara a preservar la privacidad, consistencia e integridad de los datos. Dentro de los objetivos funcionales del sistema, debe proveer un espacio de diseo donde situar objetos y definir conexiones entre ellos, de un modo similar a otras aplicaciones existentes de diseo de diagramas UML, redes de ordenadores, circuitos digitales, pero completamente genrico y extensible. El entorno desarrollado fomentar la colaboracin entre los usuarios mediante tcnicas y mecanismos adecuados que permitan compartir recursos, discutir opiniones, valorar contenidos, acceso incremental a contenidos y funcionalidad segn puntuaciones, etc. Finalmente se pretende distribuir el sistema como un proyecto de cdigo abierto basado en licencias que permitan su libre ampliacin y reutilizacin. 20
1.3. Motivacin
El proyecto surge de la necesidad de ubicuidad actual de las aplicaciones, que normalmente exigen la instalacin de componentes en el ordenador desde el cual desean utilizarse, lo que supone una serie de inconvenientes de portabilidad entre plataformas que suele solventarse mediante el empleo de mquinas virtuales. Este proyecto propone una alternativa mucho ms atractiva que evita la necesidad de realizar ninguna descarga o instalacin adicional, adems de ser completamente gratuito y permitir el libre acceso al cdigo fuente. La idea bsica es desarrollar una aplicacin Web que sirva de soporte y almacenamiento persistente de los contenidos diseados por los usuarios que facilite el acceso a los mismos desde cualquier ordenador y la colaboracin sncrona de los usuarios en tiempo real, del mismo modo que las pizarras compartidas tpicas de los sistemas de e-Learning. Debe existir un claro enfoque a la libertad de accin de los usuarios a la hora de avanzar dentro del sistema, pero que a su vez sea les permita orientarse adecuadamente y no se encuentren perdidos, tanto en la bsqueda de contenidos como en su progresin formativa. El fomento de la colaboracin y comunicacin entre usuarios es la forma ms segura y rpida de aumentar el volumen de contenidos y componentes, permitiendo adems que los usuarios compartan sus propios recursos. Desarrollar el afn de superacin de los usuarios puede resultar ventajoso, aunque arriesgado. Se podra experimentar con el uso de un sistema de rankings y estadsticas que permitan una visin global de la evolucin o las destrezas propias de cada usuario. Motivando a los usuarios a mejorar dicha situacin a travs de la realizacin de pruebas, aadiendo contenidos o componentes, con valoraciones positivas de otros usuarios, etc. Tambin se busca estudiar tcnicas de esfuerzo-recompensa con un sistema de bonificacin (acceso a recursos avanzados, nuevas funcionalidades o privilegios,), tratando de conseguir una experiencia ms atractiva y motivadora a los usuarios, que sin duda son el elemento clave del sistema. En resumen, la motivacin principal es el estudio de viabilidad y el lanzamiento de una alternativa de cdigo abierto que permita disear diagramas en un entorno colaborativo, aplicando tecnologas de Web Semntica y Web 2.0, accediendo a sus funcionalidades desde cualquier ordenador con conexin a Internet y facilitando el intercambio de recursos entre los usuarios.
21
1.4. Estructura de la Documentacin

CAPITULO 1: MEMORIA Descripcin de los objetivos y motivacin del proyecto, evolucin y estudio de tecnologas, libreras y herramientas. CAPITULO 2: ESTUDIO DE VIABILIDAD Estudio del estado del arte durante la fase de definicin del proyecto, objetivos iniciales, estudio de viabilidad y planificacin de alternativas. Descripcin y clasificacin de los sistemas existentes y especificacin de requisitos y directrices iniciales. CAPITULO 3: ANLISIS Especificacin de los requerimientos del sistema, identificacin y anlisis de casos de uso, actores y escenarios. Identificacin y descripcin inicial de las clases, definicin de la estructura y formato de la interfaz de usuario, prototipos y plan de aceptacin. CAPITULO 4: DISEO Breve descripcin de los patrones de diseo empleados, divisin del sistema en paquetes o subsistemas, diagramas de clases por capas, diagramas de secuencia, diagrama Entidad-Relacin, descripcin detallada de las clases y diagrama de componentes. CAPITULO 5: CONSTRUCCIN Descripcin y contenido de los ficheros de configuracin y del cdigo fuente desarrollado. CAPITULO 6: MANUALES Explicacin de los pasos necesarios para la instalacin del sistema y manual de usuario final. CAPITULO 7: CONCLUSIONES Conclusiones derivadas del trabajo realizado, resultados obtenidos, entregables y ampliaciones propuestas. GLOSARIO BIBLIOGRAFA NDICE ALFABTICO
22
1.5. Evolucin del Proyecto

Inicialmente el sistema tena como dominio de aplicacin las tecnologas relativas a la Domtica y la Inmtica, buscndose el desarrollo de un entrono de diseo de circuitos domticos para ser empleado en las prcticas de la asignatura optativa Domtica y Edificios Inteligentes de la Escuela Universitaria de Ingeniera Tcnica en Informtica de Oviedo. Los requisitos planteados no recogan aspectos de ndole tcnica concretos, sino que ms bien se buscaba una funcionalidad especfica. De cara a afrontar el desarrollo del proyecto se opta por cursar las asignaturas optativas Desarrollo de Aplicaciones en Entornos Distribuidos e Internet y Administracin de Sistemas de Gestin de Bases de Datos que han servido de apoyo en el empleo de Struts y Oracle respectivamente. Tras un estudio de la situacin actual y de las tecnologas, libreras y herramientas disponibles se generaliza el dominio de aplicacin al diseo de diagramas de cualquier tipo, incluyendo el dominio de aplicacin inicial, pero centrando el proyecto en la consecucin de una serie de objetivos entre los que destacan: escalabilidad, extensibilidad, usabilidad, accesibilidad, ubicuidad, multiplataforma, independencia del navegador, colaboracin, y tratando de desarrollar un entorno que adems permitiese la colaboracin sncrona de los usuarios. El mtodo de desarrollo elegido es el de prototipado gil, mediante prototipos reutilizables que han facilitado la elaboracin de la especificacin final de requerimientos y casos de uso, as como la evolucin del diseo de clases y del comportamiento dinmico del sistema mediante la evaluacin gradual de las funcionalidades del mismo. Gracias a estos prototipos ha sido posible delimitar con bastante exactitud el alcance del prototipo final a desarrollar en base a la limitacin temporal implcita en el propio proyecto. Dicho alcance recoge los objetivos mencionados este captulo y que sin embargo ha sido necesario posponer el desarrollo de algunas funcionalidades en virtud de la calidad de otras, como es el caso del editor de componentes, que ha quedado pospuesto desde la fase de anlisis actual y que seguramente se desarrolle en una versin futura.
23
1.6. Tecnologas
Este apartado nicamente cubre las tecnologas investigadas de mayor peso en el proyecto y que quedan fuera de los conocimientos bsicos adquiridos durante de la carrera o los amplan.
24
1.6.1. XML
Se trata de un estndar aprobado por el W3C que define un lenguaje extensible de marcado, es decir, la estructura del documento se construye mediante etiquetas. Cada vez ms proyectos se apoyan en las enormes posibilidades de este lenguaje y se ha convertido en una referencia obligada en la comunicacin estructurada entre sistemas, especialmente en el mbito de Internet, la Web Semntica y los Servicios Web. Aunque podra considerarse un lenguaje por s mismo, en la prctica se emplea para construir vocabularios especficos de un dominio, como XHTML, SVG, GraphML Est formado principalmente por elementos y atributos extensibles. Un elemento es una entidad que puede albergar otros elementos y atributos o contenido simple de tipo texto. Adems se pueden definir los tipos de estos elementos y atributos, as como el nmero de ocurrencias y el orden o jerarqua de los mismos. Existen dos conceptos a tener en cuenta y que tienden a confundirse. Por un lado est el concepto de documento bien formado que implica un documento correcto en cuanto a sintaxis o anidacin de etiquetas, por otro el de documento vlido que supone la adecuacin del mismo a las reglas definidas en el vocabulario asociado [Wikipedia] [XML]. 1.6.1.1. Ventajas Su principal ventaja es que es extensible y adems permite compatibilidad hacia atrs, de tal manera que podemos ampliar un lenguaje definido mediante XML sin necesidad de modificar las aplicaciones existentes, a menos que sea necesario tener acceso a las nuevas ampliaciones. Tambin es vital el hecho de que sea un estndar internacional, empleado en infinidad de contextos con notables ventajas de integracin entre distintas plataformas y sistemas. Existe una larga lista de recursos disponibles para procesar y validar documentos, simplificando y agilizando el desarrollo de sistemas que emplean este lenguaje. A pesar de ser un lenguaje de intercambio de datos entre sistemas resulta relativamente fcil de leer y entender en comparacin con otros formatos, disponiendo de multitud de herramientas para su edicin y visualizacin. Finalmente tambin se puede destacar que, a diferencia de HTML, separa el contenido del formato, permitiendo su visualizacin y transformacin en infinidad de dispositivos.
25
1.6.1.2. Desventajas Quiz la mayor desventaja que puede presentarse es el tamao de los ficheros de este tipo en comparacin con otros formatos como JSON, de cara a comunicar datos entre el cliente y el servidor en el sistema a desarrollar. Tambin hay que tener en cuenta que el cliente va a ser desarrollado mediante JavaScript, con soporte directo para JSON y como consecuencia su transformacin y utilizacin es casi inmediata, en comparacin con XML que necesitara ser analizado y generado tambin desde el propio cliente, ralentizando significativamente la sincronizacin entre los usuarios que trabajen de manera colaborativa. 1.6.1.3. Conclusiones En principio se adopta XML como formato de serializacin de los diagramas de tal manera que puedan ser editados o modificados posteriormente, aunque se evaluar la posibilidad de reemplazarlo por JSON en el intercambio de informacin entre cliente y servidor para agilizar este proceso. Tambin es de uso obligado para poder emplear otras tecnologas y herramientas como Struts o Ant, expuestas en mayor detalle ms adelante.
26
1.6.2. XML Schema

En un lenguaje basado en la sintaxis de XML que permite definir vocabularios concretos para este lenguaje. Existen otras alternativas como Relax NG, NRL, SOX, DTD, esta ltima sin embargo es ms rgida y limitada. Adems incorpora soporte para espacios de nombres (namespaces), que asocian un contexto a todos los componentes de un vocabulario definido mediante XML Schema, permitiendo combinar distintos vocabularios en un mismo documento XML o incluso redefinirlos. Para que un documento XML con un XML Schema asociado pueda considerarse vlido debe cumplir con el vocabulario definido por el mismo [XMLSchema]. 1.6.2.1. Ventajas Incorpora los tipos de datos comunes usados en los lenguajes de programacin y permite crear nuevos tipos o extender los existentes. Se trata de un estndar internacional propuesto por el W3C, ampliamente utilizado por definir vocabularios especficos como GraphML o SVG. Recoge todas las ventajas enumeradas ya para XML, como la larga lista de recursos disponibles para procesar y validar documentos o su facilidad de comprensin. Soporta espacios de nombres que facilitan la redefinicin de elementos, atributos, tipos, grupos y restricciones. Simplifica las relaciones jerrquicas de herencia mediante grupos de sustitucin, aportando extensibilidad al vocabulario definido. Est completamente documentado y existen multitud de ejemplos de vocabularios ya definidos y listos para usar. Finalmente destaca su simplicidad respecto a su antecesor DTD. 1.6.2.2. Desventajas Hereda todas las posibles desventajas de XML en cuanto a tamao, sin embargo no es necesario incluir el esquema dentro del documento XML (documento instancia), si no que basta con referenciarlo desde el mismo. 1.6.2.3. Conclusiones Dado que se consigui encontrar un vocabulario que se adapta adecuadamente al dominio de este proyecto se procurar reutilizarlo en la medida de lo posible. Dicho vocabulario es GraphML, que se detalla a continuacin.
27
1.6.3. GraphML
Es un vocabulario fcil de usar y comprender basado en XML Schema, que incluye soporte para: Grafos dirigidos, no dirigidos o mixtos, hipergrafos (con relaciones ternarias) y grafos anidados. Nodos, conexiones y puertos. Representaciones grficas. 1.6.3.1. Ventajas El ncleo principal del lenguaje permite representar grafos bsicos, pero adems permite aadir datos especficos para cada aplicacin, sin que dichos datos adicionales influyan en otras aplicaciones. Al contrario que otros lenguajes de representacin de grafos, emplea XML como soporte, por lo que se beneficia de todas las ventajas propias de este lenguaje. Tambin permite referenciar datos externos mediante XLink, aportando una enorme funcionalidad a los grafos ya que pueden contener enlaces a otros recursos. Es un formato ampliamente utilizado a nivel internacional en aplicaciones de diseo de grafos y diagramas, dada su simplicidad y escalabilidad. Permite especificar la cantidad y el grado de los nodos, el orden del contenido (primero nodos y luego conexiones), con el fin de poder desarrollar analizadores semnticos mucho ms eficientes. 1.6.3.2. Desventajas Puede presentar problemas de tamao de ficheros, por ser un lenguaje XML. 1.6.3.3. Conclusiones Como ya se expuso anteriormente se valorar el empleo de XML en la serializacin de los diagramas, posiblemente mediante este vocabulario, sin embargo se estudiarn otras alternativas en el intercambio de informacin entre cliente y servidor para reducir el consumo de ancho de banda.
28
1.6.4. JavaScript
Es un lenguaje de script, es decir no se compila, sino que es el propio navegador Web el que lo interpreta al cargar la pgina donde se haya incrustado el cdigo. Actualmente est ganando importancia gracias a nuevas tendencias Web 2.0, como AJAX. Existe una versin estandarizada llamada ECMAScript, si bien posee notables limitaciones y existe falta de soporte completo en muchos de los navegadores Web ms utilizados hoy en da. A pesar de poder definir objetos, el mecanismo que se emplea no es el mismo que usa Java, basado en clases, JavaScript utiliza un modelo de prototipos bastante ms complejo de entender y utilizar. Este defecto puede verse mitigado en gran medida gracias a las numerosas libreras existentes que permiten que el desarrollador pueda abstraerse de esta labor mediante funciones que simulen el modelo de clases de Java, como Dojo Toolkit. En los ltimos aos ha empezado a surgir una nueva tendencia denominada JavaScript no obstructivo, que pretende separar la funcionalidad JavaScript (capa lgica) del resto de capas, como ya se hace con el contenido y la presentacin mediante CSS. Tambin promueve el uso patrones para evitar inconsistencias entre navegadores o la falta de escalabilidad [Wikipedia]. 1.6.4.1. Ventajas Permite desarrollar clientes complejos sin necesidad de instalar nuevos componentes en el navegador, ni siquiera necesita Applets. Adems el cdigo resultante suele ser ms ligero y por tanto mucho ms rpido. Tiene un soporte completo de eventos que facilitan en gran medida el desarrollo de interfaces de usuario que respondan a los mismos, e incluso acceder al DOM de la pgina desde la que se carg. No necesita definir los tipos de manera anticipada, aportando gran flexibilidad, a pesar de un aumento asumible en la complejidad de su uso. Las funciones se consideran un tipo ms y pueden ser empleadas directamente como argumentos de otra funcin, aumentando enormemente la potencia del lenguaje, ya que se puede emplear para crear cdigo genrico de manera muy sencilla. Existe un plugin para Firefox llamado Firebug que nos permite depurar JavaScript en tiempo real y recorrer el DOM de la pgina, los estilos CSS Slo sera necesario en el entorno de desarrollo, no en el entorno final. Se puede encontrar mucha documentacin e infinidad de ejemplos en Internet con casos prcticos, libreras, entornos de desarrollo, manuales
29
1.6.4.2. Desventajas No es completamente estndar, de hecho una de las labores ms tediosas del desarrollo de un cliente mediante este lenguaje es que el resultado pueda ejecutarse sin problemas en cualquier navegador, optndose normalmente por dar soporte nicamente a los ms empleados. Puede llegar a resultar lento y poco escalable en funcin de la calidad del diseo realizado o de la cantidad de objetos almacenados en memoria. No hay que olvidar que no se trata de un lenguaje para desarrollar programas, sino trozos de cdigo que son interpretados por el navegador al cargar la pgina correspondiente. Necesita que el navegador tenga activada la opcin de ejecutar el cdigo JavaScript contenido en las pginas. 1.6.4.3. Conclusiones A pesar de ser un lenguaje bastante complejo de utilizar, con una curva de aprendizaje muy pronunciada, existen muchos recursos de carcter abierto, principalmente libreras, que simplifican muchos de estos aspectos e incluso aaden una capa de abstraccin que evita tener en cuenta restricciones propias de los navegadores. Por tanto resulta muy apropiado su uso, ya que es multi-plataforma y no requiere instalacin alguna por parte de los usuarios, adems de posibilitar holgadamente el desarrollo de una interfaz de usuario completa. La librera elegida para dar soporte a este lenguaje es Dojo Toolkit, por las ventajas expuestas posteriormente en este mismo captulo, en el apartado de libreras y herramientas.
30
1.6.5. AJAX y JSON

Internet cada vez cobra ms importancia en el mbito cientfico, tecnolgico y social, apareciendo constantemente nuevas tendencias y soluciones que amplan sus funcionalidades. Muchos pensaron que las tecnologas Flash iban a copar el mercado por su vistosidad y aparente facilidad de uso, sin embargo no es libre y adems requiere instalar el plugin adecuado para cada navegador. El problema estaba, como ya se ha comentado, en la aparente de dificultad de aprendizaje y uso de JavaScript, as como sus limitaciones de portabilidad. Ahora que muchos de estos inconvenientes se ven paliados por numerosas libreras altamente funcionales, comenzando a aparecer nuevos sistemas de intercomunicacin cliente-servidor como es el caso de AJAX y JSON. El trmino AJAX proviene de Asynchronous JavaScript and XML, que implica intercambio asncrono de datos en formato XML entre el cliente y el servidor, sin necesidad de recargar la pgina, permitiendo enormes posibilidades de diseo de interfaces de usuario completas y usables. Por otro lado, JSON surge de JavaScript Object Notation, es decir, notacin de objetos JavaScript. La informacin de transmite tambin en modo texto, pero no se utiliza un lenguaje de etiquetas como XML. Esta tecnologa emplea los mismos mecanismos que utiliza AJAX para transmitir informacin al servidor, por lo que se puede decir que son prcticamente equivalentes, salvo por el lenguaje empleado para codificar la informacin. 1.6.5.1. Ventajas Ambas tecnologas permiten disear interfaces de usuario en una simple pgina Web, capaz de responder a eventos, transmitir y recibir informacin, y sin necesidad de recargar toda la pgina. Al tratarse de un intercambio asncrono el desarrollador puede lanzar peticiones en segundo plano sin necesidad de que el usuario tenga que esperar por los datos. Una de las ventajas propias de JSON es que se trata de un lenguaje extremadamente ligero. Adems JSON permite estructurar perfectamente objetos y colecciones, fcilmente reconocibles y procesables por los navegadores, por lo que puede resultar ms intuitivo que el empleo de XML. En algunos casos concretos es posible tener la necesidad de transmitir o recibir datos en formato texto plano, esta posibilidad se contempla directamente, incluso es posible transmitir datos en otros lenguajes como HTML. Ambas tcnicas de desarrollo de aplicaciones Web estn en constante evolucin y poseen un apoyo importante a nivel internacional por parte de los grupos de desarrollo destinados a producir nuevas experiencias Web 2.0, como Google, Yahoo, Flicker 31
1.6.5.2. Desventajas La gestin de errores puede llegar a ser compleja en algunas circunstancias y es muy recomendable el empleo de alguna librera para paliar estos inconvenientes. No todos los navegadores implementan estas tcnicas del mismo modo, algunos ni siquiera tienen soporte para ellas. En ocasiones el modelo de aplicacin Web tradicional es ms conveniente debido a la complejidad aadida que supone el uso de estas tecnologas. 1.6.5.3. Conclusiones Dado que uno de los objetivos principales del proyecto es crear una interfaz de usuario completa, similar a las aplicaciones tpicas de escritorio para interaccionar con objetos en un entorno de diseo interactivo, resulta muy apropiado el uso de estas tcnicas. Sobre las diferencias entre AJAX y JSON, realmente se puede decir que JSON es un lenguaje que puede ser empleado por AJAX, algo ms ligero que XML y cuya principal ventaja es la facilidad con la que los navegadores pueden procesarlo, que es una transformacin casi directa. En principio JSON ser el mecanismo principal de intercambio de informacin entre el cliente y el servidor, dejando XML para la serializacin, ya que ste sea posiblemente ms fcil de entender para un usuario final.
32
1.6.6. CSS
Es un acrnimo de Cascading Style Sheets, bsicamente es un mecanismo que define el formato que va a tener un documento en pantalla, o cmo se va a imprimir, o incluso cmo va a ser pronunciada la informacin presente en ese documento a travs de un dispositivo de lectura. Se emplea para dar estilo a documentos de marcado tipo XML o HTML, separando correctamente el contenido de la presentacin. Funciona a base de reglas, es decir, declaraciones sobre el estilo de uno o ms elementos, las hojas de estilo estn compuestas por una o ms de esas reglas y cada regla tiene dos partes: un selector y la declaracin, que est compuesta por una propiedad y un valor [W3CBreves]. 1.6.6.1. Ventajas Ofrece a los desarrolladores el control total sobre estilo y formato de sus documentos, pudindose redefinir estilos o incluso combinarlos. Permite controlar el estilo y el formato de mltiples pginas Web al mismo tiempo. Cualquier cambio en el estilo marcado para un elemento en la CSS afectar a todas las pginas vinculadas a esa CSS. 1.6.6.2. Desventajas A pesar de ser un estndar aprobado por el W3C no es totalmente independiente del navegador, por lo que muchas veces es necesario realizar ciertos trucos a la hora de crear hojas de estilo que definan un formato comn para varios navegadores distintos. 1.6.6.3. Conclusiones Esta tecnologa ser empleada para definir un formato de estilo general para todas las pginas Web que conformen el sitio a desarrollar, adems Dojo Toolkit hace uso directo de esta tecnologa y es indispensable para su correcto funcionamiento.
33
1.6.7. JEE
Acrnimo de Java Enterprise Edition o Java EE (anteriormente conocido como Java 2 Enterprise Edition o J2EE), es una parte de la plataforma Java de Sun Microsistems destinada al desarrollo de aplicaciones distribuidas, construidas mediante componentes modulares y con soporte para arquitecturas basadas en el patrn MVC, como Struts. Las aplicaciones desarrolladas con esta tecnologa se despliegan sobre un servidor de aplicaciones. A pesar de no ser un estndar ISO o ECMA s que est definido mediante una especificacin que determina el comportamiento bsico que debe cumplir cualquier implementacin para poder declarar su conformidad con dicha especificacin. 1.6.7.1. Ventajas Al apoyarse sobre Java es totalmente independiente de la plataforma, aumentando en gran medida su portabilidad entre sistemas. El servidor de aplicaciones puede ocuparse de las transacciones, la seguridad, escalabilidad, concurrencia y gestin de los componentes desplegados, derivando en que los desarrolladores pueden dedicar sus esfuerzos en la lgica de negocio de los componentes en lugar de en tareas de mantenimiento de bajo nivel. Otra caracterstica destacable es el gran conjunto de APIs que facilita al desarrollador para trabajar con Servlets, JSF, JSP, EJB, JNDI, SQL, XML Se hace especial hincapi en la reusabilidad y modularidad de las aplicaciones desarrolladas, dividiendo el sistema en capas independientes. Otro de sus grandes beneficios es el desarrollo a bajo coste, pudindose encontrar infinidad de recursos de cdigo abierto, incluso entornos de desarrollo como Eclipse, NetBeans o Jedit. 1.6.7.2. Desventajas Presenta una curva de aprendizaje pronunciada, que en el caso de sistemas Web puede resultar inadecuado para proyectos pequeos que puedan construirse con una solucin simple y rpida. 1.6.7.3. Conclusiones A pesar de su elevada dificultad inicial y su desaconsejado uso en sistemas Web sencillos, es muy recomendable su uso en sistemas con grandes necesidades de escalabilidad como el proyecto a desarrollar.
34
1.6.8. Struts
Es un framework para JEE que propone una capa de control basada en estndares como Servlets, JavaBeans, XML o Jakarta Commons. Aporta facilidades para crear aplicaciones escalables gracias al uso de patrones de diseo conocidos y probados como MVC. La aplicacin Web se divide en tres subsistemas: Modelo: representa el estado y la lgica de la aplicacin. Vista: interfaz de usuario (JSP, HTML). Controlador: gestiona el flujo de la aplicacin. La arquitectura de Struts se compone de un nico Servlet que hace de Controlador y redirige el flujo de la aplicacin entre las acciones y la capa de presentacin. Es como un puente entre la Vista y el Modelo. Normalmente toda la lgica de negocio debera estar contenida en el Modelo, si bien en escenarios ms simples se podra delegar dicha responsabilidad a las acciones invocadas por el Controlador. 1.6.8.1. Ventajas En la capa del Modelo puede interaccionar con sistemas de acceso a datos estndar como JDBC, EJB, Hibernate, iBatis, pero no impone ninguna, por lo que se considera de Modelo neutral. Tiene soporte para JSP, JSF, XSLT y otras tecnologas apropiadas para representar la capa de la Vista. Adems permite desarrollar esta capa mediante plantillas o tiles, empleando etiquetas especiales de la librera Struts Tiles y simplificando en gran medida su mantenimiento y comprensin. Tambin soporta de manera directa internacionalizacin basada en la especificacin ResourceBoundles de Java, o la propia de Struts. Otra librera recomendada es Struts Validator, que permite validar formularios tanto en el cliente como en el servidor, mediante la definicin de restricciones en un archivo XML, evitando el desarrollo de dichas tareas a menudo cotidianas. Adems est perfectamente integrada la internacionalizacin provista por Struts. Proporciona clases base que pueden ser extendidas para implementar las acciones de la aplicacin Web, como las clases Action y ActionForm. La mayora de los IDEs, como Eclipse, dan soporte al desarrollo de aplicaciones con este framework. 1.6.8.2. Desventajas Al igual que JEE, presenta una curva de aprendizaje pronunciada, por lo que puede resultar inadecuado para proyectos pequeos que admitan soluciones ms sencillas. 35
1.6.8.3. Conclusiones Por los mismos motivos que se decide aprobar JEE para el desarrollo de este proyecto, se considera viable la adopcin de Struts, ya que ha dems se dispone de un prototipo completamente funcional que integra Struts Tiles y Validator, internacionalizacin, DynaActionFormss, desarrollado como prctica final de la asignatura Desarrollo de Aplicaciones en Sistemas Distribuidos e Internet.
36
1.7. Libreras y Herramientas

Este apartado contiene una descripcin general de las libreras y herramientas utilizadas o estudiadas durante todo el ciclo de vida del proyecto, incluyendo herramientas de documentacin, desarrollo, diseo y anlisis.
37
1.7.1. Dojo Toolkit

Es una API de cdigo abierto para desarrollar clientes Web completos, es decir, un conjunto de libreras JavaScript distribuidas por niveles de abstraccin o capas que pueden emplearse con diferentes enfoques. Ofrece multitud de soluciones destinadas al desarrollo de aplicaciones Web 2.0. Dojo surge como iniciativa de cdigo abierto esponsorizada por SUN, IBM, SitePen, Renkoo, AOL, JotSpot, TurboAJAX y OpenLaszlo, que pretende renovar la visin esquiva de los desarrolladores hacia JavaScript y que ha evitado la adopcin a mayor escala de tecnologas DHTML. Adems Dojo prev un aprendizaje de carcter incremental, de tal manera que se pueda acceder a sus funcionalidades desde el primer momento y sin precisar de unos amplios conocimientos previos en la materia, ms que unas nociones bsicas de DHTML y CSS. El enfoque de Dojo se basa en el principio de que una herramienta difcil de usar no se usar, independientemente de lo buena que sea [Dojo]. 1.7.1.1. Ventajas Amplia coleccin de Widgets sin necesidad de cdigo (without code). Desarrollo de Widgets mediante plantillas. Distribucin de componentes mediante contenedores o layouts. Soporte directo para internacionalizacin y accesibilidad. Funcionalidades de escritorio como Drag & Drop y efectos visuales. Desarrollo independiente del navegador (cross-browser). Gestin de eventos y acceso al DOM. Servicios RPC y peticiones asncronas mediante AJAX y JSON. Analizadores XML basados en JavaScript. Soporte para grficos vectoriales como SVG y VML. Conexiones permanentes HTTP mediante Cometd. Compresin de ficheros de cdigo JavaScript. Integracin y desarrollo de casos de prueba mediante D.O.H. Definicin de jerarquas de clases en sintaxis similar a la de Java. Completa documentacin, incluida toda la API. 1.7.1.2. Desventajas La principal desventaja es el riesgo inherente en su adopcin como librera de soporte para el desarrollo del cliente, ya que se encuentra en estado de beta.
38
1.7.1.3. Conclusiones En principio se plante la posibilidad de emplear la versin 0.4.3, sin embargo durante el mes de junio fue lanzada una nueva versin, la 0.9.0, como precursora de la primera versin completa de Dojo que ser la 1.0. El mayor problema fue que la 0.9.0 no tiene compatibilidad hacia atrs, ya que Dojo ha sufrido una reestructuracin completa de su cdigo para mejorar la escalabilidad y comprensin del mismo, as como el rendimiento, las capacidades de internacionalizacin y accesibilidad. A pesar de la migracin necesaria del prototipo inicial que se desarroll durante el mes de mayo, es ms recomendable emplear la versin 0.9.0 por los beneficios a largo plazo y sobretodo de cara a futuras ampliaciones que se deseen realizar sobre este proyecto.
39
1.7.2. SAX
Las siglas de SAX vienen de Simple API for XML, se trata de un conjunto de interfaces pensadas para procesar documentos XML de manera sencilla y eficiente. SAX funciona mediante eventos y manejadores, de tal manera que la aplicacin pueda saber el orden de apertura y el anidamiento de las etiquetas y que, al contrario que otras APIs como DOM (Document Object Model), no requiere almacenar en memoria el rbol del documento y por tanto puede ser mucho ms eficiente en muchos contextos. 1.7.2.1. Ventajas Emplea manejadores de eventos en lugar de cargar el rbol del documento en memoria, por lo que consume menos recursos y suele ser ms eficiente. La mayora de las libreras para Java que trabajan con XML tienen soporte para esta API y es de uso ampliamente extendido. Es sencillo de entender y de utilizar, pudiendo extenderse su funcionalidad sin necesidad de desarrollar complejos sistemas de procesamiento. 1.7.2.2. Desventajas En algunas circunstancias concretas puede ser necesario el empleo de analizadores basados en DOM, porque si bien es posible generar un rbol del documento a partir de los eventos invocados por SAX es preferible usar otras alternativas ms enfocadas a ese propsito. 1.7.2.3. Conclusiones Puesto que las necesidades del proyecto respecto al procesamiento de documentos XML son muy concretas, unido a la extrema simplicidad del vocabulario a utilizar (GraphML), es adecuado el uso de esta API en lugar de DOM, obteniendo una serie de ventajas en cuanto a simplicidad y rendimiento. Adems supone un ahorro considerable de recursos, permitiendo una mayor escalabilidad del sistema final a desarrollar.
40
1.7.3. JUNG
Acrnimo de Java Universal Network/Graph Framework, una API de cdigo abierto para Java que propone soluciones comunes y extensibles para el diseo, anlisis y visualizacin de datos representados mediante grafos o redes [JUNG]. 1.7.3.1. Ventajas Soporta multitud de representaciones como grafos dirigidos, no dirigidos, mixtos, hipergrafos Permite anotar meta datos en los grafos, las entidades y las relaciones, facilitando la creacin de herramientas de anlisis. Tiene soporte para GraphML, que es el vocabulario elegido para la serializacin de los diagramas. Permite manipular la distribucin de los elementos mediante algoritmos clsicos de la teora de grafos, que adems pueden ser extendidos y especializados. Incluye otras libreras como Apache Commons, Xerces, JAXP y Colt. 1.7.3.2. Desventajas Ofrece un framework de visualizacin que facilita la construccin de herramientas interactivas, sin embargo slo soporta Swing y sera necesario adaptarlo para poder emplearlo en un entorno basado en AJAX. 1.7.3.3. Conclusiones En principio nicamente dara soporte a la serializacin de los diagramas y su posterior recuperacin, sin embargo en futuras versiones podra valorarse su empleo en escenarios de gestin avanzada de grafos, como distribucin automtica de los elementos segn layouts o la aplicacin de algoritmos.
41
1.7.4. Eclipse Web Tools Platform

Eclipse es una comunidad de cdigo abierto, cuyos proyectos estn enfocados a construir una plataforma de desarrollo extensible que cubra todo el ciclo de vida del software. Esta estructurado mediante plugins de tal forma que puede llegar a cubrir casi cualquier campo del desarrollo de un proyecto, incluido el anlisis y el diseo mediante UML. Concretamente la versin Web Tools Platform est pensada para desarrollar aplicaciones Web y tiene soporte integrado para multitud de lenguajes como XML, JavaScript 1.7.4.1. Ventajas Al ser cdigo abierto y extensible, existen multitud de plugins para extender su funcionalidad. Es un entorno de desarrollo libre y ampliamente aceptado por su flexibilidad y capacidad de adaptacin. Incluye validadores y editores para los lenguajes ms empleados en la Web como XML, XML Schema, RDF, JavaScript, XHTML Soporta compilacin, generacin de jars y despliegue mediante Ant. Tambin incluye una versin propia del navegador Mozilla, con multitud de utilidades para depurar cdigo JavaScript. Integracin completa con servidores de aplicaciones, permitiendo depurar en tiempo real la parte servidor de las aplicaciones Web desarrolladas. Est en constante desarrollo, solucionndose defectos existentes y ampliando nuevas funcionalidades. No requiere instalacin. 1.7.4.2. Desventajas Pueden presentarse algunas incompatibilidades generadas por el gran nmero de plugins y las versiones de Eclipse. 1.7.4.3. Conclusiones Se ha elegido esta herramienta por ser de fcil manejo y tener todos los requisitos necesarios para poder desarrollar el proyecto en casi todos sus aspectos. Se ha valorado tambin el hecho de que sea software libre y extensible.
42
1.7.5. Visual Paradigm

Es una herramienta de diseo de diagramas UML con soporte UML 2.1 y 13 tipos distintos de diagramas. Adems es extensible, lo cual quiere decir que se pueden definir nuevos tipos de diagramas o componentes por parte del usuario. 1.7.5.1. Ventajas Su versin Community Edition es de uso libre. Puede integrarse en los IDEs ms populares como Eclipse, NetBeans, JBuilder Soporta ingeniera inversa y generacin de cdigo de multitud de lenguajes de programacin a partir de los diagramas de clases. Posibilidad de exportar los diagramas a diferentes formatos. Facilidades de visualizacin, como el uso de layouts para la disposicin de los elementos de los diagramas. Es un ejemplo perfecto de caso de uso para el proyecto a desarrollar. 1.7.5.2. Desventajas La versin libre est limitada en cuanto a funcionalidad: no se pueden crear nuevos componentes y slo puede haber un diagrama de cada tipo, entre otras. 1.7.5.3. Conclusiones Se ha seleccionado por su interfaz intuitiva y por todas las funcionalidades que aporta como herramienta de diseo de diagramas.
43
1.7.6. GIMP
Es una herramienta de cdigo abierto con soporte para edicin de casi cualquier tipo de formato de imagen, tanto raster como vectorial. 1.7.6.1. Ventajas Incluye estructuracin de imgenes por capas, pudiendo ocultarse o aplicar transformaciones de manera independiente. Posee un historial de acciones que nos permite avanzar o retroceder a cualquier versin del trabajo realizado. Ideal para generar imgenes con transparencia para el diseo de interfaces de usuario, especialmente en aplicaciones Web. 1.7.6.2. Desventajas Tiene un elevado tiempo de respuesta al arrancar el programa ya que necesita cargar un gran nmero de mdulos, que pueden ser desactivados para agilizar este proceso. 1.7.6.3. Conclusiones El empleo de esta herramienta surge de la necesidad de crear imgenes con fondo transparente para el diseo y elaboracin de la interfaz de usuario.
44
45
CAPTULO 2: ESTUDIO DE VIABILIDAD

En este captulo se identifican los requisitos iniciales que se han de satisfacer y se estudia la situacin actual y las alternativas de solucin. Esta informacin se analiza con el fin de evaluar las distintas alternativas y seleccionar la ms adecuada, definiendo y estableciendo su planificacin.
46
2.1. Definicin del Alcance del Sistema

En este apartado se determinan los objetivos y se inicia el estudio de los requisitos. Adems se analizan las posibles restricciones que puedan condicionar el estudio y la planificacin de las alternativas de solucin que se propongan. Partiendo de una descripcin general del sistema y unos objetivos iniciales se establecern los lmites y objetivos del propio estudio de viabilidad.
47
2.1.1. Descripcin Inicial del Sistema

Inicialmente el proyecto a desarrollar era un entorno colaborativo de eLearning aplicado a las disciplinas que abarcan la Domtica y la Inmtica, principalmente el estudio de componentes y tecnologas, as como sus circuitos y reglas de interconexin. El enfoque prioritario es una arquitectura de Aplicacin Web, con apoyo de las tecnologas ms adecuadas de Web Semntica o Web 2.0 basadas en XML, que faciliten las posibles ampliaciones y su crecimiento autnomo en cuanto a contenidos.
48
2.1.2. Objetivos Iniciales del Sistema

2.1.2.1. Objetivos Tcnicos del Sistema Disponibilidad: Aplicacin Web (basada en patrn MVC) Dinamismo e interactividad: AJAX. Internacionalizacin (mnimo ingls y espaol). Extensibilidad: vocabulario XML entre cliente y servidor. Facilidad de uso: estndares W3C, accesibilidad, usabilidad Definicin de un lenguaje especfico del dominio y extensible. Meta-informacin: descripcin de los recursos mediante RDF. Estudio de la viabilidad de definir o reutilizar una ontologa OWL. Cross-browser: Internet Explorer, Firefox, Opera, Safari... Control de accesos y seguridad. 2.1.2.2. Objetivos Funcionales del Sistema Espacio de trabajo donde situar objetos y establecer reglas. Contenidos ampliables: crear componentes, definir nuevas reglas Toma de decisiones sobre nuevos contenidos mediante votaciones. Entorno colaborativo opiniones Web 2.0: compartir recursos, discutir
Sistemas de puntuacin y rankings por categoras. Pruebas terico-prcticas de autoevaluacin o seguimiento. Bsqueda de documentacin y ejemplos prcticos. Bsqueda de profesionales cualificados por perfil. Acceso incremental a contenidos y funcionalidad segn puntuaciones. Base de datos de usuarios, currculos, documentos, artculos
49
2.1.3. Objetivos del Estudio de Viabilidad

Identificar los objetivos iniciales del sistema y el alcance del mismo. Buscar las posibles soluciones existentes o en desarrollo mediante un estudio del estado del arte. Definir las directrices tcnicas y de gestin, as como los requisitos funcionales preliminares. Evaluar las distintas alternativas en funcin de los requisitos identificados. Determinar la alternativa de solucin ms adecuada.
50
2.1.4. Alcance del Estudio de Viabilidad

El objetivo prioritario es encontrar subsistemas o componentes reutilizables que sirvan de ayuda durante el ciclo de desarrollo del proyecto y que no supongan una excesiva limitacin respecto a la escalabilidad del sistema. Si se diera la situacin de encontrar un producto que cubra las necesidades del proyecto sera necesario evaluar otros factores de costes, riesgos y escalabilidad que podran hacer inviable la adopcin de dicho sistema. Es importante tener en cuenta que el sistema a desarrollar debe ser completamente personalizable y extensible por parte de cualquier tipo de usuario. Adems sera conveniente que fuera totalmente accesible desde una pgina Web sin necesidad de realizar ningn tipo de instalacin adicional. Se ha de tener presente que el proyecto estaba muy poco definido durante este estudio y por tanto las aplicaciones descritas estn estrechamente relacionadas con el dominio de la Domtica y el e-Learning. Posteriormente se decidi generalizar el caso de aplicacin para poder disear cualquier tipo de diagrama en un entorno colaborativo. Este estudio fue realizado durante los meses de enero y febrero de 2007.
51
2.2. Estudio de la Situacin Actual

La situacin actual es el estado en el que se encuentran los productos existentes en el momento en el que se inicia su estudio. Se describirn brevemente los productos examinados en la fase de gestacin del proyecto, cuando el campo de aplicacin del proyecto estaba ligado a la Domtica y por tanto el estudio esta centrado en este tipo de productos. Este estudio se apoya en los objetivos funcionales del sistema listados en el apartado anterior para seleccionar aquellos productos que ms se acercan a la idea global del sistema a desarrollar. En el caso de que se cumplan, se pasara a su evaluacin tcnica para determinar si son realmente viables y cumplen los objetivos tcnicos del sistema. La gran mayora de los sistemas descritos a continuacin han sido desarrollados como proyectos fin de carrera, tesis doctorales o proyectos de investigacin asociados con Universidades y/o comunidades de software libre.
52
2.2.1. Descripcin de los Sistemas Existentes

2.2.1.1. DomoSim-TPC (2002) AUTORES: Crescencio Bravo (http://www.inf-cr.uclm.es/www/cbravo/). Miguel A. Redondo (http://chico.inf-cr.uclm.es/mredondo/dsk/). UNIVERSIDAD: Universidad de Castilla-La Mancha (http://www.uclm.es/). DomoSim-TPC constituye un entorno integrado para el aprendizaje de las tcnicas de diseo de instalaciones para la automatizacin integral de viviendas y edificios, soportando la realizacin de actividades colaborativas en grupo y a distancia, la simulacin distribuida del diseo realizado, el anlisis del proceso que ha seguido el grupo, la evaluacin de la solucin obtenida y la relaciones entre el proceso y la solucin [Chico]. Caractersticas generales, definidas por los autores: Utiliza como dominio de aplicacin la Domtica. Los alumnos pueden participar en actividades de resolucin de problemas basados en escenarios reales. Los profesores gestionan y desarrollan problemas, en base a los cuales se plantean actividades a realizar individualmente o en grupo. Los alumnos realizan una planificacin de acciones de diseo, cuya solucin final se obtiene fruto de la colaboracin del grupo. Disponen de un sub-espacio de trabajo individual donde haciendo uso de iconos que se asocian a acciones genricas de diseo desarrollan y proponen su plan de diseo. En un segundo sub-espacio de trabajo (espacio de trabajo en grupo) tiene lugar la discusin asncrona y organizacin de las propuestas de cada uno de los participantes, para as, consensuar una solucin de grupo. Tras esta planificacin del diseo, se realiza el diseo de forma sncrona. Para facilitar este proceso se cuenta con diversas herramientas de comunicacin, tanto sncronas como asncronas (IRC o Chat, e-mail, sistemas de votacin, etc.). El sistema puede simular el comportamiento del diseo realizado. La simulacin se lleva a cabo de forma sncrona. Ofrece al coordinador o profesor un anlisis cuantitativo y cualitativo, fruto de la reconstruccin del razonamiento seguido por los alumnos y del dilogo practicado por los mismos a lo largo de la actividad.
53
Fig. 2-1. Espacio de simulacin de DomoSim-TPC
Todas y cada una de las caractersticas son accesibles a distancia, empleando para ello cualquier navegador Web con soporte para cdigo Java.
Fig. 2-2. Arquitectura de DomoSim-TPC
54
2.2.1.2. DomoEdit & DomoApplet (2005) Tutorial sobre Domtica e Inmtica AUTOR: Pedro Cantero Espadas. TUTORES: Ricardo Mayo Bayn, Vctor M. Gonzlez Surez. UNIVERSIDAD: Universidad de Oviedo (http://www.uniovi.es). DomoEdit es una herramienta que permite a un usuario debidamente formado disear ejercicios de conexionados de circuitos domticos y generar automticamente una pgina Web que los contenga para poder proponrselos a un alumno. DomoApplet es el nombre que se le ha dado al Applet Java que permite a un usuario intentar resolver el problema diseado con DomoEdit [Cantero]. Caractersticas generales: DomoEdit no es una aplicacin Web, sino de escritorio. Se trata de una aplicacin totalmente visual en la cual se utilizan imgenes de componentes domticos reales para disear los ejercicios.
Fig. 2-3. Crear componente en DomoEdit
Los profesores pueden crear componentes nuevos con DomoEdit. Se ha diseado una aplicacin de fcil manejo de forma que la manera de hacer las cosas sea muy intuitiva.
Fig. 2-4. Diseo de ejercicios en DomoEdit
55
Pueden crearse ejercicios partiendo componentes anteriormente creados para conectarlos entre s y proponrselos a los alumnos mediante DomoApplet. Aunque en principio DomoEdit ha sido pensado para componentes y circuitos domticos, debido a la transparencia de su diseo puede utilizarse para disear otro tipo de circuitos para los cuales no fue inicialmente concebida. Para el almacenamiento de la informacin se ha decidido utilizar ficheros XML, en lugar de una base de datos relacional. La pgina Web que realiza la llamada al Applet con los parmetros pertinentes ha sido generada previamente y debe ser copiada en el servidor. El alumno puede chequear las conexiones para verificar que son correctas.
Fig. 2-5. Chequear conexin en DomoApplet
Finalmente se evala la solucin propuesta por el alumno.
Fig. 2-6. Solucin de un ejercicio en DomoApplet
Requiere Java 2 para visualizar las pginas Web con DomoApplet.
56
2.2.1.3. CoVis (1994) Learning through Collaborative Visualization UNIVERSIDAD: Universidad (http://www.northwestern.edu/). de Northwestern
El Proyecto CoVis (1994) surgi en la como una iniciativa para transformar el aprendizaje de la Ciencia en la educacin bsica a travs del aprendizaje colaborativo con soporte computacional. Introduce la metfora de cuadernos de notas organizados en una biblioteca jerrquica, y divididos en pginas [CoVis]. 2.2.1.4. Moodle (2002) Modular Object-Oriented Dynamic Learning Environment AUTOR: Martin Dougiamas (http://dougiamas.com/). Es un sistema de gestin de cursos Open Source que ayuda a los educadores a crear comunidades de aprendizaje en lnea. Fue creado por Martin Dougiamas, quien era el administrador de WebCT en la Universidad Tecnolgica de Curtin, y se bas en las ideas del constructivismo en pedagoga que afirman que el conocimiento se construye en la mente del estudiante en lugar de ser transmitido sin cambios a partir de libros o enseanzas y en el aprendizaje colaborativo. Un profesor que opera desde este punto de vista crea un ambiente centrado en el estudiante que le ayuda a construir ese conocimiento con base en sus habilidades y conocimientos propios en lugar de simplemente publicar y transmitir la informacin que se considera que los estudiantes deben conocer [Moodle]. 2.2.1.5. CSILE (1993) Computer Supported Intentional Learning Environments AUTORES: Carl Bereiter y Marlene Scardamalia. UNIVERSIDAD: Universidad de Toronto (http://www.utoronto.ca/). Base de conocimientos comn utilizada en entornos acadmicos que permite crear problemas y aportar opiniones. Permite a los usuarios obtener mucha ms retroalimentacin sobre sus ideas de la que tendran si el docente fuera la nica fuente de retroalimentacin. Adems se pueden formular hiptesis y sugerencias, lo que suele inducir a los alumnos a revisar sus ideas. Presenta un entorno de trabajo estructurado en espacios de trabajo separados y maneja informacin compartida. La unidad bsica de almacenamiento es la anotacin que puede tener formato de texto o grfico y est relacionada con otras notas de la base de datos. Cuando un determinado tema est suficientemente explorado se publica y pasa a formar parte del conocimiento colectivo [CSILE].
57
2.2.1.6. TIBCO General Interface (2005) Ajax Rich Internet Application Resource Center AUTOR: TIBCO Software Inc. (http://www.tibco.com/). Entorno de desarrollo de aplicaciones Web de caractersticas similares, en cuanto a apariencia y rendimiento, a las aplicaciones cotidianas de escritorio. Evita la necesidad de instalar plugins para Applets mediante el uso de AJAX, uno de los objetivos tcnicos del proyecto. Caractersticas generales [TibcoRIA]: Licencia BSD Open Source. Ms de 100 componentes AJAX para utilizar. Herramientas visuales de diseo de interfaces grficas. Soporte para Internet Explorer 7 y Firefox 2. Depuracin integrada.
58
2.2.2. Diagnstico de la Situacin Actual

Queda patente que las lneas de investigacin y desarrollo en sistemas basados en e-Learning son muy difusas y hay mucho camino an por andar. Existen muchas teoras abiertas al respecto que exponen en detalle las consideraciones a tener en cuenta antes de de desarrollar un sistema de este tipo para que su uso pueda ser provechoso para el alumno y el tutor o profesor [Redondo]. Existen bastantes sistemas e-Learning Open Source genricos [eLearning]: Moodle (http://moodle.org). WebCT (http://www.webct.com/). Claroline (http://www.claroline.net/). Dokeos (http://sourceforge.net/projects/dokeos). ATutor (http://www.atutor.ca/). ILIAS (http://www.ilias.de/ios/index-e.html). Brihaspati (http://home.iitk.ac.in/~ynsingh/tool/brihaspati.shtml). Sakai Proyect (http://www.sakaiproject.org/). Edumate (http://www.edumate.com.au/). .LRN dot LRN (http://dotlrn.org/). LON-CAPA (http://www.loncapa.org/). Tambin se han encontrado multitud de ejemplos de aplicaciones e-Learning aplicadas a dominios especficos: ISP-VL (http://ispvl.learninglab.ki.se/) SimulNet (http://www.bessis.net/index.html) Finalmente se enumeran otra serie de sistemas que pueden aportar parte de la funcionalidad (sistemas de comunicacin, diagramas de descripcin de ideas...): MFK y Speak Easy (http://kie.berkeley.edu/kiosk/kiosk.html). Belvedere (http://belvedere.sourceforge.net/). CaMILE (http://www.cc.gatech.edu/gvu/edtech/CaMILE.html). Actualmente queda pendiente de estudio la situacin del estado del arte de las libreras existentes para simplificar el uso de AJAX, as como otros productos relacionados con interconexin de objetos como editores UML, simuladores de circuitos, diseo de planos, redes de ordenadores, etc.
59
2.3. Requisitos Iniciales del Sistema

Seguidamente se intentar concretar ms a fondo los requisitos necesarios para alcanzar los objetivos expuestos al principio de este captulo. Tampoco se pretende que sean inalterables, sino que se espera que sean refinados durante todo el ciclo de vida, especialmente en la fase de Anlisis.
60
2.3.1. Identificacin de las Directrices Generales

Este apartado cubre todos los requisitos no funcionales que no encajan en el mbito tecnolgico, como puede ser cuestiones sociales, acadmicas, comunicativas, colaborativas Enfoque a la libertad de accin por parte de los usuarios. Es preciso que el usuario sea completamente libre a la hora de avanzar dentro del sistema, pero que a su vez sea capaz de orientarse adecuadamente y no se sienta perdido, tanto en la bsqueda de contenidos como en su progresin educativa. Fomentar la colaboracin y comunicacin entre usuarios. La forma ms segura y rpida de aumentar el volumen de contenidos y componentes es permitiendo que los usuarios compartan sus propios recursos y el resto puedan valorar las mejores opciones para elegir la ms ventajosa para la comunidad mediante votaciones. Tambin debera disponer de medios suficientes para poder ayudar o aconsejar a los usuarios menos avanzados. Desarrollar el afn de superacin de los usuarios. Tambin resulta ventajoso, aunque arriesgado, proveer al proyecto de un sistema de rankings y estadsticas por categoras para poder tener una visin global de la evolucin o las destrezas propias de cada usuario. Motivando a los usuarios a mejorar dicha situacin a travs de la realizacin de pruebas, aadiendo contenidos o componentes, con valoraciones positivas de otros usuarios, Aplicar tcnicas de esfuerzo-recompensa. Aportando un sistema de bonificacin (acceso a recursos avanzados, nuevas funcionalidades o privilegios,) se trata de conseguir una experiencia ms atractiva y motivadora a los usuarios, que sin duda son el elemento clave del sistema. Los contenidos deben resultar tiles dentro del campo de e-Learning enfocado a las reglas de interconexin de objetos en entornos grficos.
61
2.3.2. Identificacin de las Directrices Tcnicas

En este apartado se describen las directrices tcnicas a seguir a la hora de implementar el sistema a estudio: El sistema debe ser una aplicacin Web de dominio pblico desarrollada mediante algn lenguaje especfico que no requiera gran inversin econmica y que, si es viable, sea libre. El patrn a seguir ser MVC. Puesto que actualmente no se concibe un enfoque esttico para una aplicacin de estas caractersticas ser necesario distribuir parte de la carga computacional en el cliente (navegador Web) mediante mecanismos o lenguajes que aporten dinamismo y, de ser posible, que no requieran la instalacin de plugins. La opcin ms aconsejable sera AJAX. A la hora de elegir el entorno de desarrollo de la aplicacin es aconsejable tener en cuenta las posibilidades que ofrece de internacionalizacin. Tambin es preciso extraer el modelo de datos del sistema del cdigo fuente mediante la aplicacin de tecnologas XML para la descripcin y definicin de contenidos y componentes. Es de vital importancia fomentar el empleo de vocabularios y esquemas de documentos desde el principio del desarrollo para evitar inconsistencias y congelaciones de requisitos y aumentar la escalabilidad global del sistema. Por otro lado la lgica de negocio relativa a las reglas de interconexin podra estar definida mediante un lenguaje especfico del dominio (DSL) y que adems fuese extensible y adaptable por los usuarios con el apoyo de nuevas tendencias de Web Semntica como RIF (Rule Interchange Format). Un paso ms all sera aadir meta-informacin de los recursos a travs de RDF (Resource Description Format) y definir o reutilizar una ontologa existente en OWL (Web Ontology Lenguaje). Actualmente hay un gran problema de lo que se podra denominar portabilidad de las aplicaciones Web entre diferentes navegadores o clientes, por lo que se recomienda encarecidamente el uso de estndares del W3C (World Wide Web Consortium) con el objetivo de disponer de una aplicacin que pueda visualizarse correctamente desde cualquier navegador (cross-browser), accesible y usable. Se debe prestar especial atencin al sistema control de accesos y seguridad que se implemente o sobre el que se implante la aplicacin ya que los usuarios nunca deberan tener acceso a la parte interna del sistema, desde donde podra verse comprometida la integridad y la validez del sistema de puntuaciones.
62
2.3.3. Identificacin de Requisitos Funcionales

Para mejorar su comprensin y evaluacin se agrupan en subsistemas. 2.3.3.1. Gestionar Usuarios Este subsistema se encarga de todas las actividades que dependen directamente de los usuarios y su informacin personal, acadmica o profesional dentro del sistema. Funciones de segundo nivel identificadas: Alta, baja, modificacin y consulta de usuarios. Consultar estadsticas y rankings de puntuaciones por categoras. Buscar usuarios por perfil. Login. 2.3.3.2. Gestionar Propuestas El cometido de este subsistema es proporcionar un medio consistente de ampliacin de recursos de la aplicacin mediante votaciones colaborativas y otros criterios por determinar, que consigan una mayor participacin y satisfaccin de los usuarios. Funciones de segundo nivel identificadas: Alta, baja, modificacin y consulta de propuestas. Buscar propuestas. Votar propuestas. Aceptar propuestas (slo usuarios autorizados). 2.3.3.3. Gestionar Contenidos En principio dentro de los contenidos slo se contemplan documentos, artculos y opiniones. Este subsistema se encarga de dotar a la aplicacin de un repositorio de informacin adecuado, para poder solventar las dudas que puedan surgir al realizar los ejercicios propuestos, y un medio compartido de comunicacin y discusin de opiniones similar a los foros y wikis que existen hoy da en Internet. Adems se contempla el acceso incremental a los contenidos segn las puntuaciones de los usuarios. Funciones de segundo nivel identificadas: Alta, baja, modificacin y consulta de contenidos. Buscar contenidos. Puntuar contenidos.
63
2.3.3.4. Gestionar Componentes Es uno de los subsistemas ms relevantes ya que se encarga de gestionar todos los aspectos relacionados con los componentes que se van a usar en los ejercicios que sean propuestos. Se contempla el acceso incremental a los componentes segn las puntuaciones de los usuarios. Funciones de segundo nivel identificadas: Alta, baja, modificacin y consulta de componentes. Buscar componentes. Compartir componentes. 2.3.3.5. Gestionar Reglas de Interconexin Este subsistema quiz sea uno de los ms complejos de disear ya que se trata de un campo totalmente novedoso de investigacin en el que se proponen mecanismos para extraer la lgica de negocio de una aplicacin y dejarla en manos de los usuarios finales, de cara a mejorar la experiencia y formacin de los mismos. Estas reglas pueden ser de mbito global o pueden estar enfocadas a una tecnologa o componente en particular por lo que habr que considerar la mejor alternativa a la hora de decidir su medio de almacenamiento persistente. Funciones de segundo nivel identificadas: Alta, baja, modificacin y consulta de reglas de interconexin. Buscar reglas de interconexin. Compartir reglas de interconexin. 2.3.3.6. Gestionar Ejercicios Se encarga de proveer un sistema de evaluacin mediante pruebas tericoprcticas de auto-evaluacin o seguimiento de los usuarios que se ejecutarn de forma dinmica en el navegador del usuario. Funciones de segundo nivel identificadas: Alta, baja, modificacin y consulta de ejercicios. Buscar ejercicios. Realizar ejercicio. Evaluar solucin.
64
2.4. Alternativas de Solucin

Entre todas las posibles alternativas, encontradas durante este estudio, destacan DomoSim-TPC, DomoEdit y los entornos genricos Open Source de e-Learning que podran servir de soporte al resto de subsistemas. De cara a afrontar el desarrollo del cliente Web resulta muy recomendable enfocarlo mediante libreras Open Source que simplifiquen el uso de AJAX y garanticen la independencia respecto al navegador empleado.
65
2.4.1. Estudio de Alternativas de Solucin

2.4.1.1. DomoSim-TPC A pesar de su gran funcionalidad y sus numerosas ventajas en el campo de la enseaza colaborativa, especialmente su vertiente sncrona, este sistema de eLearning completo y enfocado a la Domtica tiene ciertos inconvenientes que hacen que su adopcin no sea la ms adecuada frente a un desarrollo a medida, entre los que destacamos: No tiene la flexibilidad suficiente para permitir que los usuarios definan de forma sencilla nuevos componentes. No permite definir las reglas lgicas que definen el comportamiento y las conexiones entre los elementos. No se ha tenido acceso al cdigo fuente por lo que es difcil especificar su grado de escalabilidad, aunque se presupone alejado de los requisitos especificados a lo largo de este documento. Los propios autores reconocen que tiene un grado de complejidad de uso elevado como consecuencia del dominio de trabajo, sin embargo este aspecto es muy relevante en el sistema a desarrollar por lo que debera refinarse y simplificarse todo lo posible. 2.4.1.2. DomoEdit En principio este producto es el que tiene ms nivel de integracin con el sistema a desarrollar ya que podra utilizarse para cubrir el subsistema de gestin de ejercicios, en el caso de estudio de la interconexin de componentes electrnicos y domticos. Sin embargo el hecho de que requiera instalar la mquina virtual de Java en el navegador Web para poder acceder a la funcionalidad de DomoApplet puede ser un inconveniente. Adems el propio autor reconoce que resulta un poco limitado en cuanto a la flexibilidad del entorno de trabajo de los circuitos. Tampoco es muy prometedora la escalabilidad global del mismo porque lo que podra limitar el resto de los requisitos del sistema. 2.4.1.3. Entornos Open Source de Gestin de e-Learning Tambin hay que tener en cuenta la posibilidad de usar uno de estos entornos genricos para aliviar en parte la fase desarrollo del proyecto, aplicando los esfuerzos en otras reas ms relevantes o de mayor carcter innovador. Es necesario sopesar los pros y contras de cada uno de ellos y si es realmente viable la adopcin de alguno siempre y cuando no limite en exceso el resto de los requisitos definidos en el captulo anterior.
66
2.4.2. Planificacin de Alternativas de Solucin

Dada la naturaleza experimental del proyecto lo ms razonable es realizar un desarrollo ad-hoc del mismo intentando examinar en ms detalle las alternativas planteadas y otras que puedan surgir durante el ciclo de vida del proyecto. Lo ms recomendable es emplear un enfoque de desarrollo gil basado en prototipos funcionales y segn un modelo incremental, de modo que puedan obtenerse lo antes posible unos requisitos completos y consistentes, acortando los perodos de congelacin y disponiendo de versiones evaluables en un tiempo razonable. Tambin sera til disponer de los subsistemas de manera organizada permitiendo integrarlos paulatinamente segn van siendo ampliadas las funcionalidades o servicios de los prototipo desarrollados en cada incremento.
67
2.5. Ampliaciones del Estudio de Viabilidad

Este ltimo apartado incluye todas las aportaciones realizadas al estudio de viabilidad durante las fases de anlisis y diseo del sistema, en las cuales se redefinieron ampliamente los requisitos iniciales planteados anteriormente en este captulo y que por tanto fue requerido un estudio posterior ms especfico del estado del arte. Todos los sistemas expuestos a continuacin cubren una parte importante de los requerimientos finales especificados, sin abarcarlos en su totalidad, por lo que han sido empleados como referencia a la hora de disear las interfaces de usuario y definir el alcance del proyecto a desarrollar. Esta ampliacin al estudio de viabilidad fue realizada durante los meses de abril y mayo de 2007.
68
2.5.1. Clasificacin de los Sistemas Evaluados

2.5.1.1. JViews URL: Cliente: Servidor: XML: http://www.ilog.com/products/visualization/index.cfm AJAX Java SVG Soporta Java Server Faces. Soporte para gran cantidad de nodos y diagramas. Algoritmos de despliegue para grafos. Diseo de nuevos componentes. Incluye entorno de desarrollo. Inconvenientes: Requiere licencia de pago. Slo permite exportacin a SVG.
Caractersticas:
2.5.1.2. InfiView URL: Cliente: Servidor: XML: http://www.infiview.com/ AJAX Neutral GraphML Desarrollo de clientes basados en Bindows Framework (AJAX) Soporte para gran cantidad de nodos y tipos de diagramas. Algoritmos de despliegue para grafos Eficiente gestin del ancho de banda Incluye entorno de desarrollo. Inconvenientes: Requiere licencia de pago.
Caractersticas:
69
2.5.1.3. yFiles URL: Cliente: Servidor: XML: http://www.yworks.com/en/products_yfiles_about.htm AJAX o Flash Java GraphML Desarrollo de clientes basados Dojo Toolkit (AJAX) Soporte para gran cantidad de nodos y tipos de diagramas. Algoritos de despliegue para grafos Eficiente gestin del ancho de banda Incluye entorno de desarrollo. Inconvenientes: Requiere licencia de pago.
Caractersticas:
2.5.1.4. Cumulate Draw URL: Cliente: Servidor: XML: http://www.cumulatelabs.com/cumulatedraw/ AJAX Java SVG, MMD, FMD. Gran variedad de tipos de diagramas. Interfaz grfica muy elaborada. Diseo de nuevos componentes. Licencia Creative Commons. Exportacin a JPG, PNG y PDF. Versin on-line gratuita. Inconvenientes: Cdigo fuente disponible slo bajo peticin.
Caractersticas:
70
2.5.1.5. JGraph, Layout Pro y mxGraph URL: Cliente: Servidor: XML: http://www.jgraph.com AJAX Java Formato propio. Gran variedad de tipos de diagramas. Algoritmos de despliegue para grafos. Interfaz grfica muy elaborada. Diseo de nuevos componentes. Licencia LGPL slo para JGraph. Inconvenientes: Licencia de pago para los extras y mxGraph (AJAX).
Caractersticas:
2.5.1.6. Flowchart URL: Cliente: Servidor: XML: http://www.flowchart.com/ AJAX Slo disponible en versin on-line. No disponible. Colaboracin en tiempo real. Almacenamiento on-line. Exportacin a PNG y PDF. Interfaz grfica muy elaborada. Gran variedad de tipos de diagramas. Versin demo on-line gratuita. Inconvenientes: Sin exportacin a XML. Sin acceso al cdigo fuente.
Caractersticas:
71
2.5.1.7. Gliffy URL: Cliente: Servidor: XML: http://gliffy.com/ Flash Slo disponible en versin on-line. SVG Colaboracin en tiempo real. Almacenamiento on-line. Exportacin a PNG y JPG. Interfaz grfica muy elaborada. Gran variedad de tipos de diagramas. Versin on-line gratuita, aunque limitada. Inconvenientes: Slo 5 diagramas en la versin gratuita. Sin acceso al cdigo fuente.
Caractersticas:
2.5.1.8. Visuwords URL: Cliente: Servidor: XML: http://www.visuwords.com/ Flash Slo disponible en versin on-line. No disponible. Diccionario grfico on-line gratuito. Cdigo fuente bajo licencia Open Source. Inconvenientes: Muy limitado: no permite editar. Sin exportacin a XML.
Caractersticas:
72
2.5.1.9. Kayuda URL: Cliente: Servidor: XML: http://www.kayuda.com/ AJAX Slo disponible en versin on-line. SVG Basado en Dojo Toolkit (AJAX). Permite compartir diagramas. Versin on-line gratuita. Inconvenientes: Escasa variedad de componentes. Sin exportacin a XML. Sin acceso al cdigo fuente. Poco usable.
Caractersticas:
2.5.1.10. Mind42 URL: Cliente: Servidor: XML: http://www.mind42.com/portal/index.xhtml AJAX Slo disponible en versin on-line. FreeMind, mind42 Basado en Dojo Toolkit (AJAX). Colaboracin en tiempo real. Incluye Google Talk Gadget. Exportacin a RTF. Inconvenientes: Muy limitado: slo mapas de ideas. Sin acceso al cdigo fuente.
Caractersticas:
73
2.5.1.11. Bubbl.us URL: Cliente: Servidor: XML: http://www.bubbl.us/ Flash Solo disponible versin on-line. Formato propio. Permite compartir diagramas Exportacin a JPG, PNG y HTML Inconvenientes: Muy limitado: slo mapas de ideas. Escasa variedad de componentes. Sin acceso al cdigo fuente.
Caractersticas:
2.5.1.12. MindMeister URL: Cliente: Servidor: XML: http://www.mindmeister.com/ AJAX Solo disponible versin on-line FreeMind, MindManager. Colaboracin en tiempo real Permite compartir diagramas Exportacin a GIF, JPG, PNG y RTF. Inconvenientes: Muy limitado: slo mapas de ideas. Escasa variedad de componentes. Emplea la librera wz_jsgraphics.js.
Caractersticas:
74
2.5.1.13. Open-jACOB Draw2D URL: Cliente: Servidor: XML: http://www.openjacob.org/draw2d.html AJAX Cualquiera. Formato propio. Open-jACOB Framework Cdigo disponible bajo licencia Open Source. Inconvenientes: Proyecto en estado de beta. Emplea la librera wz_jsgraphics.js.
Caractersticas:
2.5.1.14. Web Sequence Diagram Generator URL: Cliente: Servidor: XML: http://www.websequencediagrams.com/ HTML Solo disponible versin on-line FreeMind, MindManager. Simplicidad de uso. Edicin y exportacin en formato texto. Inconvenientes: Muy limitado: slo diagramas de secuencia. Escasa variedad de opciones.
Caractersticas:
75
CAPTULO 3: ANLISIS
En este captulo se especifican en mayor detalle los requerimientos del sistema a desarrollar, partiendo de una especificacin textual de los mismos se extraer una lista clasificada y se disearan los casos de uso asociados. Posteriormente se identifican las clases asociadas a cada caso de uso y se realiza el diagrama de clases preliminar junto con una breve descripcin de las clases encontradas. Finalmente se propone un formato base para la interfaz de usuario, que abarque las funcionalidades bsicas descritas este captulo y aporte una visin global de las pantallas a desarrollar.
76
3.1. Modelo de Requerimientos

Este apartado cubre todas las modificaciones realizadas respecto a los requisitos iniciales identificados durante el estudio de viabilidad, que surgen del estudio de las tecnologas, libreras y herramientas descrito brevemente en la memoria de este documento. El campo de aplicacin se generaliz para poder cubrir cualquier tipo de diagrama, centrando los objetivos del proyecto en la realizacin de un sistema lo ms escalable posible y tratando de desarrollar un entorno que adems permitiese la colaboracin sncrona de los usuarios.
77
3.1.1. Especificacin Textual

La aplicacin consta de dos partes: cliente y servidor. La parte servidor se desarrollar mediante el patrn Modelo-VistaControlador (MVC) junto con el empleo de diversas tecnologas de Web Semntica que aporten extensibilidad y simplifiquen en la medida de lo posible el diseo del modelo de datos y de comportamiento que servir de lenguaje comn entre el cliente y el servidor. En cuanto a la parte cliente el objetivo es que sea completamente independiente de la parte servidor y a ser posible independiente del navegador; preferiblemente ser desarrollada mediante AJAX con el fin de lograr un entorno visual ms amigable para el usuario, similar a las aplicaciones tpicas de escritorio, que adems no requiere que el usuario realice ninguna instalacin adicional. Tambin se valorar la viabilidad de implementar un entorno colaborativo dnde varios usuarios puedan interaccionar simultneamente sobre el mismo diagrama de forma similar a las posibilidades que ofrece una pizarra compartida. Respecto a los requisitos funcionales, bsicamente se espera conseguir la misma funcionalidad que cualquier otra aplicacin de diseo de diagramas, circuitos, redes, etc. Aadiendo la posibilidad de disear nuevos objetos y tecnologas segn las necesidades de los usuarios del entorno. La principal ventaja reside en la ubicuidad y disponibilidad propias de un entorno de este tipo, que permite que el usuario acceda a sus contenidos, guarde sus progresos y comparta sus diagramas desde cualquier ordenador con conexin a Internet.
78
3.1.2. Especificacin de Requerimientos Funcionales

A continuacin de enumeran todos los requerimientos aprobados para el proyecto, obtenidos a partir de un filtrado exhaustivo de los requisitos iniciales del estudio de viabilidad y de la especificacin textual del apartado anterior. 3.1.2.1. R1 Gestionar Diagramas Este subsistema deber proporcionar la funcionalidad necesaria para crear, eliminar, compartir y acceder a los diagramas. Tambin se encargar del control de versiones de los mismos, permitiendo el acceso a versiones anteriores sin perder los cambios actuales. Funciones de segundo nivel identificadas: R1.1 Alta, baja y modificacin de diagramas. R1.2 Buscar diagramas. R1.3 Publicar / compartir diagramas. R1.4 Control de versiones de los diagramas. 3.1.2.2. R2 Disear Diagramas El diseo de los diagramas abarca cualquier cambio que se desee realizar sobre el contenido o la disposicin de un diagrama concreto. Se trata de desarrollar un entorno grfico de dibujo dnde se buscar la forma de permitir a los usuarios trabajar de manera conjunta y remota sobre un mismo diagrama y a ser posible que los cambios se actualicen en tiempo real en todos los clientes. Funciones de segundo nivel identificadas: R2.1 Definir dimensiones del rea de diseo. R2.2 Aadir y eliminar componentes. R2.3 Realizar conexiones entre componentes. R2.4 Aplicar transformaciones bsicas (zoom, rotacin). R2.5 Cortar, copiar y pegar. R2.6 Historial de deshacer / rehacer. R2.7 Guardar, exportar e importar. R2.8 Colaborar mediante pizarra compartida y Chat.
79
3.1.2.3. R3 Gestionar Componentes Adicionalmente se valorar la posibilidad de desarrollar un subsistema de gestin de componentes que permita crear, borrar y modificar nuevos componentes o extender los ya existentes, con el fin de poder emplearlos en el subsistema de diseo de diagramas. Al igual que con la gestin de diagramas se permitir el acceso a versiones anteriores sin perder los cambios actuales. Funciones de segundo nivel identificadas: R3.1 Alta, baja y modificacin de componentes. R3.2 Buscar componentes. R3.3 Publicar / compartir componentes. R3.4 Control de versiones de los componentes. 3.1.2.4. R4 Disear Componentes Este subsistema quiz sea uno de los ms complejos de disear ya que se trata de un campo totalmente novedoso de investigacin en el que se proponen mecanismos para extraer la lgica de negocio de una aplicacin y dejarla en manos de los usuarios finales, de cara a mejorar su experiencia en el sistema. Funciones de segundo nivel identificadas: R4.1 Definir dimensiones del componente. R4.2 Aadir y eliminar formas bsicas (geometras, imgenes). R4.3 Definir zonas de interconexin (puertos). R4.4 Aplicar transformaciones bsicas (zoom, rotacin). R4.5 Cortar, copiar y pegar. R4.6 Historial de deshacer / rehacer. R4.7 Guardar, exportar e importar. 3.1.2.5. R5 Gestionar Cuentas de Usuario Como cualquier otro sistema en el que intervengan usuarios es necesario disponer de mecanismo para crear, borrar y actualizar sus datos. Funciones de segundo nivel identificadas: R5.1 Alta, baja y modificacin. R5.2 Validar usuario (login). R5.3 Buscar usuarios. R5.4 Consultar estadsticas y puntuaciones.
80
3.1.3. Especificacin de Requerimientos No Funcionales

En este apartado se recogen todos los requerimientos que no encajan en el apartado anterior, como puede ser cuestiones tecnolgicas, sociales, acadmicas, comunicativas, colaborativas 3.1.3.1. RNF 1: Requerimientos Generales A continuacin se describen todos los requerimientos aprobados que por su naturaleza no se pueden encuadrar en una categora concreta: RNF 1.1 Enfoque a la libertad de accin de los usuarios. Es preciso que el usuario sea completamente libre a la hora de avanzar dentro del sistema, pero que a su vez sea capaz de orientarse adecuadamente y no se sienta perdido, tanto en la bsqueda de contenidos como en su progresin formativa. RNF 1.2 Fomentar la colaboracin y comunicacin entre usuarios. La forma ms segura y rpida de aumentar el volumen de contenidos y componentes es permitiendo que los usuarios compartan sus propios recursos. RNF 1.3 Desarrollar el afn de superacin de los usuarios. Tambin puede resultar ventajoso, aunque arriesgado, proveer al proyecto de un sistema de rankings y estadsticas para poder tener una visin global de la evolucin o las destrezas propias de cada usuario. Motivando a los usuarios a mejorar dicha situacin a travs de la realizacin de pruebas, aadiendo contenidos o componentes, con valoraciones positivas de otros usuarios RNF 1.4 Aplicar tcnicas de esfuerzo-recompensa. Aportando un sistema de bonificacin (acceso a recursos avanzados, nuevas funcionalidades o privilegios,) se trata de conseguir una experiencia ms atractiva y motivadora a los usuarios, que sin duda son el elemento clave del sistema. RNF 1.5 La interfaz de usuario debe ser accesible y usable. Deben aplicarse tcnicas adecuadas de comunicacin persona-mquina para lograr una interfaz lo ms correcta posible, que permita una interaccin accesible e intuitiva. RNF 1.6 Buscar el apoyo de soluciones de cdigo abierto. Evitando en la medida de lo posible reinventar la rueda.
81
3.1.3.2. RNF 2: Requerimientos Tcnicos Finalmente se presentan los requerimientos tcnicos que debe cubrir el sistema a desarrollar: RNF 2.1 Emplear el patrn MVC para disear la arquitectura del sistema. El sistema final debe ser una aplicacin Web de dominio pblico diseada mediante el patrn MVC. RNF 2.2 Emplear tecnologas AJAX en el desarrollo del cliente. Puesto que actualmente no se concibe un enfoque esttico para una aplicacin de estas caractersticas ser necesario distribuir parte de la carga computacional en el cliente (navegador Web). RNF 2.3 Dar soporte directo a la internacionalizacin de la interfaz. A la hora de elegir el entorno de desarrollo de la aplicacin es aconsejable tener en cuenta las posibilidades que ofrece de internacionalizacin. RNF 2.4 Dar soporte a los navegadores Web ms empleados. Actualmente hay un gran problema respecto a la portabilidad de las aplicaciones Web entre diferentes navegadores, por lo que se recomienda el uso de estndares del W3C (World Wide Web Consortium) con el objetivo de disponer de una aplicacin que pueda visualizarse correctamente desde cualquier navegador (cross-browser). RNF 2.5 Evitar la necesidad de instalar plugins en los navegadores. Permitir que los usuarios puedan tener acceso al sistema desde cualquier ordenador con un navegador Web y conexin a Internet. RNF 2.6 Definir el modelo de datos mediante tecnologas XML. Es de vital importancia fomentar el empleo de vocabularios desde el principio del desarrollo para evitar inconsistencias y congelaciones de requisitos y aumentar la escalabilidad global del sistema. RNF 2.7 Definir un lenguaje especfico del domino para las conexiones. La lgica de negocio relativa a las reglas de interconexin podra estar definida mediante un lenguaje especfico del dominio (DSL) y que adems fuese extensible y adaptable. RNF 2.8 Valorar el uso de meta-informacin en los recursos. Un paso ms all sera aadir meta-informacin a los recursos a travs de RDF (Resource Description Format) y definir o reutilizar una ontologa existente en OWL (Web Ontology Lenguaje). RNF 2.9 Disear un sistema de control de accesos y seguridad adecuado. Se debe prestar especial atencin al sistema control de accesos y seguridad que se implemente o sobre el que se implante la aplicacin.
82
3.2. Especificacin de Casos de Uso
Fig. 3-1. Diagrama de Casos de Uso
83
3.2.1. Actores
En principio la aplicacin no contempla diferentes tipos de usuarios por lo que los actores que se describen a continuacin pueden representar a una misma persona en contextos diferentes. 3.2.1.1. Actor 1: Usuario Registrado
Definicin
Representa al usuario cuando interacta con el sistema de cara a obtener informacin pblica o compartida, es decir, cuando accede a contenidos sobre los que no tiene derechos de propietario. Tiene acceso total a los contenidos pblicos del sistema. Los permisos de este actor sobre los contenidos compartidos estn definidos por el propietario de los mismos.
Tabla 3.2-1. Actor 1: Usuario Registrado
Notas
3.2.1.2. Actor 2: Propietario

Definicin
Representa al usuario cuando accede a los contenidos sobre los que tiene derechos de propietario, incluyendo diagramas, componentes y datos personales. Tiene acceso total a sus propios contenidos. Puede definir permisos para otros usuarios sobre sus contenidos. Los contenidos pueden tener varios propietarios.
Tabla 3.2-2. Actor 2: Propietario
Notas
3.2.1.3. Actor 3: Colaborador

Definicin
Representa al usuario cuando colabora de manera sincronizada con otros usuarios en el diseo de un diagrama. No necesita derechos de propietario sobre el diagrama. El propietario define los permisos que tienen el resto de colaboradores.
Tabla 3.2-3. Actor 3: Colaborador
Notas
84
3.2.2. Casos de Uso

3.2.2.1. Caso de Uso 1: Gestionar Diagramas (R1)
Definicin
Proporciona la funcionalidad necesaria para crear, eliminar, modificar, compartir y acceder a los diagramas. Tambin se encarga del control de versiones. Propietario / Usuario Registrado. Alta. Alta. R1.1, R1.2, R1.3, R1.4. El propietario define los permisos que tienen el resto de usuarios sobre sus diagramas. Un diagrama puede tener varios propietarios.
Tabla 3.2-4. Caso de Uso 1: Gestionar Diagramas (R1)
Actores Prioridad Importancia Requerimientos Notas
3.2.2.1.1. Escenario 1.1: Alta, baja y modificacin de diagramas (R1.1)

Precondiciones Poscondiciones Iniciado por Finalizado por Secuencia de operaciones
El usuario debe estar registrado en el sistema. Los cambios deben actualizarse en la interfaz de usuario. Propietario / Usuario Registrado. Propietario / Usuario Registrado. El usuario solicita la operacin. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en la interfaz de usuario.
Excepciones Notas
El usuario no tiene permisos suficientes. Los propietarios definen los permisos que tienen el resto de usuarios sobre sus diagramas.
Tabla 3.2-5. Escenario 1.1: Alta, baja y modificacin de diagramas (R1.1)
85
3.2.2.1.2. Escenario 1.2: Buscar diagramas (R1.2)

Los criterios de bsqueda deben ser vlidos. Los resultados deben mostrarse en la interfaz de usuario. Propietario / Usuario Registrado. Propietario / Usuario Registrado. El usuario establece los criterios de bsqueda. El sistema valida los datos de entrada. Se realizan las acciones pertinentes. Se muestra el resultado en la interfaz de usuario.
Excepciones
No se encuentra ningn diagrama que cumpla los criterios de bsqueda establecidos. Los propietarios definen la visibilidad de sus diagramas para el resto de usuarios, es decir, pueden ocultarlos.
Tabla 3.2-6. Escenario 1.2: Buscar diagramas (R1.2)
Notas
3.2.2.1.3. Escenario 1.3: Publicar / compartir diagramas (R1.3)

El usuario debe tener derechos de propietario. Los cambios deben actualizarse en la interfaz de usuario. Propietario. Propietario. El usuario define los permisos sobre el diagrama. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en la interfaz de usuario.
Excepciones Notas
El usuario no tiene permisos suficientes. Slo el propietario puede definir permisos sobre sus diagramas. Un diagrama puede tener varios propietarios.
Tabla 3.2-7. Escenario 1.3: Publicar / compartir diagramas (R1.3)
86
3.2.2.1.4. Escenario 1.4: Control de versiones de los diagramas (R1.4)

El usuario debe tener permiso de edicin sobre el diagrama Los cambios deben actualizarse en la interfaz de usuario. Propietario / Usuario Registrado. Propietario / Usuario Registrado. El usuario selecciona la versin del diagrama. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se muestra el diagrama en la interfaz de usuario.
Excepciones Notas
Tabla 3.2-8. Escenario 1.4: Control de versiones de los diagramas (R1.4)
87
3.2.2.2. Caso de Uso 2: Disear Diagramas (R2)

Definicin
El diseo de los diagramas abarca cualquier cambio que se desee realizar sobre el contenido o la disposicin de un diagrama concreto. Se trata de desarrollar un entorno grfico de dibujo dnde se buscar la forma de permitir a los usuarios trabajar de manera conjunta y remota sobre un mismo diagrama y a ser posible que los cambios se actualicen en tiempo real en todos los clientes. Propietario / Usuario Registrado / Colaborador. Mxima. Mxima. R2.1, R2.2, R2.3, R2.4, R2.5, R2.6, R2.7, R2.8 Los propietarios definen los permisos que tienen el resto de usuarios sobre sus diagramas. Un diagrama puede tener varios propietarios.
Tabla 3.2-9. Caso de Uso 2: Disear Diagramas (R2)
3.2.2.2.1. Escenario 2.1: Definir dimensiones del rea de diseo (R2.1)

El usuario debe tener permiso de edicin sobre el diagrama Los cambios deben actualizarse en todos los clientes. Propietario / Usuario Registrado / Colaborador. Propietario / Usuario Registrado / Colaborador. El usuario solicita redimensionar el rea de diseo. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en todos los clientes conectados.
Excepciones Notas
Tabla 3.2-10. Escenario 2.1: Definir dimensiones del rea de diseo (R2.1)
88
3.2.2.2.2. Escenario 2.2: Aadir y eliminar componentes (R2.2)

El usuario debe tener permiso de edicin sobre el diagrama Los cambios deben actualizarse en todos los clientes. Propietario / Usuario Registrado / Colaborador. Propietario / Usuario Registrado / Colaborador. El usuario solicita la operacin. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en todos los clientes conectados.
Excepciones Notas
Tabla 3.2-11. Escenario 2.2: Aadir y eliminar componentes (R2.2)
3.2.2.2.3. Escenario 2.3: Realizar conexiones entre componentes (R2.3)

Excepciones Notas
Tabla 3.2-12. Escenario 2.3: Realizar conexiones entre componentes (R2.3)
89
3.2.2.2.4. Escenario 2.4: Aplicar transformaciones bsicas (R2.4)

El usuario debe tener permiso de edicin sobre el diagrama Los cambios deben actualizarse en todos los clientes. Propietario / Usuario Registrado / Colaborador. Propietario / Usuario Registrado / Colaborador. El usuario solicita la transformacin. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en todos los clientes conectados.
Excepciones Notas
Tabla 3.2-13. Escenario 2.4: Aplicar transformaciones bsicas (R2.4)
3.2.2.2.5. Escenario 2.5: Cortar, copiar y pegar (R2.5)

Excepciones Notas
Tabla 3.2-14. Escenario 2.5: Cortar, copiar y pegar (R2.5)
90
3.2.2.2.6. Escenario 2.6: Historial de deshacer / rehacer (R2.6)

El usuario debe tener permiso de edicin sobre el diagrama Los cambios deben actualizarse en todos los clientes. Propietario / Usuario Registrado / Colaborador. Propietario / Usuario Registrado / Colaborador. El usuario solicita cambiar a un estado anterior o posterior. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en todos los clientes conectados.
Excepciones Notas
Tabla 3.2-15. Escenario 2.6: Historial de deshacer / rehacer (R2.6)
3.2.2.2.7. Escenario 2.7: Guardar, exportar e importar (R2.7)

El usuario debe tener permiso de edicin sobre el diagrama Los cambios deben ser visibles en todo el sistema. Propietario / Usuario Registrado / Colaborador. Propietario / Usuario Registrado / Colaborador. El usuario solicita la operacin. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en todo el sistema.
Excepciones Notas
Tabla 3.2-16. Escenario 2.7: Guardar, exportar e importar (R2.7)
91
3.2.2.2.8. Escenario 2.8: Colaborar mediante pizarra compartida (R2.8)

El usuario debe tener permiso de edicin sobre el diagrama El usuario puede comunicarse con los dems colaboradores Colaborador. Colaborador. El usuario solicita colaborar en un diagrama o es invitado. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en todo los clientes conectados.
Excepciones Notas
El usuario no tiene permisos suficientes. Los propietarios definen los permisos que tienen el resto de usuarios sobre sus diagramas. Se valorar la posibilidad de implementar o reutilizar una herramienta tipo Chat para la comunicacin entre colaboradores.
Tabla 3.2-17. Escenario 2.8: Colaborar mediante pizarra compartida (R2.8)
92
3.2.2.3. Caso de Uso 3: Gestionar Componentes (R3)

Definicin
Permite crear, borrar y modificar nuevos componentes o extender los ya existentes, con el fin de poder emplearlos en el diseo de diagramas. Al igual que con la gestin de diagramas se permitir el acceso a versiones anteriores sin perder los cambios actuales. Propietario / Usuario Registrado. Media. Alta. R3.1, R3.2, R3.3, R3.4. El propietario define los permisos que tienen el resto de usuarios sobre sus componentes. Un componente puede tener varios propietarios.
Tabla 3.2-18. Caso de Uso 3: Gestionar Componentes (R3)
3.2.2.3.1. Escenario 3.1: Alta, baja y modificacin de componentes (R3.1)

El usuario debe estar registrado en el sistema. Los cambios deben actualizarse en la interfaz de usuario. Propietario / Usuario Registrado. Propietario / Usuario Registrado. El usuario solicita la operacin. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en la interfaz de usuario.
Excepciones Notas
El usuario no tiene permisos suficientes. Los propietarios definen los permisos que tienen el resto de usuarios sobre sus componentes.
Tabla 3.2-19. Escenario 3.1: Alta, baja y modificacin de componentes (R3.1)
93
3.2.2.3.2. Escenario 3.2: Buscar componentes (R3.2)

Excepciones
No se encuentra ningn componente que cumpla los criterios de bsqueda establecidos. Los propietarios definen la visibilidad de sus componentes para el resto de usuarios, es decir, pueden ocultarlos.
Tabla 3.2-20. Escenario 3.2: Buscar componentes (R3.2)
Notas
3.2.2.3.3. Escenario 3.3: Publicar / compartir componentes (R3.3)

El usuario debe tener derechos de propietario. Los cambios deben actualizarse en la interfaz de usuario. Propietario. Propietario. El usuario define los permisos sobre el componente. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en la interfaz de usuario.
Excepciones Notas
El usuario no tiene permisos suficientes. Slo el propietario puede definir permisos sobre sus componentes. Un componente puede tener varios propietarios.
Tabla 3.2-21. Escenario 3.3: Publicar / compartir componentes (R3.3)
94
3.2.2.3.4. Escenario 1.4: Control de versiones de los componentes (R1.4)

Tener permiso de edicin sobre el componente. Los cambios deben actualizarse en la interfaz de usuario. Propietario / Usuario Registrado. Propietario / Usuario Registrado. El usuario selecciona la versin del componente. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se muestra el diagrama en la interfaz de usuario.
Excepciones Notas
Tabla 3.2-22. Escenario 3.4: Control de versiones de los componentes (R3.4)
95
3.2.2.4. Caso de Uso 4: Disear Componentes (R4)

Definicin
Este subsistema quiz sea uno de los ms complejos de disear ya que se trata de un campo totalmente novedoso en el que se proponen mecanismos para extraer la lgica de negocio de una aplicacin y dejarla en manos de los usuarios finales, de cara a mejorar su experiencia en el sistema. Propietario / Usuario Registrado. Baja. Alta. R4.1, R4.2, R4.3, R4.4, R4.5, R4.6, R4.7. No se contempla colaboracin sncrona entre usuarios. Los propietarios definen los permisos que tienen el resto de usuarios sobre sus componentes. Un componente puede tener varios propietarios.
Tabla 3.2-23. Caso de Uso 4: Disear Componentes (R4)
3.2.2.4.1. Escenario 4.1: Definir dimensiones del componente (R4.1)

Tener permiso de edicin sobre el componente. Los cambios deben actualizarse en la interfaz de usuario. Propietario / Usuario Registrado. Propietario / Usuario Registrado. El usuario solicita redimensionar el rea de diseo. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en la interfaz de usuario.
Excepciones Notas
Tabla 3.2-24. Escenario 4.1: Definir dimensiones del componente (R4.1)
96
3.2.2.4.2. Escenario 4.2: Aadir y eliminar formas bsicas (R4.2)

Tener permiso de edicin sobre el componente. Los cambios deben actualizarse en la interfaz de usuario. Propietario / Usuario Registrado. Propietario / Usuario Registrado. El usuario solicita la operacin. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en la interfaz de usuario.
Excepciones Notas
Tabla 3.2-25. Escenario 4.2: Aadir y eliminar formas bsicas (R4.2)
3.2.2.4.3. Escenario 4.3: Definir zonas de interconexin (R4.3)

Tener permiso de edicin sobre el componente. Los cambios deben actualizarse en la interfaz de usuario. Propietario / Usuario Registrado. Propietario / Usuario Registrado. El usuario solicita la operacin. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en la interfaz de usuario.
Excepciones Notas
Tabla 3.2-26. Escenario 4.3: Definir zonas de interconexin (R4.3)
97
3.2.2.4.4. Escenario 4.4: Aplicar transformaciones bsicas (R4.4)

Tener permiso de edicin sobre el componente. Los cambios deben actualizarse en la interfaz de usuario. Propietario / Usuario Registrado. Propietario / Usuario Registrado. El usuario solicita la transformacin. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en la interfaz de usuario.
Excepciones Notas
Tabla 3.2-27. Escenario 4.4: Aplicar transformaciones bsicas (R4.4)
3.2.2.4.5. Escenario 4.5: Cortar, copiar y pegar (R4.5)

Tener permiso de edicin sobre el componente. Los cambios deben actualizarse en la interfaz de usuario. Propietario / Usuario Registrado / Colaborador. Propietario / Usuario Registrado / Colaborador. El usuario solicita la operacin. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en la interfaz de usuario.
Excepciones Notas
Tabla 3.2-28. Escenario 4.5: Cortar, copiar y pegar (R4.5)
98
3.2.2.4.6. Escenario 4.6: Historial de deshacer / rehacer (R4.6)

Tener permiso de edicin sobre el componente. Los cambios deben actualizarse en la interfaz de usuario. Propietario / Usuario Registrado / Colaborador. Propietario / Usuario Registrado / Colaborador. El usuario solicita cambiar a un estado anterior o posterior. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en la interfaz de usuario.
Excepciones Notas
Tabla 3.2-29. Escenario 4.6: Historial de deshacer / rehacer (R4.6)
3.2.2.4.7. Escenario 4.7: Guardar, exportar e importar (R4.7)

Tener permiso de edicin sobre el componente. Los cambios deben ser visibles en todo el sistema. Propietario / Usuario Registrado / Colaborador. Propietario / Usuario Registrado / Colaborador. El usuario solicita la operacin. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en todo el sistema.
Excepciones Notas
Tabla 3.2-30. Escenario 4.7: Guardar, exportar e importar (R4.7)
99
3.2.2.5. Caso de Uso 5: Gestionar Cuentas de Usuario (R5)

Definicin
Como cualquier otro sistema en el que intervengan usuarios es necesario disponer de mecanismo para crear, borrar y actualizar sus datos. Propietario / Usuario Registrado. Media. Media. R5.1, R5.2, R5.3, R5.4. Slo el propietario de la cuenta puede borrar o modificar los datos de la misma.
Tabla 3.2-31. Caso de Uso 5: Gestionar Cuentas de Usuario (R5)
3.2.2.5.1. Escenario 5.1: Alta, baja y modificacin de usuarios (R5.1)

El usuario debe estar registrado en el sistema. Los cambios deben actualizarse en la interfaz de usuario. Propietario. Propietario. El usuario solicita la operacin. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en la interfaz de usuario.
Excepciones Notas
El usuario no tiene permisos suficientes. Slo el propietario de la cuenta puede borrar o modificar los datos de la misma.
Tabla 3.2-32. Escenario 5.1: Alta, baja y modificacin de usuarios (R5.1)
100
3.2.2.5.2. Escenario 5.2: Validar usuario (R5.2)

Los datos de identificacin del usuario deben ser vlidos. El usuario puede acceder a sus contenidos privados. Propietario. Propietario. El usuario introduce sus datos de identificacin. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en la interfaz de usuario.
Excepciones Notas
Los datos de identificacin son incorrectos. Un usuario puede validarse tantas veces como sea necesario.
Tabla 3.2-33. Escenario 5.2: Validar usuario (R5.2)
3.2.2.5.3. Escenario 5.3: Buscar usuarios (R5.3)

Excepciones
No se encuentra ningn usuario que cumpla los criterios de bsqueda establecidos. Los propietarios definen la visibilidad de sus datos para el resto de usuarios, es decir, pueden ocultarlos.
Tabla 3.2-34. Escenario 5.3: Buscar usuarios (R5.3)
Notas
101
3.2.2.5.4. Escenario 5.4: Consultar estadsticas y puntuaciones (R5.4)

El usuario debe estar registrado en el sistema. Los datos deben mostrarse en la interfaz de usuario. Propietario / Usuario Registrado. Propietario / Usuario Registrado. El usuario selecciona la opcin a visualizar. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se muestran los datos en la interfaz de usuario.
Excepciones Notas
El usuario no tiene permisos suficientes. Los propietarios definen la visibilidad de sus datos para el resto de usuarios, es decir, pueden ocultarlos.
Tabla 3.2-35. Escenario 5.4: Consultar estadsticas y puntuaciones (R5.4)
102
3.3. Anlisis de Clases

A partir del estudio de los casos de uso se extrae una lista de objetos candidatos a ser clases y se hace una primera aproximacin del modelo de clases que ser refinada posteriormente durante el diseo. Las responsabilidades de una clase definen la funcionalidad de esa clase, y estn basadas en el estudio de los papeles que desempean sus objetos dentro de los distintos casos de uso [Mtrica].
103
3.3.1. Identificacin de Clases Asociadas a Casos de Uso

3.3.1.1. Anlisis del Caso de Uso 1: Gestionar Diagramas (R1)
Nombre de la clase / recurso Modelo Tecnologa
DiagramManager Diagram
Java Java JSP + JavaScript XML / Struts Java / Struts Java / Struts Java / Struts Java / Struts Java / Struts Java / Struts
Vista
DiagramManager DiagramDynaActionForm (R1.1)
Controlador
AddDiagramAction.do (R1.1) RemoveDiagramAction.do (R1.1) EditDiagramAction.do (R1.1) QueryDiagramsAction.do (R1.2) ShareDiagramAction.do (R1.3) RestoreDiagramAction.do (R1.4)
Tabla 3.3-1. Anlisis del Caso de Uso 1: Gestionar Diagramas (R1)
3.3.1.2. Anlisis del Caso de Uso 2: Disear Diagramas (R2)

DiagramManager Diagram
Java Java JSP + JavaScript Java / Struts Java / Struts Java / Struts Java / Struts Java / Struts
Vista Controlador
DiagramEditor CommitChangeAction.do (R2.x) QueryChangesAction.do (R2.x) SaveChangesAction.do (R2.7) ExportDiagramAction.do (R2.7) SendMessageAction.do (R2.8)
Tabla 3.3-2. Anlisis del Caso de Uso 2: Disear Diagramas (R2)
104
3.3.1.3. Anlisis del Caso de Uso 3: Gestionar Componentes (R3)

ComponentManager Component
Vista
ComponentManager ComponentDynaActionForm (R3.1)
Controlador
AddComponentAction.do (R3.1) RemoveComponentAction.do (R3.1) EditComponentAction.do (R3.1) QueryComponentsAction.do (R3.2) ShareComponentAction.do (R3.3) RestoreComponentAction.do (R3.4)
Tabla 3.3-3. Anlisis del Caso de Uso 3: Gestionar Componentes (R3)
3.3.1.4. Anlisis del Caso de Uso 4: Disear Componentes (R4)

ComponentManager Component
Java Java JSP + JavaScript Java / Struts Java / Struts Java / Struts Java / Struts
Vista Controlador
ComponentEditor CommitChangeAction.do (R4.x) QueryChangesAction.do (R4.x) SaveChangesAction.do (R4.7) ExportComponentAction.do (R4.7)
Tabla 3.3-4. Anlisis del Caso de Uso 4: Disear Componentes (R4)
105
3.3.1.5. Anlisis del Caso de Uso 5: Gestionar Usuarios (R5)

UserManager User
Vista
UserManager UserDynaActionForm (R2.1)
Controlador
AddUserAction.do (R5.1) RemoveUserAction.do (R5.1) EditUserAction.do (R5.1) LoginAction.do (R5.2) QueryUsersAction.do (R5.3) QueryStatisticsAction.do (R5.4)
Tabla 3.3-5. Anlisis del Caso de Uso 5: Gestionar Usuarios (R5)
106
3.3.2. Diagrama de Clases (Preliminar)
Fig. 3-2. Diagrama de Clases (Preliminar)
107
3.3.3. Descripcin de Clases (Preliminar)

La descripcin de las clases se subdivide en las tres capas del patrn MVC para facilitar su comprensin. 3.3.3.1. Modelo El Modelo es la capa responsable de mantener el estado de los objetos empleados por el usuario a lo largo de la sesin, implementa las reglas de negocio y garantiza el almacenamiento persistente de los cambios realizados.
3.3.3.1.1. Clase DiagramManager

Implementacin Caso de Uso Hereda de...
Java
Requerimiento
R1 Gestionar Diagramas
Responsabilidades Descripcin Alta, baja y modificacin de diagramas Buscar diagramas Publicar / compartir diagramas Control de versiones de diagramas Observaciones
R1.1 R1.2 R1.3 R1.4
Puede disearse mediante el patrn Facade, delegando sus responsabilidades en otras clases diseadas a tal efecto.
Tabla 3.3-6. Clase DiagramManager (Modelo)
3.3.3.1.2. Clase Diagram

Java
Requerimiento
R2 Disear Diagramas
Responsabilidades Descripcin
R2.1 R2.2 R2.3 R2.4 R2.5 R2.6 R2.7 R2.8
Definir dimensiones del rea de diseo. Aadir y eliminar componentes. Realizar conexiones entre componentes. Aplicar transformaciones bsicas (zoom, rotacin). Cortar, copiar y pegar. Historial de deshacer / rehacer. Guardar, exportar e importar. Colaborar mediante pizarra compartida y Chat.
Observaciones
Para permitir la colaboracin sncrona de varios usuarios es necesario que compartan la misma instancia de esta clase, bien a travs de un repositorio en el contexto de la aplicacin o bien mediante una base da datos.
Tabla 3.3-7. Clase Diagram (Modelo)
108
3.3.3.1.3. Clase ComponentManager

Java
Requerimiento
R3 Gestionar Componentes
Responsabilidades Descripcin Alta, baja y modificacin de componentes Buscar componentes Publicar / compartir componentes Control de versiones de componentes Observaciones
R3.1 R3.2 R3.3 R3.4
Tabla 3.3-8. Clase ComponentManager (Modelo)
3.3.3.1.4. Clase Component

Java
Requerimiento
R4 Disear Componentes
Responsabilidades Descripcin
R4.1 R4.2 R4.3 R4.4 R4.5 R4.6 R4.7
Definir dimensiones del componente. Aadir y eliminar formas bsicas. Definir zonas de interconexin (puertos). Aplicar transformaciones bsicas (zoom, rotacin). Cortar, copiar y pegar. Historial de deshacer / rehacer. Guardar, exportar e importar.
Observaciones
Tabla 3.3-9. Clase Component (Modelo)
3.3.3.1.5. Clase UserManager

Java
Requerimiento
R5 Gestionar Usuarios
Responsabilidades Descripcin Alta, baja y modificacin de usuarios Validar usuario Buscar Usuarios Consultar estadsticas y puntuaciones Observaciones
R5.1 R5.2 R5.3 R5.4
Tabla 3.3-10. Clase UserManager (Modelo)
109
3.3.3.1.6. Clase User

Java
Requerimiento
R5 Gestionar Cuentas de Usuario

Responsabilidades Descripcin Alta, baja y modificacin de usuarios Validar usuario Observaciones
R5.1 R5.2
Puede implementarse una clase auxiliar tipo JavaBean que almacene los datos bsicos del usuario.
Tabla 3.3-11. Clase User (Modelo)
110
3.3.3.2. Vista La Vista es la capa encargada recoger las peticiones del usuario, transmitirlas al Controlador y mostrar los resultados derivados de las operaciones realizadas en el Modelo a travs de los datos depositados en la sesin, el contexto o la peticin.
3.3.3.2.1. Clase DiagramManager

Implementacin Caso de Uso Responsabilidades Descripcin Alta, baja y modificacin de diagramas Buscar diagramas Publicar / compartir diagramas Control de versiones de diagramas Observaciones Hereda de...
JSP + JavaScript R1 Gestionar Diagramas

Requerimiento
R1.1 R1.2 R1.3 R1.4
El usuario solicita la pgina JSP que contiene el cdigo necesario para cargar un objeto JavaScript en el cliente, el cual delegar las operaciones al controlador mediante AJAX.
Tabla 3.3-12. Clase DiagramManager (Vista)
3.3.3.2.2. Clase DiagramEditor

Implementacin Caso de Uso Responsabilidades Descripcin Hereda de...
JSP + JavaScript R2 Disear Diagramas

Requerimiento
R2.1 R2.2 R2.3 R2.4 R2.5 R2.6 R2.7 R2.8
Observaciones
Tabla 3.3-13. Clase DiagramEditor (Vista)
111
3.3.3.2.3. Clase ComponentManager

Implementacin Caso de Uso Responsabilidades Descripcin Alta, baja y modificacin de componentes Buscar componentes Publicar / compartir componentes Control de versiones de componentes Observaciones Hereda de...
JSP + JavaScript R3 Gestionar Componentes

Requerimiento
R3.1 R3.2 R3.3 R3.4
Tabla 3.3-14. Clase ComponentManager (Vista)
3.3.3.2.4. Clase ComponentEditor

Implementacin Caso de Uso Responsabilidades Descripcin Hereda de...
JSP + JavaScript R4 Disear Componentes

Requerimiento
R4.1 R4.2 R4.3 R4.4 R4.5 R4.6 R4.7
Definir dimensiones del componente. Aadir y eliminar formas bsicas. Definir zonas de interconexin (puertos). Aplicar transformaciones bsicas (zoom, rotacin). Cortar, copiar y pegar. Historial de deshacer / rehacer. Guardar, exportar e importar.
Observaciones
Tabla 3.3-15. Clase ComponentEditor (Vista)
3.3.3.2.5. Clase UserManager

Implementacin Caso de Uso Responsabilidades Descripcin Alta, baja y modificacin de usuarios Validar usuario Buscar Usuarios Consultar estadsticas y puntuaciones Observaciones Hereda de...
JSP + JavaScript R5 Gestionar Usuarios

Requerimiento
R5.1 R5.2 R5.3 R5.4
Tabla 3.3-16. Clase UserManager (Vista)
112
3.3.3.2.6. Clase DiagramDynaActionForm

XML / Struts
Requerimiento
R1 Gestionar Diagramas
Responsabilidades Descripcin Alta y modificacin de diagramas Observaciones
DynaActionForm
R1.1
No es una clase Java: los campos del formulario se definen en el archivo de configuracin de Struts (Struts-config.xml) y las validaciones en el archivo de configuracin del framework Struts Validator (validation.xml).
Tabla 3.3-17. Clase DiagramDynaActionForm (Vista)
3.3.3.2.7. Clase ComponentDynaActionForm

XML / Struts
Requerimiento
R3 Gestionar Componentes
Responsabilidades Descripcin Alta y modificacin de componentes Observaciones
DynaActionForm
R3.1
Tabla 3.3-18. Clase ComponentDynaActionForm (Vista)
3.3.3.2.8. Clase UserDynaActionForm

XML / Struts
Requerimiento
R5 Gestionar Cuentas de Usuario

Responsabilidades Descripcin Alta y modificacin de usuarios Observaciones
DynaActionForm
R5.1
Tabla 3.3-19. Clase UserDynaActionForm (Vista)
113
3.3.3.3. Controlador Se encarga de coordinar el flujo de la aplicacin, conectando adecuadamente las peticiones de la Vista con servicios del Modelo y actualizando los resultados en la peticin, la sesin o el contexto para que los cambios sean accesibles a la Vista. Al emplear Struts como soporte para el desarrollo del servidor, esta capa queda muy simplificada ya que implementa un nico ActionServlet que se encarga de dirigir automticamente el flujo de la aplicacin a travs de la configuracin definida en el archivo struts-config.xml y mediante la implementacin de clases que deriven de la clase Action. Estas clases derivadas nicamente necesitan implementar el mtodo execute, donde se definirn las llamadas a las clases del Modelo que se encargarn de realizar las operaciones de la lgica de negocio y mantener el estado.
114
3.4. Definicin de Interfaces de Usuario
Fig. 3-3. Estructura General de la Interfaz de Usuario
115
3.4.1. Especificacin de Principios Generales

A continuacin se recogen los principios generales a tener en cuenta en la definicin de las interfaces de usuario: Enfoque a la libertad de accin de los usuarios (RNF 1.1). La interfaz de usuario debe ser accesible y usable (RNF 1.5). Emplear el patrn MVC (RNF 2.1). Emplear tecnologas AJAX en el desarrollo del cliente (RNF 2.2). Dar soporte directo a la internacionalizacin de la interfaz (RNF 2.3). Dar soporte a los navegadores Web ms empleados (RNF 2.4). Evitar la necesidad de instalar plugins en los navegadores (RNF 2.5). Los elementos deben distribuirse mediante layouts. Los mensajes de error se mostrarn en una consola o un dilogo modal. Todos los elementos deben mostrar informacin contextual (tooltips). Dar soporte a la interaccin por teclado para usuarios con limitaciones.
116
3.4.2. Especificacin de Formatos Individuales

Una vez definidos los principios generales se procede a la especificacin del formato de cada pantalla de la aplicacin, partiendo del estudio de los casos de uso identificados en este mismo captulo. 3.4.2.1. Interfaz de Usuario 1: Gestionar Diagramas (R1)
Fig. 3-4. Interfaz de Usuario 1: Gestionar Diagramas (R1)
3.4.2.2. Interfaz de Usuario 2: Disear Diagramas (R2)
Fig. 3-5. Interfaz de Usuario 2: Disear Diagramas (R2)
117
3.4.2.3. Interfaz de Usuario 3: Gestionar Componentes (R3)
Fig. 3-6. Interfaz de Usuario 3: Gestionar Componentes (R3)
3.4.2.4. Interfaz de Usuario 4: Disear Componentes (R4)
Fig. 3-7. Interfaz de Usuario 4: Disear Componentes (R4)
118
3.4.2.5. Interfaz de Usuario 5: Gestionar Cuentas de Usuario (R5)
Fig. 3-8. Interfaz de Usuario 5: Gestionar Cuentas de Usuario (R5)
119
3.4.3. Especificacin del Comportamiento Dinmico

Inicialmente el usuario que acceda al sistema debe registrarse o crear una nueva cuenta que lo registrar automticamente. El acceso a las diferentes interfaces de usuario principales se realiza a travs del men, mientras que las funciones de segundo nivel son accedidas desde dichas interfaces.
Fig. 3-9. Modelo de Navegacin de la Interfaz de Usuario
120
3.5. Plan de Aceptacin

El plan de aceptacin recoge las fases de puesta en marcha u aceptacin del prototipo final, de manera que se pueda seguir una planificacin estructura del diseo y construccin del mismo. Una vez pasadas todas pruebas recogidas en el plan se dar el prototipo por terminado. Se contemplarn pruebas tanto individuales, como de integracin y de usabilidad a diferentes escalas y en funcin de la fase de desarrollo en la que se encuentre el proyecto y los subsistemas finalizados e integrados.
121
3.5.1. Fase 1: Construccin de Prototipos Bsicos

En esta primera fase se estudiarn las diferentes alternativas de viabilidad para el desarrollo de los interfaces de usuario dedicados al diseo de los diagramas y componentes. Principalmente se desarrollarn funcionalidades estticas totalmente independientes del servidor y que verifiquen hasta que punto es viable el desarrollo de un entorno de este tipo sobre un navegador Web. Prototipos a desarrollar: Prototipo 1: Interconexin de componentes. Es necesario estudiar las diferentes posibilidades a la hora de construir objetos grficos en un navegador que permitan un comportamiento dinmico, con respuestas a eventos, e incluso establecer conexiones visibles entre ellos. Prototipo 2: Formato de la interfaz de usuario. Este prototipo servir para definir las posibilidades de diseo de la interfaz de usuario y su grado de proximidad en cuanto a componentes reutilizables disponibles para crear el entorno de diseo de los diagramas. Prototipo 3: Integracin de capas del sistema. Finalmente se desarrollar un prototipo que valore el uso e integracin de todas las capas del sistema, incluyendo el soporte de almacenamiento persistente y la colaboracin sncrona de usuarios.
122
3.5.2. Fase 2: Diseo Detallado del Sistema

Una vez aprobados los prototipos de la fase anterior se proceder al diseo exhaustivo del prototipo final a desarrollar, que incluir al menos los subsistemas de gestin de usuario y diagramas, pero principalmente se buscar obtener un entorno de diseo de diagramas lo ms completo y usable posible, siendo este el apartado prioritario del proyecto. Se deberan contemplar al menos las siguientes capas: Modelo Responsable de mantener el estado de los objetos empleados por el usuario a lo largo de la sesin, implementa las reglas de negocio y garantiza el almacenamiento persistente de los cambios realizados. Vista Encargada recoger las peticiones del usuario, transmitirlas al controlador y mostrar los resultados derivados de las operaciones realizadas en el modelo. Controlador Coordina el flujo de la aplicacin, conectando adecuadamente las peticiones de la vista con servicios del modelo y actualizando los resultados en la peticin, la sesin o el contexto. Infraestructura Establece un lenguaje comn entre las capas mediante la definicin de clases de tipo bean, que facilite el intercambio de informacin.
123
3.5.3. Fase 3: Construccin del Prototipo Final

Tras la aprobacin del diseo detallado se proceder a la implementacin del prototipo final, subdividindose el trabajo en las capas definidas durante el diseo, que faciliten la integracin y ampliacin de las responsabilidades. El sistema deber cubrir al menos los siguientes requerimientos globales: R1 Gestionar Diagramas Este subsistema deber proporcionar la funcionalidad necesaria para crear, eliminar, compartir y acceder a los diagramas. R2 Disear Diagramas Se trata de desarrollar un entorno grfico de dibujo dnde se permita a los usuarios trabajar de manera sncrona sobre un mismo diagrama y que los cambios se actualicen en tiempo real en todos los clientes. R5 Gestionar Cuentas de Usuario Como cualquier otro sistema en el que intervengan usuarios es necesario disponer de mecanismo para crear, borrar y actualizar sus datos.
124
3.6. Prototipos
Este apartado se dedica a los prototipos desarrollados durante las fases de anlisis y diseo del sistema, el enfoque elegido es de prototipado funcional, reutilizando los prototipos desarrollados para la construccin de los siguientes. El objetivo de estos prototipos es estudiar la viabilidad del desarrollo del cliente mediante tecnologas AJAX con el soporte de Dojo Toolkit [Dojo] y valorar las posibilidades de integracin de los diferentes paquetes desarrollados.
125
3.6.1. Prototipo 1: Interconexin de Componentes

Este prototipo permite definir objetos compuestos por varios componentes grficos mediante SVG o VML dependiendo del navegador empleado. Gracias a Dojo Toolkit es posible realizar un despliegue independiente del navegador sin necesidad de preocuparse por realizar ninguna comprobacin ya que provee una capa de abstraccin a tal efecto que libera al programador de dichas tareas. Los objetos pueden moverse libremente por el rea de trabajo y poseen unas zonas predefinidas mediante las cuales se pueden realizar conexiones con otras zonas especficas del resto de objetos del diagrama. Se trata de un prototipo extremadamente bsico, pero que aporta una gran luz en la viabilidad de la realizacin del cliente mediante AJAX, ya que quedan patentes las enormes posibilidades que alberga y adems permitir implementar un entorno visual agradable y altamente interactivo.
Fig. 3-10. Prototipo 1: Interconexin de Componentes
Fecha Requerimientos funcionales Requerimientos no funcionales
17/04/2007 2.3, 2.4. 1.6, 2.2, 2.4, 2.5.
Tabla 3.6-1. Prototipo 1: Interconexin de Componentes
126
3.6.2. Prototipo 2: Formato de la Interfaz de Usuario

Esta implementacin permite desplazar libremente los componentes por el rea de diseo, representado por una rejilla en la imagen superior. Tambin se ha diseado una estructura bsica para la interfaz de diseo de los diagramas que se redistribuye automticamente al redimensionar la ventana del navegador. Funciona correctamente en Internet Explorer 6, Mozilla Firefox 2, Opera 9 y Safari 3.
Fig. 3-11. Prototipo 2: Formato de la Interfaz de Usuario
29/05/2007 2,2, 2.4. 1.5, 1.6, 2.2, 2.4, 2.5.
Tabla 3.6-2. Prototipo 2: Formato de la Interfaz de Usuario
127
3.6.3. Prototipo 3: Integracin de capas del Sistema.

Este ltimo prototipo integra de forma bsica todas las capas del sistema, incluyendo el soporte de almacenamiento persistente con Oracle 10g y la colaboracin sncrona de usuarios. Permite crear cuentas de usuario y diagramas, aunque el resto de informacin debe introducirse manualmente en la base de datos. Tampoco tiene control de accesos por lo que cualquier usuario puede acceder libremente a cualquier diagrama. El sistema de control de cambios de los diagramas es completamente funcional y permite compartir los cambios sobre ellos con otros usuarios en tiempo real, es decir, cualquier cambio realizado se actualiza automticamente en el resto de usuarios conectados al mismo diagrama. Tambin se disea el aspecto o formato general para el gestor de contenidos a desarrollar como soporte.
Fig. 3-12. Prototipo 3: Integracin de capas del Sistema
12/07/2007 1.1, 2.2, 2.4, 2.7, 2.8, 5.1 1.2, 1.5, 1.6, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6
Tabla 3.6-3. Integracin de capas del Sistema
128
129
CAPTULO 4: DISEO
En este captulo se describen brevemente los patrones de diseo empleados, se subdivide el sistema en paquetes o subsistemas y se disean los diagramas de clases. Una vez completados estos apartados se proponen los diagramas de secuencia y de estados ms relevantes, el diagrama Entidad-Relacin para la base de datos a desplegar, la descripcin detallada de las clases y el diagrama de componentes.
130
4.1. Patrones de Diseo

Para simplificar el diseo del sistema se ha optado por el empleo de diversos patrones, como MVC, Facade, DAO y Factory. El uso de patrones se recomienda nicamente en escenarios muy concretos, en los que se conozca de antemano los objetivos que se desean conseguir. Un patrn de diseo es una solucin a un problema de diseo que ha demostrado resultar efectiva y que suele ser reutilizable. Los objetivos principales que tienen son: Proporcionar catlogos de elementos reutilizables. Evitar la reiteracin en la bsqueda de soluciones a problemas. Formalizar un vocabulario comn entre diseadores. Estandarizar el modo en que se realiza el diseo. Facilitar el aprendizaje de las nuevas generaciones de diseadores. Asimismo, no pretenden: Imponer ciertas alternativas de diseo frente a otras. Eliminar la creatividad inherente al proceso de diseo. No es obligatorio utilizar los patrones siempre, solo en el caso de tener el mismo problema o similar que soluciona el patrn, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. Abusar o forzar el uso de los patrones puede ser un error [Wikipedia].
131
4.1.1. Patrn Modelo-Vista-Controlador (MVC)

Este patrn est destinado a sistemas complejos en los que las responsabilidades quedan separadas en capas bien diferenciadas. Puede emplearse tanto en aplicaciones de escritorio como en aplicaciones Web. La descripcin de las capas que se expone a continuacin se basa en la segunda opcin. 4.1.1.1. Modelo El modelo es la capa responsable de mantener el estado de los objetos empleados por el usuario a lo largo de la sesin, implementa las reglas de negocio y garantiza el almacenamiento persistente de los cambios realizados. 4.1.1.2. Vista La vista es la capa encargada recoger las peticiones del usuario, transmitirlas al controlador y mostrar los resultados derivados de las operaciones realizadas en el modelo a travs de los datos depositados en la sesin, el contexto o la peticin. 4.1.1.3. Controlador Se encarga de coordinar el flujo de la aplicacin, conectando adecuadamente las peticiones de la vista con servicios del modelo y actualizando los resultados en la peticin, la sesin o el contexto para que los cambios sean accesibles a la vista. Al emplear Struts como soporte para el desarrollo del servidor, esta capa queda muy simplificada ya que implementa un nico ActionServlet que se encarga de dirigir automticamente el flujo de la aplicacin a travs de la configuracin definida en el archivo struts-config.xml y mediante la implementacin de clases que deriven de la clase Action. Estas clases derivadas nicamente necesitan implementar el mtodo execute, donde se definirn las llamadas a las clases del modelo que se encargarn de realizar las operaciones de la lgica de negocio y mantener el estado.
132
4.1.2. Otros patrones empleados

En este apartado se agrupan el resto de patrones empleados, que suelen tener una visin ms localizada a ciertas responsabilidades. 4.1.2.1. Patrn Facade El patrn Facade ser empleado en el diseo de las interfaces entre las diferentes capas del patrn MVC, de tal modo que cualquier peticin de la vista ser recogida por el ActionServlet y la redirigir a la clase Action adecuada, que solicitar el servicio al modelo a travs de la clase ModelFacade. La clase ModelFacade es la encargada de redirigir las peticiones hacia el EntityManager adecuado, bien el UserManager para los usuarios, o bien el DiagramManager para los diagramas. Dichas clases se encargarn de realizar todas las acciones necesarias de la lgica de negocio antes y/o despus de acceder a la capa de persistencia, como puede ser la comprobacin de privilegios o el procesamiento y serializacin de datos. La comunicacin entre el modelo y la capa de persistencia se realiza a travs de la clase PersistenceFacade. 4.1.2.2. Patrn Data Access Objects (DAO) Este patrn permite generalizar el soporte empleado para la capa de persistencia del modelo, para lo cual se crean tantas interfaces como tipos de entidad deseen gestionarse, definiendo las operaciones que pueden realizarse sobre ellas. Adems se crear una clase abstracta DAOFactory que permite crear diversas instancias de clases derivadas que incluyan soporte para algn tipo concreto de base de datos, en este caso nicamente se derivar la clase OracleDAOFactory. Finalmente se derivan clases de todas las interfaces diseadas y se implementan las operaciones definidas en funcin del tipo de almacenamiento elegido. 4.1.2.3. Patrn Factory El nico cometido de este patrn es apoyar el diseo del anterior mediante factoras que permitan una ampliacin ms sencilla de futuras versiones del sistema que precisen de otro tipo de base de datos de soporte.
133
4.2. Diagramas de Clases

En este apartado se presenta el modelo de subsistemas para el prototipo final a desarrollar, que no incluye los casos de uso relacionados con los componentes ya que se consideran secundarios dentro del proyecto y se busca obtener una versin completamente funcional antes de disear el sistema completo. Adems el diseo de estos casos de uso est estrechamente ligado al diseo de los casos de uso relacionados con los diagramas, por lo que una vez desarrollados y probados servirn de gua para el futuro diseo de los casos de uso no recogidos en esta versin. La arquitectura del sistema se basa en el patrn MVC, por lo que las responsabilidades quedan factorizadas en capas, mejorando la escalabilidad y el mantenimiento posterior. El subsistema controller o controlador se encarga de coordinar el flujo de la aplicacin, conectando adecuadamente las peticiones del subsistema view o vista con servicios del model o modelo, actualizando los resultados en la peticin, la sesin o el contexto para que los cambios sean accesibles a la vista empleando las clases del paquete common para transferir informacin entre las capas. Al emplear Struts como soporte para el desarrollo del servidor, las capas del controlador y la vista quedan muy simplificadas, ya que implementa un nico Servlet siguiendo el patrn Singleton que se encarga de dirigir automticamente el flujo de la aplicacin a travs de la configuracin definida en el archivo struts-config.xml y mediante la implementacin de clases que extiendan el mtodo execute de la clase Action. Tambin permite definir formularios dinmicamente en el archivo de configuracin y especificar las restricciones de los campos mediante el archivo validation.xml, economizando el tiempo de desarrollo. La vista puede factorizarse mediante layouts en el archivo de configuracin tiles-defs.xml, favoreciendo la reutilizacin de JSPs, estilos y formato. Tambin permite definir todos los mensajes de la vista en un archivo .properties para su posterior internacionalizacin. Las clases derivadas de la clase Action realizarn llamadas a mtodos de la clase ModelFacade, que implementa el patrn Facade para independizar el controlador del subsistema model, que se encargar de realizar las operaciones de la lgica de negocio y mantener el estado mediante las capas de persistencia. El subsistema model.graphml se encarga de procesar los archivos GraphML, tanto para leer como para escribir, y expone un Facade al modelo mediante la clase GraphMLFile. Por otro lado, el subsistema model.persistence internamente sigue el patrn DAO con soporte para Oracle 10g en esta versin y posibilidad de migracin en futuras versiones. El modelo se comunica con este subsistema mediante otro Facade, denominado PersistenceFacade.
134
4.2.1. Diagrama de Paquetes
Fig. 4-1. Diagrama de Paquetes
135
4.2.2. Paquete model
Fig. 4-2. Paquete model
136
4.2.3. Paquete model.persistence
Fig. 4-3. Paquete model.persistence
137
4.2.4. Paquete model.graphml
Fig. 4-4. Paquete model.graphml
138
4.2.5. Paquete common
Fig. 4-5. Paquete common
139
4.2.6. Paquete controller
Fig. 4-6. Paquete controller
140
4.2.7. Paquete view
Fig. 4-7. Paquete view
141
4.3. Diagramas de Secuencia

Al emplearse una arquitectura basada en el patrn MVC la secuencia de acciones a seguir es muy similar en todas las operaciones, salvo los detalles especficos que se recogern en la capa del modelo, tanto a nivel lgico, como a nivel de persistencia. En este apartado se detallan los tres tipos de operacin ms empleados en el sistema a desarrollar. Primero se disea la interaccin entre la vista y en controlador, es decir la interfaz con el usuario. La siguiente secuencia se corresponde con la comunicacin y transferencia de datos entre el modelo y la persistencia, y finalmente el anlisis y procesamiento de un archivo GraphML, empleados en la exportacin e importacin de diagramas.
142
4.3.1. Interaccin Vista Controlador
Fig. 4-8. Interaccin Vista Controlador
La interaccin entre la vista y el controlador se puede generalizar perfectamente con el diagrama de secuencia anterior. Si la accin solicitada corresponde a la zona privada, el LoginFilter captura la peticin y comprueba que el usuario est registrado mediante un acceso a la sesin del mismo. En el caso de una peticin por formulario, el framework Struts Validator comprueba los campos del formulario y, en caso de encontrar alguno incorrecto, redirecciona de forma automtica a la pgina de la solicitud con los errores correspondientes. Los Action implementados crearn los Beans adecuados del subsistema common para transferir y recibir informacin del modelo, mediante el Facade del mismo, el resto de operaciones se describen ms adelante. Finalmente el framework Struts Tiles genera la respuesta HTTP mediante los JSPs, los archivos de mensajes internacionalizados y los Beans disponibles.
143
4.3.2. Interaccin Modelo Persistencia
Fig. 4-9. Interaccin Modelo Persistencia
El modelo recoge todas las peticiones del controlador desde la clase ModelFacade, encargada de redirigirlas hacia el EntityManager adecuado, bien el UserManager para los usuarios, o bien el DiagramManager para los diagramas. Dichas clases se encargarn de realizar todas las acciones necesarias de la lgica de negocio antes y/o despus de acceder a la capa de persistencia, como puede ser la comprobacin de privilegios o el procesamiento y serializacin de datos. La comunicacin entre el modelo y la capa de persistencia se realiza a travs de la clase PersistenceFacade que delega las acciones en las clases OracleEntityDAO, implementadas a partir de las interfaces genricas EntityDAO, es decir, habr un interfaz por cada tipo de entidad y una clase por cada tipo de base de datos a la que se desee dar soporte, en esta versin slo usuarios y diagramas como entidades y Oracle 10g como base de datos.
144
4.3.3. Procesar archivo GraphML
Fig. 4-10. Procesar archivo GraphML
Los diagramas pueden cargarse desde la base de datos mediante la secuencia de operaciones descrita en el apartado anterior o pueden ser importados desde un archivo XML que use el vocabulario GraphML. Los archivos GraphML permiten exportar e importar los diagramas y se emplearn para recoger los diagramas al crear nuevas versiones, es decir, mientras una versin est en edicin es necesario cargar su archivo correspondiente y actualizarlo en el cliente con los cambios almacenados en la base de datos.
145
4.4. Diagrama Entidad-Relacin

Para almacenar los diagramas, usuarios y privilegios de la aplicacin se ha optado por emplear Oracle 10g como base de datos. A continuacin se muestra el diagrama Entidad-Relacin diseado a tal efecto:
Fig. 4-11. Diagrama Entidad-Relacin
146
4.5. Diccionario de Datos

Este apartado resume todas las clases que intervienen en el funcionamiento bsico del sistema con los mtodos y atributos a desarrollar. La estructura de este apartado se subdivide en paquetes para facilitar su entendimiento, de tal manera que los paquetes ms representativos aparecen con un ttulo de nivel 3, reflejado en la tabla de contenidos de este documento y los paquetes internos menos importantes quedan contenidos dentro de estos, junto con el resto de clases e interfaces.
147

4.5.1.1. Clase ModelFacade
Nombre Modo Requerimientos Descripcin
ModelFacade
public Interfaz entre las capas del modelo y el controlador.
R1, R2, R5 Proveer al controlador de todos los servicios necesarios. RNF 1 Delegar las peticiones del controlador en la clase adecuada del modelo.
Acceso Retorno Mtodos Nombre Modo Parmetros
public public public public public public public public public public public public public public
void void Collection UserBean boolean void void void void Collection DiagramBean Collection DiagramBean String
addUser exit getAllUsers getUser login addDiagram changeDiagramPrivilege commitDiagramChange destroyDiagram getAllDiagrams getDiagram getDiagramPrivileges loadDiagram queryDiagramChanges
Observaciones
virtual virtual virtual virtual virtual virtual virtual virtual virtual virtual virtual virtual virtual virtual
user : UserBean userId : String void userId : String user : TinyUserBean bean : DiagramBean actorId : String privilege : DiagramPrivilegeBean change : DiagramChangeBean actorId : String diagramId : String actorId : String actorId : String diagramId : String actorId : String diagramId : String actorId : String diagramId : String lastChange : DiagramChangeBean
Esta clase no realiza ningn procesamiento de los datos recibidos o devueltos.

Tabla 4.5-1. Clase ModelFacade
148
4.5.1.2. Clase DiagramManager

Nombre Modo Descripcin
DiagramManager R1.1 R1.2 R1.3 R1.4 R2.1 R2.2 R2.3 R2.4 R2.5 R2.6 R2.7 R2.8 RNF 2.9
Acceso
Se encarga de realizar las acciones de la lgica de public negocio correspondiente a los diagramas.
Requerimientos
Alta, baja y modificacin de diagramas Buscar diagramas Publicar / compartir diagramas Control de versiones de diagramas Definir dimensiones del rea de diseo. Aadir y eliminar componentes. Realizar conexiones entre componentes. Aplicar transformaciones bsicas (zoom, rotacin). Cortar, copiar y pegar. Historial de deshacer / rehacer. Guardar, exportar e importar. Colaborar mediante pizarra compartida y Chat. Disear un sistema de control de accesos y seguridad adecuado.
Retorno Mtodos Nombre Modo Parmetros
public public public public public public public public public
void void void void Collection DiagramBean Collection DiagramBean String
addDiagram changeDiagramPrivilege commitDiagramChange destroyDiagram getAllDiagrams getDiagram getDiagramPrivileges loadDiagram queryDiagramChanges

Observaciones
virtual bean : DiagramBean actorId : String virtual privilege : DiagramPrivilegeBean change : virtual DiagramChangeBean actorId : String virtual diagramId : String virtual actorId : String actorId : String virtual diagramId : String actorId : String virtual diagramId : String actorId : String virtual diagramId : String lastChange : virtual DiagramChangeBean
Esta clase realiza las operaciones de la lgica de negocio relativa a los diagramas, delegando las responsabilidades de mantenimiento del estado a la capa de persistencia. Las acciones restringidas por permisos requieren que se validen los permisos del usuario antes de realizar dichas operaciones.
Tabla 4.5-2. Clase DiagramManager
149
4.5.1.3. Clase UserManager

UserManager R5.1 R5.2 R5.3 R5.4 RNF 2.9

Acceso
Se encarga de realizar las acciones de la lgica de public negocio correspondiente a los usuarios.
Requerimientos
Alta, baja y modificacin de usuarios Validar usuario Buscar usuarios Consultar datos de usuarios Disear un sistema de control de accesos y seguridad adecuado.
public public public public public
void void Collection UserBean boolean
addUser exit getAllUsers getUser login

Observaciones
virtual virtual virtual virtual virtual
user : UserBean userId : String void userId : String user : TinyUserBean
Esta clase realiza las operaciones de la lgica de negocio relativa a los usuarios, delegando las responsabilidades de mantenimiento del estado a la capa de persistencia.
Tabla 4.5-3. Clase UserManager
150

4.5.2.1. Clase PersistenceFacade
Nombre Modo Requerimientos Descripcin
PersistenceFacade
public Interfaz entre las capas de la persistencia y el modelo.
R1, R2, R5 Proveer al modelo de todos los servicios de persistencia necesarios. RNF 1 Delegar las peticiones del modelo en el DAO adecuado.
private public public public public public public public public public public public public public public
DAOFactory void void Collection UserBean boolean void void void void Collection DiagramBean Collection DiagramBean String
getDAOFactory addUser exit getAllUsers getUser login addDiagram changeDiagramPrivilege commitDiagramChange destroyDiagram getAllDiagrams getDiagram getDiagramPrivileges loadDiagram queryDiagramChanges
Observaciones
virtual virtual virtual virtual virtual virtual virtual virtual virtual virtual virtual virtual virtual virtual virtual
void user : UserBean userId : String void userId : String user : TinyUserBean bean : DiagramBean actorId : String privilege : DiagramPrivilegeBean change : DiagramChangeBean actorId : String diagramId : String actorId : String actorId : String diagramId : String actorId : String diagramId : String actorId : String diagramId : String lastChange : DiagramChangeBean
Esta clase no realiza ningn procesamiento de los datos recibidos o devueltos.

Tabla 4.5-4. Clase PersistenceFacade
151
4.5.2.2. Clase DAOFactory

DAOFactory
Se encarga de crear el DAOFactory adecuado a la base abstract de datos utilizada.

Requerimientos
Crear el DAOFactory adecuado. Definir los tipos DAO que pueden ser creados.
Atributos Acceso Tipo / Clase Nombre Static
public
Acceso
byte
Retorno
ORACLE
Mtodos Nombre Modo Parmetros
SI virtual type : byte abstract void abstract void
public public public
DAOFactory UserDAO DiagramDAO
getDAOFactory getUserDAO getDiagramDAO

Observaciones
Construye el DAOFactory adecuado en funcin del tipo de base de datos y define los tipos de DAOs que se pueden crear.
Tabla 4.5-5. Clase DAOFactory
152
4.5.2.3. Interfaz DiagramDAO

DiagramDAO R1.1 R1.2 R1.3 R1.4 R2.1 R2.2 R2.3 R2.4 R2.5 R2.6 R2.7 R2.8
Acceso
Define las operaciones que se pueden realizar sobre la public entidad Diagram de la base de datos.
Requerimientos
Alta, baja y modificacin de diagramas Buscar diagramas Publicar / compartir diagramas Control de versiones de diagramas Definir dimensiones del rea de diseo. Aadir y eliminar componentes. Realizar conexiones entre componentes. Aplicar transformaciones bsicas (zoom, rotacin). Cortar, copiar y pegar. Historial de deshacer / rehacer. Guardar, exportar e importar. Colaborar mediante pizarra compartida y Chat.

Observaciones
abstract bean : DiagramBean actorId : String abstract privilege : DiagramPrivilegeBean change : abstract DiagramChangeBean actorId : String abstract diagramId : String abstract actorId : String actorId : String abstract diagramId : String actorId : String abstract diagramId : String actorId : String abstract diagramId : String lastChange : abstract DiagramChangeBean
Tabla 4.5-6. Interfaz DiagramDAO
153
4.5.2.4. Interfaz UserDAO

UserDAO R5.1 R5.2 R5.3 R5.4

Acceso
Define las operaciones que se pueden realizar sobre la public entidad User de la base de datos.
Requerimientos
Alta, baja y modificacin de usuarios Validar usuario Buscar usuarios Consultar datos de usuarios

Observaciones
abstract abstract abstract abstract abstract
Tabla 4.5-7. Interfaz UserDAO
154
4.5.2.5. Paquete model.persistence.oracle
4.5.2.5.1. Clase OracleDAOFactory

OracleDAOFactory Extiende: DAOFactory
Permite crear una conexin JDBC con Oracle 10g y public solicitar los DAO que se definen en DAOFactory.
Requerimientos
Crear y gestionar las conexiones con Oracle. Crear los tipos DAO definidos en DAOFactory. Liberar los recursos empleados al finalizar el acceso a Oracle.
public
Acceso
byte
Retorno
ORACLE
SI void stat : Statement static rs : ResultSet abstract void abstract void static
public public public public
Connection void
createConnection freeResources
UserDAO getUserDAO DiagramDAO getDiagramDAO

Observaciones
Construye el DAOFactory adecuado en funcin del tipo de base de datos y define los tipos de DAOs que se pueden crear.
Tabla 4.5-8. Clase OracleDAOFactory
155
4.5.2.5.2. Clase OracleDiagramDAO

OracleDiagramDAO Extiende: DiagramDAO R1.1 R1.2 R1.3 R1.4 R2.1 R2.2 R2.3 R2.4 R2.5 R2.6 R2.7 R2.8
Acceso
Implementa las operaciones que se pueden realizar public sobre la entidad Diagram de la base de datos.
Requerimientos
Alta, baja y modificacin de diagramas Buscar diagramas Publicar / compartir diagramas Control de versiones de diagramas Definir dimensiones del rea de diseo. Aadir y eliminar componentes. Realizar conexiones entre componentes. Aplicar transformaciones bsicas (zoom, rotacin). Cortar, copiar y pegar. Historial de deshacer / rehacer. Guardar, exportar e importar. Colaborar mediante pizarra compartida y Chat.

Observaciones
virtual bean : DiagramBean actorId : String virtual privilege : DiagramPrivilegeBean change : virtual DiagramChangeBean actorId : String virtual diagramId : String virtual actorId : String actorId : String virtual diagramId : String actorId : String virtual diagramId : String actorId : String virtual diagramId : String lastChange : virtual DiagramChangeBean
Tabla 4.5-9. Clase OracleDiagramDAO
156
4.5.2.5.3. Clase OracleUserDAO

OracleUserDAO Extiende: UserDAO R5.1 R5.2 R5.3 R5.4

Acceso
Implementa las operaciones que se pueden realizar public sobre la entidad User de la base de datos.
Requerimientos
Alta, baja y modificacin de usuarios Validar usuario Buscar usuarios Consultar datos de usuarios

Observaciones
virtual virtual virtual virtual virtual
Tabla 4.5-10. Clase OracleUserDAO
157

4.5.3.1. Clase GraphMLFile
GraphMLFile
public
Procesa los ficheros GraphML del sistema.

Requerimientos
R2.7 Guardar, exportar e importar. RNF 2.6 Definir el modelo de datos mediante tecnologas XML.
Atributos Acceso Tipo / Clase Nombre Mtodos Nombre Static
private
Acceso
GraphMLDefaultHandler defaultHandler
Retorno Modo
NO
Parmetros
GraphMLErrorHandler Graph Graph void void
getErrorHandler load load save save

Observaciones
virtual void virtual filename : String virtual stream : Reader graph : Graph virtual filename : String graph : Graph virtual stream : Writer
Esta clase redefine la clase GraphMLFile de la librera JUNG para adaptarla a las necesidades del sistema.
Tabla 4.5-11. Clase GraphMLFile
158
4.5.3.2. Clase GraphMLDefaultHandler

Gestiona los eventos producidos por el SAXParser GraphMLDefaultHandler public empleado para analizar el documento XML.
Requerimientos
Generar un objeto de la clase Graph a partir de un documento GraphML

private private private private private private

Acceso
Graph Stack HashMap GraphMLErrorHandler StringLabeller boolean

Retorno
graph elementStack keyMap errorHandler stringLabeller default_directed

NO NO NO NO NO NO nsUri : String lName : String qName : String attrs : Attributes nsUri : String lName : String qName : String attrs : Attributes chars : char[] start : int length : int e : SAXParseException e : SAXParseException e : SAXParseException void void void attributeMap : Map attributeMap : Map attributeMap : Map attributeMap : Map qName : String attributeMap : Map attrs : Attributes textData : String udc : UserDataContainer attributeMap : Map elem : GraphMlElement
public
void
startElement
virtual
public
void
endElement
virtual
public public public public public protected protected protected protected protected protected private private private private
void void void void GraphMlErrorHandler Graph StringLabeller void void void void Map void void void
characters warning error fatalError getErrorHandler getGraph getLabeller createGraph createVertex createEdge createKey getAttributeMap createTextData setUserData
Observaciones
virtual virtual virtual virtual virtual virtual virtual virtual virtual virtual virtual virtual virtual virtual
protected void
createNestedElem. virtual
addNestedElemen. virtual
Esta clase redefine la clase GraphMLDefaultHandler de la librera JUNG para adaptarla a las necesidades del sistema.
Tabla 4.5-12. Clase GraphMLDefaultHandler
159
4.5.3.3. Clase GraphMLErrorHandler

GraphMLErrorHandler
Captura las excepciones lanzadas por el SAXParser public empleado para analizar el documento XML.
Requerimientos Atributos
Recoger los errores y advertencias generados al analizar documentos GraphML.

Acceso Tipo / Clase Nombre Static
private private private

Acceso
long long Vector

Retorno
errorCount warnCount messages

NO NO NO virtual virtual virtual virtual virtual virtual virtual e : SAXParseException e : SAXParseException e : SAXParseException void void void e : SAXParseException
public public public public public public private
void void void long long Vector String
warning error fatalError getWarningCount getErrorCount getMessages formatLineAndCol

Observaciones
Esta clase implementa los mtodos de gestin de excepciones SAXParseException y almacena los mensajes internamente para su posterior consulta. Se emplea internamente en la clase GraphMLDefaultHandler, descrita en el apartado anterior.
Tabla 4.5-13. Clase GraphMLErrorHandler
160
4.5.3.4. Clase GraphMLSerializer

GraphMLSerializer
Serializa el contenido de un objeto de la clase Graph public en un documento GraphML

Generar un documento GraphML a partir de un objeto de la clase Graph.

Acceso Tipo / Clase Nombre Static

Acceso
boolean PrintStream int

Retorno
directed out level

NO NO NO static virtual virtual virtual virtual virtual virtual str : String graph : Graph filename : String graph : Graph stream : PrintStream graph : Graph graph : Graph udc : UserDataContainer elem : GraphMLElement
public public public private private private private
boolean void void void void void void
invalidXMLData save save saveVerticesSection saveEdgesSection saveUserData saveNestedElement

Observaciones
Tabla 4.5-14. Clase GraphMLSerializer
161

4.5.4.1. Clase JSONSerializer
JSONSerializer
public
Clase auxiliar para convertir a formato JSON los objetos que se devuelven en las llamadas AJAX de la vista.
Convertir a formato JSON los objetos devueltos a la capa de la vista.

Acceso Tipo / Clase Nombre Stati c

Acceso
boolean StringBuffer Graph

Retorno
directed buffer graph

NO NO NO virtual virtual virtual virtual virtual virtual virtual graph : Graph vector : Vector array : Object[] void void void udc : UserDataContainer
public public public private private private private
String String String void void void void
parseGraph parseVector parseArray parseVertices parseEdges parseShapes parseAttributes

Observaciones
Pueden aadirse tantos mtodos como sean necesarios durante el desarrollo del sistema, tambin sera recomendable valorar el diseo de una interfaz adecuada para transferir parmetros a esta clase.
Tabla 4.5-15. Clase JSONSerializer
162
4.5.4.2. Paquete common.entity
4.5.4.2.1. Clase DiagramBean

DiagramBean R1.1 R1.2 R1.3 R1.4

Acceso
public
Almacena informacin de un diagrama.

Requerimientos
Alta, baja y modificacin de diagramas Buscar diagramas Publicar / compartir diagramas Control de versiones de diagramas
Atributos Tipo / Clase Nombre Static
public public public public public public public private private private private private private private
byte byte byte byte byte byte byte String String String int String byte String
DIAGRAM_PRIVILEGE_NONE DIAGRAM_PRIVILEGE_VIEW DIAGRAM_PRIVILEGE_COPY DIAGRAM_PRIVILEGE_EDIT DIAGRAM_PRIVILEGE_MAKE_VERSIONS DIAGRAM_PRIVILEGE_TOTAL_CONTROL DIAGRAM_PRIVILEGE_CREATOR id name creator version description privilege jsonObjects
Observaciones
SI SI SI SI SI SI SI NO NO NO NO NO NO NO
Esta clase se emplea para la transferencia de informacin relativa a los diagramas, a travs de todas las capas del sistema a desarrollar.
Tabla 4.5-16. Clase DiagramBean
163
4.5.4.2.2. Clase DiagramPrivilegeBean

DiagramPrivilegeBean R1.1 R1.2 R1.3 R1.4 RNF 2.9

Acceso
public
Almacena informacin del privilegio asignado a un usuario sobre un diagrama.

Requerimientos
Alta, baja y modificacin de diagramas Buscar diagramas Publicar / compartir diagramas Control de versiones de diagramas Disear un sistema de control de accesos y seguridad adecuado.
String String byte
diagramId userId privilege

Observaciones
NO NO NO
Esta clase se emplea para la transferencia de informacin relativa a los permisos de los usuarios sobre los diagramas, a travs de todas las capas del sistema a desarrollar.
Tabla 4.5-17. Clase DiagramPrivilegeBean
4.5.4.2.3. Clase DiagramChangeBean

DiagramChangeBean R2.1 R2.2 R2.3 R2.4 R2.5 R2.6 R2.7 R2.8

Acceso
public
Almacena informacin de un cambio puntual en el diseo de un diagrama.

Requerimientos
private private private private private
String String String String String
changeId diagramId userId jsonRedo jsonUndo

Observaciones
NO NO NO NO NO
Esta clase se emplea para la transferencia de informacin relativa a los cambios que los usuarios realizan sobre los diagramas.
Tabla 4.5-18. Clase DiagramChangeBean
164
4.5.4.2.4. Clase TinyUserBean

TinyUserBean
public
Almacena el identificador y la contrasea de un usuario.

Requerimientos
R5.2 Validar usuario RNF 2.9 Disear un sistema de control de accesos y seguridad adecuado.
private private
String String
id password
Observaciones
NO NO
Esta clase se emplea para la transferencia de informacin relativa al proceso de login de los usuarios del sistema.
Tabla 4.5-19. Clase TinyUserBean
4.5.4.2.5. Clase UserBean

UserBean Extiende: TinyUserBean R5.1 R5.3 R5.4

Acceso
public
Almacena informacin relativa a un usuario del sistema.

Requerimientos
Alta, baja y modificacin de usuarios Buscar usuarios Consultar datos de usuarios

private private private private
String String String int
firstName lastName email diagramCount

Observaciones
NO NO NO NO
Esta clase se emplea para la transferencia de informacin relativa a los usuarios del sistema.
Tabla 4.5-20. Clase UserBean
165

4.5.5.1. Paquete controller.filter
4.5.5.1.1. Clase FilterLogin

FilterLogin
public
Comprueba que el usuario est registrado al solicitar un recurso privado del sistema.
Requerimientos
public
void
doFilter
virtual
Observaciones
request : ServletRequest response : ServletResponse chain : FilterChain
Todas las peticiones que accedan desde el contexto app/ se consideran accesos privados y requieren que el usuario se haya registrado en el sistema. En caso contrario se le redireccionar a la pgina de registro, mostrando un error adecuado.
Tabla 4.5-21. Clase FilterLogin
166
4.5.5.2. Paquete controller.action.diagram
4.5.5.2.1. Clase AddDiagramAction

AddDiagramAction Extiende: Action R1.1

Acceso
public
Aade un diagrama al sistema.

Requerimientos
Alta, baja y modificacin de diagramas

public
ActionForward
execute
mapping : ActionMapping form : ActionForm virtual request : HttpServletRequest response : HttpServletResponse
Tabla 4.5-22. Clase AddDiagramAction
4.5.5.2.2. Clase QueryDiagramAction

QueryDiagramAction Extiende: Action R1.2 R2.8

Acceso
public
Consulta un diagrama del sistema.

Requerimientos
Buscar diagramas Colaborar mediante pizarra compartida y Chat.

public
ActionForward
execute
Tabla 4.5-23. Clase QueryDiagramAction
4.5.5.2.3. Clase DestroyDiagramAction

DestroyDiagramAction Extiende: Action R1.1

Acceso
public
Destruye por completo un diagrama.

Requerimientos
Alta, baja y modificacin de diagramas

public
ActionForward
execute
Tabla 4.5-24. Clase DestroyDiagramAction
167
4.5.5.2.4. Clase QueryDiagramChangeAction

QueryDiagramChangeAction Extiende: Action R2.1 R2.2 R2.3 R2.4 R2.5 R2.6 R2.7 R2.8
Acceso
public
Consulta los cambios producidos en un diagrama a partir de un cambio dado.
Requerimientos
public
ActionForward
execute
Tabla 4.5-25. Clase QueryDiagramChangeAction
4.5.5.2.5. Clase CommitDiagramChangeAction

CommitDiagramChangeAction Extiende: Action R2.1 R2.2 R2.3 R2.4 R2.5 R2.6 R2.7 R2.8
Acceso
public
Registra los cambios producidos en un diagrama.
Requerimientos
public
ActionForward
execute
Tabla 4.5-26. Clase CommitDiagramChangeAction
168
4.5.5.2.6. Clase LoadDiagramAction

LoadDiagramAction Extiende: Action R1.4 R2.6 R2.7 R2.8

Acceso
public
Carga un diagrama del sistema en el editor.

Requerimientos
Control de versiones de diagramas Historial de deshacer / rehacer. Guardar, exportar e importar. Colaborar mediante pizarra compartida y Chat.
public
ActionForward
execute
Tabla 4.5-27. Clase LoadDiagramAction
4.5.5.2.7. Clase QueryAllDiagramsAction

QueryAllDiagramsAction Extiende: Action R1.2 R1.3

Acceso
Consulta todos los diagramas a los que puede public acceder el usuario.
Requerimientos
Buscar diagramas Publicar / compartir diagramas

public
ActionForward
execute
Tabla 4.5-28. Clase QueryAllDiagramsAction
4.5.5.2.8. Clase QueryDiagramPrivilegesAction

QueryDiagramPrivilegesAction Extiende: Action R1.3 R2.8

Acceso
public
Consulta los permisos de los usuarios del sistema sobre el diagrama.
Requerimientos
Publicar / compartir diagramas Colaborar mediante pizarra compartida y Chat.

public
ActionForward
execute
virtual
mapping : ActionMapping form : ActionForm request : HttpServletRequest response : HttpServletResponse
Tabla 4.5-29. Clase QueryDiagramPrivilegesAction
169
4.5.5.2.9. Clase ChangeDiagramPrivilegeAction

ChangeDiagramPrivilegeAction Extiende: Action R1.3 R2.8

Acceso
Consulta los permisos de los usuarios del public sistema sobre el diagrama.
Requerimientos
Publicar / compartir diagramas Colaborar mediante pizarra compartida y Chat.

public
ActionForward
execute
virtual
Tabla 4.5-30. Clase ChangeDiagramPrivilegeAction
170
4.5.5.3. Paquete controller.action.user
4.5.5.3.1. Clase AddUserAction

AddUserAction Extiende: Action R5.1

Acceso
public Aade un usuario al sistema.

Requerimientos
Alta, baja y modificacin de usuarios

public
ActionForward
execute
virtual
Tabla 4.5-31. Clase AddUserAction
4.5.5.3.2. Clase QueryUserAction

QueryUserAction Extiende: Action R5.3 R5.4

Acceso
public Consulta un usuario del sistema.

Requerimientos
Buscar usuarios Consultar datos de usuarios

public
ActionForward
execute
virtual
Tabla 4.5-32. Clase QueryUserAction
4.5.5.3.3. Clase QueryAllUsersAction

QueryAllUsersAction Extiende: Action R5.3 R5.4

Acceso
public Consulta todos los usuarios del sistema.

Requerimientos
Buscar usuarios Consultar datos de usuarios

public
ActionForward
execute
virtual
Tabla 4.5-33. Clase QueryAllUsersAction
171
4.5.5.3.4. Clase LoginAction

LoginAction Extiende: Action
public Registra un usuario en el sistema.

Requerimientos
public
ActionForward
execute
virtual
Tabla 4.5-34. Clase LoginAction
4.5.5.3.5. Clase LoginCounterAction

LoginCounterAction Extiende: Action R5.2

Acceso
Almacena el nmero de usuarios registrados public con xito en el sistema.

Requerimientos Mtodos Nombre Modo
Validar usuario
Retorno Parmetros
public
ActionForward
execute
virtual
Tabla 4.5-35. Clase LoginCounterAction
4.5.5.3.6. Clase ExitAction

ExitAction Extiende: Action R5.2

Acceso
public Desconecta un usuario del sistema.

Requerimientos
Validar usuario
public
ActionForward
execute
virtual
Tabla 4.5-36. Clase ExitAction
172
4.5.6. Paquete view

4.5.6.1.1. Clase DiagramEditor
DiagramEditor R2.1 R2.2 R2.3 R2.4 R2.5 R2.6 R2.7 R2.8

Acceso
public
Gestiona todas las acciones de edicin de diagramas en el navegador Web.

Responsabilidades

Acceso
Node[] Link[] Surface String String DIV

Retorno
nodes edges surface diagramId userId container

NO NO NO NO NO NO virtual virtual virtual virtual virtual virtual virtual virtual virtual virtual node : Json sourceId : String targetId : String void void change : Json void e : Event e : Event e : Event response HttpResponse ioArgs : xhrArgs
public public public public public public public public public private
void void void void void void void void void void
createNode createLink zoomIn zoomOut commitChange queryChanges onMouseDown onMouseMove onMouseUp handleXhrResponse
Observaciones
No es una clase real tal y como se entiende en Java, ya que JavaScript es un lenguaje de prototipos, sin embargo la sintaxis a emplear es muy similar gracias a los mecanismos de definicin de clases de Dojo Toolkit.
Tabla 4.5-37. Clase DiagramEditor
173
4.5.6.1.2. Clase Node

Node R2.2 R2.3 R2.4

Acceso
public
Almacena los datos necesarios para la representacin e interaccin de los objetos del diagrama a disear.
Responsabilidades
Aadir y eliminar componentes. Realizar conexiones entre componentes. Aplicar transformaciones bsicas (zoom, rotacin).

Acceso
String Group Shape String Shapes[] Shapes[]

Retorno
nodeId gfx boundingShape text shapes ports

NO NO NO NO NO NO virtual virtual virtual shapes : Shape[] shape : Shape void
public public public
void void String
createShapes createShape toJson

Observaciones
Tabla 4.5-38. Clase Node
174
4.5.6.1.3. Clase Link

Link R2.3 R2.4

Acceso
public
Almacena los datos necesarios para la representacin e interaccin de las conexiones entre los nodos del diagrama a disear.
Responsabilidades
Realizar conexiones entre componentes. Aplicar transformaciones bsicas (zoom, rotacin).

private private private private private

Acceso
String Shape String Node Node

Retorno
linkId shape text source target

NO NO NO NO NO source : Node source : Node void
public public
void String
createLink toJson
Observaciones
virtual virtual
Tabla 4.5-39. Clase Link
175
4.6. Diagrama de Componentes

En este diagrama se detallan los diferentes componentes que forman el sistema, incluidas las libreras y herramientas externas al desarrollo del mismo, as como las interfaces que se emplean para comunicarse entre s. Se trata de un diagrama de alto nivel en el que quedan reflejados los componentes externos utilizados y la interaccin a grandes rasgos con los componentes a desarrollar.
Fig. 4-12. Diagrama de Componentes
176
177
CAPTULO 5: CONSTRUCCIN
Este captulo se dedica ntegramente a los archivos de configuracin desarrollados, as como al cdigo fuente y las pginas JSP.
178
5.1. Ficheros de Configuracin

Los ficheros de configuracin contenidos en este apartado son los siguientes: web.xml Este fichero se emplea para configurar las aplicaciones JEE, entre otras opciones se configuran los Servlets a emplear, las libreras de etiquetas, los filtros, los mapeos y los parmetros bsicos. struts-config.xml Sirve para configurar el funcionamiento de Struts, pudiendo definir la cadena de acciones, el control de flujo, los formularios dinmicos, los mapeos de las acciones, el archivo de recursos internacionalizados y los plugins. validation.xml Permite definir las restricciones asociadas a los campos de los formularios definidos en el archivo anterior. tiles-defs.xml Se emplea para definir la estructura de las pginas JSP, disminuyendo el nmero de pginas a desarrollar y aumentando en gran medida la reutilizacin de cdigo. build.xml Este archivo no es un fichero de configuracin propiamente dicho, aunque sirve para especificar una serie de tareas automatizadas que den como resultado una nueva versin actualizada del proyecto. MessagesResources.properties Es el archivo de mensajes internacionalizados por defecto, en caso de querer traducir la aplicacin a otro idioma bastara con traducir las cadenas contenidas en este fichero, renombrndolo con el idioma en formato ISO al final, por ejemplo MessagesResources_en.properties para ingls.
179
5.1.1. web.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
   <display-name>Abstract Minds</display-name>
   <description>Web 2.0 Enviroment for Object Interconection Diagram Design </description>
   <welcome-file-list> <welcome-file>index.jsp</welcome-file> </welcome-file-list>
   <servlet>
<servlet-name>action</servlet-name> <servlet-class>org.apache.struts.action.ActionServlet </servlet-class>
 <init-param> <param-name>config</param-name> <param-value>/WEB-INF/struts-config.xml</param-value> </init-param>
180
 <init-param> <param-name>convertNull</param-name> <param-value>true</param-value> </init-param>
 <init-param> <param-name>validating</param-name> <param-value>true</param-value> </init-param>
 <init-param> <param-name>debug</param-name> <param-value>2</param-value> </init-param>
 <init-param> <param-name>detail</param-name> <param-value>2</param-value> </init-param>
<load-on-startup>2</load-on-startup> </servlet>
   <servlet-mapping> <servlet-name>action</servlet-name> <url-pattern>*.do</url-pattern> </servlet-mapping>
   <filter> <filter-name>LoginFilter</filter-name> <filter-class>abstractminds.controller.filter.LoginFilter </filter-class> </filter>
181
   <filter-mapping> <filter-name>LoginFilter</filter-name> <url-pattern>/app/*</url-pattern> </filter-mapping>
   <taglib> <taglib-uri>/tags/struts-bean</taglib-uri> <taglib-location>/WEB-INF/struts-bean.tld</taglib-location> </taglib> <taglib> <taglib-uri>/tags/struts-html</taglib-uri> <taglib-location>/WEB-INF/struts-html.tld</taglib-location> </taglib> <taglib> <taglib-uri>/tags/struts-logic</taglib-uri> <taglib-location>/WEB-INF/struts-logic.tld</taglib-location> </taglib> <taglib> <taglib-uri>/tags/struts-nested</taglib-uri> <taglib-location>/WEB-INF/struts-nested.tld</taglib-location> </taglib> <taglib> <taglib-uri>/tags/struts-tiles</taglib-uri> <taglib-location>/WEB-INF/struts-tiles.tld</taglib-location> </taglib>
</web-app>
182
5.1.2. struts-config.xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.2//EN" "http://jakarta.apache.org/struts/dtds/struts-config_1_3.dtd">
<struts-config>    <form-beans>
 <form-bean name="LoginForm" type="org.apache.struts.validator.DynaValidatorForm"> <form-property name="id" type="java.lang.String"/> <form-property name="password" type="java.lang.String"/> </form-bean>
 <form-bean name="AddUserForm" type="org.apache.struts.validator.DynaValidatorForm"> <form-property name="id" type="java.lang.String"/> <form-property name="password" type="java.lang.String"/> <form-property name="firstName" type="java.lang.String"/> <form-property name="lastName" type="java.lang.String"/> <form-property name="email" type="java.lang.String"/> </form-bean>
183

type="org.apache.struts.validator.DynaValidatorForm"> <form-property name="name" type="java.lang.String"/> <form-property name="description" type="java.lang.String"/> </form-bean>
</form-beans>
   <global-forwards> <forward name="login" path="loginTilesDefinition"/> <forward name="global_error" path="errorTilesDefinition"/> <forward name="ajax_error" path="/ajax_error.jsp"/> </global-forwards>
   <action-mappings>

<action path="/Index" forward="defaultTilesDefinition"/>
<action path="/Login" forward="loginTilesDefinition"/>
<action path="/LoginAction" type="abstractminds.controller.action.LoginAction" scope="request" name="LoginForm" input="/Login.do"> <forward name="success" path="/LoginCounterAction.do"/> <forward name="bad_login" path="/Login.do"/> </action>
184
<action path="/ExitAction" type="abstractminds.controller.action.ExitAction"> <forward name="success" path="/Login.do"/> </action>
<action path="/LoginCounterAction" type="abstractminds.controller.action.LoginCounterAction"> <forward name="success" path="app/QueryAllDiagramsAction.do" redirect="true"/> </action>
<action path="/AddUser" forward="addUserTilesDefinition"/>
<action path="/AddUserAction" type="abstractminds.controller.action.user.AddUserAction" scope="request" name="AddUserForm" input="/AddUser.do"> <forward name="success" path="/LoginCounterAction.do"/> </action>
<action path="/XML" forward="xmlTilesDefinition"/>
<action path="/ValidateGraphMLAction" type="abstractminds.controller.action.ValidateGraphMLAction"> <forward name="success" path="/XML.do"/> <forward name="parse_error" path="/XML.do"/> </action>

<action path="/app/QueryUserAction" type="abstractminds.controller.action.user.QueryUserAction"> <forward name="success" path="userTilesDefinition"/> </action>
<action path="/app/QueryAllUsersAction" type="abstractminds.controller.action.user.QueryAllUsersAction"> <forward name="success" path="usersTilesDefinition"/> </action>
<action path="/app/AddDiagram" forward="addDiagramTilesDefinition"/>
185
<action path="/app/AddDiagramAction" type="abstractminds.controller.action.diagram.AddDiagramAction" scope="request" name="AddDiagramForm" input="/app/AddDiagram.do"> <forward name="success" path="/app/LoadDiagramAction.do" redirect="true"/> </action>
<action path="/app/QueryDiagramAction" type="abstractminds.controller.action.diagram.QueryDiagramAction"> <forward name="success" path="diagramTilesDefinition"/> </action>
<action path="/app/QueryDiagramPrivilegesAction"
type="abstractminds.controller.action.diagram.QueryDiagramPrivilegesAction"> <forward name="success" path="diagramPrivilegesTilesDefinition"/> </action>
<action path="/app/QueryDiagramPrivilegesAction" type="abstractminds.controller.action.diagram.QueryDiagramPrivilegesAction"> <forward name="success" path="diagramPrivilegesTilesDefinition"/> </action>
<action path="/app/ChangeDiagramPrivilegeAction" type="abstractminds.controller.action.diagram.ChangeDiagramPrivilegeAction"> <forward name="diagrams" path="/app/QueryAllDiagramsAction.do" redirect="true"/> <forward name="privileges" path="/app/QueryDiagramPrivilegesAction.do" redirect="true"/> </action>
<action path="/app/DestroyDiagramAction" type="abstractminds.controller.action.diagram.DestroyDiagramAction"> <forward name="success" path="/app/QueryAllDiagramsAction.do" redirect="true"/> </action>
<action path="/app/QueryAllDiagramsAction" type="abstractminds.controller.action.diagram.QueryAllDiagramsAction"> <forward name="success" path="diagramsTilesDefinition"/> </action>
186
<action path="/app/LoadDiagramAction" type="abstractminds.controller.action.diagram.LoadDiagramAction"> <forward name="success" path="/diagramEditor.jsp"/> </action>

<action path="/ajax/CommitDiagramChangeAction" type="abstractminds.controller.action.diagram.CommitDiagramChangeAction"> <forward name="success" path="/ajax.jsp"/> </action>
<action path="/ajax/QueryDiagramChangesAction" type="abstractminds.controller.action.diagram.QueryDiagramChangesAction"> <forward name="success" path="/ajax.jsp"/> </action>
</action-mappings>
   <controller processorClass="org.apache.struts.tiles.TilesRequestProcessor" />
   <message-resources parameter="abstractminds.common.MessageResources" />
    <plug-in className="org.apache.struts.tiles.TilesPlugin" >
 <set-property property="definitions-config" value="/WEB-INF/tiles-defs.xml" />
187
 <set-property property="moduleAware" value="true" />
 <set-property property="definitions-parser-validate" value="true" />
</plug-in>
 <plug-in className="org.apache.struts.validator.ValidatorPlugIn">
 <set-property property="pathnames" value="/WEB-INF/validator-rules.xml,/WEB-INF/validation.xml" />
 <set-property property="stopOnFirstError" value="false"/>
</plug-in>
</struts-config>
188
5.1.3. validation.xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE form-validation PUBLIC "-//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.1.3//EN" "http://jakarta.apache.org/commons/dtds/validator_1_1_3.dtd">
<form-validation>
<formset>
<form name="LoginForm"> <field property="id" depends="required,minlength,maxlength,mask"> <arg0 key="form.user.id"/> <arg1 name="minlength" key="${var:minlength}" resource="false"/> <arg1 name="maxlength" key="${var:maxlength}" resource="false"/> <var><var-name>minlength</var-name><var-value>4</var-value></var> <var><var-name>maxlength</var-name><var-value>20</var-value></var> <var> <var-name>mask</var-name> <var-value>^[0-9a-zA-Z_]*$</var-value> </var> </field> <field property="password" depends="required,minlength,maxlength,mask"> <arg0 key="form.user.password"/> <arg1 name="minlength" key="${var:minlength}" resource="false"/> <arg1 name="maxlength" key="${var:maxlength}" resource="false"/> <arg1 name="mask" key="${var:mask}" resource="false"/> <var><var-name>minlength</var-name><var-value>4</var-value></var> <var><var-name>maxlength</var-name><var-value>20</var-value></var> <var> <var-name>mask</var-name> <var-value>^[0-9a-zA-Z_]*$</var-value> </var> </field> </form>
189
<form name="AddUserForm"> <field property="id" depends="required,minlength,maxlength,mask"> <arg0 key="form.user.id"/> <arg1 name="minlength" key="${var:minlength}" resource="false"/> <arg1 name="maxlength" key="${var:maxlength}" resource="false"/> <arg1 name="mask" key="${var:mask}" resource="false"/> <var><var-name>minlength</var-name><var-value>4</var-value></var> <var><var-name>maxlength</var-name><var-value>20</var-value></var> <var> <var-name>mask</var-name> <var-value>^[0-9a-zA-Z_]*$</var-value> </var> </field> <field property="password" depends="required,minlength,maxlength,mask"> <arg0 key="form.user.password"/> <arg1 name="minlength" key="${var:minlength}" resource="false"/> <arg1 name="maxlength" key="${var:maxlength}" resource="false"/> <arg1 name="mask" key="${var:mask}" resource="false"/> <var><var-name>minlength</var-name><var-value>4</var-value></var> <var><var-name>maxlength</var-name><var-value>20</var-value></var> <var> <var-name>mask</var-name> <var-value>^[0-9a-zA-Z_]*$</var-value> </var> </field> <field property="firstName" depends="maxlength,mask"> <arg0 key="form.user.first_name"/> <arg1 name="maxlength" key="${var:maxlength}" resource="false"/> <arg1 name="mask" key="${var:mask}" resource="false"/> <var><var-name>maxlength</var-name><var-value>50</var-value></var> <var> <var-name>mask</var-name> <var-value>^[0-9a-zA-Z_ ]*$</var-value> </var> </field>
190
<field property="lastName" depends="maxlength,mask"> <arg0 key="form.user.last_name"/> <arg1 name="maxlength" key="${var:maxlength}" resource="false"/> <arg1 name="mask" key="${var:mask}" resource="false"/> <var><var-name>maxlength</var-name><var-value>100</var-value></var> <var> <var-name>mask</var-name> <var-value>^[0-9a-zA-Z_ ]*$</var-value> </var> </field> <field property="email" depends="maxlength,email"> <arg0 key="form.user.email"/> <arg1 name="maxlength" key="${var:maxlength}" resource="false"/> <var><var-name>maxlength</var-name><var-value>50</var-value></var> </field> </form> <form name="AddDiagramForm"> <field property="name" depends="required,maxlength,mask"> <arg0 key="form.diagram.name"/> <arg1 name="maxlength" key="${var:maxlength}" resource="false"/> <var><var-name>maxlength</var-name><var-value>50</var-value></var> <var> <var-name>mask</var-name> <var-value>^[0-9a-zA-Z_ ]*$</var-value> </var> </field> <field property="description" depends="maxlength,mask"> <arg0 key="form.diagram.description"/> <arg1 name="maxlength" key="${var:maxlength}" resource="false"/> <arg1 name="mask" key="${var:mask}" resource="false"/> <var><var-name>maxlength</var-name><var-value>500</var-value></var> <var> <var-name>mask</var-name> <var-value>^[0-9a-zA-Z_]*$</var-value> </var> </field> </form> </formset> </form-validation>
191
5.1.4. tiles-defs.xml
<?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE tiles-definitions PUBLIC "-//Apache Software Foundation//DTD Tiles Configuration 1.1//EN" "http://jakarta.apache.org/struts/dtds/tiles-config_1_3.dtd">
<tiles-definitions>
   <definition name="defaultTilesDefinition" path="/defaultLayout.jsp"> <put name="appTitle" type="string" value="AbstractMinds" /> <put name="titleKey" type="string" value="title.index" /> <put name="header" value="header.jsp" /> <put name="body" value="menu.jsp" /> <put name="menu" value="menu.jsp" /> <put name="footer" value="footer.jsp" /> </definition>
   <definition name="loginTilesDefinition" extends="defaultTilesDefinition"> <put name="titleKey" type="string" value="title.login"/> <put name="body" value="login.jsp" /> </definition>
   <definition name="addUserTilesDefinition" extends="defaultTilesDefinition"> <put name="titleKey" type="string" value="title.add_user" /> <put name="body" value="addUser.jsp" /> </definition>
   <definition name="userTilesDefinition" extends="defaultTilesDefinition"> <put name="titleKey" type="string" value="title.user" /> <put name="body" value="user.jsp" /> </definition>
192
   <definition name="usersTilesDefinition" extends="defaultTilesDefinition"> <put name="titleKey" type="string" value="title.users" /> <put name="body" value="users.jsp" /> </definition>
   <definition name="addDiagramTilesDefinition" extends="defaultTilesDefinition"> <put name="titleKey" type="string" value="title.add_diagram" /> <put name="body" value="addDiagram.jsp" /> </definition>
   <definition name="diagramTilesDefinition" extends="defaultTilesDefinition"> <put name="titleKey" type="string" value="title.diagram" /> <put name="body" value="diagram.jsp" /> </definition>
   <definition name="diagramPrivilegesTilesDefinition" extends="defaultTilesDefinition"> <put name="titleKey" type="string" value="title.diagram.privileges" /> <put name="body" value="diagramPrivileges.jsp" /> </definition>
   <definition name="diagramsTilesDefinition" extends="defaultTilesDefinition"> <put name="titleKey" type="string" value="title.diagrams" /> <put name="body" value="diagrams.jsp" /> </definition>
193
   <definition name="errorTilesDefinition" extends="defaultTilesDefinition"> <put name="titleKey" type="string" value="title.error" /> <put name="body" value="error.jsp" /> </definition>
   <definition name="xmlTilesDefinition" extends="defaultTilesDefinition"> <put name="titleKey" type="string" value="title.xml" /> <put name="body" value="xml.jsp" /> </definition>
</tiles-definitions>
194
5.1.5. build.xml
<?xml version="1.0"?>
  --> --> -->

<project name="AbstractMinds" default="deploy" basedir=".">
   <property name="name" value="AbstractMinds"/> <property name="version" value="0.0"/>  <property environment="env"/>  <property name="year" value="2007"/> <property name="ant.home" value="."/> <property name="debug" value="on"/> <property name="optimize" value="off"/> <property name="deprecation" value="off"/>
   <property name="src.java.dir" value="../src"/> <property name="web.src.java.dir" value="../src"/> <property name="ejb.src.java.dir" value="../src"/> <property name="configuration.src.dir" value="../configuration"/> <property name="lib.dir" value="../lib"/> <property name="compilelib.dir" value="../compile-lib"/> <property name="misc.dir" value="../misc"/> <property name="conf.dir" value="../conf"/> <property name="devetc.dir" value="../etc"/> <property name="web.dir" value="../web"/>
195
   <property name="distribution.dir" value="../distribution"/>  <property name="war.file.name" value="AbstractMinds.war"/>
 
 <property name="build.compiler" value="modern"/> <property name="build.dir" value="../bin"/> <property name="build.src" value="${build.dir}/src"/> <property name="build.src.web" value="${build.dir}/src"/> <property name="build.dest" value="${build.dir}/classes"/> <property name="build.dest.web" value="${build.dir}/classes"/> <property name="build.dest.ejb" value="${build.dir}/classes"/> <property name="build.web" value="${build.dir}/web"/> <property name="build.web-inf" value="${build.dir}/web/WEB-INF"/>
 
 <property name="deliver.dir" value="../ilm"/> <property name="deliver.class" value="${deliver.dir}/WEB-INF/classes"/> <property name="deliver.lib" value="${deliver.dir}/WEB-INF/lib"/> <property name="deliver.ejb" value="${deliver.dir}/ejb-jar"/>
 
   
<patternset id="all.src.files">
 <include name="**/*.java"/>
 <include name="**/*.xml"/> <include name="**/*.properties"/>
196
 <include name="**/*.jpg"/> <include name="**/*.gif"/> <include name="**/*.js"/> <include name="**/*.jsp"/> <include name="**/*.html"/>
</patternset>
   <target name="enviroment">
<echo message="build.compiler = ${build.compiler}"/> <echo message="java.class.path = ${java.class.path}"/> <echo message="java.home = ${java.home}"/> <echo message="user.home = ${user.home}"/> <echo message="jboss.home = ${env.JBOSS_HOME}"/>
</target>
   <target name="prepare" depends="enviroment">
<mkdir dir="${build.dir}"/> <mkdir dir="${build.dest}"/> <mkdir dir="${build.dest.ejb}"/> <mkdir dir="${build.dest.web}"/> <mkdir dir="${build.src}"/> <mkdir dir="${build.web}"/> <mkdir dir="${build.web-inf}"/> <mkdir dir="${distribution.dir}"/> <mkdir dir="${web.src.java.dir}"/> <mkdir dir="${ejb.src.java.dir}"/> <mkdir dir="${build.src.web}"/>
 <filter token="version" value="${version}"/>
197
<copy todir="${build.src}" filtering="on"> <fileset dir="${src.java.dir}" > <patternset refid="all.src.files"/> </fileset> </copy>
<copy todir="${build.web}"> <fileset dir="${web.dir}"> <include name="**/*.*"/> <exclude name="**/*.bak"/> </fileset> </copy>
</target>
 
 <target name="compile" depends="prepare">
<javac srcdir="${build.src.web}" destdir="${build.dest.web}" debug="${debug}" deprecation="${deprecation}" optimize="${optimize}" classpath= "${build.dest.ejb}">
 <exclude name="**/package.html"/> <exclude name="**/overview.html"/> <classpath> <path> <fileset dir="${build.dest.ejb}"/> <fileset dir="${lib.dir}"/> <fileset dir="${compilelib.dir}"/> </path> </classpath>
</javac>
198
<copy todir="${build.web-inf}"> <fileset dir="${devetc.dir}"> <exclude name="**/*.bak"/> <exclude name="ejb-jar.xml"/> </fileset> </copy>
<copy todir="${build.dest.web}"> <fileset dir="${web.src.java.dir}"> <include name="**/*.xml"/> <include name="**/*.properties"/> <exclude name="**/*.bak"/> </fileset> </copy>
</target>
 
 <target name="war" depends="compile"> <war warfile="${distribution.dir}/${war.file.name}" webxml="${devetc.dir}/web.xml"> <fileset dir="${build.web}"> <exclude name="**/lib/*.*"/> <exclude name="**/classes/**/*.*"/> <exclude name="**/web.xml"/> </fileset>
<lib dir="${lib.dir}"/> <classes dir="${build.dest.web}"/>
</war> </target>
199
 
 <target name="deploy" depends="war">
<copy todir="${env.JBOSS_HOME}/server/default/deploy"> <fileset dir="${distribution.dir}"> <include name="*.war"/> </fileset> </copy>
</target>
 
 <target name="clean">
<delete dir="${build.dir}"/> <mkdir dir="${build.dir}"/>
</target>
 
 <target name="javadoc" depends="compile">
<exec dir="${makejavadoc.dir}" executable="${makejavadoc.dir}/${javadoc.file.name}"> <arg value="${javadoc.dir}"/> </exec>
</target>
</project>
200
5.1.6. MessageResources.properties
app.index.link=Inicio app.user.link=Cuenta app.users.link=Usuarios app.login.link=Conectar app.add_user.link=Nuevo Usuario app.add_diagram.link=Crear Diagrama app.diagrams.link=Diagramas app.exit.link=Desconectar
title.index=Inicio title.login=Conectar title.add_user=Nuevo Usuario title.user=Datos de la Cuenta de Usuario title.users=Consultar Usuarios title.add_diagram=Crear Diagrama title.diagram=Datos del Diagrama title.diagram.editor=Editar Diagrama title.diagram.copy=Copiar Diagrama title.diagram.privileges=Gestionar Permisos title.diagrams=Consultar Diagramas title.error=Error title.xml=XML
form.user.id=Usuario form.user.password=Contrasea form.user.first_name=Nombre form.user.last_name=Apellidos form.user.email=e-mail
form.diagram.id=ID form.diagram.version=Versin form.diagram.name=Nombre form.diagram.creator=Creador form.diagram.description=Descripcin form.diagram.remove=Descartar Diagrama form.diagram.destroy=Destruir Diagrama
label.diagramCount=Diagramas label.managePrivileges=Gestionar Permisos label.privileges=Permisos label.actions=Acciones label.removePrivileges=Quitar Permisos
201
privilege.none=Ninguno privilege.view=Consultar privilege.copy=Copiar privilege.edit=Editar privilege.versions=Crear Versiones privilege.total=Control Total privilege.creator=Creador
submit.update=Actualizar
msg.logged_as=Conectado como msg.logout=Usuario desconectado con xito msg.not_logged=No conectado msg.empty=Ninguna fila seleccionada msg.privilege.updated=Se han actualizado los permisos para el usuario
errors.global_error=El servicio solicitado no est disponible. errors.login=Usuario o contrasea incorrectos.
# Struts Validator Error Messages errors.required=Debe especificar un valor para el campo {0}. errors.minlength=El campo {0} no puede tener menos de {1} caracteres. errors.maxlength=El campo {0} no puede tener ms de {1} caracteres. errors.invalid=El campo {0} contiene caracteres no vlidos.
errors.byte=El campo {0} debe ser de tipo byte. errors.short=El campo {0} debe ser de tipo short. errors.integer=El campo {0} debe ser de tipo integer. errors.long=El campo {0} debe ser de tipo long. errors.float=El campo {0} debe ser de tipo float. errors.double=El campo {0} debe ser de tipo double.
errors.date=El campo {0} no es una fecha vlida. errors.range=El campo {0} no est entre {1} y {2}. errors.creditcard=El campo {0} no es un numero de tarjeta de crdito vlido. errors.email=El campo {0} no es una direccin de e-mail correcta.
202
5.2. Cdigo Fuente

En este apartado se incorpora el cdigo fuente Java generado durante el desarrollo del proyecto, omitindose los comentarios JavaDoc para facilitar su lectura y economizar espacio. El cdigo fuente tambin puede obtenerse directamente del CD que acompaa a este documento. Se ha respetado la organizacin empleada durante el diseo, subdividendo el sistema en los paquetes ms importantes y separando de manera adecuada las responsabilidades. Estos paquetes pueden contener otros paquetes internos con los que compartan responsabilidades. Tambin se incluye un apartado de recursos adicionales dedicado a las pginas JSP y los ficheros CSS desarrollados.
203

5.2.1.1. ModelFacade.java
package abstractminds.model;
import java.sql.SQLException; import java.util.Collection;
import abstractminds.common.entity.DiagramBean; import abstractminds.common.entity.DiagramChangeBean; import abstractminds.common.entity.DiagramPrivilegeBean; import abstractminds.common.entity.TinyUserBean; import abstractminds.common.entity.UserBean;
public class ModelFacade {
public boolean login(TinyUserBean user) throws SQLException { return (new UserManager().login(user)); }
public UserBean getUser(String id) throws SQLException { return (new UserManager().getUser(id)); }
public Collection<UserBean> getAllUsers() throws SQLException { return (new UserManager().getAllUsers()); }
public void addUser(UserBean user) throws SQLException { new UserManager().addUser(user); }
public void commitDiagramChange( DiagramChangeBean change) throws SQLException { new DiagramManager().commitDiagramChange(change); }
public DiagramBean getDiagram( String actorId, String diagramId) throws SQLException { return (new DiagramManager().getDiagram(actorId, diagramId)); }
204
public String queryDiagramChanges( DiagramChangeBean change) throws SQLException { return (new DiagramManager().queryDiagramChanges(change)); }
public void addDiagram( DiagramBean diagram) throws SQLException { new DiagramManager().addDiagram(diagram); }
public Collection<?> getAllDiagrams( String actorId) throws SQLException { return (new DiagramManager().getAllDiagrams(actorId)); }
public void destroyDiagram( String actorId, String diagramId) throws SQLException { new DiagramManager().destroyDiagram(actorId, diagramId); }
public Collection<?> getDiagramPrivileges( String actorId, String diagramId) throws SQLException { return (new DiagramManager().getDiagramPrivileges(actorId, diagramId)); }
public void changeDiagramPrivilege( String actorId, DiagramPrivilegeBean privilege) throws SQLException { new DiagramManager().changeDiagramPrivilege(actorId, privilege); }
public DiagramBean loadDiagram( String actorId, String diagramId) throws SQLException { return (new DiagramManager().loadDiagram(actorId, diagramId)); } }
205
5.2.1.2. DiagramManager.java
import java.sql.SQLException; import java.util.Collection; import java.util.Iterator; import edu.uci.ics.jung.graph.Graph; import abstractminds.common.entity.DiagramBean; import abstractminds.common.entity.DiagramChangeBean; import abstractminds.common.entity.DiagramPrivilegeBean; import abstractminds.model.graphml.GraphMLFile; import abstractminds.model.graphml.JSONSerializer; import abstractminds.model.persistence.PersistenceFacade;
public class DiagramManager {
public DiagramBean getDiagram(String actor_id, String diagram_id) throws SQLException { DiagramBean diagramBean = new PersistenceFacade().getDiagram(actor_id, diagram_id); if (diagramBean == null) { throw new IllegalArgumentException( "Not found or insufficient privileges."); } return (diagramBean); }
public void commitDiagramChange(DiagramChangeBean change) throws SQLException { new PersistenceFacade().commitDiagramChange(change); }
public String queryDiagramChanges(DiagramChangeBean change) throws SQLException {
Collection<?> changes = new PersistenceFacade().queryDiagramChanges(change); StringBuffer buffer = new StringBuffer(); if (changes.size() < 1) { buffer.append("{ack: '" + change.getChangeId() + "'}"); } else { Iterator<?> it = changes.iterator(); change = (DiagramChangeBean) it.next();
206
buffer.append("{redo:["); buffer.append(change.getJsonRedo()); while (it.hasNext()) { buffer.append(','); change = (DiagramChangeBean) it.next(); buffer.append(change.getJsonRedo()); } buffer.append("],changeId:'"); buffer.append(change.getChangeId()); buffer.append("'}"); } return buffer.toString(); }
public void addDiagram(DiagramBean diagram) throws SQLException { new PersistenceFacade().addDiagram(diagram); }
public Collection<?> getAllDiagrams(String actor_id) throws SQLException { return (new PersistenceFacade().getAllDiagrams(actor_id)); }
public void destroyDiagram(String actor_id, String diagram_id) throws SQLException { DiagramBean diagram = getDiagram(actor_id, diagram_id); if (diagram.getPrivilege() >= DiagramBean.DIAGRAM_PRIVILEGE_CREATOR) { new PersistenceFacade().destroyDiagram(diagram_id); } else { throw new IllegalArgumentException("Insufficient privileges."); } }
public Collection<?> getDiagramPrivileges( String actor_id, String diagram_id) throws SQLException {
DiagramBean diagram = getDiagram(actor_id, diagram_id); if (diagram.getPrivilege() >= DiagramBean.DIAGRAM_PRIVILEGE_TOTAL_CONTROL) { return (new PersistenceFacade().getDiagramPrivileges(diagram_id)); } else { throw new IllegalArgumentException("Insufficient privileges."); } }
207
public void changeDiagramPrivilege( String actor_id, DiagramPrivilegeBean privilegeBean) throws SQLException { DiagramBean diagram = getDiagram(actor_id, privilegeBean.getDiagramId()); if (actor_id.equals(privilegeBean.getUserId()) || diagram.getPrivilege() >= DiagramBean.DIAGRAM_PRIVILEGE_TOTAL_CONTROL) {
if (privilegeBean.getPrivilege() <= DiagramBean.DIAGRAM_PRIVILEGE_NONE) { new PersistenceFacade().removeDiagramPrivilege(privilegeBean);
} else if (privilegeBean.getPrivilege() < DiagramBean.DIAGRAM_PRIVILEGE_CREATOR){ new PersistenceFacade().updateDiagramPrivilege(privilegeBean);
} else { throw new IllegalArgumentException("Privilege isn't valid."); } } else { throw new IllegalArgumentException("Insufficient privileges."); }
public DiagramBean loadDiagram( String actorId, String diagramId) throws SQLException { DiagramBean diagram = getDiagram(actorId, diagramId); if (diagram.getPrivilege() >= DiagramBean.DIAGRAM_PRIVILEGE_EDIT) { if (diagram.getVersion() > 0) { String path = "../xml/" + diagram.getId() + '_' + diagram.getVersion() + ".graphml"; Graph g = new GraphMLFile().load(path); diagram.setJsonObjects(new JSONSerializer().parseGraph(g)); } else { diagram.setJsonObjects("{ack: 'empty'}"); } } else { throw new IllegalArgumentException("Insufficient privileges."); } return diagram; } }
208
5.2.1.3. UserManager.java
import abstractminds.common.entity.TinyUserBean; import abstractminds.common.entity.UserBean; import abstractminds.model.persistence.PersistenceFacade;
public class UserManager {
public boolean login(TinyUserBean user) throws SQLException { return (new PersistenceFacade().login(user)); }
public UserBean getUser(String id) throws SQLException { return (new PersistenceFacade().getUser(id)); }
public Collection<UserBean> getAllUsers() throws SQLException { return (new PersistenceFacade().getAllUsers()); }
public void addUser(UserBean user) throws SQLException { new PersistenceFacade().addUser(user); } }
209

5.2.2.1. PersistenceFacade.java
package abstractminds.model.persistence;
import abstractminds.common.entity.DiagramBean; import abstractminds.common.entity.DiagramChangeBean; import abstractminds.common.entity.DiagramPrivilegeBean; import abstractminds.common.entity.TinyUserBean; import abstractminds.common.entity.UserBean;
public class PersistenceFacade {
private DAOFactory getDAOFactory() { return DAOFactory.getDAOFactory(DAOFactory.ORACLE); }
public Collection<UserBean> getAllUsers() throws SQLException { return getDAOFactory().getUserDAO().getAllUsers(); }
public void addUser(UserBean user) throws SQLException { getDAOFactory().getUserDAO().insertUser(user); }
public UserBean getUser(String id) throws SQLException { return getDAOFactory().getUserDAO().getUser(id); }
public boolean login(TinyUserBean user) throws SQLException { return getDAOFactory().getUserDAO().login(user); }
public void commitDiagramChange(DiagramChangeBean change) throws SQLException { getDAOFactory().getDiagramDAO().commitDiagramChange(change); }
210
public DiagramBean getDiagram(String user_id, String diagram_id) throws SQLException { return getDAOFactory().getDiagramDAO().getDiagram(user_id, diagram_id); }
public Collection<?> queryDiagramChanges( DiagramChangeBean diagramChangeBean) throws SQLException { return(getDAOFactory().getDiagramDAO().queryDiagramChanges(diagramChangeBean )); }
public void addDiagram(DiagramBean diagram) throws SQLException { getDAOFactory().getDiagramDAO().addDiagram(diagram); }
public Collection<?> getAllDiagrams(String user_id) throws SQLException { return getDAOFactory().getDiagramDAO().getAllDiagrams(user_id); }
public void destroyDiagram(String diagram_id) throws SQLException { getDAOFactory().getDiagramDAO().destroyDiagram(diagram_id); }
public Collection<?> getDiagramPrivileges(String diagram_id) throws SQLException { return getDAOFactory().getDiagramDAO().getDiagramPrivileges(diagram_id); }
public void removeDiagramPrivilege(DiagramPrivilegeBean privilegeBean) throws SQLException { getDAOFactory().getDiagramDAO().removeDiagramPrivilege(privilegeBean); }
public void updateDiagramPrivilege(DiagramPrivilegeBean privilegeBean) throws SQLException { getDAOFactory().getDiagramDAO().updateDiagramPrivilege(privilegeBean); } }
211
5.2.2.2. DAOFactory.java
import abstractminds.model.persistence.oracle.OracleDAOFactory;
public abstract class DAOFactory {
public static final byte ORACLE = 1;
public abstract UserDAO getUserDAO(); public abstract DiagramDAO getDiagramDAO();
public static DAOFactory getDAOFactory(byte type) { switch (type) { case ORACLE: return new OracleDAOFactory(); } throw new IllegalArgumentException(); }
212
5.2.2.3. DiagramDAO.java
import abstractminds.common.entity.DiagramBean; import abstractminds.common.entity.DiagramChangeBean; import abstractminds.common.entity.DiagramPrivilegeBean;
public interface DiagramDAO {
public void addDiagram(DiagramBean diagramBean) throws SQLException;
public DiagramBean getDiagram(String user_id, String diagram_id) throws SQLException;
public void commitDiagramChange(DiagramChangeBean change) throws SQLException;
public Collection<?> queryDiagramChanges( DiagramChangeBean diagramChangeBean) throws SQLException;
public Collection<?> getAllDiagrams(String user_id) throws SQLException;
public void destroyDiagram(String diagram_id) throws SQLException;
public Collection<?> getDiagramPrivileges(String diagram_id) throws SQLException;
public void removeDiagramPrivilege(DiagramPrivilegeBean privilegeBean) throws SQLException;
public void updateDiagramPrivilege(DiagramPrivilegeBean privilegeBean) throws SQLException;
213
5.2.2.4. UserDAO.java
import abstractminds.common.entity.TinyUserBean; import abstractminds.common.entity.UserBean;
public interface UserDAO {
public void insertUser(UserBean user) throws SQLException;
public Collection<UserBean> getAllUsers() throws SQLException;
public UserBean getUser(String id) throws SQLException;
public boolean login(TinyUserBean login) throws SQLException; }
214
5.2.2.5. Paquete model.persistence.oracle
5.2.2.5.1. OracleDAOFactory.java
package abstractminds.model.persistence.oracle;
import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.SQLException; import java.sql.Statement;
import abstractminds.model.persistence.DAOFactory; import abstractminds.model.persistence.DiagramDAO; import abstractminds.model.persistence.UserDAO;
public class OracleDAOFactory extends DAOFactory {
static { try { Class.forName("oracle.jdbc.driver.OracleDriver"); } catch (ClassNotFoundException e) { e.printStackTrace(); } }
@Override public DiagramDAO getDiagramDAO() { return new OracleDiagramDAO(); }
@Override public UserDAO getUserDAO() { return new OracleUserDAO(); }
public static Connection createConnection() throws SQLException { return DriverManager.getConnection( "jdbc:oracle:thin:@HP:1521:orcl", "scott", "tiger"); }
215
public static void freeResources(Statement stat, ResultSet rs) { try { if (stat != null) stat.close(); } catch (Exception e) { System.out.println(e.getLocalizedMessage()); } try { if (rs != null) rs.close(); } catch (Exception e) { System.out.println(e.getLocalizedMessage()); } }
216
5.2.2.5.2. OracleDiagramDAO.java
import java.sql.Connection; import java.sql.ResultSet; import java.sql.SQLException; import java.sql.Statement; import java.util.Collection; import java.util.Vector;
import abstractminds.common.entity.DiagramBean; import abstractminds.common.entity.DiagramChangeBean; import abstractminds.common.entity.DiagramPrivilegeBean; import abstractminds.model.persistence.DiagramDAO;
public class OracleDiagramDAO implements DiagramDAO {
public void addDiagram(DiagramBean diagramBean) throws SQLException { Connection conn = OracleDAOFactory.createConnection(); String sql = "INSERT INTO diagrams" + "(diagram_name,diagram_creator,diagram_description)" + " VALUES(" + "'" + diagramBean.getName() + "'," + "'" + diagramBean.getCreator() + "'," + "'" + diagramBean.getDescription() + "')"; Statement stat = null; ResultSet rs = null; try { stat = conn.createStatement(); stat.executeUpdate(sql); sql = "SELECT MAX(diagram_id) " + "FROM diagrams " + "WHERE diagram_creator='" + diagramBean.getCreator() + "'"; rs = stat.executeQuery(sql); rs.next(); diagramBean.setId(rs.getString(1)); } finally { OracleDAOFactory.freeResources(stat, null); } }
217
public DiagramBean getDiagram(String user_id, String diagram_id) throws SQLException {
Connection conn = OracleDAOFactory.createConnection(); String sql = "SELECT * FROM ((" + "SELECT diagrams.*, " + " diagram_creator user_id, " + " 5 diagram_privilege " + "FROM diagrams " + "WHERE diagram_creator='" + user_id + "' " + " AND diagram_id='" + diagram_id + "' " + ") UNION (" + "SELECT * " + "FROM (SELECT * FROM diagrams WHERE diagram_id='"+diagram_id+"') "+ "NATURAL JOIN diagram_privileges " + "WHERE user_id='" + user_id + "' " + ")) ORDER BY diagram_privilege DESC, diagram_name"; Statement stat = null; ResultSet rs = null; try { stat = conn.createStatement(); rs = stat.executeQuery(sql); if (!rs.next()) return null; return new DiagramBean( rs.getString("DIAGRAM_ID"), rs.getString("DIAGRAM_NAME"), rs.getString("DIAGRAM_CREATOR"), rs.getInt("DIAGRAM_VERSION"), rs.getString("DIAGRAM_DESCRIPTION"), rs.getByte("DIAGRAM_PRIVILEGE") ); } finally { OracleDAOFactory.freeResources(stat, rs); } }
218
public void commitDiagramChange(DiagramChangeBean change) throws SQLException {
Connection conn = OracleDAOFactory.createConnection(); String sql = "INSERT INTO diagram_changes" + "(diagram_id,user_id,diagram_change_redo,diagram_change_undo)" + " VALUES(" + "'" + change.getDiagramId() + "'," + "'" + change.getUserId() + "'," + "'" + change.getJsonRedo() + "'," + "'" + change.getJsonUndo() + "')"; Statement stat = null; try { stat = conn.createStatement(); stat.executeUpdate(sql); } finally { OracleDAOFactory.freeResources(stat, null); } }
219
public Collection<?> queryDiagramChanges(DiagramChangeBean diagramChangeBean) throws SQLException {
Connection conn = OracleDAOFactory.createConnection(); String sql = "SELECT " + " diagram_change_id," + " diagram_change_redo " + "FROM diagram_changes " + "WHERE diagram_change_id > '" + diagramChangeBean.getChangeId()+"' " + " AND diagram_id = '" + diagramChangeBean.getDiagramId() + "' "; if(diagramChangeBean.getChangeId() != null && !diagramChangeBean.getChangeId().trim().equals("0")) { sql += " AND user_id<>'" + diagramChangeBean.getUserId() + "' "; } sql += "ORDER BY diagram_change_id"; Vector<DiagramChangeBean> v = new Vector<DiagramChangeBean>(); Statement stat = null; ResultSet rs = null; try { stat = conn.createStatement(); rs = stat.executeQuery(sql); while(rs.next()) { v.add(new DiagramChangeBean( rs.getString(1), null, null, rs.getString(2), null )); } return v; } finally { OracleDAOFactory.freeResources(stat, rs); } }
220
public Collection<?> getAllDiagrams(String user_id) throws SQLException { Connection conn = OracleDAOFactory.createConnection(); String sql = "SELECT * FROM ((" + "SELECT diagrams.*, " + " diagram_creator user_id, " + " 5 diagram_privilege " + "FROM diagrams " + "WHERE diagram_creator='" + user_id + "' " + ") UNION (" + "SELECT * " + "FROM diagrams " + "NATURAL JOIN diagram_privileges " + "WHERE user_id='" + user_id + "' " + ")) ORDER BY diagram_privilege DESC, diagram_name"; Vector<DiagramBean> v = new Vector<DiagramBean>(); Statement stat = null; ResultSet rs = null; try { stat = conn.createStatement(); rs = stat.executeQuery(sql); while(rs.next()) { v.add(new DiagramBean( rs.getString("DIAGRAM_ID"), rs.getString("DIAGRAM_NAME"), rs.getString("DIAGRAM_CREATOR"), rs.getInt("DIAGRAM_VERSION"), rs.getString("DIAGRAM_DESCRIPTION"), rs.getByte("DIAGRAM_PRIVILEGE") )); } return v; } finally { OracleDAOFactory.freeResources(stat, rs); } }
221
public Collection<?> getDiagramPrivileges(String diagram_id) throws SQLException { Connection conn = OracleDAOFactory.createConnection(); String sql = "SELECT " + " diagram_id, " + " user_id, " + " MAX(diagram_privilege) diagram_privilege " + "FROM ((" + "SELECT " + " diagram_id, " + " diagram_creator user_id, " + " 5 diagram_privilege " + "FROM diagrams " + "WHERE diagram_id='" + diagram_id + "' " + ") UNION (" + "SELECT " + " diagram_id, " + " user_id, " + " diagram_privilege " + "FROM diagram_privileges " + " WHERE diagram_id='" + diagram_id + "' " + ") UNION (" + "SELECT " + " '" + diagram_id + "' diagram_id, " + " user_id, " + " -1 diagram_privilege " + "FROM users " + ")) " + "GROUP BY user_id, diagram_id " + "ORDER BY diagram_privilege DESC, user_id";
222
Vector<DiagramPrivilegeBean> v = new Vector<DiagramPrivilegeBean>(); Statement stat = null; ResultSet rs = null; try { stat = conn.createStatement(); rs = stat.executeQuery(sql); while(rs.next()) { v.add(new DiagramPrivilegeBean( rs.getString("DIAGRAM_ID"), rs.getString("USER_ID"), rs.getByte("DIAGRAM_PRIVILEGE") )); } return v; } finally { OracleDAOFactory.freeResources(stat, rs); } }
public void destroyDiagram(String diagram_id) throws SQLException { Connection conn = OracleDAOFactory.createConnection(); String sql = null; Statement stat = null; try { stat = conn.createStatement(); sql = "DELETE FROM diagram_privileges " + "WHERE diagram_id='" + diagram_id + "' "; stat.executeUpdate(sql); sql = "DELETE FROM diagram_changes " + "WHERE diagram_id='" + diagram_id + "' "; stat.executeUpdate(sql); sql = "DELETE FROM diagrams " + "WHERE diagram_id='" + diagram_id + "' "; stat.executeUpdate(sql); } finally { OracleDAOFactory.freeResources(stat, null); } }
223
public void removeDiagramPrivilege(DiagramPrivilegeBean privilegeBean) throws SQLException { Connection conn = OracleDAOFactory.createConnection(); String sql = "DELETE FROM diagram_privileges " + "WHERE user_id='" + privilegeBean.getUserId() + "' " + " AND diagram_id='" + privilegeBean.getDiagramId() + "'"; Statement stat = null; try { stat = conn.createStatement(); stat.executeUpdate(sql); } finally { OracleDAOFactory.freeResources(stat, null); } }
public void updateDiagramPrivilege(DiagramPrivilegeBean privilegeBean) throws SQLException { Connection conn = OracleDAOFactory.createConnection(); String sql = "UPDATE diagram_privileges " + " SET diagram_privilege=" + privilegeBean.getPrivilege() + " " + "WHERE user_id='" + privilegeBean.getUserId() + "' " + " AND diagram_id='" + privilegeBean.getDiagramId() + "'"; Statement stat = null; try { stat = conn.createStatement(); int c = stat.executeUpdate(sql); System.out.println(c); if (c == 0) { sql = "INSERT INTO diagram_privileges " + " (diagram_id, user_id, diagram_privilege) " + "VALUES (" + "'" + privilegeBean.getDiagramId() + "', " +
"'" + privilegeBean.getUserId() + "', " + privilegeBean.getPrivilege() + ")"; System.out.println(sql); stat.executeUpdate(sql); System.out.println(sql); } } finally { OracleDAOFactory.freeResources(stat, null); } } }
224
5.2.2.5.3. OracleUserDAO.java
import java.sql.Connection; import java.sql.ResultSet; import java.sql.SQLException; import java.sql.Statement; import java.util.Collection; import java.util.Vector;
import abstractminds.common.entity.TinyUserBean; import abstractminds.common.entity.UserBean; import abstractminds.model.persistence.UserDAO;
public class OracleUserDAO implements UserDAO {
public void insertUser(UserBean user) throws SQLException { Connection conn = OracleDAOFactory.createConnection(); String sql = "INSERT INTO users" + " VALUES(" + "'" + user.getId() + "'," + "'" + user.getPassword() + "'," + "'" + user.getFirstName() + "'," + "'" + user.getLastName() + "'," + "'" + user.getEmail() + "')"; Statement stat = null; try { stat = conn.createStatement(); stat.executeUpdate(sql); } finally { OracleDAOFactory.freeResources(stat, null); } }
225
public Collection<UserBean> getAllUsers() throws SQLException { Connection conn = OracleDAOFactory.createConnection(); String sql = "SELECT u.*, " + " NVL(g.diagram_count,0) diagram_count " + "FROM users u LEFT JOIN " + "(SELECT diagram_creator, " + " COUNT(diagram_id) diagram_count " +
" FROM diagrams " + " GROUP BY diagram_creator) g " + "ON u.user_id = g.diagram_creator " + "ORDER BY NVL(g.diagram_count,0) DESC"; Vector<UserBean> v = new Vector<UserBean>(); Statement stat = null; ResultSet rs = null; try { stat = conn.createStatement(); rs = stat.executeQuery(sql); UserBean userBean = null; while(rs.next()) { userBean = new UserBean( rs.getString("USER_ID"), null, rs.getString("USER_FIRSTNAME"), rs.getString("USER_LASTNAME"), rs.getString("USER_EMAIL") ); userBean.setDiagramCount(rs.getInt("DIAGRAM_COUNT")); v.add(userBean); } return v; } finally { OracleDAOFactory.freeResources(stat, rs); } }
226
public UserBean getUser(String id) throws SQLException { Connection conn = OracleDAOFactory.createConnection(); Statement stat = conn.createStatement(); String sql = "SELECT u.*, " + " NVL(g.diagram_count,0) diagram_count " + "FROM " + "(SELECT * " + " FROM users u " + " WHERE user_id='" + id + "') u " + "LEFT JOIN " + "(SELECT diagram_creator, " + " COUNT(diagram_id) diagram_count " +
" FROM diagrams " + " WHERE diagram_creator='" + id + "' " + " GROUP BY diagram_creator) g " + "ON u.user_id = g.diagram_creator"; ResultSet rs = stat.executeQuery(sql); if (!rs.next()) return null; UserBean userBean = new UserBean( rs.getString("USER_ID"), null, rs.getString("USER_FIRSTNAME"), rs.getString("USER_LASTNAME"), rs.getString("USER_EMAIL") ); userBean.setDiagramCount(rs.getInt("DIAGRAM_COUNT")); return userBean; }
227
public boolean login(TinyUserBean login) throws SQLException { Connection conn = OracleDAOFactory.createConnection(); String sql = "SELECT user_id, user_password FROM users WHERE user_id='" + login.getId() + "'"; String id = null; String password = null; Statement stat = null; ResultSet rs = null; try { stat = conn.createStatement(); rs = stat.executeQuery(sql); if (!rs.next()) return false; id = rs.getString("USER_ID"); password = rs.getString("USER_PASSWORD"); } finally { OracleDAOFactory.freeResources(stat, rs); } if (!login.getId().equals(id) || !login.getPassword().equals(password)) { return false; } return true; } }
228

5.2.3.1. GraphMLFile.java
package abstractminds.model.graphml;
import java.io.File; import java.io.FileNotFoundException; import java.io.FileReader; import java.io.FilenameFilter; import java.io.InputStream; import java.io.InputStreamReader; import java.io.PrintStream; import java.io.Reader; import java.util.ArrayList; import java.util.List;
import javax.xml.parsers.SAXParser; import javax.xml.parsers.SAXParserFactory;
import org.xml.sax.InputSource;
import edu.uci.ics.jung.exceptions.FatalException; import edu.uci.ics.jung.graph.Graph; import edu.uci.ics.jung.io.GraphFile;
public class GraphMLFile implements GraphFile { private GraphMLDefaultHandler mDefaultHandler; protected boolean directed; protected boolean undirected;
public GraphMLFile() { mDefaultHandler = new GraphMLDefaultHandler(); }
public GraphMLFile(GraphMLDefaultHandler defaultHandler) { mDefaultHandler = defaultHandler; }
public Graph load(InputStream stream) { return load( new InputStreamReader(stream) ); }
229
public Graph load( String filename ) { File file = new File(filename); FileReader fileReader = null; try { fileReader = new FileReader(file); } catch (FileNotFoundException e) { throw new FatalException("Error loading graphml file", e); } return load( fileReader ); }
public Graph load( Reader reader ) { SAXParserFactory spf = SAXParserFactory.newInstance(); try { spf.setFeature("http://xml.org/sax/features/validation", true); spf.setFeature( "http://apache.org/xml/features/validation/schema",true); spf.setFeature( "http://apache.org/xml/features/validation/dynamic",true); spf.setNamespaceAware(true); spf.setValidating(true); SAXParser parser = spf.newSAXParser(); parser.parse( new InputSource( reader ), } catch (Exception e) { throw new FatalException("Error loading graphml file: " + e); } return mDefaultHandler.getGraph(); } mDefaultHandler );
public List<Graph> loadGraphCollection( String dirName, FilenameFilter filter){ File dir = new File(dirName); if (!dir.isDirectory()) { throw new FatalException("Parameter dirName must be a directory"); } String[] files = dir.list(filter); List<Graph> graphCollection = new ArrayList<Graph>(); for (int i = 0; i < files.length; i++) { String currentFile = dirName + File.separatorChar + files[i]; GraphMLFile graphmlFile = new GraphMLFile(mDefaultHandler); graphCollection.add(graphmlFile.load(currentFile)); } return graphCollection; }
230
public GraphMLErrorHandler getErrorHandler() { return mDefaultHandler.getErrorHandler(); }
public void setGraphMLFileHandler(GraphMLDefaultHandler fileHandler) { mDefaultHandler = fileHandler; }
public void save(Graph g, String filename) { new GraphMLSerializer().save(g, filename);
public void save(Graph g, PrintStream out) { new GraphMLSerializer().save(g, out); } }
231
5.2.3.2. GraphMLDefaultHandler.java
import java.util.HashMap; import java.util.Iterator; import java.util.Map; import java.util.Stack; import java.util.Vector;
import org.xml.sax.Attributes; import org.xml.sax.SAXException; import org.xml.sax.SAXParseException; import org.xml.sax.helpers.DefaultHandler;
import abstractminds.model.graphml.element.GraphMLElement; import abstractminds.model.graphml.element.GraphMLTextData; import edu.uci.ics.jung.exceptions.FatalException; import edu.uci.ics.jung.graph.ArchetypeVertex; import edu.uci.ics.jung.graph.Edge; import edu.uci.ics.jung.graph.Graph; import edu.uci.ics.jung.graph.Vertex; import edu.uci.ics.jung.graph.decorators.StringLabeller; import edu.uci.ics.jung.graph.impl.DirectedSparseEdge; import edu.uci.ics.jung.graph.impl.SparseGraph; import edu.uci.ics.jung.graph.impl.SparseVertex; import edu.uci.ics.jung.graph.impl.UndirectedSparseEdge; import edu.uci.ics.jung.utils.UserData; import edu.uci.ics.jung.utils.UserDataContainer;
public class GraphMLDefaultHandler extends DefaultHandler { private Graph mGraph; private Stack<UserDataContainer> elementsStack; private HashMap<String, GraphMLElement> keysMap; private GraphMLErrorHandler errorHandler; private StringLabeller mLabeller; private boolean default_directed;
public GraphMLDefaultHandler() { elementsStack = new Stack<UserDataContainer>(); keysMap = new HashMap<String, GraphMLElement>(); errorHandler = new GraphMLErrorHandler(); }
232
public GraphMLErrorHandler getErrorHandler() { return errorHandler; }
public void warning(SAXParseException e) throws SAXException { errorHandler.warning(e); }
public void error(SAXParseException e) throws SAXException { errorHandler.error(e); }
public void fatalError(SAXParseException e) throws SAXException { errorHandler.fatalError(e); }
public void startElement( String namespaceURI, String lName, // local name String qName, // qualified name Attributes attrs) throws SAXException {
Map<String, String> attributeMap = getAttributeMap(attrs); if (qName.toLowerCase().equals("node")) { elementsStack.push(createVertex(attributeMap));
} else if (qName.toLowerCase().equals("edge")) { elementsStack.push(createEdge(attributeMap));
} else if (qName.toLowerCase().equals("data")) { elementsStack.push(createNestedElement(qName, attributeMap));
} else if (qName.toLowerCase().equals("key")) { elementsStack.push(createKey(attributeMap));
} else if (qName.toLowerCase().equals("graph")) { elementsStack.push(createGraph(attributeMap));
} else { elementsStack.push(createNestedElement(qName, attributeMap)); } }
233
public void characters(char[] ch, int start, int length) { if (elementsStack.empty()) return; String aux = String.copyValueOf(ch, start, length).trim(); if (aux.length() > 0) { createTextData(aux); } }
public void endElement( String namespaceURI, String lName, // local name String qName // qualified name ) throws SAXException {
if (!qName.toLowerCase().equals("graph") && !qName.toLowerCase().equals("graphml")) { elementsStack.pop(); } }
protected Graph getGraph() { return mGraph; }
protected StringLabeller getLabeller() { return mLabeller; }
234
protected Graph createGraph(Map<String, String> attributeMap) { mGraph = new SparseGraph(); mGraph.setUserDatum("keysMap", keysMap, UserData.SHARED);
String edgeDefaultType = (String) attributeMap.get("edgedefault"); if (edgeDefaultType.equals("directed")) { default_directed = true; // mGraph = new DirectedSparseGraph(); } else if (edgeDefaultType.equals("undirected")) { default_directed = false; // mGraph = new UndirectedSparseGraph(); } else { throw new FatalException( "Error parsing graph. Edge default type not specified."); }
mLabeller = StringLabeller.getLabeller(mGraph);
setUserData(mGraph, attributeMap); return mGraph; }
protected ArchetypeVertex createVertex(Map<String, String> attributeMap) { if (mGraph == null) { throw new FatalException("Error parsing graph. " + "Graph element must be specified before node element."); }
ArchetypeVertex vertex = mGraph.addVertex(new SparseVertex()); String idString = (String) attributeMap.remove("id");
try { mLabeller.setLabel((Vertex) vertex,idString); } catch (StringLabeller.UniqueLabelException ule) { throw new FatalException("Ids must be unique");
setUserData(vertex, attributeMap); return vertex; }
235
protected Edge createEdge(Map<String, String> attributeMap) { if (mGraph == null) { throw new FatalException("Error parsing graph. " + "Graph element must be specified before edge element."); } String sourceId = (String) attributeMap.remove("source"); Vertex sourceVertex = mLabeller.getVertex(sourceId);
String targetId = (String) attributeMap.remove("target"); Vertex targetVertex = mLabeller.getVertex(targetId);
String direction = (String) attributeMap.remove("directed"); boolean directed; if (direction == null) { // use default_directed directed = default_directed; } else { // use specified direction if (direction.equals("true")) directed = true; else if (direction.equals("false")) directed = false; else throw new FatalException( "Error parsing graph: 'directed' tag has invalid value: " + direction); } Edge e; if (directed) e = mGraph.addEdge( new DirectedSparseEdge(sourceVertex, targetVertex)); else e = mGraph.addEdge( new UndirectedSparseEdge(sourceVertex, targetVertex));
setUserData(e, attributeMap); return e; }
236
protected GraphMLElement createKey(Map<String, String> attributeMap) { if (mGraph != null) { throw new FatalException("Error parsing graph. " + "Key elements must be specified before graph element."); }
GraphMLElement key = new GraphMLElement("key"); setUserData(key, attributeMap);
String keyId = (String) attributeMap.get("id"); keysMap.put(keyId, key);
return key; }
protected GraphMLElement createNestedElement( String qName, Map<String, String> attributeMap) {
if (elementsStack.size() == 0) { throw new FatalException( "Error parsing graph. Unespected element \"" + qName + "\"."); }
GraphMLElement element = new GraphMLElement(qName);
setUserData(element, attributeMap);
addNestedElement(element);
return element; }
private void createTextData(String textData) { UserDataContainer udc = elementsStack.peek(); // if different from graph, node or edge if (udc instanceof GraphMLElement) { addNestedElement(new GraphMLTextData(textData)); } }
237
private void setUserData( UserDataContainer udc, Map<String, String> attributeMap) {
for (Iterator<String> keyIt = attributeMap.keySet().iterator(); keyIt.hasNext(); ) { Object key = keyIt.next(); Object value = attributeMap.get(key); udc.setUserDatum(key, value, UserData.SHARED); } }
private void addNestedElement(GraphMLElement nestedElement) { Vector ne = (Vector) elementsStack.peek().getUserDatum("nestedElements"); if (ne == null) { ne = new Vector<GraphMLElement>(); elementsStack.peek() .setUserDatum("nestedElements", ne, UserData.SHARED); } ne.add(nestedElement); }
private Map<String, String> getAttributeMap(Attributes attrs) { Map<String, String> map = new HashMap<String, String>(); if (attrs != null) { for (int i = 0; i < attrs.getLength(); i++) { map.put(attrs.getQName(i), attrs.getValue(i)); } } return map; } }
238
5.2.3.3. GraphMLErrorHandler.java
import java.util.Vector;
import org.xml.sax.ErrorHandler; import org.xml.sax.SAXException; import org.xml.sax.SAXParseException;
public class GraphMLErrorHandler implements ErrorHandler { private long errorCount = 0; private long warnCount = 0;
private Vector<String> messages = new Vector<String>();
public long getErrorCount() { return errorCount; }
public long getWarningCount() { return warnCount; }
public Vector<String> getMessages(){ return messages; }
public void warning(SAXParseException e) { ++warnCount; messages.add("Warning " + getLineAndCol(e) + e.getMessage()); }
public void error(SAXParseException e) { ++errorCount; messages.add("Error " + getLineAndCol(e) + e.getMessage()); }
public void fatalError(SAXParseException e) throws SAXException { ++errorCount; messages.add("Fatal error " + getLineAndCol(e) + e.getMessage()); throw new SAXException(messages.lastElement()); }
239
private String getLineAndCol(SAXParseException e) { return " on line " + e.getLineNumber() + ", column " + e.getColumnNumber() + " >> "; } }
240
5.2.3.4. GraphMLSerializer.java
import java.io.FileOutputStream; import java.io.PrintStream; import java.util.HashMap; import java.util.Iterator; import java.util.Vector;
import abstractminds.model.graphml.element.GraphMLElement; import edu.uci.ics.jung.exceptions.FatalException; import edu.uci.ics.jung.graph.DirectedEdge; import edu.uci.ics.jung.graph.Edge; import edu.uci.ics.jung.graph.Graph; import edu.uci.ics.jung.graph.UndirectedEdge; import edu.uci.ics.jung.graph.Vertex; import edu.uci.ics.jung.graph.decorators.Indexer; import edu.uci.ics.jung.graph.decorators.StringLabeller; import edu.uci.ics.jung.utils.Pair; import edu.uci.ics.jung.utils.PredicateUtils; import edu.uci.ics.jung.utils.UserData; import edu.uci.ics.jung.utils.UserDataContainer;
public class GraphMLSerializer {
private boolean directed; private PrintStream out; private int level;
public static boolean invalidXMLData(String str) { if (str.indexOf("&") >= 0) return true; if (str.indexOf("<") >= 0) return true; if (str.indexOf(">") >= 0) return true; if (str.indexOf("\'") >= 0) return true; if (str.indexOf("\"") >= 0) return true; return false; }
241
public void save(Graph g, String filename) { try { out = new PrintStream(new FileOutputStream(filename, false)); } catch (Exception e) { throw new FatalException( "Could not open file \"" + filename + "\" for writing. " + e); } save(g, out); out.close(); }
public void save(Graph g, PrintStream out) { this.out = out; level = 0; out.println("<?xml version=\"1.0\" encoding=\"UTF-8\"?>"); out.println("<graphml xmlns=\"http://graphml.graphdrawing.org/xmlns\""); out.println(" out.print(" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"");
xsi:schemaLocation=\"");
out.println("http://graphml.graphdrawing.org/xmlns"); out.print(" ");
out.println("http://127.0.0.1:8080/dasdi/graphml.xsd"); out.print(" ");
out.println("http://graphml.graphdrawing.org/xmlns"); out.print(" ");
out.println("http://graphml.graphdrawing.org/xmlns/1.0/graphml.xsd\">");
HashMap keysMap = (HashMap) g.removeUserDatum("keysMap"); if (keysMap != null) { level--; saveNestedElements(keysMap.values().iterator()); level++; } directed = PredicateUtils.enforcesEdgeConstraint(g, Graph.DIRECTED_EDGE) || g.removeUserDatum("edgedefault").toString().equalsIgnoreCase("directed");
newLine(); out.print("<graph edgedefault=\"");
242
if (directed) out.print("directed\""); else out.print("undirected\""); if (!saveUserData(g)) out.print(">"); saveVerticesSection(g); saveEdgesSection(g); newLine(); out.print("</graph>"); newLine(); out.print("</graphml>"); }
private void saveVerticesSection(Graph g) { level++; int numVertices = g.getVertices().size(); Indexer indexer = Indexer.getIndexer(g); for (int i = 0; i < numVertices; i++) { newLine(); Vertex v = (Vertex) indexer.getVertex(i); String vId = StringLabeller.getLabeller(g).getLabel(v); out.print("<node id=\"" + vId + "\"");
if (saveUserData(v)) { out.print("</node>"); } else { out.print("/>"); } } level--; }
243
private void saveEdgesSection(Graph g) { level++; for (Iterator edgeIterator = g.getEdges().iterator(); edgeIterator.hasNext();) newLine(); Edge e = (Edge) edgeIterator.next(); Pair p = e.getEndpoints(); Vertex src = (Vertex) p.getFirst(); Vertex dest = (Vertex) p.getSecond(); String srcId = StringLabeller.getLabeller(g).getLabel(src); out.print("<edge source=\"" + srcId + "\" "); String destId = StringLabeller.getLabeller(g).getLabel(dest); out.print("target=\"" + destId + "\""); {
// only tag the edges that don't match the default if (directed) { if (e instanceof UndirectedEdge) out.print(" directed=\"false\""); } else // undirected if (e instanceof DirectedEdge) out.print(" directed=\"true\"");
if (saveUserData(e)) { out.print("</edge>"); } else { out.print("/>"); } } level--; }
244
private void saveNestedElements(Iterator<GraphMLElement> iterator) { level++; boolean data = false; GraphMLElement element = null; for (; iterator.hasNext(); ) { element = iterator.next(); String qName = element.getQName(); if (qName == null) { // textData out.print(element); } else { data = true; newLine(); out.print("<" + qName); if (saveUserData(element)) { out.print("</" + qName + ">"); } else { out.print("/>"); } } } level--; if (data) newLine(); }
private boolean saveUserData(UserDataContainer udc) { Vector<GraphMLElement> elements = new Vector<GraphMLElement>();
for (Iterator udki = udc.getUserDatumKeyIterator(); udki.hasNext(); ) { Object key_obj = udki.next(); if (udc.getUserDatumCopyAction(key_obj) == UserData.REMOVE) continue; String key = key_obj.toString(); if (invalidXMLData(key)) continue; Object o = udc.getUserDatum(key); if (o == null) continue; if (key == "nestedElements") { elements = (Vector) o; } else { String datum = o.toString(); if (invalidXMLData(datum)) continue; out.print(" " + key + "=\"" + datum + "\""); } }
245
if (elements.size() > 0) { out.print(">"); saveNestedElements(elements.iterator()); return true; } return false; }
private void newLine() { out.println(); if (level < 0) return; else if (level < TABS.length) out.print(TABS[level]);
else out.print(TABS[TABS.length - 1]); }
private static final String[] TABS = { "", " " " " " " " " }; } ", ", ", ", ", ", ", "
246

5.2.4.1. JSONSerializer.java
package abstractminds.common;
import java.util.Iterator; import java.util.Vector;
import abstractminds.model.graphml.element.GraphMLElement; import edu.uci.ics.jung.graph.Graph; import edu.uci.ics.jung.graph.Vertex; import edu.uci.ics.jung.graph.decorators.Indexer; import edu.uci.ics.jung.graph.decorators.StringLabeller; import edu.uci.ics.jung.utils.PredicateUtils; import edu.uci.ics.jung.utils.UserDataContainer;
public class JSONSerializer {
private Graph g; private boolean directed; private StringBuffer buffer;
public String parseGraph(Graph g) { this.g = g;
directed = PredicateUtils.enforcesEdgeConstraint(g, Graph.DIRECTED_EDGE) || g.removeUserDatum("edgedefault").toString().equalsIgnoreCase("directed");
buffer = new StringBuffer("{nodes:["); parseVertices(); buffer.append("],edges:["); parseEdges(); buffer.append("]}"); return buffer.toString(); }
247
private void parseVertices() { int numVertices = g.getVertices().size(); Indexer indexer = Indexer.getIndexer(g); for (int i = 0;;) { Vertex v = (Vertex) indexer.getVertex(i); String vId = StringLabeller.getLabeller(g).getLabel(v); buffer.append("{nodeId:\""); buffer.append(vId); buffer.append("\",shapes:["); parseShapes(v); buffer.append("],matrix:null}"); if (++i < numVertices) buffer.append(','); else break; } }
private void parseShapes(Vertex v) { Vector<GraphMLElement> data = (Vector<GraphMLElement>) v.getUserDatum("nestedElements"); if (data.size() == 1 && data.lastElement().getQName().equalsIgnoreCase("data")) { Vector<GraphMLElement> shapes = (Vector<GraphMLElement>) data.lastElement().getUserDatum("nestedElements"); for (int i = 0;;) { GraphMLElement currentShape = shapes.get(i); Vector<GraphMLElement> properties = (Vector<GraphMLElement>) currentShape.getUserDatum("nestedElements"); buffer.append("{shapeId:\""); buffer.append(currentShape.getUserDatum("shapeId")); buffer.append("\",fill:"); buffer.append(currentShape.getUserDatum("fill")); buffer.append(",coords:{"); parseAttributes(properties.get(0)); /*buffer.append("},fill:{"); parseAttributes(properties.get(1));*/ buffer.append("},stroke:{"); parseAttributes(properties.get(1)); buffer.append("}}"); if (++i < shapes.size()) buffer.append(','); else break; } } }
248
private void parseAttributes(UserDataContainer udc) { for (Iterator udki = udc.getUserDatumKeyIterator();;) { String key = udki.next().toString(); Object o = udc.getUserDatum(key); if (o == null) continue; buffer.append(key); buffer.append(':'); if(key.equalsIgnoreCase("type")) { buffer.append('\"'); buffer.append(o.toString()); buffer.append('\"'); } else { buffer.append(o.toString()); } if (udki.hasNext()) buffer.append(','); else break; } } }
249
5.2.4.2. Constants.java
package abstractminds.common;
public abstract class Constants {
// ATRIBUTTES
public static final String ID = "id";
public static final String PASSWORD = "password";
public static final String FIRST_NAME = "firstName";
public static final String LAST_NAME = "lastName";
public static final String EMAIL = "email";
public static final String LOGIN = "login";
public static final String LOGIN_COUNTER = "loginCounter";
public static final String USER_ID = "userId";
public final static String USER_BEAN = "userBean";
public final static String USERS_LIST = "usersList";
public static final String DIAGRAM_ID = "diagramId";
public static final String DIAGRAM_BEAN = "diagramBean";
public static final String DIAGRAM_PRIVILEGES = "diagramPrivileges";
public static final String DIAGRAMS_LIST = "diagramsList";
public static final String PRIVILEGE = "privilege";
public static final String NAME = "name";
public static final String DESCRIPTION = "description";
public static final String JSON = "JSON";
250
public final static String ERROR = "error";
public final static String EXCEPTION = "exception";
public final static String EXIT = "exit";
// FORWARDS
public static final String SUCCESS_FORWARD = "success";
public static final String GLOBAL_ERROR_FORWARD = "global_error";
public static final String BAD_LOGIN_FORWARD = "bad_login";
public static final String NOT_FOUND_FORWARD = "not_found";
public static final String PARSE_ERROR_FORWARD = "parse_error";
public static final String AJAX_ERROR_FORWARD = "ajax_error";
public static final String PRIVILEGES_FORWARD = "privileges";
public static final String DIAGRAMS_FORWARD = "diagrams";
251
5.2.4.3. Paquete common.entity
5.2.4.3.1. DiagramBean.java
package abstractminds.common.entity;
public class DiagramBean {
public final static byte DIAGRAM_PRIVILEGE_NONE = -1; public final static byte DIAGRAM_PRIVILEGE_VIEW = 0; public final static byte DIAGRAM_PRIVILEGE_COPY = 1; public final static byte DIAGRAM_PRIVILEGE_EDIT = 2; public final static byte DIAGRAM_PRIVILEGE_MAKE_VERSIONS = 3; public final static byte DIAGRAM_PRIVILEGE_TOTAL_CONTROL = 4; public final static byte DIAGRAM_PRIVILEGE_CREATOR = 5;
private String id; private String name; private String creator; private int version; private String description; private byte privilege; private String jsonObjects;
public DiagramBean( String id, String name, String creator, int version, String description, byte privilege) {
this.id = id; this.name = name; this.creator = creator; this.version = version; this.description = description; this.privilege = privilege; this.jsonObjects = "{}"; }
252
public DiagramBean(DiagramBean diagramBean) { this.id = diagramBean.id; this.name = diagramBean.name; this.creator = diagramBean.creator; this.version = diagramBean.version; this.description = diagramBean.description; this.privilege = diagramBean.privilege; this.jsonObjects = diagramBean.jsonObjects; }
public String getId() { return id; }
public void setId(String id) { this.id = id; }
public String getName() { return name; }
public void setName(String name) { this.name = name; }
public String getCreator() { return creator; }
public void setCreator(String creator) { this.creator = creator; }
public int getVersion() { return version; }
public void setVersion(int version) { this.version = version; }
253
public String getDescription() { return description; }
public void setDescription(String description) { this.description = description; }
public byte getPrivilege() { return privilege; }
public void setPrivilege(byte privilege) { this.privilege = privilege; }
public void setJsonObjects(String jsonObjects) { this.jsonObjects = jsonObjects; }
public String getJsonObjects() { return jsonObjects; } }
254
5.2.4.3.2. DiagramPrivilegeBean.java
public class DiagramPrivilegeBean {
private String diagramId; private String userId; private byte privilege;
public DiagramPrivilegeBean(String diagramId, String userId, byte privilege) { this.diagramId = diagramId; this.userId = userId; this.privilege = privilege; } public String getDiagramId() { return diagramId; } public void setDiagramId(String diagramId) { this.diagramId = diagramId; } public String getUserId() { return userId; } public void setUserId(String userId) { this.userId = userId; } public byte getPrivilege() { return privilege; } public void setPrivilege(byte privilege) { this.privilege = privilege; } }
255
5.2.4.3.3. DiagramChangeBean.java
public class DiagramChangeBean {
private String changeId; private String diagramId; private String userId; private String jsonRedo; private String jsonUndo;
public DiagramChangeBean( String changeId, String diagramId, String userId, String jsonRedo, String jsonUndo) {
this.changeId = changeId; this.diagramId = diagramId; this.userId = userId; this.jsonRedo = jsonRedo; this.jsonUndo = jsonUndo; }
public String getChangeId() { return changeId; }
public void setChangeId(String changeId) { this.changeId = changeId; }
public String getDiagramId() { return diagramId; }
public void setDiagramId(String diagramId) { this.diagramId = diagramId; }
256
public String getUserId() { return userId; }
public void setUserId(String userId) { this.userId = userId; }
public String getJsonRedo() { return jsonRedo; }
public void setJsonRedo(String jsonRedo) { this.jsonRedo = jsonRedo; }
public String getJsonUndo() { return jsonUndo; }
public void setJsonUndo(String jsonUndo) { this.jsonUndo = jsonUndo; }
257
5.2.4.3.4. TinyUserBean.java
public class TinyUserBean implements Comparable {
protected String id; protected String password;
public int compareTo(Object o) { return id.compareTo(((UserBean) o).id); }
public TinyUserBean(String id, String password) { this.id = id; this.password = password; }
public TinyUserBean(TinyUserBean tinyUserBean) { this.id = tinyUserBean.id; this.password = tinyUserBean.password; }
public String getId() { return id; } public void setId(String id) { this.id = id; } public String getPassword() { return password; } public void setPassword(String password) { this.password = password; }
public String getHashCode() { return (id); } }
258
5.2.4.3.5. UserBean.java
public class UserBean extends TinyUserBean {
private String firstName; private String lastName; private String email; private int diagramCount;
public UserBean(String id, String password, String firstName, String lastName, String email) { super(id, password); this.firstName = firstName; this.lastName = lastName; this.email = email; }
public UserBean(UserBean userBean) { super(userBean.id, userBean.password); firstName = userBean.firstName; lastName = userBean.lastName; email = userBean.email; }
public int getDiagramCount() { return diagramCount; }
public void setDiagramCount(int diagramCount) { this.diagramCount = diagramCount; }
public String getEmail() { return email; }
public void setEmail(String email) { this.email = email; }
259
public String getFirstName() { return firstName; }
public void setFirstName(String firstName) { this.firstName = firstName; }
public String getLastName() { return lastName; }
public void setLastName(String lastName) { this.lastName = lastName; } }
260

5.2.5.1. Paquete controller.filter
5.2.5.1.1. FilterLogin.java
package abstractminds.controller.filter;
import java.io.IOException;
import javax.servlet.FilterChain; import javax.servlet.FilterConfig; import javax.servlet.ServletException; import javax.servlet.ServletRequest; import javax.servlet.ServletResponse; import javax.servlet.http.HttpServletRequest;
import abstractminds.common.Constants;
public class LoginFilter implements javax.servlet.Filter {
public void init(FilterConfig filterConfig) throws ServletException {
public void destroy() {
public void doFilter( ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
try { if (request instanceof HttpServletRequest){ String id = (String) ((HttpServletRequest)request). getSession().getAttribute(Constants.LOGIN); System.out.println("LoginFilter: Quering session");
261
if (id == null) { System.out.println( "LoginFilter: Not logged, fowarding to login page..."); request.setAttribute(Constants.ERROR, Constants.ERROR); ((HttpServletRequest) request).getSession() .getServletContext().getContext("/AbstractMinds") .getRequestDispatcher("/Login.do").forward(request, response); return; } else { System.out.println("LoginFilter: Logged as " + id); } chain.doFilter(request, response); } } catch (Exception e) { e.printStackTrace(); System.out.println( "LoginFilter: " + e.getClass().getSimpleName() + " " + e.getMessage()); } } }
262
5.2.5.2. Paquete controller.action.diagram
5.2.5.2.1. AddDiagramAction.java
package abstractminds.controller.action.diagram;
import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse;
import org.apache.struts.action.*; import org.apache.struts.validator.DynaValidatorForm;
import abstractminds.common.Constants; import abstractminds.common.entity.DiagramBean; import abstractminds.model.ModelFacade;
public class AddDiagramAction extends Action { public ActionForward execute( ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) { try { DynaValidatorForm dynaForm = (DynaValidatorForm) form; String name = (String) dynaForm.get(Constants.NAME); String description = (String) dynaForm.get(Constants.DESCRIPTION); String creator_id = (String) request.getSession().getAttribute(Constants.LOGIN); DiagramBean diagram = new DiagramBean( null, name, creator_id, 0, description, DiagramBean.DIAGRAM_PRIVILEGE_CREATOR); new ModelFacade().addDiagram(diagram); request.getSession() .setAttribute(Constants.DIAGRAM_ID, diagram.getId()); System.out.println("AddDiagramAction:" + request.getSession().getAttribute(Constants.DIAGRAM_ID)); } catch(Exception e) { request.setAttribute(Constants.EXCEPTION, e); return mapping.findForward(Constants.GLOBAL_ERROR_FORWARD); } return mapping.findForward(Constants.SUCCESS_FORWARD); } }
263
5.2.5.2.2. ChangeDiagramPrivilege.java
import org.apache.struts.action.*;
import abstractminds.common.Constants; import abstractminds.common.entity.DiagramBean; import abstractminds.common.entity.DiagramPrivilegeBean; import abstractminds.model.ModelFacade;
public class ChangeDiagramPrivilegeAction extends Action { public ActionForward execute( ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) { try { String actor_id = (String) request.getSession().getAttribute(Constants.LOGIN); String user_id = request.getParameter(Constants.USER_ID); String diagram_id = request.getParameter(Constants.DIAGRAM_ID); byte privilege = Byte.parseByte(request.getParameter(Constants.PRIVILEGE)); new ModelFacade().changeDiagramPrivilege( actor_id, new DiagramPrivilegeBean(diagram_id, user_id, privilege) ); if (actor_id.equals(user_id) && privilege < DiagramBean.DIAGRAM_PRIVILEGE_TOTAL_CONTROL) { return mapping.findForward(Constants.DIAGRAMS_FORWARD); } else { // Fix for redirections (see QueryDiagramPrivilegesAction) request.getSession().setAttribute(Constants.USER_ID, user_id); request.getSession() .setAttribute(Constants.DIAGRAM_ID,diagram_id); return mapping.findForward(Constants.PRIVILEGES_FORWARD); } } catch(Exception e) { request.setAttribute(Constants.EXCEPTION, e); return mapping.findForward(Constants.GLOBAL_ERROR_FORWARD); } } }
264
5.2.5.2.3. CommitDiagramChangeAction.java
import org.apache.struts.action.Action; import org.apache.struts.action.ActionForm; import org.apache.struts.action.ActionForward; import org.apache.struts.action.ActionMapping;
import abstractminds.common.Constants; import abstractminds.common.entity.DiagramChangeBean; import abstractminds.model.ModelFacade; import abstractminds.model.graphml.element.GraphMLMatrix;
public class CommitDiagramChangeAction extends Action {
public ActionForward execute( ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) {
try { String userId = (String) request.getSession().getAttribute(Constants.LOGIN);
if (userId == null) throw new Exception("Not logged");
String diagramId = (String) request.getParameter(Constants.DIAGRAM_ID);
String jsonRedo = null; String jsonUndo = null;
265
if (request.getParameter("newNode") != null) { jsonRedo = request.getParameter("newNode").replaceAll(" ", ""); } else if (request.getParameter("xx") != null) { GraphMLMatrix matrix = new GraphMLMatrix( Float.parseFloat(request.getParameter("xx")), Float.parseFloat(request.getParameter("xy")), Float.parseFloat(request.getParameter("yx")), Float.parseFloat(request.getParameter("yy")), Float.parseFloat(request.getParameter("dx")), Float.parseFloat(request.getParameter("dy")), request.getParameter("nodeId") ); jsonRedo = matrix.toJSON(); } new ModelFacade().commitDiagramChange( new DiagramChangeBean( null, diagramId, userId, jsonRedo, jsonUndo) );
String resp = "{ack:" + request.getParameter("commitId") + "}"; request.setAttribute(Constants.JSON, resp); } catch(Exception e) { request.setAttribute(Constants.ERROR, e); return mapping.findForward(Constants.AJAX_ERROR_FORWARD); } return mapping.findForward(Constants.SUCCESS_FORWARD); } }
266
5.2.5.2.4. DestroyDiagramAction.java
import abstractminds.common.Constants; import abstractminds.model.ModelFacade;
public class DestroyDiagramAction extends Action { public ActionForward execute( ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) {
try { String user_id = (String) request.getSession().getAttribute(Constants.LOGIN); String diagram_id = request.getParameter(Constants.DIAGRAM_ID); new ModelFacade().destroyDiagram(user_id, diagram_id); } catch(Exception e) { request.setAttribute(Constants.EXCEPTION, e); return mapping.findForward(Constants.GLOBAL_ERROR_FORWARD); } return mapping.findForward(Constants.SUCCESS_FORWARD); } }
267
5.2.5.2.5. LoadDiagramAction.java
import abstractminds.common.Constants; import abstractminds.common.entity.DiagramBean; import abstractminds.model.ModelFacade;
public class LoadDiagramAction extends Action { public ActionForward execute( ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) {
try{ String actorId = (String) request.getSession().getAttribute(Constants.LOGIN); DiagramBean diagram = new ModelFacade().loadDiagram( actorId, request.getParameter("diagramId")); request.setAttribute(Constants.DIAGRAM_BEAN, diagram); } catch(Exception e) { request.setAttribute(Constants.EXCEPTION, e); return mapping.findForward(Constants.GLOBAL_ERROR_FORWARD); } return mapping.findForward(Constants.SUCCESS_FORWARD); }
268
5.2.5.2.6. QueryAllDiagrams.java
import java.util.Collection;
public class QueryAllDiagramsAction extends Action { public ActionForward execute( ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) {
try { String user_id = (String) request.getSession().getAttribute(Constants.LOGIN); Collection<?> diagrams = new ModelFacade().getAllDiagrams(user_id); if (diagrams != null && diagrams.size() > 0) { request.setAttribute(Constants.DIAGRAMS_LIST, diagrams); } } catch(Exception e) { request.setAttribute(Constants.EXCEPTION, e); return mapping.findForward(Constants.GLOBAL_ERROR_FORWARD); } return mapping.findForward(Constants.SUCCESS_FORWARD); } }
269
5.2.5.2.7. QueryDiagramAction.java
public class QueryDiagramAction extends Action {
try { String user_id = (String) request.getSession().getAttribute(Constants.LOGIN); String diagram_id = request.getParameter(Constants.DIAGRAM_ID); request.setAttribute( Constants.DIAGRAM_BEAN, new ModelFacade().getDiagram(user_id, diagram_id)); } catch(Exception e) { request.setAttribute(Constants.EXCEPTION, e); return mapping.findForward(Constants.GLOBAL_ERROR_FORWARD); } return mapping.findForward(Constants.SUCCESS_FORWARD); } }
270
5.2.5.2.8. QueryDiagramChangesAction.java
import abstractminds.common.Constants; import abstractminds.common.entity.DiagramChangeBean; import abstractminds.model.ModelFacade;
public class QueryDiagramChangesAction extends Action {
try { String actorId = (String) request.getSession().getAttribute(Constants.LOGIN); if (actorId == null) throw new Exception("Not logged");
String diagramId = (String) request.getParameter(Constants.DIAGRAM_ID);
String changeId = request.getParameter("changeId");
String json = new ModelFacade().queryDiagramChanges( new DiagramChangeBean( changeId, diagramId, actorId,null, null)); request.setAttribute(Constants.JSON, json);
} catch(Exception e) { request.setAttribute(Constants.ERROR, e); return mapping.findForward(Constants.AJAX_ERROR_FORWARD); } return mapping.findForward(Constants.SUCCESS_FORWARD); } }
271
5.2.5.2.9. QueryDiagramPrivilegesAction.java
public class QueryDiagramPrivilegesAction extends Action { public ActionForward execute( ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) { try { String actor_id = (String) request.getSession().getAttribute(Constants.LOGIN); String diagram_id = request.getParameter(Constants.DIAGRAM_ID); // Fix for redirections (see ChangeDiagramPrivilegeAction) if (diagram_id == null) { diagram_id = (String) request.getSession().getAttribute(Constants.DIAGRAM_ID); request.setAttribute( Constants.USER_ID, (String) request.getSession().getAttribute(Constants.USER_ID) ); request.getSession().removeAttribute(Constants.USER_ID); } request.setAttribute( Constants.DIAGRAM_PRIVILEGES, new ModelFacade().getDiagramPrivileges(actor_id, diagram_id)); } catch(Exception e) { request.setAttribute(Constants.EXCEPTION, e); return mapping.findForward(Constants.GLOBAL_ERROR_FORWARD); } return mapping.findForward(Constants.SUCCESS_FORWARD); } }
272
5.2.5.3. Paquete controller.action.user
5.2.5.3.1. AddUserAction.java
package abstractminds.controller.action.user;
import org.apache.struts.action.Action; import org.apache.struts.action.ActionForm; import org.apache.struts.action.ActionForward; import org.apache.struts.action.ActionMapping; import org.apache.struts.validator.DynaValidatorForm;
import abstractminds.common.Constants; import abstractminds.common.entity.UserBean; import abstractminds.model.ModelFacade;
public class AddUserAction extends Action {
try { DynaValidatorForm dynaForm = (DynaValidatorForm) form; String id = (String)dynaForm.get(Constants.ID); String pwd = (String)dynaForm.get(Constants.PASSWORD); String firstName = (String)dynaForm.get(Constants.FIRST_NAME); String lastName = (String)dynaForm.get(Constants.LAST_NAME); String email = (String)dynaForm.get(Constants.EMAIL); UserBean user = new UserBean(id, pwd, firstName, lastName, email); new ModelFacade().addUser(user); request.getSession().setAttribute(Constants.LOGIN, user.getId()); } catch(Exception e) { request.setAttribute(Constants.EXCEPTION, e); return mapping.findForward(Constants.GLOBAL_ERROR_FORWARD); } return mapping.findForward(Constants.SUCCESS_FORWARD); } }
273
5.2.5.3.2. ExitAction.java
import abstractminds.common.entity.TinyUserBean;
public class ExitAction extends Action {
try { String id = (String) request.getSession().getAttribute(Constants.LOGIN); if (id != null) { new ModelFacade().exit(id); request.getSession().invalidate(); } request.setAttribute(Constants.EXIT, Constants.EXIT); return mapping.findForward(Constants.SUCCESS_FORWARD); } catch(Exception e) { request.setAttribute(Constants.EXCEPTION, e); return mapping.findForward(Constants.GLOBAL_ERROR_FORWARD); } } }
274
5.2.5.3.3. LoginAction.java
import org.apache.struts.action.Action; import org.apache.struts.action.ActionForm; import org.apache.struts.action.ActionForward; import org.apache.struts.action.ActionMapping; import org.apache.struts.validator.DynaValidatorForm;
import abstractminds.common.Constants; import abstractminds.common.entity.TinyUserBean; import abstractminds.model.ModelFacade;
public class LoginAction extends Action {
try { DynaValidatorForm dynaForm = (DynaValidatorForm) form; TinyUserBean user = new TinyUserBean( (String)dynaForm.get("id"), (String)dynaForm.get("password")); if (new ModelFacade().login(user)) { request.getSession() .setAttribute(Constants.LOGIN, user.getId()); return mapping.findForward(Constants.SUCCESS_FORWARD); } request.setAttribute(Constants.ERROR, Constants.ERROR); return mapping.findForward(Constants.BAD_LOGIN_FORWARD); } catch(Exception e) { request.setAttribute(Constants.EXCEPTION, e); return mapping.findForward(Constants.GLOBAL_ERROR_FORWARD); } } }
275
5.2.5.3.4. LoginCounterAction.java
import abstractminds.common.Constants;
public class LoginCounterAction extends Action {
try { Integer loginCounter = (Integer) request.getSession().getServletContext() .getAttribute(Constants.LOGIN_COUNTER);
if (loginCounter == null) { loginCounter = new Integer(1); } else { loginCounter = new Integer(loginCounter.intValue() + 1); } request.getSession().getServletContext() .setAttribute(Constants.LOGIN_COUNTER, loginCounter); System.out.println("Successful logins: " + loginCounter); return mapping.findForward(Constants.SUCCESS_FORWARD); } catch(Exception e) { request.setAttribute(Constants.EXCEPTION, e); return mapping.findForward(Constants.GLOBAL_ERROR_FORWARD); } } }
276
5.2.5.3.5. QueryAllUsersAction.java
public class QueryAllUsersAction extends Action {
try { request.setAttribute( Constants.USERS_LIST, new ModelFacade().getAllUsers()); } catch(Exception e) { request.setAttribute(Constants.EXCEPTION, e); return mapping.findForward(Constants.GLOBAL_ERROR_FORWARD); } return mapping.findForward(Constants.SUCCESS_FORWARD); } }
277
5.2.5.3.6. QueryUserAction.java
public class QueryUserAction extends Action {
try { String id = request.getParameter(Constants.ID); if (id == null) { id = (String) request.getSession() .getAttribute(Constants.LOGIN); } request.setAttribute( Constants.USER_BEAN, new ModelFacade().getUser(id)); } catch(Exception e) { request.setAttribute(Constants.EXCEPTION, e); return mapping.findForward(Constants.GLOBAL_ERROR_FORWARD); } return mapping.findForward(Constants.SUCCESS_FORWARD); } }
278
5.2.6. Paquete view

5.2.6.1. DiagramEditor.js
if(!dojo._hasResource["diagram.DiagramEditor"]){ dojo._hasResource["diagram.DiagramEditor"] = true; dojo.provide("diagram.DiagramEditor");
dojo.require("dojox.gfx"); dojo.require("diagram.defaults"); dojo.require("diagram.Node");
diagram.editor = null;
diagram.DiagramEditor = function(jsonDiagram) {
diagram.editor = this;
// destroy loading dialog close button dijit.byId("loadingDialog").closeButtonNode.className = null;
this._setLoading(true);
this.surfaceContainer = dojo.byId("diagramContainer"); this.surfaceBackground = dojo.byId("diagramBackground"); this.mouseLabel = dojo.byId("mouseLabel");
// virtual editing surface dimensions this.surfaceTop = 7; this.surfaceLeft = 7; this.surfaceWidth = 600; this.surfaceHeight = 400;
dojo.style("diagramContainer", "background", "#DDDDDD"); dojo.style("diagramContainer", "overflow", "hidden"); dojo.style("diagramBackground", "width", (!dojo.isIE)? this.surfaceWidth : this.surfaceWidth + 1); dojo.style("diagramBackground", "height", (!dojo.isIE)? this.surfaceHeight : this.surfaceHeight + 1); dojo.style("diagramBackground", "position", "absolute"); dojo.style("diagramBackground", "top", (!dojo.isIE)? this.surfaceTop - 1 : this.surfaceTop );
279
dojo.style("diagramBackground", "left", (!dojo.isIE)? this.surfaceLeft - 1 : this.surfaceLeft); dojo.style("diagramBackground", "background", "#fff url(\"../css/img/grid.png\") repeat top left"); dojo.style("diagramBackground", "border", "1px solid black"); dojo.style("diagramBackground", "overflow", "hidden");
dojo.style("mouseLabel", "background", "#EEEEEE"); dojo.style("mouseLabel", "borderTop", "1px solid #AAAAAA");
this.surface = null; this.mainGroup = null;
this._createSurface();
this.panMode = false; this.zoomFactor = 1; // no zoom this.nodes = []; this.nodeCounter = 0; this.currentNode = null; this.initialPosition = {x: 0, y: 0}; this.lastPosition = {x: 0, y: 0}; this.lastChange = 0; this.commitCount = 0; this.userId = jsonDiagram.userId; this.diagramId = jsonDiagram.diagramId; this._createDiagram(jsonDiagram.objects);
this.intervalQuery = null; this.queryAllChanges();
// basic mouse handlers dojo.connect(this.surfaceContainer, "onmousedown", this, "onMouseDown"); dojo.connect(this.surfaceContainer, "onmousemove", this, "onMouseMove"); dojo.connect(this.surfaceContainer, "onmouseup", this, "onMouseUp");
// cancel text selection and text dragging dojo.connect(this.surfaceContainer, "ondragstart", dojo, "stopEvent");
dojo.connect(this.surfaceContainer, "onselectstart", dojo, "stopEvent"); };
280
/////////////////////////////////////////////////////////////////////////////// /// // Common methods for 'diagram.DiagramEditor' /////////////////////////////////////////////////////////////////////////////// /// dojo.extend(diagram.DiagramEditor, { _applyChanges: function(changeId, changes){ this.lastChange = changeId; console.debug(this.lastChange); for(var i=0;i<changes.length;++i){ if("shapes" in changes[i]){ this._createNode(changes[i]); }else if("matrix" in changes[i]){ this.nodes[changes[i].nodeId].gfx .setTransform(changes[i].matrix); } } }, _getNodeUniqueId: function(){ var newUniqueId = "n" + (this.nodeCounter++) + this.userId; while(this.nodes[newUniqueId]){ newUniqueId = "n" + (this.nodeCounter++) + this.userId; } return newUniqueId; }, _setLoading:function(loading){ if (loading){ dijit.byId("loadingDialog").show(); }else{ dijit.byId("loadingDialog").hide(); } this.loading = loading; }, _relativePosition: function(p){ var coords = dojo._abs(this.surfaceContainer, true); return { x: (p.x - coords.x - this.surfaceLeft) / this.zoomFactor, y: (p.y - coords.y - this.surfaceTop) / this.zoomFactor }; }, _setLastPosition: function(p){ this.lastPosition = this._relativePosition(p); },
281
_setMouseLabel: function(p){ if(!p){ this.mouseLabel.innerHTML = " "; }else{ this.mouseLabel.innerHTML = " x: " + parseInt(p.x) + ", y: " + parseInt(p.y); } }, _addNode: function(node){ if (!node.nodeId){ return; } this.nodes[node.nodeId] = node; }, _getEventNode: function(event) { var id = event.target.getAttribute('nodeId'); return (id ? this.nodes[id] : null); }, _createSurface: function(){ var width = "100%"; var height = "100%"; if (dojo.isIE){ // fix IE bug that escales figures if surface is 100% x 100%, width = screen.width; // max screen width
height = screen.height; // max screen height } // this surface covers all the space withing ContentPane this.surface = dojox.gfx.createSurface( this.surfaceContainer, width , height); // this is a virtual editing surface for pan mode this.mainGroup = this.surface.createGroup(); // places every shape on diagram this.mainGroup.applyTransform( {dx: this.surfaceLeft, dy: this.surfaceTop}); // place surface to begin on top left dojo.style(this.surface.getEventSource(), "position", "absolute"); dojo.style(this.surface.getEventSource(), "top", 0); dojo.style(this.surface.getEventSource(), "left", 0); },
282
_createDiagram: function(json){ var i = 0; try{ if("nodes" in json){ for(;i<json.nodes.length;++i){ this._createNode(json.nodes[i]); } } if("edges" in json){ // TODO console.debug("TODO: edges"); } }catch(e){ console.debug(e); } }, _createNode: function(node){ if (!node.nodeId){ node.nodeId = this._getNodeUniqueId(); } this._addNode( new diagram.Node( this.mainGroup, node.nodeId, node.shapes, node.matrix) ); } } );
dojo.extend(diagram.DiagramEditor, { createNode: function(node){ this._createNode(node); this.commitChange({newNode: dojo.toJson(node)}); } } );
283
/////////////////////////////////////////////////////////////////////////////// /// // Mouse interaction events for 'diagram.DiagramEditor' /////////////////////////////////////////////////////////////////////////////// ///
dojo.extend(diagram.DiagramEditor, {
onMouseDown: function(event){ if(this.currentNode || this.panMode) {return;} this._setLastPosition({ x: event.pageX, y: event.pageY }); this.initialPosition = { x: this.lastPosition.x, y: this.lastPosition.y }; var node = this._getEventNode(event); if (node) { this.panMode = false; this.currentNode = node; } else { this.currentNode = null; this.panMode = true; } dojo.stopEvent(event); },
284
onMouseMove: function(event){ var position = { x: event.pageX , y: event.pageY }; var relative = this._relativePosition(position);
if (relative.x < 0 || relative.x > this.surfaceWidth / this.zoomFactor || relative.y < 0 || relative.y > this.surfaceHeight / this.zoomFactor){ this._setMouseLabel(null); this.onMouseUp(event); dojo.stopEvent(event); return; }
this._setMouseLabel(relative);
var transform = { dx: relative.x - this.lastPosition.x, dy: relative.y - this.lastPosition.y };
if(this.currentNode) { this.currentNode.gfx.applyTransform(transform); } else if (this.panMode) { this.mainGroup.applyTransform(transform); this.surfaceTop += transform.dy * this.zoomFactor; this.surfaceLeft += transform.dx * this.zoomFactor; dojo.style(this.surfaceBackground, "top", (!dojo.isIE)? this.surfaceTop - 1 : this.surfaceTop); dojo.style(this.surfaceBackground, "left", (!dojo.isIE)? this.surfaceLeft - 1 : this.surfaceLeft); } this._setLastPosition(position); dojo.stopEvent(event); },
285
onMouseUp: function(event){ var aux = null; if(this.currentNode){ aux = {nodeId: this.currentNode.nodeId}; for (var i in this.currentNode.gfx.matrix) { aux[i] = this.currentNode.gfx.matrix[i]; } this.currentNode = null; this.commitChange(aux); } else if (this.panMode) { this.panMode = false; } dojo.stopEvent(event); } } );
/////////////////////////////////////////////////////////////////////////////// /// // Zoom in and out for 'diagram.DiagramEditor' /////////////////////////////////////////////////////////////////////////////// /// dojo.extend(diagram.DiagramEditor, { zoomIn: function(){ this.zoomFactor *= 2; this.surfaceWidth *= 2; this.surfaceHeight *= 2; this.zoom(dojox.gfx.matrix.scale(2)); }, zoomOut: function(){ this.zoomFactor /= 2; this.surfaceWidth /= 2; this.surfaceHeight /= 2; this.zoom(dojox.gfx.matrix.scale(0.5)); }, zoom: function(matrix){ dojo.style("diagramBackground", "width", this.surfaceWidth); dojo.style("diagramBackground", "height", this.surfaceHeight); this.mainGroup.applyTransform(matrix); } } );
286
/////////////////////////////////////////////////////////////////////////////// /// // XHR requests and handles for 'diagram.DiagramEditor' /////////////////////////////////////////////////////////////////////////////// ///
dojo.extend(diagram.DiagramEditor, {
queryAllChanges: function(){ if (this.intervalQuery) { clearInterval(this.intervalQuery); } try { this._setLoading(true); dojo.byId("commitLabel").innerHTML = "Commits: " + (++this.commitCount); dojo.xhrPost( { url: "../ajax/QueryDiagramChangesAction.do", handleAs: "text", timeout: 100000, content: { diagramId: diagram.editor.diagramId, changeId: diagram.editor.lastChange }, handle: function(response, ioArgs){ diagram.editor.handleFirstXhr(response, ioArgs); } }); } catch (e) { console.debug(e); this._setLoading(false); } },
287
queryChanges: function(){ try { dojo.byId("commitLabel").innerHTML = "Commits: " + (++diagram.editor.commitCount); dojo.xhrPost( { url: "../ajax/QueryDiagramChangesAction.do", handleAs: "text", timeout: 5000, content: { diagramId: diagram.editor.diagramId, changeId: diagram.editor.lastChange }, handle: function(response, ioArgs){ diagram.editor.handleXhr(response, ioArgs); } }); } catch (e) { console.debug(e); } }, commitChange: function(request){ request.diagramId = diagram.editor.diagramId; try { dojo.byId("commitLabel").innerHTML = "Commits: " + (++diagram.editor.commitCount); dojo.xhrPost( { url: "../ajax/CommitDiagramChangeAction.do", handleAs: "text", timeout: 5000, content: request, handle: function(response, ioArgs){ diagram.editor.handleXhr(response, ioArgs); } }); } catch (e) { console.debug(e); } },
288
handleFirstXhr: function(response, ioArgs){ this.handleXhr(response, ioArgs); this._setLoading(false); // simulate live conection with server this.intervalQuery = setInterval(this.queryChanges, 5000); }, handleXhr: function(response, ioArgs){ if(response instanceof Error){ if(response.dojoType == "cancel"){ this.handleXhrCancel(response, ioArgs); }else if(response.dojoType == "timeout"){ this.handleXhrTimeout(response, ioArgs); }else{ this.handleXhrError(response, ioArgs); } }else{ this.handleXhrResponse(response, ioArgs); } return response; }, handleXhrResponse: function(response, ioArgs){ var json = null; var i = 0; try{ json = dojo.fromJson(response); if ("changeId" in json){ this._applyChanges(json.changeId, json.redo); }else if("nodes" in json || "edges" in json){ this._createDiagram(json); }else if ("error" in json){ this.handleXhrError(json.error, ioArgs); } } catch (e) { console.debug("Error on 'handleXhrResponse'."); console.debug(e); } },
289
handleXhrError: function(response, ioArgs){ try { console.debug(response); console.debug("HTTP status code: " + ioArgs.xhr.status); } catch (e) { console.debug("Error on 'handleXhrError'."); console.debug(e); } }, handleXhrTimeout: function(response, ioArgs){ try { console.debug("Request timeout"); console.dir(ioArgs); } catch (e) { console.debug("Error on 'handleXhrTimeout'."); console.debug(e); } }, handleXhrCancel: function(response, ioArgs){ try { console.debug("Request cancelled"); console.dir(ioArgs); } catch (e) { console.debug("Error on 'handleXhrCancel'."); console.debug(e); } } } ); }
290
5.2.6.2. Node.js
if(!dojo._hasResource["diagram.Node"]){ dojo._hasResource["diagram.Node"] = true; dojo.provide("diagram.Node");
dojo.require("dojox.gfx");
diagram.Node = function(surface, nodeId, shapes, matrix) {
this.nodeId = nodeId; this.gfx = surface.createGroup();
this.boundShape = null; this.text = null;
this.shapes = []; this.shapeCounter = 0;
this.ports = []; this.portCounter = 0;
if(shapes){ this.addShapes(shapes); }
if(matrix){ this.gfx.setTransform(matrix); } };
291
/////////////////////////////////////////////////////////////////////////////// /// // Common methods for 'diag.Node' /////////////////////////////////////////////////////////////////////////////// /// dojo.extend(diagram.Node, { _createShape: function(shape){ var s = null; var shapeId = null;
try{ shapeId = this.nodeId + "_" + (this.shapeCounter++); if(dojo.isObject(shape) && "coords" in shape){ switch(shape.coords.type){ case dojox.gfx.defaultPath.type: s = this.gfx.createPath(shape.coords); break; case dojox.gfx.defaultRect.type: s = this.gfx.createRect(shape.coords); break; case dojox.gfx.defaultCircle.type: s = this.gfx.createCircle(shape.coords); break; case dojox.gfx.defaultEllipse.type: s = this.gfx.createEllipse(shape.coords); break; case dojox.gfx.defaultLine.type: s = this.gfx.createLine(shape.coords); break; case dojox.gfx.defaultPolyline.type: s = this.gfx.createPolyline(shape.coords); break; case dojox.gfx.defaultImage.type: s = this.gfx.createImage(shape.coords); break; case dojox.gfx.defaultText.type: s = this.gfx.createText(shape.coords); break; case dojox.gfx.defaultTextPath.type: s = this.gfx.createTextPath(shape.coords); break; } if("fill" in shape){ s.setFill(shape.fill); } if("stroke" in shape){ s.setStroke(shape.stroke); } s.getEventSource().setAttribute('nodeId', this.nodeId); s.getEventSource().setAttribute('shapeId', shapeId); this.shapes[shapeId] = s; }
292
}catch(e){ console.debug(e); } }, addShapes: function(shapes){ if(dojo.isArray(shapes)){ for(i=0;i<shapes.length;++i){ this._createShape(shapes[i]); } }else{ this._createShape(shapes); } }, toJSON: function(){ var i = null; var shapesJSON = []; for(i in this.shapes){ shapesJSON.push({ coords: this.shapes[i].shape, fill: this.shapes[i].fillStyle, stroke: this.shapes[i].strokeStyle }); } return { nodeId: this.nodeId, shapes: shapesJSON, matrix: this.gfx.matrix }; } } ); }
293
5.2.7. Recursos adicionales

5.2.7.1. Java Server Pages (JSP)
5.2.7.1.1. defaultLayout.jsp
<%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles" %> <%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %> <%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
<html> <head> <html:base ref="site"/> <bean:define id="titleKey" toScope="request"> <tiles:getAsString name="titleKey"/> </bean:define> <title> <tiles:getAsString name="appTitle"/> <bean:message name="titleKey" scope="request"/> </title> <link rel="stylesheet" type="text/css" href="css/style.css" /> </head> <body> <div id="header"> <tiles:insert attribute="header"> <tiles:put name="session" beanName="footer" beanScope="tile"/> </tiles:insert> </div> <div id="menu"> <tiles:insert attribute="menu" ignore="true"/> </div> <div id="body"> <tiles:insert attribute="body"/> <div id="footer"> <p class="rightBlue"><tiles:insert attribute="footer" ignore="true"/></p> </div> </div> </body> <html/>
294
5.2.7.1.2. index.jsp
<%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic"%> <logic:redirect page="/Login.do"/>
5.2.7.1.3. header.jsp
<%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles" %> <%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %> <%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
<p class="rightWhite"><tiles:insert attribute="session" ignore="true"/></p> <h1><bean:message name="titleKey"/></h1>
5.2.7.1.4. footer.jsp
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %> <%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
<logic:present name="login" scope="session"> <bean:message key="msg.logged_as"/>: <a href="app/QueryUserAction.do"> <bean:write name="login" scope="session"/> </a> ( <a href="ExitAction.do"><bean:message key="app.exit.link"/></a> ) </logic:present> <logic:notPresent name="login" scope="session"> <bean:message key="msg.not_logged"/> ( <a href="Login.do"><bean:message key="app.login.link"/></a> - <a href="AddUser.do"><bean:message key="app.add_user.link"/></a> ) </logic:notPresent>
5.2.7.1.5. error.jsp
<%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles" %> <%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %> <%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
<h2><bean:message key="errors.global_error"/></h2> <logic:present name="exception" scope="request"> <br> <p class="error"><bean:write name="exception" scope="request"/></p> </logic:present>
295
5.2.7.1.6. menu.jsp
<%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles" %> <%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %> <%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %> <%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
<ul> <li> <a href="Index.do" title="<bean:message key="app.index.link"/>"> <span><bean:message key="app.index.link"/></span></a> </li> <li> <a href="app/QueryUserAction.do" title="<bean:message key="app.user.link"/>"> <span><bean:message key="app.user.link"/></span></a> </li> <li> <a href="app/QueryAllUsersAction.do" title="<bean:message key="app.users.link"/>"> <span><bean:message key="app.users.link"/></span></a> </li> <li> <a href="app/AddDiagram.do" title="<bean:message key="app.add_diagram.link"/>"> <span><bean:message key="app.add_diagram.link"/></span></a> </li> <li> <a href="app/QueryAllDiagramsAction.do" title="<bean:message key="app.diagrams.link"/>"> <span><bean:message key="app.diagrams.link"/></span></a> </li> </ul>
296
5.2.7.1.7. login.jsp
<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html"%> <%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean"%> <%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic"%>
<html:form action="/LoginAction.do" focus="id"> <table> <logic:present name="exit" scope="request"> <tr><td colspan="2"> <p class="success"><bean:message key="msg.logout"/>.</p> </td></tr> </logic:present> <logic:present name="error" scope="request"> <tr><td colspan="2"> <p class="error"><bean:message key="errors.login"/></p> </td></tr> </logic:present> <tr> <td class="td10 fieldLabel"> <h1><bean:message key="form.user.id"/>:</h1></td> <td class="tdMax"> <html:text property="id"/> <p class="error"> <html:errors property="id"/> </p> </td> </tr> <tr> <td class="fieldLabel"> <h1><bean:message key="form.user.password"/>:</h1></td> <td> <html:password property="password"/> <p class="error"> <html:errors property="password"/> </p> </td> </tr> <tr> <td></td><td><html:submit/><html:reset/></td> </tr> </table> </html:form>
297
5.2.7.1.8. addUser.jsp
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean"%> <%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html"%>
<html:form action="/AddUserAction.do" focus="id"> <table> <tr> <td class="td10 fieldLabel"> <h1><bean:message key="form.user.id"/>:</h1></td> <td class="tdMax"><html:text property="id"/> <p class="error"><html:errors property="id"/></p> </td> </tr><tr> <td class="fieldLabel"> <h1><bean:message key="form.user.password"/>:</h1></td> <td><html:password property="password"/> <p class="error"><html:errors property="password"/></p> </td> </tr><tr> <td class="fieldLabel"> <h1><bean:message key="form.user.first_name"/>:</h1></td> <td><html:text property="firstName"/> <p class="error"><html:errors property="firstName"/></p> </td> </tr><tr> <td class="fieldLabel"> <h1><bean:message key="form.user.last_name"/>:</h1></td> <td><html:text property="lastName"/> <p class="error"><html:errors property="lastName"/></p> </td> </tr><tr> <td class="fieldLabel"> <h1><bean:message key="form.user.email"/>:</h1></td> <td><html:text property="email"/> <p class="error"><html:errors property="email"/></p> </td> </tr><tr> <td></td><td><html:submit/><html:reset/></td><td></td> </tr> </table> </html:form>
298
5.2.7.1.9. user.jsp
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean"%>
<table> <tr> <td class="td10"><h1><bean:message key="form.user.id"/>:</h1></td> <td class="tdMax"><h2> <bean:write name="userBean" property="id" scope="request"/> </h2></td> </tr> <tr> <tr> <td><h1><bean:message key="label.diagramCount"/>:</h1></td> <td><h2> <bean:write name="userBean" property="diagramCount" scope="request"/> </h2></td> </tr> <tr> <td><h1><bean:message key="form.user.first_name"/>:</h1></td> <td><h2> <bean:write name="userBean" property="firstName" scope="request"/> </h2></td> </tr> <tr> <td><h1><bean:message key="form.user.last_name"/>:</h1></td> <td><h2> <bean:write name="userBean" property="lastName" scope="request"/> </h2></td> </tr> <tr> <td><h1><bean:message key="form.user.email"/>:</h1></td> <td><h2> <bean:write name="userBean" property="email" scope="request"/> </h2></td> </tr> </table>
299
5.2.7.1.10. users.jsp
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean"%> <%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic"%>
<table class="report"> <thead> <tr> <td class="tdMin"><p><bean:message key="form.user.id"/></p></td> <td class="tdMin"><p><bean:message key="label.diagramCount"/></p></td> <td class="td20"><p><bean:message key="form.user.first_name"/></p> </td> <td class="td25"><p><bean:message key="form.user.last_name"/></p></td> <td class="tdReamin"><p><bean:message key="form.user.email"/></p></td> </tr> </thead> <tbody> <logic:iterate id="user" name="usersList" scope="request"> <tr> <td><p><bean:write name="user" property="id"/>&nbsp</p></td> <td><p><bean:write name="user" property="diagramCount"/>&nbsp</p></td> <td><p><bean:write name="user" property="firstName"/>&nbsp</p></td> <td><p><bean:write name="user" property="lastName"/>&nbsp</p></td> <td><p><bean:write name="user" property="email"/>&nbsp</p></td> </tr> </logic:iterate> </tbody> </table>
300
5.2.7.1.11. addDiagram.jsp
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean"%> <%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html"%>
<html:form action="/app/AddDiagramAction.do" focus="name"> <table> <tr> <td class="td10 fieldLabel"> <h1><bean:message key="form.diagram.name"/>:</h1></td> <td class="tdMax"> <html:text property="name"/> <p class="error"><html:errors property="name"/></p> </td> </tr> <tr> <td class="fieldLabel"> <h1><bean:message key="form.diagram.description"/>:</h1></td> <td> <html:textarea property="description"/> <p class="error"><html:errors property="description"/></p> </td> </tr> <tr> <td></td><td><html:submit/><html:reset/></td><td></td> </tr> </table> </html:form>
301
5.2.7.1.12. diagram.jsp
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean"%> <%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles"%> <table> <tr> <td width="td10"><h1><bean:message key="form.diagram.id"/>:</h1></td> <td class="tdMax"><h2><bean:write name="diagramBean" property="id" scope="request"/></h2></td> </tr> <tr> <tr> <td><h1><bean:message key="form.diagram.name"/>:</h1></td> <td><h2><bean:write name="diagramBean" property="name" scope="request"/></h2></td> </tr> <tr> <td><h1><bean:message key="form.diagram.creator"/>:</h1></td> <td><h2><bean:write name="diagramBean" property="creator" scope="request"/></h2></td> </tr> <tr> <td><h1><bean:message key="form.diagram.version"/>:</h1></td> <td><h2><bean:write name="diagramBean" property="version" scope="request"/></h2></td> </tr> <tr> <td><h1><bean:message key="label.actions"/>:</h1></td> <td> <tiles:insert page="privilegesActions.jsp"></tiles:insert> </td> </tr> <tr> <td><h1><bean:message key="form.diagram.description"/>:</h1></td> <td><h2><bean:write name="diagramBean" property="description" scope="request"/></h2></td> </tr> </table>
302
5.2.7.1.13. diagrams.jsp
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean"%> <%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic"%> <%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles"%> <table class="report"> <thead> <tr> <td class="td20"><p><bean:message key="form.diagram.name"/></p></td> <td class="tdMin"> <p><bean:message key="form.diagram.version"/></p></td> <td class="tdMin"> <p><bean:message key="form.diagram.creator"/></p></td> <td class="tdMax"><p><bean:message key="label.actions"/></p></td> </tr> </thead> <logic:present name="diagramsList" scope="request"> <tbody> <logic:iterate id="diagramBean" name="diagramsList" scope="request"> <tr> <td><p><bean:write name="diagramBean" property="name"/>&nbsp</p></td> <td><p><bean:write name="diagramBean" property="version"/>&nbsp</p></td> <td><p><bean:write name="diagramBean" property="creator"/>&nbsp</p></td> <td> <bean:define id="diagramBean" name="diagramBean" toScope="request"/> <jsp:include page="privilegesActions.jsp" flush="true"/> </td> </tr> </logic:iterate> </tbody> </logic:present> <logic:notPresent name="diagramsList" scope="request"> <tr><td colspan="4"> <p><bean:message key="msg.empty"/>.</p> </td></tr> </logic:notPresent> </table>
303
5.2.7.1.14. diagramPrivileges.jsp
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean"%> <%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic"%> <logic:present name="userId" scope="request"> <p class="success"><bean:message key="msg.privilege.updated"/>: <strong>'<bean:write name="userId"/>'</strong></p> </logic:present> <table class="report"> <thead> <tr> <td class="tdMin"><p><bean:message key="form.user.id"/></p></td> <td class="tdMax"><p><bean:message key="label.privileges"/></p></td> </tr> </thead> <tbody> <logic:iterate id="privilege" name="diagramPrivileges" scope="request"> <tr> <td><p><a href="app/QueryUserAction.do?id=<bean:write name="privilege" property="userId"/>" title="<bean:message key="app.user.link"/>" ><bean:write name="privilege" property="userId"/></p></a> </td> <logic:equal name="privilege" property="privilege" value="5"> <td> <img src="css/img/extra.png" alt="<bean:message key="privilege.creator"/>"> <bean:message key="privilege.creator"/> </td> </logic:equal> <logic:notEqual name="privilege" property="privilege" value="5"> <td> <form method="POST" action="app/ChangeDiagramPrivilegeAction.do"> <input type="hidden" name="diagramId" value="<bean:write name="privilege" property="diagramId"/>"> <input type="hidden" name="userId" value="<bean:write name="privilege" property="userId"/>">
<input type="radio" value="-1" name="privilege" <logic:equal name="privilege" property="privilege" value="-1">
304
CHECKED</logic:equal>> <img src="css/img/remove16.png" alt="<bean:message key="privilege.none"/>"> <bean:message key="privilege.none"/><br> <input type="radio" value="0" name="privilege" <logic:equal name="privilege" property="privilege" value="0"> CHECKED</logic:equal>> <img src="css/img/info16.png" alt="<bean:message key="privilege.view"/>"> <bean:message key="privilege.view"/><br> <input type="radio" value="1" name="privilege" <logic:equal name="privilege" property="privilege" value="1"> CHECKED</logic:equal>> <img src="css/img/copy16.png" alt="<bean:message key="privilege.copy"/>"> <bean:message key="privilege.copy"/><br> <input type="radio" value="2" name="privilege" <logic:equal name="privilege" property="privilege" value="2"> CHECKED</logic:equal>> <img src="css/img/open16.png" alt="<bean:message key="privilege.edit"/>"> <bean:message key="privilege.edit"/><br> <input type="radio" value="3" name="privilege" <logic:equal name="privilege" property="privilege" value="3"> CHECKED</logic:equal>> <img src="css/img/versions16.png" alt="<bean:message key="privilege.versions"/>"> <bean:message key="privilege.versions"/><br> <input type="radio" value="4" name="privilege" <logic:equal name="privilege" property="privilege" value="4"> CHECKED</logic:equal>> <img src="css/img/privileges16.png" alt="<bean:message key="privilege.total"/>"> <bean:message key="privilege.total"/><br> <input type="submit" value="<bean:message key="submit.update"/>"/> </form> </td> </logic:notEqual> </tr> </logic:iterate> </tbody> </table>
305
5.2.7.1.15. privilegesActions.jsp
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean"%> <%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic"%>
<logic:greaterEqual name="diagramBean" property="privilege" value="0"> <a class="action" href="app/QueryDiagramAction.do?diagramId=<bean:write name="diagramBean" property="id"/>" title="<bean:message key="title.diagram"/>" ><img src="css/img/info.png" alt="<bean:message key="title.diagram"/>"/></a> </logic:greaterEqual>
<logic:greaterEqual name="diagramBean" property="privilege" value="1"> <a class="action" href="app/LoadDiagramAction.do?diagramId=<bean:write name="diagramBean" property="id"/>" title="<bean:message key="title.diagram.copy"/>" ><img src="css/img/copy.png" alt="<bean:message key="title.diagram.copy"/>"/></a> </logic:greaterEqual>
<logic:greaterEqual name="diagramBean" property="privilege" value="2"> <a class="action" target="editor" href="app/LoadDiagramAction.do?diagramId=<bean:write name="diagramBean" property="id"/>" title="<bean:message key="title.diagram.editor"/>" ><img src="css/img/open.png" alt="<bean:message key="title.diagram.editor"/>"/></a> </logic:greaterEqual>
<logic:greaterEqual name="diagramBean" property="privilege" value="3"> </logic:greaterEqual>
<logic:greaterEqual name="diagramBean" property="privilege" value="4"> <a class="action" href="app/QueryDiagramPrivilegesAction.do?diagramId=<bean:write name="diagramBean" property="id"/>" title="<bean:message key="label.managePrivileges"/>" ><img src="css/img/privileges.png" alt="<bean:message key="title.diagram.privileges"/>"/></a> </logic:greaterEqual>
306
<logic:lessEqual name="diagramBean" property="privilege" value="4"> <a class="action" href="app/ChangeDiagramPrivilegeAction.do?diagramId=<bean:write name="diagramBean" property="id" />&userId=<bean:write name="login" scope="session" />&privilege=-1" title="<bean:message key="form.diagram.remove"/>" ><img src="css/img/remove.png" alt="<bean:message key="form.diagram.remove"/>"/></a> </logic:lessEqual>
<logic:greaterEqual name="diagramBean" property="privilege" value="5"> <a class="action" href="app/DestroyDiagramAction.do?diagramId=<bean:write name="diagramBean" property="id"/>" title="<bean:message key="form.diagram.destroy"/>" ><img src="css/img/destroy.png" alt="<bean:message key="form.diagram.destroy"/>"/></a> </logic:greaterEqual>
307
5.2.7.1.16. diagramEditor.jsp
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %> <html> <head> <title>Abstract Minds - <bean:message key="title.diagram.editor"/></title> <script type="text/javascript" src="../ajax/dojo/dojo.js.uncompressed.js" djConfig="parseOnLoad: true, isDebug: true"></script> <link rel="stylesheet" type="text/css" href="../ajax/dojo/resources/dojo.css"/> <link rel="stylesheet" type="text/css" href="../ajax/dijit/themes/tundra/tundra.css"/> <link rel="stylesheet" type="text/css" href="../css/diagram.css"/>
<script type="text/javascript"> /* Dojo Parser */ dojo.require("dojo.parser"); /* Widgets */ dojo.require("dijit.Menu"); dojo.require("dijit.Toolbar"); dojo.require("dijit.form.Button"); dojo.require("dijit.layout.ContentPane"); dojo.require("dijit.layout.SplitContainer"); dojo.require("dijit.layout.AccordionContainer"); dojo.require("dijit.layout.LayoutContainer"); dojo.require("dijit.Dialog"); dojo.require("dijit.ProgressBar"); /* Diagram Editor */ dojo.require("diagram.DiagramEditor");
/* Initialization */ function initDiagramEditor(){ editor = new diagram.DiagramEditor({ diagramId:'<bean:write name="diagramBean" property="id" scope="request"/>', userId:'<bean:write name="login" scope="session"/>', objects:<bean:write name="diagramBean" property="jsonObjects" scope="request" filter="false"/> } ); } dojo.addOnLoad(initDiagramEditor); </script> </head>
308
<body class="tundra">
<div id="loadingDialog" dojoType="dijit.Dialog" title="Loading..." duration="500" style="width: 275px; display: none; position: absolute"> <div id="loadingProgressBar" indeterminate="true" dojoType="dijit.ProgressBar" style="width:250px; height:12px;"></div> </div>
<div id="main" dojoType="dijit.layout.LayoutContainer"> <div id="toolbar" dojoType="dijit.Toolbar" layoutAlign="top"> <button dojoType="dijit.form.ComboButton" iconClass="dijitEditorIconSave" onClick='console.debug("clicked file menu")'> <span>File</span> <div dojoType="dijit.Menu" id="fileMenu" style="display: none;"> <div dojoType="dijit.MenuItem" iconClass="dijitEditorIconSave" Save </div> <div dojoType="dijit.MenuItem" Save As </div> </div> </button> <span dojoType="dijit.ToolbarSeparator"></span> <button dojoType="dijit.form.Button" id="zoomIn" onClick='editor.zoomIn()'> <span>Zoom In</span> </button> <button dojoType="dijit.form.Button" id="zoomOut" onClick='editor.zoomOut()'> <span>Zoom Out</span> </button> <span dojoType="dijit.ToolbarSeparator"></span> </div>
309
<div dojoType="dijit.layout.SplitContainer" orientation="horizontal" sizerWidth="7" layoutAlign=client id="mainSplit" activeSizing="true">
<div id="accordion" dojoType="dijit.layout.AccordionContainer" duration="300" sizeMin="100" sizeShare="10" style="width:100%; height:100%"> <div dojoType="dijit.layout.AccordionPane" title="Formas" selected="true"> <div id="toolbarShapes" dojoType="dijit.Toolbar"> <button dojoType="dijit.form.Button" id="createRect" onClick='editor.createNode(new diagram.defaultRect)'> </button> <button dojoType="dijit.form.Button" id="createCircle" onClick='editor.createNode(new diagram.defaultCircle)'> </button> <button dojoType="dijit.form.Button" id="createEllipse" onClick='editor.createNode(new diagram.defaultEllipse)'> </button> </div> </div> <div dojoType="dijit.layout.AccordionPane" title="Conexin"> <div id="commitLabel">Commits: 0</div> </div> </div>
<div dojoType="dijit.layout.LayoutContainer" sizeMin="300" sizeShare="90"> <div dojoType="dijit.layout.ContentPane" layoutAlign="bottom" id="mouseLabel"> </div> <div dojoType="dijit.layout.ContentPane" id="diagramContainer" layoutAlign="client"> <div id="diagramBackground"></div> </div> </div>
</div> </div> </body> </html>
310
5.2.7.1.17. ajax.jsp
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %><bean:write name="JSON" scope="request" filter="false"/>
5.2.7.1.18. ajax_error.jsp
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>{error:"<bean:write name="error" scope="request" filter="false"/>"}
311
5.2.7.2. Cascade Style Sheets (CSS)
5.2.7.2.1. style.css
body{ margin: 0; padding: 10px; background: #324b63 url(img/prueba.png) repeat-x left top; }
h1,h2,h3{ font-family: Arial, sans-serif; padding: 0; margin: 0; }
p{ font-size:0.90em; }
/* IDs */
#header{ background: transparent; color: white; padding:0; padding-left: 1em; margin-bottom: 3em; }
#header a{ color: white; }
#body{ color: black; font-family:Verdana,sans-serif; background: white url(img/body.gif) repeat-x left bottom; border: 1px solid #2956B2; padding: 20px 20px 10px 20px; }
312
#body form{ margin:0; }
#body table{ border: 0px; }
#body td{ padding: 1em; margin:0; }
#body .report{ border:1px solid #2956B2; border-spacing:0; margin-bottom:25px; }
#body .report thead{ font-family: Arial, sans-serif; background:#324b63 url(img/prueba.png) repeat-x left top; color:white; font-size:1em; font-weight:bold; }
#body .report td{ padding:5px; border:1px solid #AAAAAA; }
#body .shadow{ background:white url(img/body.gif) repeat-x left bottom; }
#body .action{ text-decoration:none; border:0; margin:0; padding:0; }
#body .action img{ padding:1px;
313
border:1px solid transparent; } #body .action:hover img{ border:1px solid #2956B2; }
#body h1{ color: #2956B2; font-size:1.2em; }
#body h2{ font-size:1em; }
#body h3{ font-size:0.9em; }
#menu{ font-size:14px; padding: 0; background: transparent; height:1.8em; }
#menu ul{ list-style-type: none; margin:0; margin-left: 5px; padding:0; }
#menu li{ display:inline;
314
#menu a{ float:left; background:url(img/tab-left.gif) no-repeat left top; margin:0; margin-right: 1px; /*Espacio entre pestaas*/ padding:0 0 0 14px; text-decoration:none; }
#menu a span{ float:left; display:block; background:url(img/tab.gif) no-repeat right top; padding: 6px 18px 2px 3px; font-weight:bold; font-family: Arial, sans-serif; color:#3B3B3B; cursor: pointer; }
#menu a:hover span { color: black; }
#menu #seleccionado a{ background-position:0 -82px; }
#menu #seleccionado a span{ background-position:100% -82px; color: } #2956B2;
#menu a:hover{ background-position:0% -82px; }
#menu a:hover span{ background-position:100% -82px; color: } #2956B2;
315
#footer{ font-family: Arial, sans-serif; font-size:1em; text-align:right; margin:0; padding-right:5px; padding-bottom:5px; color: #2956B2; }
#footer a { color: #2956B2; }
/* Classes */
.migas{ font-family: Arial, sans-serif; font-size:0.7em; text-align:right; }
.migas a:visited{ color: white; }
.title{ font-style: italic; color: #2956B2; border-bottom:2px solid #7e9fff; margin-top:3em; padding: 0.5em; }
.right{ float:right; }
316
.rightWhite{ font-family: Arial, sans-serif; font-size:0.7em; color: white; text-align:right; margin:0; padding-right:5px; }
.error{ font-family: Arial, sans-serif; color: red; font-size:1em; }
.success{ font-family: Arial, sans-serif; color: green; font-size:1em; }
.fieldLabel{ vertical-align: top; }
.hidden { color:white; }
.withoutBorder img{ border:white; }
.tdMin{ width:1%; }
.tdMax{ width:100%; }
317
.td10{ width:10%; }
.td20{ width:20%; }
.td30{ width:30%; }
.td40{ width:40%; }
.td50{ width:50%; }
.tdRemain{ width:*; }
318
5.2.7.2.2. diagram.css
head, body { height: 100%; width: 100%; padding: 0; margin: 0; border: 0; }
body { background: #EEEEEE; }
#main { height: 100%; width: 100%; }
#mainSplit { border: 1px solid #AAAAAA; }
#mouseLabel { padding: 1px; }
#header { width: 100%; font-size: 2em; margin: 0 0 0 0; }
#toolbar { width: 100%; margin: 0px; border: 1px solid #AAAAAA; }
319
#zoomIn, #zoomOut { width: 25px; height: 25px; display: block; }
#zoomIn { background: url('img/viewmag+.png') no-repeat; }
#zoomOut { background: url('img/viewmag-.png') no-repeat; }
#toolbarShapes { padding: 0; margin: 0; border: none; }
#createRect, #createCircle, #createEllipse, #default { padding: 0; margin: 0; margin-bottom: 2px; background: url('img/button_empty.png') no-repeat; width: 28px; height: 24px; display: block; border: none; background-position: 0 0; }
#createRect { background: url('img/rect.png') no-repeat; }
#createCircle { background: url('img/circle.png') no-repeat; }
320
#createEllipse { background: url('img/ellipse.png') no-repeat; }
.tundra .dijitAccordionPane .title .arrow { background: url('../ajax/dijit/themes/tundra/images/arrowRight.png') norepeat; }
.tundra .dijitAccordionPane-selected .title .arrow { background: url('../ajax/dijit/themes/tundra/images/arrowDown.png') norepeat; }
321
CAPTULO 6: MANUALES
Este captulo incluye el manual de instalacin del sistema con los pasos a seguir y los requisitos mnimos de hardware y software. Tambin se describe el uso bsico del entorno mediante un manual de usuario organizado por funcionalidades.
322
6.1. Manual de Instalacin

Este manual est destinado a describir los requisitos de instalacin del sistema desarrollado, as como la enumeracin de pasos a seguir para su correcta implantacin y despliegue.
323
6.1.1. Requisitos Mnimos

6.1.1.1. Hardware
Recurso Mnimo Recomendado
Disco Duro Memoria RAM Conexin a Internet
500 MB 500 MB 10 Mbps

Tabla 6.1-1. Requisitos hardware
Ms de 10 GB Ms de 2 GB Ms de 100 Mbps
6.1.1.2. Software
Recurso Mnimo Recomendado
Java JRE JBOSS Oracle Struts Dojo Toolkit JUNG
1.5 4 10g 1 0.9.0 1.7.6

Tabla 6.1-2. Requisitos software
1.5 4 10g 2 0.9.0 1.7.6
324
6.1.2. Instalacin y despliegue

6.1.2.1. JBOSS (Java JRE 1.5) Para instalar JBOSS, basta con copiar la carpeta JBOSS del directorio Entorno del CD al disco duro del ordenador de destino, tambin es necesario copiar la carpeta JRE y los archivos por lotes. Para arrancar el servidor se ejecuta el archivo por lotes jboss.bat. 6.1.2.2. Oracle La instalacin de Oracle se realizar siguiendo los pasos indicados por el fabricante si es necesario. Basta con realizar una instalacin tpica del servidor y la base de datos por defecto. Una vez instalado se carga el archivo ddl.sql del directorio Sistema en la base de datos para que se cree el diccionario de datos necesario para el correcto funcionamiento de la aplicacin. 6.1.2.3. Despliegue El resto de componentes se incluyen en el archivo AbstractMinds.war del directorio despliegue. Para poder acceder a la aplicacin copiamos este archivo al directorio /default/deploy dentro del directorio donde se instal JBOSS. Una vez arrancado JBOSS se comprueba que todo funciona correctamente desde la siguiente direccin: http://127.0.0.1:8080/AbstractMinds
325
6.2. Manual de Usuario

Este manual est dirigido al usuario final del sistema, que es aquel interactuar de manera directa con las interfaces desarrolladas. Durante la elaboracin de este manual, algunas de las funcionalidades descritas no estaban completamente testadas o integradas por lo que podan observarse ligeras variaciones en el sistema final. Tambin puede darse el caso de encontrar nuevas funcionalidades o interfaces no previstas durante su redaccin, por lo que en ltima instancia se recomienda acceder a la versin on-linedel mismo, disponible desde cualquiera de las interfaces descritas en este manual.
326
6.2.1. Gestin de Usuarios

Para poder acceder a los contenidos almacenados en el sistema es necesario estar registrado en el mismo, bien mediante la pantalla de registro o bien creando un nuevo usuario, que ser registrado automticamente. 6.2.1.1. Conectar La forma ms comn de acceso es mediante el formulario de conexin al sistema, el cual requiere del usuario un identificador y una contrasea previamente especificados al crear la cuenta.
Fig. 6-1. Formulario de conexin
El usuario y la contrasea deben estar formados por un mnimo de cuatro caracteres y un mximo de veinte, sin espacios y sin smbolos especiales, nicamente letras, nmeros y el carcter de subrayado (_). En caso de introducir algn campo incorrecto o que no exista el usuario en el sistema se mostrar un mensaje de error adaptado al idioma seleccionado en el navegador Web. 327
6.2.1.2. Crear Usuario Si el usuario es nuevo en el sistema se requiere la creacin de una nueva cuenta de usuario con un identificador y una contrasea como mnimo, adems de otros datos opcionales que se irn ampliando en futuras versiones del sistema en funcin de las necesidades.
Fig. 6-2. Crear usuario
Al igual que en el formulario de conexin los mensajes que se muestran estn internacionalizados, tanto las etiquetas de los campos como los mensajes de error.
328
6.2.1.3. Consultar Usuarios Los usuarios del sistema pueden ser consultados libremente por cualquier usuario del sistema tanto desde la opcin del men correspondiente, como desde otras zonas ms especficas. Al seleccionar un usuario concreto se mostrar una pgina con sus datos.
Fig. 6-3. Datos de la cuenta de usuario
329
6.2.2. Gestin de Diagramas

El sistema permite crear, eliminar, compartir y acceder a los distintos diagramas creados, tanto propios como compartidos. Tambin sigue un control de versiones de los mismos, permitiendo el acceso a versiones anteriores sin perder los cambios actuales. 6.2.2.1. Crear Diagrama Inicialmente un usuario recin creado no posee ningn diagrama, por lo que el primer paso es crear un nuevo diagrama mediante el formulario correspondiente. Al crear el diagrama es obligatorio asignarle un nombre y, opcionalmente, una descripcin.
Fig. 6-4. Crear diagrama
Slo existe un usuario que pueda ser creador de un diagrama y es aquel que lo creara mediante este formulario. El creador es el nico que puede destruir el diagrama y todos los recursos asociados al mismo.
330
6.2.2.2. Consultar Diagramas La gestin de diagramas se realiza mediante el listado de diagramas del usuario. En dicho listado aparecen los diagramas a los que tiene acceso ordenados por nivel de privilegios descendente.
Fig. 6-5. Consultar diagramas
El creador puede destruir diagramas desde esta pantalla mediante el botn , sin embargo esta opcin es irreversible, por lo que deber emplearse con cautela. Ningn usuario puede destruir un diagrama que no haya sido creado por l mismo, lo que s puede es descartar el acceso a dicho diagrama mediante .
331
6.2.2.3. Gestionar Permisos sobre Diagramas Uno de los apartados ms importantes de la gestin de diagramas es la gestin de los privilegios asociados a cada usuario.
Fig. 6-6. Gestionar permisos sobre diagramas
Desde esta pgina podemos asignar los permisos apropiados para cada usuario del sistema. Slo los usuarios con privilegio de control total o el propio creador pueden gestionar los permisos, es decir, inicialmente slo el creador puede acceder a esta funcionalidad. Las acciones permitidas por cada privilegio son acumulables y van de menos a ms funcionalidad.
332
Los privilegios disponibles se describen a continuacin:
El usuario no puede listar el diagrama ni consultar sus datos.
Slo puede consultar la informacin del diagrama.
Puede crear una copia exacta del diagrama para uso personal. El nuevo diagrama tendr por creador el usuario que solicita la copia.
Permite cargar y modificar libremente el diagrama, as como colaborar de manera sncrona con otros usuarios autorizados.
Aade permisos para exportar y publicar o crear nuevas versiones del diagrama.
Este ltimo privilegio da acceso total al diagrama, permitiendo incluso modificar los permisos de otros usuarios (salvo del creador).
333
6.2.3. Edicin de Diagramas

El diseo de los diagramas abarca cualquier cambio que se desee realizar sobre el contenido o la disposicin de un diagrama concreto. Se trata de un entorno grfico de dibujo dnde varios usuarios pueden trabajar de manera sncrona sobre un mismo diagrama, actualizndose los cambios en tiempo real en todos los clientes.
Fig. 6-7. Edicin de diagramas
Entre las acciones posibles destacan algunas como definir las dimensiones del rea de diseo, aadir y eliminar componentes, realizar conexiones entre componentes, aplicar transformaciones bsicas (zoom, rotacin), cortar, copiar y pegar, historial de deshacer / rehacer, guardar, exportar e importar.
334
335
CAPTULO 7: CONCLUSIONES
Como captulo final se exponen las conclusiones derivadas de todo el trabjo realizado para el anlisis, diseo y construccin del prototipo final, as como para la elaboracin de este documento. Adicionalmente se detalla el contenido de los entregables y el catlogo de ampliaciones que se proponen.
336
7.1. Resultados
Este apartado comprende todas las conclusiones derivadas de la realizacin de este proyecto, tanto en los estudios previos como en las fases ms avanzadas de desarrollo. Estudios realizados Durante la mayor parte de este proyecto la actividad principal ha sido el estudio de las diferentes tecnologas, libreras y herramientas a emplear para cumplir los objetivos marcados. La metodologa de trabajo empleada enfoca la solucin al problema hacia la reutilizacin de componentes ya desarrollados, preferiblemente basados en cdigo abierto. Lo cual a primera vista supone un ahorro de tiempo de desarrollo, pero que sin embargo requiere un esfuerzo continuo, ms an cuando es necesario realizar alguna funcin concreta a travs de estos componentes. Quiz la mayor barrera sea la escasa documentacin del cdigo y las libreras empleadas, incluso la falta de madurez que llegan a presentar estos recursos al profundizar en sus funcionalidades ms complejas. Para solver estos problemas, en muchas ocasiones se ha optado por consultar el cdigo fuente directamente, como es el caso del mdulo de grficos vectoriales de Dojo, cuya documentacin es mnima y que sin embargo se pueden conseguir resultados de gran calidad mediante el examen detallado del cdigo fuente. De no haber elegido recursos de cdigo abierto esto nunca hubiese sido posible y se podra haber convertido en una barrera ms difcil de solucionar. De esta fase cabe destacar el conocimiento adquirido sobre tecnologas relativamente modernas como XML, AJAX, Web 2.0 y Struts entre otras. Planificacin Este ha sido uno de los apartados en los que se ha hecho ms notable la falta de experiencia con la que se afronta un proyecto de fin de carrera. Resulta muy complicado prever cunto tiempo puede requerir una actividad concreta, de hecho se ha tendido a planificar con holgura las diferentes fases del proyecto de tal modo que pudiesen acometerse con los menores contratiempos posibles, y an as siempre hay momentos en los que por circunstacias externas puede tambalearse cualquier plan previsto. Sin duda el mejor mecanismo de la que se ha hecho uso es la elaboracin de los prototipos, que ha permitido ir acotando paulatinamente el alcance del prototipo final, consiguiendo ajustar adecuadamente los plazos de desarrollo y documentacin del proyecto a las fechas previstas.
337
Prototipos La decisin de usar una metodologa de desarrollo basada en prototipado gil surge ya en la primera reunin con el director del proyecto. La motivacin fue el hecho de plantear el sistema como un entorno Web 2.0, ya que este tipo de sistemas se basan en el concepto de beta continua, lo que supone que nacen como prototipo y evolucionan continuamente como prototipos cada vez ms completos y fiables. Este hecho unido a la motivacin de crear un proyecto de cdigo abierto permite que sean los propios usuarios los que depuren el sistema a traves de listas de bugs y peticiones, siempre que se consiga proveerlos de un entorno y una documentacin adecuados. Incluso la colaboracin de los usuarios puede ser directa mediante la modificacin explcita del sistema o proponiendo modulos y ampliaciones adicionales. Anlisis En esta fase tambin se ha hecho palpable la falta de experiencia anterior en la identificacin y especificacin de requerimientos. Se ha tratado de llevar un seguimiento exhaustivo de la especificacin realizada al principio del anlisis que ha permitido delimitar adecuadamente el grado de completitud de cada prototipo y que ha sido un gran apoyo de cara a afrontar el diseo detallado del sistema y su posterior desarrollo. Una vez superadas todas las fases del proyecto resulta evidente la importancia de esta actividad en el ciclo de vida de cualquier proyecto, hasta el punto de que muchas de las barreras y contratiempos detectados durante el desarrollo surgen de incoherencias en los requisitos o en los casos de uso. Diseo A partir de esta actividad el proyecto empieza a tomar forma y pueden probarse las funcionalidades ms bsicas mediante los prototipos que se han ido desarrollando con anterioridad. Los mtodos empleados para disear el sistema han resultado ms amigables y expresivos que los del anlisis. Se define la arquitetura del sistema mediante el patrn MVC, que le confiere un grado de escalabilidad destacable y permite separar las responsabilidades en capas con muy bajo acoplamiento entre s, normalmente interconectadas mediante clases basadas en el patrn Facade. Sin duda esta ha sido la actividad ms laboriosa de completar, y quiz la ms tensa, por la necesidad de acotar correctamente el alcance del prototipo final y disponer de tiempo suficiente para disear una arquitectura global y su posterior implementacin.
338
Construccin El objetivo original de este proyecto es el desarrollo de un prototipo lo ms completo y funcional posible de un entorno de diseo de diagramas de interconexin de objetos a travs de Internet. Al ser una aplicacin Web permite a los usuarios acceder a su funcionalidad desde cualquier ordenador con conexin a Internet. Adems se ha construido mediante tecnologas Web 2.0, como AJAX y JSON, que aportan un grado mucho ms elevado de interactividad y dinamismo a las interfaces de usuario. Tambin se logr encontrar un vocabulario XML apropiado, GraphML, que es empleado en la representacin de grafos y por tanto cubre perfectamente las necesidades del diseo de diagramas. Al final el requerimiento de colaboracin sncrona entre usuarios ha sido prioritario respecto al resto por lo que ha podido ser completado con xito y adems se incluye un entorno de diseo y gestin de diagramas bastante completo, en el que los usuarios pueden compartir sus recursos. En lo que respecta a los navegadote, puede decirse que cubre ampliamente el catlogo de alternativas ms utilizadas por los usuarios, habiendo sido prubado con xito en Internet Explorer 6, Mozilla Firefox 2. Opera 9 y Safari 3. Adems no requiere de instalacin alguna de plugins en ninguno de ellos. Gracias a las facilidades aportadas por Struts tambin ha sido posible realizar una interfaz de usuario internacionalizada completamente mediante archivos de recursos.
339
7.2. Entregables
El presente documento adjunta un CD cuyo contenido se detalla brevemente a continuacin: Archivo LEEME.txt Archivo de texto con la descripcin del contenido del CD y la identificacin del proyecto y del autor. Directorio Entorno Entorno de desarrollo empleado en la construccin del proyecto. Directorio Sistema Archivo de despliegue WAR para JBOSS y archivo de comandos SQL para crear la base de datos en Oracle 10g. Directorio Fuentes Cdigo fuente, ficheros de configuracin y libreras necesarias para compilar el proyecto desde Eclipse u otro entorno de desarrollo para JEE. Directorio Documentacion Copia digital de este documento y otros recursos empleados en su elaboracin. Directorio Manuales Manuales de instalacin y de usuario.
340
7.3. Ampliaciones
La siguiente actividad a llevar a cabo antes de proseguir el desarrollo de prototipos es la especificacin detallada de un plan de pruebas que incluya pruebas individuales exhaustivas de todos los componentes desarrollados, pruebas de integracin de todos los subsistemas y pruebas de rendimiento para comprobar la escalabilidad del sistema y la correcin de la gestin de recursos del hardware de cara a afrontar un gran numero de usuarios simultneos. Tambin es imprescindible realizar tests apropiados de usabilidad que garantizen la calidad de la interfaz de usuario en sucesivas versiones. Uno de los aspectos ms destacables de la solucin planteada es la arquitectura del sistema ya mencionada en anteriores ocasiones que realmente supone una puerta abierta para incorporar al sistema las ampliaciones que se proponen a continuacin. Mejorar el entorno de diseo de diagramas El editor de diagramas admite ms funcionalidades de las implementadas, algunas de las cuales se prev que surjan del uso mismo del sistema. Mejorar el gestor de contenidos El prototipo desarrollado no est destinado a trabajar con un gran nmero de ocurrencias en los listados, en caso de querer gestionar una cantidad elevada de infomacin sera conveniente aadir funcionalidades bsicas de paginacin de resultados. Mejorar el sistema de comunicacin entre usuarios Cualquier ampliacin que suponga una mejora en los mecanismos disponibles para fomentar la comunicacin entre usuarios, puede suponer un gran avance en la usabilidad del subsistema de colaboracin sncrona. Editor de componentes La incorporacin de un subsistema de gestin y edicin de componentes permitira a los usuarios personalizar las herramientas empleadas en el diseo de los diagramas. Teora de grafos Existen mltiples posibilidades de ampliacin en este campo, entre las que destaca la posibilidad de distribuir los elementos del diagrama en estructura jerrquica, orgnica, circular... Tambin podran aadirse utilidades especficas para el diseo de grafos y la aplicacin de algoritmos cuyos resultados se reflejen en el propio grafo.
341
342
343
GLOSARIO
Componente
Objeto con entidad propia que tiene una representacin grfica y un comportamiento especficos dentro del editor de diagramas. Lnea de unin entre dos componentes que representa un relacin lgica determinada entre ambos. Capa encargada de coordinar el flujo de la aplicacin y gestionar las peticiones del servidor en el patrn MVC. Estructura formada por un conjunto componentes o nodos y las conexiones existentes entre ellos. Capa responsable de la lgica de negocio dentro del patrn de diseo MVC. Un patrn de diseo es una solucin a un problema de diseo no trivial que es efectiva y reutilizable. Conjunto de mdulos o subsistemas que se integran para proporcionar una funcionalidad completa. Cambio en las propiedades de un componente o diagrama que modifica su aspecto o su colocacin. Esta capa se encarga de mostrar los resultados al usuario y recoger sus solicitudes en el patrn MVC.
Conexin
Controlador
Diagrama
Modelo
Patrn
Sistema
Transformacin
Vista
344
345
BIBLIOGRAFA
[Cantero] Pedro Cantero Espadas. Tutorial sobre Domtica e Inmtica Universidad de Oviedo, Escuela Politcnica Superior de Informtica de Gijn. PFC 1042012, Enero de 2005. [Chico] Grupo CHICO. DomoSim-TPC Universidad de Castilla - La Mancha, Escuela Superior de Informtica. http://chico.inf-cr.uclm.es/domosim/ [CoVis] The School of Education & Social Policy. Learning through Collaborative Visualization Northwestern University. http://www.covis.northwestern.edu/ [CSILE] Marlene Scardamalia, Carl Bereiter. Computer-Supported Intentional Learning Environments Ontario Institute for Studies in Education. http://www.ed.gov/pubs/EdReformStudies/EdTech/csile.html [Dojo] Dojo Fundation. The Dojo Toolkit, The JavaScript Toolkit http://dojotoolkit.org/ [eLearning] Wikimedia Foundation. Aprendizaje Colaborativo http://es.wikibooks.org/wiki/Aprendizaje_colaborativo [GraphML] GraphML Project Group. The GraphML File Format http://graphml.graphdrawing.org/
346
[JEE] Sun Microsistems. Java Enterprise Edition http://java.sun.com/javaee/ [JUNG] The JUNG Framework Development Team. Java Universal Network/Graph Framework http://jung.sourceforge.net/ [Moodle] Martin Dougiamas. Modular Object-Oriented Dynamic Learning Environment http://moodle.org/ [Redaccin] Jos A. Mari Mutt. Manual de Redaccin Cientfica Universidad de Puerto Rico, Departamento de Biologa. http://caribjsci.org/epub1/index.htm [Redondo] Miguel ngel Redondo Duque. Planificacin Colaborativa del Diseo en Entornos de Simulacin para el Aprendizaje a Distancia Universidad de Castilla - La Mancha, Escuela Superior de Informtica. Marzo de 2002. http://chico.inf-cr.uclm.es/mredondo/dsk/inves/tesis/tesis.pdf [Struts] The Apache Software Foundation. Apache Jakarta Struts Framework http://struts.apache.org/1.x/userGuide/ [TibcoRIA] TIBCO Software Inc. Ajax Rich Internet Application Resource Center http://www.tibco.com/software/rich_internet_application/general_interface/ [W3CBreves] The World Wide Web Consortium (W3C). Guas Breves de Tecnologas W3C http://www.w3c.es/Divulgacion/Guiasbreves/
347
[W3Schools] Refsnes Data. Full Web Building Tutorials - All Free http://www.w3schools.com/ [Wikipedia] Wikimedia Fundation. Wikipedia, The Free Encyclopedia http://en.wikipedia.org/ [XML] The World Wide Web Consortium (W3C). Extensible Markup Language (XML) http://www.w3.org/XML/ [XMLSchema] The World Wide Web Consortium (W3C). XML Schema http://www.w3.org/XML/Schema
348
349
NDICE ALFABTICO
Domtica 23, 48, 51, 52, 53, 55, 66, 346
A
Action 35, 114, 132, 133, 134, 143, 167, 168, 169, 170, 171, 172, 180, 181, 184, 263, 264, 265, 267, 268, 269, 270, 271, 272, 273, 274, 275, 276, 277, 278 Actor 84 AJAX 4, 20, 29, 31, 32, 38, 41, 49, 58, 59, 62, 65, 69, 70, 71, 73, 74, 75, 78, 82, 111, 112, 116, 125, 126, 162, 187, 251, 266, 271, 339 Alcance 47, 51 Anlisis 6, 60, 103, 104, 105, 106, 338
E
Eclipse 34, 35, 42, 43 Edicin 75, 334 Editar 201, 202 Entidad 22, 130, 146 Entorno 49, 58 Escenario 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102 Especificacin 22, 78, 79, 81, 83, 116, 117, 120 Estructura 6, 22, 115 Estudio 6, 22, 49, 50, 51, 52, 66, 68
B
Bean 183
F
Formato 71, 74, 75, 122, 127 Formulario 327 Framework 41, 69, 75, 347
C
Caso de Uso 85, 88, 93, 96, 100, 104, 105, 106, 108, 109, 110, 111, 112, 113 Casos de Uso 83, 85 Clase 108, 109, 110, 111, 112, 113, 148, 149, 150, 151, 152, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175 Clasificacin 69 Cdigo Fuente 203 Conexin 310, 324 Configuracin 179 Construccin 122, 124 Controlador 4, 35, 78, 104, 105, 106, 111, 114, 123, 132, 143 CSS 29, 33, 38, 203, 312
G
Gestin 23, 38, 66, 327, 330 Gestionar 63, 64, 79, 80, 85, 93, 100, 104, 105, 106, 108, 109, 110, 111, 112, 113, 117, 118, 119, 124, 201, 332 GraphML 25, 27, 28, 40, 41, 69, 70, 134, 142, 145, 158, 159, 160, 161, 229, 231, 232, 346
I
Identificacin 22, 61, 62, 63, 104 Implementacin 108, 109, 110, 111, 112, 113 Instalacin 323, 325 Integracin 38, 42, 122, 128 Interconexin 64, 122, 126 Interfaz de Usuario 115, 117, 118, 119, 120, 127 Internet 4, 20, 21, 23, 25, 29, 31, 36, 49, 58, 63, 78, 82, 127, 324, 339, 347 IU 115, 116
D
Desarrollo 23, 36, 38, 69, 70 Descripcin de Clases 108 Despliegue 325 Detalle IU 116 Diagrama 83, 107, 135, 146, 176, 201, 330 Diagrama de Clases 107 Diagrama de Componentes 176 Diagrama de Flujo IU 115 Diagrama de Paquetes 135 Diccionario de Datos 147 Disear 79, 80, 82, 88, 96, 104, 105, 108, 109, 111, 112, 117, 118, 124, 149, 150, 164, 165, 166, 172 Diseo 6, 55, 69, 70, 71, 123, 131, 338, 347 Dojo 29, 30, 33, 38, 39, 70, 73, 125, 126, 173, 174, 175, 308, 324, 346
J
Java 29, 34, 35, 38, 40, 41, 54, 55, 56, 66, 69, 70, 71, 104, 105, 106, 108, 109, 110, 113, 173, 174, 175, 181, 203, 294, 324, 325, 347 JavaScript 26, 29, 30, 31, 38, 42, 104, 105, 106, 111, 112, 173, 174, 175, 346 JEE 34, 35, 36, 179, 347
350
JSON 20, 26, 31, 32, 38, 162, 250, 266, 271, 311, 339 JSP 34, 35, 104, 105, 106, 111, 112, 178, 179, 203, 294 JUNG 41, 158, 159, 324, 347
Struts 23, 26, 34, 35, 36, 104, 105, 106, 113, 114, 132, 134, 143, 179, 180, 182, 183, 202, 324, 347
T
Tiles 35, 36, 143, 187, 192, 193, 194 Toolkit 29, 30, 33, 38, 70, 73, 125, 126, 173, 174, 175, 324, 346
M
Manual 323, 326, 347 Modelo 4, 35, 77, 78, 104, 105, 106, 108, 109, 110, 111, 114, 120, 123, 132, 144 Modelo de Requerimientos 77 MVC 4, 20, 34, 35, 49, 62, 78, 82, 108, 116, 131, 132, 133, 134, 142
U
Usuario 80, 84, 85, 86, 87, 88, 89, 90, 91, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 110, 113, 115, 117, 118, 119, 120, 124, 127, 201, 202, 326, 328
P
Paquete 136, 137, 138, 139, 140, 141, 148, 151, 155, 158, 162, 163, 166, 167, 171, 173, 204, 210, 215, 229, 247, 252, 261, 263, 273, 279 Patrn 132, 133 Plan de Aceptacin 121 Procesar 145 Prototipo 122, 124, 126, 127, 128
V
Validator 35, 36, 113, 143, 188, 189, 202 Viabilidad 50, 51, 68 Vista 4, 35, 78, 104, 105, 106, 111, 112, 113, 114, 123, 132, 143
R
Recurso 324 Relacin 22, 130, 146 Requerimiento 108, 109, 110, 111, 112, 113 Requerimientos no funcionales 81, 126, 127, 128
W
W3C 20, 25, 27, 33, 49, 62, 82, 347, 348 Web 4, 20, 21, 25, 29, 31, 32, 33, 34, 35, 38, 42, 44, 48, 49, 51, 54, 55, 56, 58, 62, 65, 66, 75, 78, 82, 116, 122, 132, 173, 180, 327, 339, 347, 348
S
SAX 40 Sistema 47, 48, 49, 60, 123, 128
X
XML 20, 25, 26, 27, 28, 31, 32, 33, 34, 35, 38, 40, 42, 48, 49, 56, 62, 69, 70, 71, 72, 73, 74, 75, 82, 104, 105, 106, 113, 145, 158, 159, 160, 181, 185, 187, 188, 194, 195, 201, 348 XML Schema 27, 28, 42, 348
351

Entorno Web 2.0 para El Diseño de Diagramas de Interconexión de Objetos

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Entorno Web 2.0 para El Diseño de Diagramas de Interconexión de Objetos

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSIDAD DE OVIEDO

ESCUELA UNIVERSITARIA DE INGENIERA TCNICA EN INFORMTICA DE OVIEDO

PROYECTO FIN DE CARRERA

ENTORNO WEB 2.0 PARA EL DISEO DE DIAGRAMAS DE INTERCONEXIN DE OBJETOS

DIRECTOR: Jos Emilio Labra Gayo AUTOR: Jos Barranquero Tolosa

0.00 0.01 0.02 0.03 0.05 1.00 1.01

28/01/2007 19/02/2007 12/05/2007 28/05/2007 09/07/2007 20/08/2007 26/08/2007

1.7. Libreras y Herramientas............................................................................................37

CAPTULO 2: ESTUDIO DE VIABILIDAD................................................................... 46

2.2. Estudio de la Situacin Actual ................................................................................52

2.3. Requisitos Iniciales del Sistema ...............................................................................60

2.4. Alternativas de Solucin...........................................................................................65

2.5. Ampliaciones del Estudio de Viabilidad ...............................................................68

CAPTULO 3: ANLISIS ........................................................................................... 76

3.2. Especificacin de Casos de Uso ............................................................................83

3.3. Anlisis de Clases.................................................................................................... 103

3.4. Definicin de Interfaces de Usuario.................................................................... 115

3.5. Plan de Aceptacin .............................................................................................. 121

3.6. Prototipos.................................................................................................................. 125

CAPTULO 4: DISEO ........................................................................................... 130

4.2. Diagramas de Clases............................................................................................. 134

4.3. Diagramas de Secuencia..................................................................................... 142

4.4. Diagrama Entidad-Relacin................................................................................. 146 4.5. Diccionario de Datos ............................................................................................. 147

4.6. Diagrama de Componentes................................................................................ 176

CAPTULO 5: CONSTRUCCIN............................................................................ 178

5.2. Cdigo Fuente .........................................................................................................203

CAPTULO 6: MANUALES ..................................................................................... 322

6.2. Manual de Usuario ..................................................................................................326

CAPTULO 7: CONCLUSIONES ............................................................................. 336

1.4. Estructura de la Documentacin

1.5. Evolucin del Proyecto

1.6.2. XML Schema

1.6.5. AJAX y JSON

1.7. Libreras y Herramientas

1.7.1. Dojo Toolkit

1.7.4. Eclipse Web Tools Platform

1.7.5. Visual Paradigm

CAPTULO 2: ESTUDIO DE VIABILIDAD

2.1. Definicin del Alcance del Sistema

2.1.1. Descripcin Inicial del Sistema

2.1.2. Objetivos Iniciales del Sistema

2.1.3. Objetivos del Estudio de Viabilidad

2.1.4. Alcance del Estudio de Viabilidad

2.2. Estudio de la Situacin Actual

2.2.1. Descripcin de los Sistemas Existentes

Fig. 2-1. Espacio de simulacin de DomoSim-TPC

Fig. 2-2. Arquitectura de DomoSim-TPC

Fig. 2-3. Crear componente en DomoEdit

Fig. 2-4. Diseo de ejercicios en DomoEdit

Fig. 2-5. Chequear conexin en DomoApplet

Finalmente se evala la solucin propuesta por el alumno.

Fig. 2-6. Solucin de un ejercicio en DomoApplet

Requiere Java 2 para visualizar las pginas Web con DomoApplet.

2.2.2. Diagnstico de la Situacin Actual

2.3. Requisitos Iniciales del Sistema

2.3.1. Identificacin de las Directrices Generales

2.3.2. Identificacin de las Directrices Tcnicas

2.3.3. Identificacin de Requisitos Funcionales

2.4. Alternativas de Solucin

2.4.1. Estudio de Alternativas de Solucin

2.4.2. Planificacin de Alternativas de Solucin

2.5. Ampliaciones del Estudio de Viabilidad

2.5.1. Clasificacin de los Sistemas Evaluados