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

UNIVERSIDAD DE OVIEDO

ESCUELA UNIVERSITARIA DE INGENIERÍA TÉCNICA EN INFORMÁTICA DE OVIEDO

PROYECTO FIN DE CARRERA

“ENTORNO WEB 2.0 PARA EL DISEÑO DE DIAGRAMAS DE INTERCONEXIÓN 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 Diseño de Diagramas de Interconexión de Objetos

1


PALABRAS CLAVE Diagrama Diseño Editor Interconexión Objeto Entorno Colaborativo Web Semántica AJAX Gráficos Vectoriales GraphML Modelo-Vista-Controlador Struts

2


3


RESUMEN La aplicación consta de dos partes: cliente y servidor. La parte servidor se desarrollará mediante el patrón Modelo-VistaControlador (MVC) junto con el empleo de diversas tecnologías de Web Semántica que aporten extensibilidad y simplifiquen en la medida de lo posible el diseño del modelo de datos y de comportamiento que servirá de lenguaje común 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 más amigable para el usuario, similar a las aplicaciones típicas de escritorio, que además no requiera ninguna instalación adicional por parte del usuario. También se valorará la viabilidad de implementar un entorno colaborativo dónde varios usuarios puedan interaccionar simultáneamente sobre el mismo diagrama de forma similar a las posibilidades que ofrece una pizarra compartida. compartida. Respecto a los requisitos funcionales, básicamente se espera conseguir la misma funcionalidad que cualquier otra aplicación de diseño de diagramas, circuitos, redes, etc. Añadiendo la posibilidad de diseñar nuevos objetos y tecnologías según 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 conexión a Internet.

4


5


HISTÓRICO DE VERSIONES Versión

Fecha

Resumen de los cambios producidos

0.00 0.01 0.02

28/01/2007 Estructura y formato. 19/02/2007 Estudio de viabilidad. 12/05/2007 Tecnologías, librerías y herramientas.

0.03

28/05/2007 Prototipos preliminares del cliente.

0.05

09/07/2007 Análisis y Diseño preliminares.

1.00 1.01

20/08/2007 Primer borrador completo. 26/08/2007 Versión definitiva de este documento.

6


7


TABLA DE CONTENIDOS PALABRAS CLAVE.................................................................................................... 2 RESUMEN.................................................................................................................. 4 HISTÓRICO DE VERSIONES ...................................................................................... 6 TABLA DE CONTENIDOS .......................................................................................... 8 ÍNDICE DE FIGURAS ............................................................................................... 12 ÍNDICE DE TABLAS ................................................................................................. 14 CAPÍTULO 1: MEMORIA ......................................................................................... 18 1.1. Agradecimientos.......................................................................................................19 1.2. Objetivos .....................................................................................................................20 1.3. Motivación..................................................................................................................21 1.4. Estructura de la Documentación...........................................................................22 1.5. Evolución del Proyecto ............................................................................................23 1.6. Tecnologías.................................................................................................................24 1.6.1. 1.6.2. 1.6.3. 1.6.4. 1.6.5. 1.6.6. 1.6.7. 1.6.8.

XML............................................................................................................................... 25 XML Schema............................................................................................................... 27 GraphML ..................................................................................................................... 28 JavaScript ................................................................................................................... 29 AJAX y JSON............................................................................................................... 31 CSS ............................................................................................................................... 33 JEE ................................................................................................................................ 34 Struts............................................................................................................................. 35

1.7. Librerías y Herramientas............................................................................................37 1.7.1. 1.7.2. 1.7.3. 1.7.4. 1.7.5. 1.7.6.

Dojo Toolkit.................................................................................................................. 38 SAX ............................................................................................................................... 40 JUNG ............................................................................................................................ 41 Eclipse Web Tools Platform ...................................................................................... 42 Visual Paradigm......................................................................................................... 43 GIMP ............................................................................................................................ 44

CAPÍTULO 2: ESTUDIO DE VIABILIDAD................................................................... 46 2.1. Definición del Alcance del Sistema.......................................................................47 2.1.1. 2.1.2. 2.1.3. 2.1.4.

Descripción Inicial del Sistema................................................................................ 48 Objetivos Iniciales del Sistema ................................................................................ 49 Objetivos del Estudio de Viabilidad ....................................................................... 50 Alcance del Estudio de Viabilidad ........................................................................ 51

2.2. Estudio de la Situación Actual ................................................................................52 2.2.1. Descripción de los Sistemas Existentes .................................................................. 53 2.2.2. Diagnóstico de la Situación Actual ....................................................................... 59

2.3. Requisitos Iniciales del Sistema ...............................................................................60 2.3.1. Identificación de las Directrices Generales.......................................................... 61 2.3.2. Identificación de las Directrices Técnicas ............................................................ 62 2.3.3. Identificación de Requisitos Funcionales.............................................................. 63

2.4. Alternativas de Solución...........................................................................................65 2.4.1. Estudio de Alternativas de Solución....................................................................... 66 2.4.2. Planificación de Alternativas de Solución ............................................................ 67

2.5. Ampliaciones del Estudio de Viabilidad ...............................................................68 2.5.1. Clasificación de los Sistemas Evaluados ............................................................... 69

8


CAPÍTULO 3: ANÁLISIS........................................................................................... 76 3.1. Modelo de Requerimientos.....................................................................................77 3.1.1. Especificación Textual...............................................................................................78 3.1.2. Especificación de Requerimientos Funcionales...................................................79 3.1.3. Especificación de Requerimientos No Funcionales.............................................81

3.2. Especificación de Casos de Uso ............................................................................83 3.2.1. Actores ......................................................................................................................... 84 3.2.2. Casos de Uso...............................................................................................................85

3.3. Análisis de Clases.................................................................................................... 103 3.3.1. Identificación de Clases Asociadas a Casos de Uso ........................................104 3.3.2. Diagrama de Clases (Preliminar) ..........................................................................107 3.3.3. Descripción de Clases (Preliminar) .......................................................................108

3.4. Definición de Interfaces de Usuario.................................................................... 115 3.4.1. Especificación de Principios Generales...............................................................116 3.4.2. Especificación de Formatos Individuales ............................................................117 3.4.3. Especificación del Comportamiento Dinámico ................................................120

3.5. Plan de Aceptación .............................................................................................. 121 3.5.1. Fase 1: Construcción de Prototipos Básicos........................................................122 3.5.2. Fase 2: Diseño Detallado del Sistema ..................................................................123 3.5.3. Fase 3: Construcción del Prototipo Final..............................................................124

3.6. Prototipos.................................................................................................................. 125 3.6.1. Prototipo 1: Interconexión de Componentes.....................................................126 3.6.2. Prototipo 2: Formato de la Interfaz de Usuario ...................................................127 3.6.3. Prototipo 3: Integración de capas del Sistema..................................................128

CAPÍTULO 4: DISEÑO ...........................................................................................130 4.1. Patrones de Diseño ................................................................................................ 131 4.1.1. Patrón Modelo-Vista-Controlador (MVC)............................................................132 4.1.2. Otros patrones empleados ....................................................................................133

4.2. Diagramas de Clases............................................................................................. 134 4.2.1. 4.2.2. 4.2.3. 4.2.4. 4.2.5. 4.2.6. 4.2.7.

Diagrama de Paquetes .......................................................................................... 135 Paquete “model”.....................................................................................................136 Paquete “model.persistence” ...............................................................................137 Paquete “model.graphml” ....................................................................................138 Paquete “common”................................................................................................139 Paquete “controller” ...............................................................................................140 Paquete “view” ........................................................................................................141

4.3. Diagramas de Secuencia..................................................................................... 142 4.3.1. Interacción Vista – Controlador ............................................................................143 4.3.2. Interacción Modelo – Persistencia........................................................................144 4.3.3. Procesar archivo GraphML ....................................................................................145

4.4. Diagrama Entidad-Relación................................................................................. 146 4.5. Diccionario de Datos............................................................................................. 147 4.5.1. 4.5.2. 4.5.3. 4.5.4. 4.5.5. 4.5.6.

Paquete “model”.....................................................................................................148 Paquete “model.persistence” ...............................................................................151 Paquete “model.graphml” ....................................................................................158 Paquete “common”................................................................................................162 Paquete “controller” ...............................................................................................166 Paquete “view” ........................................................................................................173

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

9


CAPÍTULO 5: CONSTRUCCIÓN............................................................................ 178 5.1. Ficheros de Configuración ....................................................................................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. Código Fuente .........................................................................................................203 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

CAPÍTULO 6: MANUALES ..................................................................................... 322 6.1. Manual de Instalación............................................................................................323 6.1.1. Requisitos Mínimos ................................................................................................... 324 6.1.2. Instalación y despliegue ........................................................................................ 325

6.2. Manual de Usuario ..................................................................................................326 6.2.1. Gestión de Usuarios................................................................................................. 327 6.2.2. Gestión de Diagramas ........................................................................................... 330 6.2.3. Edición de Diagramas............................................................................................ 334

CAPÍTULO 7: CONCLUSIONES............................................................................. 336 7.1. Resultados.................................................................................................................337 7.2. Entregables...............................................................................................................340 7.3. Ampliaciones............................................................................................................341

GLOSARIO ........................................................................................................... 344 BIBLIOGRAFÍA...................................................................................................... 346 ÍNDICE ALFABÉTICO ............................................................................................ 350

10


11


ÍNDICE DE FIGURAS Fig. Fig. Fig. Fig. Fig. Fig.

2-1. Espacio de simulación de DomoSim-TPC .....................................................54 2-2. Arquitectura de DomoSim-TPC .......................................................................54 2-3. Crear componente en DomoEdit ..................................................................55 2-4. Diseño de ejercicios en DomoEdit..................................................................55 2-5. Chequear conexión en DomoApplet ...........................................................56 2-6. Solución 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: Diseñar Diagramas (R2) ...........................................117 Fig. 3-6. Interfaz de Usuario 3: Gestionar Componentes (R3).................................118 Fig. 3-7. Interfaz de Usuario 4: Diseñar Componentes (R4) .....................................118 Fig. 3-8. Interfaz de Usuario 5: Gestionar Cuentas de Usuario (R5) .......................119 Fig. 3-9. Modelo de Navegación de la Interfaz de Usuario ...................................120 Fig. 3-10. Prototipo 1: Interconexión de Componentes ..........................................126 Fig. 3-11. Prototipo 2: Formato de la Interfaz de Usuario ........................................127 Fig. 3-12. Prototipo 3: Integración de capas del Sistema .......................................128 Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig. Fig.

4-1. Diagrama de Paquetes ..................................................................................13 5 4-2. Paquete “model”.............................................................................................136 4-3. Paquete “model.persistence”.......................................................................137 4-4. Paquete “model.graphml” ............................................................................138 4-5. Paquete “common”........................................................................................139 4-6. Paquete “controller” .......................................................................................14 0 4-7. Paquete “view” ................................................................................................14 1 4-8. Interacción Vista –Controlador .....................................................................143 4-9. Interacción Modelo – Persistencia ...............................................................144 4-10. Procesar archivo GraphML ..........................................................................145 4-11. Diagrama Entidad-Relación........................................................................146 4-12. Diagrama de Componentes.......................................................................176

Fig. Fig. Fig. Fig. Fig. Fig. Fig.

7-1. Formulario de conexión..................................................................................327 7-2. Crear usuario.....................................................................................................328 7-3. Datos de la cuenta de usuario .....................................................................329 7-4. Crear diagrama ...............................................................................................330 7-5. Consultar diagramas.......................................................................................331 7-6. Gestionar permisos sobre diagramas ..........................................................332 7-7. Edición 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 modificación 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: Diseñar Diagramas (R2).................................................88 Tabla 3.2-10. Escenario 2.1: Definir dimensiones del área de diseño (R2.1) .........88 Tabla 3.2-11. Escenario 2.2: Añadir 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 básicas (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 modificación 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 / c ompartir 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: Diseñar Componentes (R4) ........................................96 Tabla 3.2-24. Escenario 4.1: Definir dimensiones del componente (R4.1) .............96 Tabla 3.2-25. Escenario 4.2: Añadir y eliminar formas básicas (R4.2) .....................97 Tabla 3.2-26. Escenario 4.3: Definir zonas de interconexión (R4.3) .........................97 Tabla 3.2-27. Escenario 4.4: Aplicar transformaciones básicas (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 modificación 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 estadístic as y puntuaciones (R5.4) .........102

14


Tabla 3.3-1. Análisis del Caso de Uso 1: Gestionar Diagramas (R1)..................... 104 Tabla 3.3-2. Análisis del Caso de Uso 2: Diseñar Diagramas (R2) ..........................104 Tabla 3.3-3. Análisis del Caso de Uso 3: Gestionar Componentes (R3) ...............105 Tabla 3.3-4. Análisis del Caso de Uso 4: Diseñar Componentes (R4)....................105 Tabla 3.3-5. Análisis 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: Interconexión de Componentes .....................................126 Tabla 3.6-2. Prototipo 2: Formato de la Interfaz de Usuario ...................................127 Tabla 3.6-3. Integración 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 ..................................................................................15 0 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 .......................................................................................15 4 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 ..............................................................................................17 4 Tabla 4.6-39. Clase Link..................................................................................................175 Tabla 7.1-1. Requisitos hardware .................................................................................324 Tabla 7.1-2. Requisitos software ...................................................................................324

16


17


I A CAPÍTULO 1: MEMOR A Este primer capítulo se dedica a la descripción general del proyecto realizado, basada en los objetivos que se persiguen alcanzar y la motivación que justifica el planteamiento del mismo. Se expone brevemente la estructura general de este documento, así como la evolución del proyecto a lo largo de su ciclo de vida. Finalmente se describen en mayor detalle las tecnologías, librerías y herramientas estudiadas y que han servido de soporte al proyecto.

18


1.1. Agradecimientos Este proyecto nunca podría haberse encarado sin el apoyo de todas las personas que supieron darme ánimos en los momentos más duros. En primer lugar a mi director José Emilio Labra Gayo por su inestimable visión práctica del problema y su enfoque didáctico y humano de esta experiencia. A mi compañera Sheila Méndez Núñez 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 más completo y funcional posible de un entrono de diseño de diagramas de interconexión de objetos a través de Internet. Se busca una aplicación escalable que admita ampliaciones continuas, sin necesidad de remodelar las funcionalidades desarrolladas previamente. Para lo cual se emplea el patrón de diseño MVC que garantiza cierta independencia entre las diferentes capas del sistema y favorece la separación de responsabilidades. En principio el sistema está pensado como una aplicación Web que permita a los usuarios acceder a su funcionalidad desde cualquier ordenador con conexión a Internet, facilitando en la medida de lo posible la internacionalización de los recursos y la usabilidad y accesibilidad de los mismos. Como objetivo específico, se espera poder emplear tecnologías Web 2.0, como AJAX y JSON, que aporten un grado mucho más elevado de interactividad al cliente Web, tratando de aproximar la experiencia del usuario a la de las aplicaciones típicas de escritorio. También 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 consecución del resto de los objetivos presentados. Dadas las necesidades de escalabilidad funcional del sistema sería muy conveniente desarrollar un lenguaje específico del dominio, permitiendo a los usuarios diseñar nuevos componentes bien directamente o bien mediante algún editor diseñado a tal efecto. Otro de los objetivos técnicos específicos es conseguir desarrollar un entorno independiente del navegador utilizado, basado en estándares del W3C y en técnicas y patrones AJAX ampliamente utilizados, preferiblemente mediante alguna librería o herramienta de código libre. Se tendrán 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 diseño donde situar objetos y definir conexiones entre ellos, de un modo similar a otras aplicaciones existentes de diseño de diagramas UML, redes de ordenadores, circuitos digitales…, pero completamente genérico y extensible. El entorno desarrollado fomentará la colaboración entre los usuarios mediante técnicas y mecanismos adecuados que permitan compartir recursos, discutir opiniones, valorar contenidos, acceso incremental a contenidos y funcionalidad según puntuaciones, etc. Finalmente se pretende distribuir el sistema como un proyecto de código abierto basado en licencias que permitan su libre ampliación y reutilización. 20


1.3. Motivación El proyecto surge de la necesidad de ubicuidad actual de las aplicaciones, que normalmente exigen la instalación 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 máquinas virtuales. Este proyecto propone una alternativa mucho más atractiva que evita la necesidad de realizar ninguna descarga o instalación adicional, además de ser completamente gratuito y permitir el libre acceso al código fuente. La idea básica es desarrollar una aplicación Web que sirva de soporte y almacenamiento persistente de los contenidos diseñados por los usuarios que facilite el acceso a los mismos desde cualquier ordenador y la colaboración síncrona de los usuarios en tiempo real, del mismo modo que las pizarras compartidas típicas de los sistemas de e-Learning. Debe existir un claro enfoque a la libertad de acción 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 búsqueda de contenidos como en su progresión formativa. El fomento de la colaboración y comunicación entre usuarios es la forma más segura y rápida de aumentar el volumen de contenidos y componentes, permitiendo además que los usuarios compartan sus propios recursos. Desarrollar el afán de superación de los usuarios puede resultar ventajoso, aunque arriesgado. Se podría experimentar con el uso de un sistema de ranking’s y estadísticas que permitan una visión global de la evolución o las destrezas propias de cada usuario. Motivando a los usuarios a mejorar dicha situación a través de la realización de pruebas, añadiendo contenidos o componentes, con valoraciones positivas de otros usuarios, etc. También se busca estudiar técnicas de esfuerzo-recompensa con un sistema de bonificación (acceso a recursos avanzados, nuevas funcionalidades o privilegios,…), tratando de conseguir una experiencia más atractiva y motivadora a los usuarios, que sin duda son el elemento clave del sistema. En resumen, la motivación principal es el estudio de viabilidad y el lanzamiento de una alternativa de código abierto que permita diseñar diagramas en un entorno colaborativo, aplicando tecnologías de Web Semántica y Web 2.0, accediendo a sus funcionalidades desde cualquier ordenador con conexión a Internet y facilitando el intercambio de recursos entre los usuarios.

21


1.4. Estructura de la Documentación CAPITULO 1: MEMORIA Descripción de los objetivos y motivación del proyecto, evolución y estudio de tecnologías, librerías y herramientas. CAPITULO 2: ESTUDIO DE VIABILIDAD Estudio del estado del arte durante la fase de definición del proyecto, objetivos iniciales, estudio de viabilidad y planificación de alternativas. Descripción y clasificación de los sistemas existentes y especificación de requisitos y directrices iniciales. CAPITULO 3: ANÁLISIS Especificación de los requerimientos del sistema, identificación y análisis de casos de uso, actores y escenarios. Identificación y descripción inicial de las clases, definición de la estructura y formato de la interfaz de usuario, prototipos y plan de aceptación. CAPITULO 4: DISEÑO Breve descripción de los patrones de diseño empleados, división del sistema en paquetes o subsistemas, diagramas de clases por capas, diagramas de secuencia, diagrama Entidad-Relación, descripción detallada de las clases y diagrama de componentes. CAPITULO 5: CONSTRUCCIÓN Descripción y contenido de los ficheros de configuración y del código fuente desarrollado. CAPITULO 6: MANUALES Explicación de los pasos necesarios para la instalación del sistema y manual de usuario final. CAPITULO 7: CONCLUSIONES Conclusiones derivadas del trabajo realizado, resultados obtenidos, entregables y ampliaciones propuestas. GLOSARIO BIBLIOGRAFÍA ÍNDICE ALFABÉTICO

22


1.5. Evolución del Proyecto Inicialmente el sistema tenía como dominio de aplicación las tecnologías relativas a la Domótica y la Inmótica, buscándose el desarrollo de un entrono de diseño de circuitos domóticos para ser empleado en las prácticas de la asignatura optativa “Domótica y Edificios Inteligentes” de la Escuela Universitaria de Ingeniería Técnica en Informática de Oviedo. Los requisitos planteados no recogían aspectos de índole técnica concretos, sino que más bien se buscaba una funcionalidad específica. De cara a afrontar el desarrollo del proyecto se opta por cursar las asignaturas optativas “Desarrollo de Aplicaciones en Entornos Distribuidos e Internet” y “Administración de Sistemas de Gestión de Bases de Datos” que han servido de apoyo en el empleo de Struts y Oracle respectivamente. Tras un estudio de la situación actual y de las tecnologías, librerías y herramientas disponibles se generaliza el dominio de aplicación al diseño de diagramas de cualquier tipo, incluyendo el dominio de aplicación inicial, pero centrando el proyecto en la consecución de una serie de objetivos entre los que destacan: escalabilidad, extensibilidad, usabilidad, accesibilidad, ubicuidad, multiplataforma, independencia del navegador, colaboración…, y tratando de desarrollar un entorno que además permitiese la colaboración síncrona de los usuarios. El método de desarrollo elegido es el de prototipado ágil, mediante prototipos reutilizables que han facilitado la elaboración de la especificación final de requerimientos y casos de uso, así como la evolución del diseño de clases y del comportamiento dinámico del sistema mediante la evaluación 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 limitación temporal implícita en el propio proyecto. Dicho alcance recoge los objetivos mencionados este capítulo 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 análisis actual y que seguramente se desarrolle en una versión futura.

23


1.6. Tecnologías Este apartado únicamente cubre las tecnologías investigadas de mayor peso en el proyecto y que quedan fuera de los conocimientos básicos adquiridos durante de la carrera o los amplían.

24


1.6.1. XML Se trata de un estándar aprobado por el W3C que define un lenguaje extensible de marcado, es decir, la estructura del documento se construye mediante etiquetas. Cada vez más proyectos se apoyan en las enormes posibilidades de este lenguaje y se ha convertido en una referencia obligada en la comunicación estructurada entre sistemas, especialmente en el ámbito de Internet, la Web Semántica y los Servicios Web. Aunque podría considerarse un lenguaje por sí mismo, en la práctica se emplea para construir vocabularios específicos 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. Además se pueden definir los tipos de estos elementos y atributos, así como el número de ocurrencias y el orden o jerarquía 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 anidación de etiquetas, por otro el de documento válido que supone la adecuación 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 además permite compatibilidad hacia atrás, 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. También es vital el hecho de que sea un estándar internacional , empleado en infinidad de contextos con notables ventajas de integración 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 fácil de leer y entender en comparación con otros formatos, disponiendo de multitud de herramientas para su edición y visualización. Finalmente también se puede destacar que, a diferencia de HTML, separa el contenido del formato, permitiendo su visualización y transformación en infinidad de dispositivos.

25


1.6.1.2. Desventajas Quizá la mayor desventaja que puede presentarse es el tamaño de los ficheros de este tipo en comparación con otros formatos como JSON, de cara a comunicar datos entre el cliente y el servidor en el sistema a desarrollar. También hay que tener en cuenta que el cliente va a ser desarrollado mediante JavaScript, con soporte directo para JSON y como consecuencia su transformación y utilización es casi inmediata, en comparación con XML que necesitaría ser analizado y generado también desde el propio cliente, ralentizando significativamente la sincronización entre los usuarios que trabajen de manera colaborativa.

1.6.1.3. Conclusiones En principio se adopta XML como formato de serialización 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 información entre cliente y servidor para agilizar este proceso. También es de uso obligado para poder emplear otras tecnologías y herramientas como Struts o Ant, expuestas en mayor detalle más 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 más rígida y limitada. Además 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 válido 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 programación y permite crear nuevos tipos o extender los existentes. Se trata de un estándar internacional propuesto por el W3C, ampliamente utilizado por definir vocabularios específicos 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 comprensión. Soporta espacios de nombres que facilitan la redefinición de elementos, atributos, tipos, grupos y restricciones. Simplifica las relaciones jerárquicas de herencia mediante grupos de sustitución, 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 tamaño, 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 continuación.

27


1.6.3. GraphML Es un vocabulario fácil 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 gráficas.

1.6.3.1. Ventajas El núcleo principal del lenguaje permite representar grafos básicos, pero además permite añadir datos específicos para cada aplicación, sin que dichos datos adicionales influyan en otras aplicaciones. Al contrario que otros lenguajes de representación de grafos, emplea XML como soporte, por lo que se beneficia de todas las ventajas propias de este lenguaje. También 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 diseño 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 semánticos mucho más eficientes.

1.6.3.2. Desventajas Puede presentar problemas de tamaño 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 serialización de los diagramas, posiblemente mediante este vocabulario, sin embargo se estudiarán otras alternativas en el intercambio de información 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 página donde se haya incrustado el código. Actualmente está ganando importancia gracias a nuevas tendencias Web 2.0, como AJAX. Existe una versión estandarizada llamada ECMAScript, si bien posee notables limitaciones y existe falta de soporte completo en muchos de los navegadores Web más utilizados hoy en día. 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 más complejo de entender y utilizar. Este defecto puede verse mitigado en gran medida gracias a las numerosas librerías 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 años ha empezado a surgir una nueva tendencia denominada JavaScript no obstructivo, que pretende separar la funcionalidad JavaScript (capa lógica) del resto de capas, como ya se hace con el contenido y la presentación mediante CSS. También 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. Además el código resultante suele ser más ligero y por tanto mucho más rápido. 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 página 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 más y pueden ser empleadas directamente como argumentos de otra función, aumentando enormemente la potencia del lenguaje, ya que se puede emplear para crear código genérico 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 página, los estilos CSS… Sólo sería necesario en el entorno de desarrollo, no en el entorno final. Se puede encontrar mucha documentación e infinidad de ejemplos en Internet con casos prácticos, librerías, entornos de desarrollo, manuales…

29


1.6.4.2. Desventajas No es completamente estándar , de hecho una de las labores más tediosas del desarrollo de un cliente mediante este lenguaje es que el resultado pueda ejecutarse sin problemas en cualquier navegador, optándose normalmente por dar soporte únicamente a los más empleados. Puede llegar a resultar lento y poco escalable en función de la calidad del diseño 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 código que son interpretados por el navegador al cargar la página correspondiente. Necesita que el navegador tenga activada la opción de ejecutar el código JavaScript contenido en las páginas.

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 carácter abierto, principalmente librerías, que simplifican muchos de estos aspectos e incluso añaden una capa de abstracción 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 instalación alguna por parte de los usuarios, además de posibilitar holgadamente el desarrollo de una interfaz de usuario completa. La librería elegida para dar soporte a este lenguaje es Dojo Toolkit, por las ventajas expuestas posteriormente en este mismo capítulo, en el apartado de librerías y herramientas.

30


1.6.5. AJAX y JSON Internet cada vez cobra más importancia en el ámbito científico, tecnológico y social, apareciendo constantemente nuevas tendencias y soluciones que amplían sus funcionalidades. Muchos pensaron que las tecnologías Flash iban a copar el mercado por su vistosidad y aparente facilidad de uso, sin embargo no es libre y además 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 librerías altamente funcionales, comenzando a aparecer nuevos sistemas de intercomunicación cliente-servidor como es el caso de AJAX y JSON. El término AJAX proviene de “Asynchronous JavaScript and XML”, que implica intercambio asíncrono de datos en formato XML entre el cliente y el servidor, sin necesidad de recargar la página, permitiendo enormes posibilidades de diseño de interfaces de usuario completas y usables. Por otro lado, JSON surge de “JavaScript Object Notation”, es decir, notación de objetos JavaScript. La información de transmite también en modo texto, pero no se utiliza un lenguaje de etiquetas como XML. Esta tecnología emplea los mismos mecanismos que utiliza AJAX para transmitir información al servidor, por lo que se puede decir que son prácticamente equivalentes, salvo por el lenguaje empleado para codificar la información.

1.6.5.1. Ventajas Ambas tecnologías permiten diseñar interfaces de usuario en una simple página Web, capaz de responder a eventos, transmitir y recibir información…, y sin necesidad de recargar toda la página. Al tratarse de un intercambio asíncrono 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. Además JSON permite estructurar perfectamente objetos y colecciones, fácilmente reconocibles y procesables por los navegadores, por lo que puede resultar más 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 técnicas de desarrollo de aplicaciones Web están en constante evolución 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 gestión de errores puede llegar a ser compleja en algunas circunstancias y es muy recomendable el empleo de alguna librería para paliar estos inconvenientes. No todos los navegadores implementan estas técnicas del mismo modo, algunos ni siquiera tienen soporte para ellas. En ocasiones el modelo de aplicación Web tradicional es más conveniente debido a la complejidad añadida que supone el uso de estas tecnologías.

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 típicas de escritorio para interaccionar con objetos en un entorno de diseño interactivo, resulta muy apropiado el uso de estas técnicas. Sobre las diferencias entre AJAX y JSON, realmente se puede decir que JSON es un lenguaje que puede ser empleado por AJAX, algo más ligero que XML y cuya principal ventaja es la facilidad con la que los navegadores pueden procesarlo, que es una transformación casi directa. En principio JSON será el mecanismo principal de intercambio de información entre el cliente y el servidor, dejando XML para la serialización, ya que éste sea posiblemente más fácil de entender para un usuario final.

32


1.6.6. CSS Es un acrónimo de “Cascading Style Sheets”, básicamente es un mecanismo que define el formato que va a tener un documento en pantalla, o cómo se va a imprimir, o incluso cómo va a ser pronunciada la información presente en ese documento a través de un dispositivo de lectura. Se emplea para dar estilo a documentos de marcado tipo XML o HTML, separando correctamente el contenido de la presentación. Funciona a base de reglas, es decir, declaraciones sobre el estilo de uno o más elementos, las hojas de estilo están compuestas por una o más de esas reglas y cada regla tiene dos partes: un selector y la declaración, 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, pudiéndose redefinir estilos o incluso combinarlos. Permite controlar el estilo y el formato de múltiples páginas Web al mismo tiempo. Cualquier cambio en el estilo marcado para un elemento en la CSS afectará a todas las páginas vinculadas a esa CSS.

1.6.6.2. Desventajas A pesar de ser un estándar 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 común para varios navegadores distintos.

1.6.6.3. Conclusiones Esta tecnología será empleada para definir un formato de estilo general para todas las páginas Web que conformen el sitio a desarrollar, además Dojo Toolkit hace uso directo de esta tecnología y es indispensable para su correcto funcionamiento.

33


1.6.7. JEE Acrónimo 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 patrón MVC, como Struts. Las aplicaciones desarrolladas con esta tecnología se despliegan sobre un servidor de aplicaciones. A pesar de no ser un estándar ISO o ECMA sí que está definido mediante una especificación que determina el comportamiento básico que debe cumplir cualquier implementación para poder declarar su conformidad con dicha especificación.

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 gestión de los componentes desplegados, derivando en que los desarrolladores pueden dedicar sus esfuerzos en la lógica de negocio de los componentes en lugar de en tareas de mantenimiento de bajo nivel. Otra característica destacable es el gran conjunto de API’s que facilita al desarrollador para trabajar con Servlet’s, 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, pudiéndose encontrar infinidad de recursos de código 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 pequeños que puedan construirse con una solución simple y rápida.

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 estándares como Servlet’s, JavaBean’s, XML o Jakarta Commons. Aporta facilidades para crear aplicaciones escalables gracias al uso de patrones de diseño conocidos y probados como MVC. La aplicación Web se divide en tres subsistemas: Modelo: representa el estado y la lógica de la aplicación. 

Vista: interfaz de usuario (JSP, HTML…). Controlador: gestiona el flujo de la aplicación. La arquitectura de Struts se compone de un único Servlet que hace de Controlador y redirige el flujo de la aplicación entre las acciones y la capa de presentación. Es como un puente entre la Vista y el Modelo. Normalmente toda la lógica de negocio debería estar contenida en el Modelo, si bien en escenarios más simples se podría 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 estándar 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 tecnologías apropiadas para representar la capa de la Vista. Además permite desarrollar esta capa mediante plantillas o tiles, empleando etiquetas especiales de la librería Struts Tiles y simplificando en gran medida su mantenimiento y comprensión. También soporta de manera directa internacionalización basada en la especificación ResourceBoundles de Java, o la propia de Struts. Otra librería recomendada es Struts Validator, que permite validar formularios tanto en el cliente como en el servidor, mediante la definición de restricciones en un archivo XML, evitando el desarrollo de dichas tareas a menudo cotidianas. Además está perfectamente integrada la internacionalización provista por Struts. Proporciona clases base que pueden ser extendidas para implementar las acciones de la aplicación Web, como las clases Action y ActionForm. La mayoría 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 pequeños que admitan soluciones más 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 adopción de Struts, ya que ha demás se dispone de un prototipo completamente funcional que integra Struts Tiles y Validator, internacionalización, DynaActionForms’s…, desarrollado como práctica final de la asignatura “Desarrollo de Aplicaciones en Sistemas Distribuidos e Internet”.

36


1.7. Librerías y Herramientas Este apartado contiene una descripción general de las librerías y herramientas utilizadas o estudiadas durante todo el ciclo de vida del proyecto, incluyendo herramientas de documentación, desarrollo, diseño y análisis.

37


1.7.1. Dojo Toolkit Es una API de código abierto para desarrollar clientes Web completos, es decir, un conjunto de librerías JavaScript distribuidas por niveles de abstracción 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 código abierto esponsorizada por SUN, IBM, SitePen, Renkoo, AOL, JotSpot, TurboAJAX y OpenLaszlo, que pretende renovar la visión esquiva de los desarrolladores hacia JavaScript y que ha evitado la adopción a mayor escala de tecnologías DHTML. Además Dojo prevé un aprendizaje de carácter 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, más que unas nociones básicas de DHTML y CSS. El enfoque de Dojo se basa en el principio de que “una herramienta difícil de usar no se usará, independientemente de lo buena que sea” [Dojo].






Amplia colección de Widgets sin necesidad de código (‘without code’). Desarrollo de Widgets mediante plantillas. Distribución de componentes mediante contenedores o ‘layouts’.



Soporte directo para internacionalización y accesibilidad. Funcionalidades de escritorio como ‘Drag & Drop’ y efectos visuales.



Desarrollo independiente del navegador (cross-browser).











Gestión de eventos y acceso al DOM. Servicios RPC y peticiones asíncronas mediante AJAX y JSON. Analizadores XML basados en JavaScript. Soporte para gráficos vectoriales como SVG y VML.



Conexiones permanentes HTTP mediante Cometd. Compresión de ficheros de código JavaScript.



Integración y desarrollo de casos de prueba mediante D.O.H.







Definición de jerarquías de clases en sintaxis similar a la de Java. Completa documentación, incluida toda la API.

1.7.1.2. Desventajas La principal desventaja es el riesgo inherente en su adopción como librería 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 versión 0.4.3, sin embargo durante el mes de junio fue lanzada una nueva versión, la 0.9.0, como precursora de la primera versión completa de Dojo que será la 1.0. El mayor problema fue que la 0.9.0 no tiene compatibilidad hacia atrás, ya que Dojo ha sufrido una reestructuración completa de su código para mejorar la escalabilidad y comprensión del mismo, así como el rendimiento, las capacidades de internacionalización y accesibilidad. A pesar de la migración necesaria del prototipo inicial que se desarrolló durante el mes de mayo, es más recomendable emplear la versión 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 aplicación 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 más eficiente en muchos contextos.






Emplea manejadores de eventos en lugar de cargar el árbol del documento en memoria, por lo que consume menos recursos y suele ser más eficiente. La mayoría de las librerías 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 más enfocadas a ese propósito.

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. Además supone un ahorro considerable de recursos, permitiendo una mayor escalabilidad del sistema final a desarrollar.

40


1.7.3. JUNG Acrónimo de “Java Universal Network/Graph Framework”, una API de código abierto para Java que propone soluciones comunes y extensibles para el diseño, análisis y visualización de datos representados mediante grafos o redes [JUNG].










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 creación de herramientas de análisis. Tiene soporte para GraphML, que es el vocabulario elegido para la serialización de los diagramas. Permite manipular la distribución de los elementos mediante algoritmos clásicos de la teoría de grafos, que además pueden ser extendidos y especializados. Incluye otras librerías como Apache Commons, Xerces, JAXP y Colt.

1.7.3.2. Desventajas Ofrece un framework de visualización que facilita la construcción de herramientas interactivas, sin embargo sólo soporta Swing y sería necesario adaptarlo para poder emplearlo en un entorno basado en AJAX.

1.7.3.3. Conclusiones En principio únicamente daría soporte a la serialización de los diagramas y su posterior recuperación, sin embargo en futuras versiones podría valorarse su empleo en escenarios de gestión avanzada de grafos, como distribución automática de los elementos según layout’s o la aplicación de algoritmos.

41


1.7.4. Eclipse Web Tools Platform Eclipse es una comunidad de código abierto, cuyos proyectos están enfocados a construir una plataforma de desarrollo extensible que cubra todo el ciclo de vida del software. Esta estructurado mediante plugin’s de tal forma que puede llegar a cubrir casi cualquier campo del desarrollo de un proyecto, incluido el análisis y el diseño mediante UML. Concretamente la versión Web Tools Platform está pensada para desarrollar aplicaciones Web y tiene soporte integrado para multitud de lenguajes como XML, JavaScript…
















Al ser código abierto y extensible, existen multitud de plugin’s para extender su funcionalidad. Es un entorno de desarrollo libre y ampliamente aceptado por su flexibilidad y capacidad de adaptación. Incluye validadores y editores para los lenguajes más empleados en la Web como XML, XML Schema, RDF, JavaScript, XHTML… Soporta compilación, generación de jar’s y despliegue mediante Ant. También incluye una versión propia del navegador Mozilla, con multitud de utilidades para depurar código JavaScript. Integración completa con servidores de aplicaciones, permitiendo depurar en tiempo real la parte servidor de las aplicaciones Web desarrolladas. Está en constante desarrollo, solucionándose defectos existentes y ampliando nuevas funcionalidades.

No requiere instalación.

1.7.4.2. Desventajas Pueden presentarse algunas incompatibilidades generadas por el gran número de plugin’s y las versiones de Eclipse.

1.7.4.3. Conclusiones Se ha elegido esta herramienta por ser de fácil manejo y tener todos los requisitos necesarios para poder desarrollar el proyecto en casi todos sus aspectos. Se ha valorado también el hecho de que sea software libre y extensible.

42


1.7.5. Visual Paradigm Es una herramienta de diseño de diagramas UML con soporte UML 2.1 y 13 tipos distintos de diagramas. Además es extensible, lo cual quiere decir que se pueden definir nuevos tipos de diagramas o componentes por parte del usuario.












Su versión “Community Edition” es de uso libre. Puede integrarse en los IDEs más populares como Eclipse, NetBeans, JBuilder… Soporta ingeniería inversa y generación de código de multitud de lenguajes de programación a partir de los diagramas de clases. Posibilidad de exportar los diagramas a diferentes formatos. Facilidades de visualización, como el uso de layout’s para la disposición 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 versión libre está limitada en cuanto a funcionalidad: no se pueden crear nuevos componentes y sólo 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 diseño de diagramas.

43


1.7.6. GIMP Es una herramienta de código abierto con soporte para edición de casi cualquier tipo de formato de imagen, tanto raster como vectorial.

1.7.6.1. Ventajas Incluye estructuración de imágenes por capas, pudiendo ocultarse o aplicar transformaciones de manera independiente. Posee un historial de acciones que nos permite avanzar o retroceder a cualquier versión del trabajo realizado. Ideal para generar imágenes con transparencia para el diseño 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 número de módulos, que pueden ser desactivados para agilizar este proceso.

1.7.6.3. Conclusiones El empleo de esta herramienta surge de la necesidad de crear imágenes con fondo transparente para el diseño y elaboración de la interfaz de usuario.

44


45


I ABILID AD CAPÍTULO 2: ESTUDIO DE V A En este capítulo se identifican los requisitos iniciales que se han de satisfacer y se estudia la situación actual y las alternativas de solución. Esta información se analiza con el fin de evaluar las distintas alternativas y seleccionar la más adecuada, definiendo y estableciendo su planificación.

46


2.1. Definición del Alcance del Sistema En este apartado se determinan los objetivos y se inicia el estudio de los requisitos. Además se analizan las posibles restricciones que puedan condicionar el estudio y la planificación de las alternativas de solución que se propongan. Partiendo de una descripción general del sistema y unos objetivos iniciales se establecerán los límites y objetivos del propio estudio de viabilidad.

47


2.1.1. Descripción Inicial del Sistema Inicialmente el proyecto a desarrollar era un entorno colaborativo de eLearning aplicado a las disciplinas que abarcan la Domótica y la Inmótica, principalmente el estudio de componentes y tecnologías, así como sus circuitos y reglas de interconexión. El enfoque prioritario es una arquitectura de Aplicación Web, con apoyo de las tecnologías más adecuadas de Web Semántica o Web 2.0 basadas en XML, que faciliten las posibles ampliaciones y su crecimiento autónomo en cuanto a contenidos.

48


2.1.2. Objetivos Iniciales del Sistema

2.1.2.1. Objetivos Técnicos del Sistema 



Disponibilidad: Aplicación Web (basada en patrón MVC) Dinamismo e interactividad: AJAX.



Internacionalización (mínimo inglés y español). Extensibilidad: vocabulario XML entre cliente y servidor.



Facilidad de uso: estándares W3C, accesibilidad, usabilidad…







Definición de un lenguaje específico del dominio y extensible. Meta-información: descripción de los recursos mediante RDF.



Estudio de la viabilidad de definir o reutilizar una ontología 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 Web 2.0: compartir recursos, discutir opiniones… Sistemas de puntuación y ranking’s por categorías.



Pruebas teórico-prácticas de autoevaluación o seguimiento.











49

Búsqueda de documentación y ejemplos prácticos. Búsqueda de profesionales cualificados por perfil. Acceso incremental a contenidos y funcionalidad según puntuaciones. Base de datos de usuarios, currículos, documentos, artículos…


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 técnicas y de gestión, así como los requisitos funcionales preliminares. Evaluar las distintas alternativas en función de los requisitos identificados. Determinar la alternativa de solución más 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 limitación respecto a la escalabilidad del sistema. Si se diera la situación de encontrar un producto que cubra las necesidades del proyecto sería necesario evaluar otros factores de costes, riesgos y escalabilidad que podrían hacer inviable la adopción 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. Además sería conveniente que fuera totalmente accesible desde una página Web sin necesidad de realizar ningún tipo de instalación adicional. Se ha de tener presente que el proyecto estaba muy poco definido durante este estudio y por tanto las aplicaciones descritas están estrechamente relacionadas con el dominio de la Domótica y el e-Learning. Posteriormente se decidió generalizar el caso de aplicación para poder diseñar 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 Situación Actual La situación actual es el estado en el que se encuentran los productos existentes en el momento en el que se inicia su estudio. Se describirán brevemente los productos examinados en la fase de gestación del proyecto, cuando el campo de aplicación del proyecto estaba ligado a la Domótica 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 más se acercan a la idea global del sistema a desarrollar. En el caso de que se cumplan, se pasaría a su evaluación técnica para determinar si son realmente viables y cumplen los objetivos técnicos del sistema. La gran mayoría de los sistemas descritos a continuación han sido desarrollados como proyectos fin de carrera, tesis doctorales o proyectos de investigación asociados con Universidades y/o comunidades de software libre.

52


2.2.1. Descripción 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 técnicas de diseño de instalaciones para la automatización integral de viviendas y edificios, soportando la realización de actividades colaborativas en grupo y a distancia, la simulación distribuida del diseño realizado, el análisis del proceso que ha seguido el grupo, la evaluación de la solución obtenida y la relaciones entre el proceso y la solución [Chico]. Características generales, definidas por los autores: 















53

Utiliza como dominio de aplicación la Domótica. Los alumnos pueden participar en actividades de resolución 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 planificación de acciones de diseño, cuya solución final se obtiene fruto de la colaboración del grupo. Disponen de un sub-espacio de trabajo individual donde haciendo uso de iconos que se asocian a acciones genéricas de diseño desarrollan y proponen su plan de diseño. En un segundo sub-espacio de trabajo (espacio de trabajo en grupo) tiene lugar la discusión asíncrona y organización de las propuestas de cada uno de los participantes, para así, consensuar una solución de grupo. Tras esta planificación del diseño, se realiza el diseño de forma síncrona. Para facilitar este proceso se cuenta con diversas herramientas de comunicación, tanto síncronas como asíncronas (IRC o Chat, e-mail, sistemas de votación, etc.). El sistema puede simular el comportamiento del diseño realizado. La simulación se lleva a cabo de forma síncrona. Ofrece al coordinador o profesor un análisis cuantitativo y cualitativo, fruto de la reconstrucción del razonamiento seguido por los alumnos y del diálogo practicado por los mismos a lo largo de la actividad.


Fig. 2-1. Espacio de simulación de DomoSim-TPC 

Todas y cada una de las características son accesibles a distancia, empleando para ello cualquier navegador Web con soporte para código Java.

Fig. 2-2. Arquitectura de DomoSim-TPC

54


2.2.1.2. DomoEdit & DomoApplet (2005) “Tutorial sobre Domótica e Inmótica”

AUTOR: Pedro Cantero Espadas. TUTORES: Ricardo Mayo Bayón, Víctor M. González Suárez. UNIVERSIDAD: Universidad de Oviedo (http://www.uniovi.es). DomoEdit es una herramienta que permite a un usuario debidamente formado diseñar ejercicios de conexionados de circuitos domóticos y generar automáticamente una página Web que los contenga para poder proponérselos a un alumno. DomoApplet es el nombre que se le ha dado al Applet Java que permite a un usuario intentar resolver el problema diseñado con DomoEdit [Cantero]. Características generales: DomoEdit no es una aplicación Web, sino de escritorio. 



Se trata de una aplicación totalmente visual en la cual se utilizan imágenes de componentes domóticos reales para diseñar los ejercicios.

Fig. 2-3. Crear componente en DomoEdit 

Los profesores pueden crear componentes nuevos con DomoEdit. Se ha diseñado una aplicación de fácil manejo de forma que la manera de hacer las cosas sea muy intuitiva.

Fig. 2-4. Diseño de ejercicios en DomoEdit

55












Pueden crearse ejercicios partiendo componentes anteriormente creados para conectarlos entre sí y proponérselos a los alumnos mediante DomoApplet. Aunque en principio DomoEdit ha sido pensado para componentes y circuitos domóticos, debido a la transparencia de su diseño puede utilizarse para diseñar otro tipo de circuitos para los cuales no fue inicialmente concebida. Para el almacenamiento de la información se ha decidido utilizar ficheros XML, en lugar de una base de datos relacional. La página Web que realiza la llamada al Applet con los parámetros 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 conexión en DomoApplet 

Finalmente se evalúa la solución propuesta por el alumno.

Fig. 2-6. Solución de un ejercicio en DomoApplet 

Requiere Java 2 para visualizar las páginas Web con DomoApplet.

56


2.2.1.3. CoVis (1994) “Learning through Collaborative Visualization”

UNIVERSIDAD: Universidad de Northwestern (http://www.northwestern.edu/). El Proyecto CoVis (1994) surgió en la como una iniciativa para transformar el aprendizaje de la Ciencia en la educación básica a través del aprendizaje colaborativo con soporte computacional. Introduce la metáfora de cuadernos de notas organizados en una biblioteca jerárquica, y divididos en páginas [CoVis].

2.2.1.4. Moodle (2002) “Modular Object-Oriented Dynamic Learning Environment”

AUTOR: Martin Dougiamas (http://dougiamas.com/). Es un sistema de gestión de cursos Open Source que ayuda a los educadores a crear comunidades de aprendizaje en línea. Fue creado por Martin Dougiamas, quien era el administrador de WebCT en la Universidad Tecnológica de Curtin, y se basó en las ideas del constructivismo en pedagogía que afirman que el conocimiento se construye en la mente del estudiante en lugar de ser transmitido sin cambios a partir de libros o enseñanzas 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 información 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 común utilizada en entornos académicos que permite crear problemas y aportar opiniones. Permite a los usuarios obtener mucha más retroalimentación sobre sus ideas de la que tendrían si el docente fuera la única fuente de retroalimentación. Además se pueden formular hipótesis 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 información compartida. La unidad básica de almacenamiento es la anotación que puede tener formato de texto o gráfico 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 características similares, en cuanto a apariencia y rendimiento, a las aplicaciones cotidianas de escritorio. Evita la necesidad de instalar plugin’s para Applets mediante el uso de AJAX, uno de los objetivos técnicos del proyecto. Características generales [TibcoRIA]: Licencia BSD Open Source. 



Más de 100 componentes AJAX para utilizar.



Herramientas visuales de diseño de interfaces gráficas. Soporte para Internet Explorer 7 y Firefox 2.



Depuración integrada.



58


2.2.2. Diagnóstico de la Situación Actual Queda patente que las líneas de investigación y desarrollo en sistemas basados en e-Learning son muy difusas y hay mucho camino aún por andar. Existen muchas teorías 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 genéricos [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/). También se han encontrado multitud de ejemplos de aplicaciones e-Learning aplicadas a dominios específicos: 





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 comunicación, diagramas de descripción 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 situación del estado del arte de las librerías existentes para simplificar el uso de AJAX, así como otros productos relacionados con interconexión de objetos como editores UML, simuladores de circuitos, diseño de planos, redes de ordenadores, etc. 

59


2.3. Requisitos Iniciales del Sistema Seguidamente se intentará concretar más a fondo los requisitos necesarios para alcanzar los objetivos expuestos al principio de este capítulo. Tampoco se pretende que sean inalterables, sino que se espera que sean refinados durante todo el ciclo de vida, especialmente en la fase de Análisis.

60


2.3.1. Identificación de las Directrices Generales Este apartado cubre todos los requisitos no funcionales que no encajan en el ámbito tecnológico, como puede ser cuestiones sociales, académicas, comunicativas, colaborativas… Enfoque a la libertad de acción 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 búsqueda de contenidos como en su progresión educativa. Fomentar la colaboración y comunicación entre usuarios. La forma más segura y rápida 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 más ventajosa para la comunidad mediante votaciones. También debería disponer de medios suficientes para poder ayudar o aconsejar a los usuarios menos avanzados. Desarrollar el afán de superación de los usuarios. También resulta ventajoso, aunque arriesgado, proveer al proyecto de un sistema de ranking’s y estadísticas por categorías para poder tener una visión global de la evolución o las destrezas propias de cada usuario. Motivando a los usuarios a mejorar dicha situación a través de la realización de pruebas, añadiendo contenidos o componentes, con valoraciones positivas de otros usuarios,… Aplicar técnicas de esfuerzo-recompensa. Aportando un sistema de bonificación (acceso a recursos avanzados, nuevas funcionalidades o privilegios,…) se trata de conseguir una experiencia más 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 interconexión de objetos en entornos gráficos. 









61


2.3.2. Identificación de las Directrices Técnicas En este apartado se describen las directrices técnicas a seguir a la hora de implementar el sistema a estudio: El sistema debe ser una aplicación Web de dominio público desarrollada mediante algún lenguaje específico que no requiera gran inversión económica y que, si es viable, sea libre. El patrón a seguir será MVC. 















Puesto que actualmente no se concibe un enfoque estático para una aplicación de estas características 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 instalación de plugin’s. La opción más aconsejable sería AJAX. A la hora de elegir el entorno de desarrollo de la aplicación es aconsejable tener en cuenta las posibilidades que ofrece de internacionalización. También es preciso extraer el modelo de datos del sistema del código fuente mediante la aplicación de tecnologías XML para la descripción y definición 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 lógica de negocio relativa a las reglas de interconexión podría estar definida mediante un lenguaje específico del dominio (DSL) y que además fuese extensible y adaptable por los usuarios con el apoyo de nuevas tendencias de Web Semántica como RIF (Rule Interchange Format). Un paso más allá sería añadir meta-información de los recursos a través de RDF (Resource Description Format) y definir o reutilizar una ontología existente en OWL (Web Ontology Lenguaje). Actualmente hay un gran problema de lo que se podría denominar portabilidad de las aplicaciones Web entre diferentes navegadores o clientes, por lo que se recomienda encarecidamente el uso de estándares del W3C (World Wide Web Consortium) con el objetivo de disponer de una aplicación que pueda visualizarse correctamente desde cualquier navegador ( cross-browser), accesible y usable . Se debe prestar especial atención al sistema control de accesos y seguridad que se implemente o sobre el que se implante la aplicación ya que los usuarios nunca deberían tener acceso a la parte interna del sistema, desde donde podría verse comprometida la integridad y la validez del sistema de puntuaciones.

62


2.3.3. Identificación de Requisitos Funcionales Para mejorar su comprensión y evaluación 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 información personal, académica o profesional dentro del sistema. Funciones de segundo nivel identificadas: Alta, baja, modificación y consulta de usuarios. 



Consultar estadísticas y ranking’s de puntuaciones por categorías. Buscar usuarios por perfil.



Login.



2.3.3.2. Gestionar Propuestas El cometido de este subsistema es proporcionar un medio consistente de ampliación de recursos de la aplicación mediante votaciones colaborativas y otros criterios por determinar, que consigan una mayor participación y satisfacción de los usuarios. Funciones de segundo nivel identificadas: 

Alta, baja, modificación y consulta de propuestas.



Buscar propuestas. Votar propuestas.



Aceptar propuestas (sólo usuarios autorizados).



2.3.3.3. Gestionar Contenidos En principio dentro de los contenidos sólo se contemplan documentos, artículos y opiniones. Este subsistema se encarga de dotar a la aplicación de un repositorio de información adecuado, para poder solventar las dudas que puedan surgir al realizar los ejercicios propuestos, y un medio compartido de comunicación y discusión de opiniones similar a los foros y wiki’s que existen hoy día en Internet. Además se contempla el acceso incremental a los contenidos según las puntuaciones de los usuarios. Funciones de segundo nivel identificadas:

63



Alta, baja, modificación y consulta de contenidos.



Buscar contenidos.



Puntuar contenidos.


2.3.3.4. Gestionar Componentes Es uno de los subsistemas más 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 según las puntuaciones de los usuarios. Funciones de segundo nivel identificadas: Alta, baja, modificación y consulta de componentes. 





Buscar componentes. Compartir componentes.

2.3.3.5. Gestionar Reglas de Interconexión Este subsistema quizá sea uno de los más complejos de diseñar ya que se trata de un campo totalmente novedoso de investigación en el que se proponen mecanismos para extraer la lógica de negocio de una aplicación y dejarla en manos de los usuarios finales, de cara a mejorar la experiencia y formación de los mismos. Estas reglas pueden ser de ámbito global o pueden estar enfocadas a una tecnología 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, modificación y consulta de reglas de interconexión. 



Buscar reglas de interconexión.



Compartir reglas de interconexión.

2.3.3.6. Gestionar Ejercicios Se encarga de proveer un sistema de evaluación mediante pruebas teórico prácticas de auto-evaluación o seguimiento de los usuarios que se ejecutarán de forma dinámica en el navegador del usuario. Funciones de segundo nivel identificadas: 

Alta, baja, modificación y consulta de ejercicios.



Buscar ejercicios. Realizar ejercicio.



Evaluar solución.



64


2.4. Alternativas de Solución Entre todas las posibles alternativas, encontradas durante este estudio, destacan DomoSim-TPC, DomoEdit y los entornos genéricos Open Source de e-Learning que podrían servir de soporte al resto de subsistemas. De cara a afrontar el desarrollo del cliente Web resulta muy recomendable enfocarlo mediante librerías Open Source que simplifiquen el uso de AJAX y garanticen la independencia respecto al navegador empleado.

65


2.4.1. Estudio de Alternativas de Solución

2.4.1.1. DomoSim-TPC A pesar de su gran funcionalidad y sus numerosas ventajas en el campo de la enseñaza colaborativa, especialmente su vertiente síncrona, este sistema de eLearning completo y enfocado a la Domótica tiene ciertos inconvenientes que hacen que su adopción no sea la más 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 lógicas que definen el comportamiento y las conexiones entre los elementos. 







No se ha tenido acceso al código fuente por lo que es difícil 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 debería refinarse y simplificarse todo lo posible.

2.4.1.2. DomoEdit En principio este producto es el que tiene más nivel de integración con el sistema a desarrollar ya que podría utilizarse para cubrir el subsistema de gestión de ejercicios, en el caso de estudio de la interconexión de componentes electrónicos y domóticos. Sin embargo el hecho de que requiera instalar la máquina virtual de Java en el navegador Web para poder acceder a la funcionalidad de DomoApplet puede ser un inconveniente. Además 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 podría limitar el resto de los requisitos del sistema.

2.4.1.3. Entornos Open Source de Gestión de e-Learning También hay que tener en cuenta la posibilidad de usar uno de estos entornos genéricos para aliviar en parte la fase desarrollo del proyecto, aplicando los esfuerzos en otras áreas más relevantes o de mayor carácter innovador. Es necesario sopesar los pros y contras de cada uno de ellos y si es realmente viable la adopción de alguno siempre y cuando no limite en exceso el resto de los requisitos definidos en el capítulo anterior.

66


2.4.2. Planificación de Alternativas de Solución Dada la naturaleza experimental del proyecto lo más razonable es realizar un desarrollo ad-hoc del mismo intentando examinar en más detalle las alternativas planteadas y otras que puedan surgir durante el ciclo de vida del proyecto. Lo más recomendable es emplear un enfoque de desarrollo ágil basado en prototipos funcionales y según un modelo incremental, de modo que puedan obtenerse lo antes posible unos requisitos completos y consistentes, acortando los períodos de congelación y disponiendo de versiones evaluables en un tiempo razonable. También sería útil disponer de los subsistemas de manera organizada permitiendo integrarlos paulatinamente según 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 análisis y diseño del sistema, en las cuales se redefinieron ampliamente los requisitos iniciales planteados anteriormente en este capítulo y que por tanto fue requerido un estudio posterior más específico del estado del arte. Todos los sistemas expuestos a continuación 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 diseñar las interfaces de usuario y definir el alcance del proyecto a desarrollar. Esta ampliación al estudio de viabilidad fue realizada durante los meses de abril y mayo de 2007.

68


2.5.1. Clasificación de los Sistemas Evaluados

2.5.1.1. JViews URL: Cliente: Servidor: XML:

http://www.ilog.com/products/visualization/index.cfm AJAX Java SVG

Características: Soporta Java Server Faces. Soporte para gran cantidad de nodos y diagramas. Algoritmos de despliegue para grafos. Diseño de nuevos componentes. Incluye entorno de desarrollo. 









Inconvenientes: Requiere licencia de pago. Sólo permite exportación a SVG. 



2.5.1.2. InfiView URL: http://www.infiview.com/ Cliente: AJAX Servidor: Neutral XML: GraphML Características: Desarrollo de clientes basados en Bindows Framework (AJAX) Soporte para gran cantidad de nodos y tipos de diagramas. Algoritmos de despliegue para grafos Eficiente gestión del ancho de banda Incluye entorno de desarrollo. 









Inconvenientes: Requiere licencia de pago. 

69


2.5.1.3. yFiles URL: Cliente: Servidor: XML:

http://www.yworks.com/en/products_yfiles_about.htm AJAX o Flash Java GraphML

Características: Desarrollo de clientes basados Dojo Toolkit (AJAX) Soporte para gran cantidad de nodos y tipos de diagramas. Algoritos de despliegue para grafos Eficiente gestión del ancho de banda Incluye entorno de desarrollo. Inconvenientes: Requiere licencia de pago. 











2.5.1.4. Cumulate Draw URL: Cliente: Servidor: XML:

http://www.cumulatelabs.com/cumulatedraw/ AJAX Java SVG, MMD, FMD.

Características: Gran variedad de tipos de diagramas. Interfaz gráfica muy elaborada. Diseño de nuevos componentes. Licencia Creative Commons. Exportación a JPG, PNG y PDF. Versión on-line gratuita. Inconvenientes: Código fuente disponible sólo bajo petición. 













70


2.5.1.5. JGraph, Layout Pro y mxGraph URL: Cliente: Servidor: XML:

http://www.jgraph.com AJAX Java Formato propio.

Características: Gran variedad de tipos de diagramas. Algoritmos de despliegue para grafos. Interfaz gráfica muy elaborada. Diseño de nuevos componentes. Licencia LGPL sólo para JGraph. Inconvenientes: Licencia de pago para los extras y mxGraph (AJAX). 











2.5.1.6. Flowchart URL: http://www.flowchart.com/ AJAX Cliente: Servidor: Sólo disponible en versión on-line. XML: No disponible. Características: Colaboración en tiempo real. Almacenamiento on-line. Exportación a PNG y PDF. Interfaz gráfica muy elaborada. Gran variedad de tipos de diagramas. Versión demo on-line gratuita. Inconvenientes: Sin exportación a XML. Sin acceso al código fuente. 















71


2.5.1.7. Gliffy URL: Cliente: Servidor: XML:

http://gliffy.com/ Flash Sólo disponible en versión on-line. SVG

Características: Colaboración en tiempo real. Almacenamiento on-line. Exportación a PNG y JPG. Interfaz gráfica muy elaborada. Gran variedad de tipos de diagramas. Versión on-line gratuita, aunque limitada. 











Inconvenientes: Sólo 5 diagramas en la versión gratuita. Sin acceso al código fuente. 



2.5.1.8. Visuwords URL: http://www.visuwords.com/ Cliente: Flash Servidor: Sólo disponible en versión on-line. XML: No disponible. Características: Diccionario gráfico on-line gratuito. Código fuente bajo licencia Open Source. 



Inconvenientes: Muy limitado: no permite editar. Sin exportación a XML. 



72


2.5.1.9. Kayuda URL: Cliente: Servidor: XML:

http://www.kayuda.com/ AJAX Sólo disponible en versión on-line. SVG

Características: Basado en Dojo Toolkit (AJAX). Permite compartir diagramas. Versión on-line gratuita. 





Inconvenientes: Escasa variedad de componentes. Sin exportación a XML. Sin acceso al código fuente. Poco usable. 







2.5.1.10. Mind42 URL: Cliente: Servidor: XML:

http://www.mind42.com/portal/index.xhtml AJAX Sólo disponible en versión on-line. FreeMind, mind42…

Características: Basado en Dojo Toolkit (AJAX). Colaboración en tiempo real. Incluye Google Talk Gadget. Exportación a RTF. 







Inconvenientes: Muy limitado: sólo mapas de ideas. Sin acceso al código fuente. 



73


2.5.1.11. Bubbl.us URL: Cliente: Servidor: XML:

http://www.bubbl.us/ Flash Solo disponible versión on-line. Formato propio.

Características: Permite compartir diagramas Exportación a JPG, PNG y HTML 



Inconvenientes: Muy limitado: sólo mapas de ideas. Escasa variedad de componentes. Sin acceso al código fuente. 





2.5.1.12. MindMeister URL: http://www.mindmeister.com/ Cliente: AJAX Servidor: Solo disponible versión on-line XML: FreeMind, MindManager. Características: Colaboración en tiempo real Permite compartir diagramas Exportación a GIF, JPG, PNG y RTF. Inconvenientes: Muy limitado: sólo mapas de ideas. Escasa variedad de componentes. Emplea la librería ‘wz_jsgraphics.js’. 











74


2.5.1.13. Open-jACOB Draw2D URL: Cliente: Servidor: XML:

http://www.openjacob.org/draw2d.html AJAX Cualquiera. Formato propio.

Características: Open-jACOB Framework Código disponible bajo licencia Open Source. 



Inconvenientes: Proyecto en estado de beta. Emplea la librería ‘wz_jsgraphics.js’. 



2.5.1.14. Web Sequence Diagram Generator URL: http://www.websequencediagrams.com/ Cliente: HTML Servidor: Solo disponible versión on-line FreeMind, MindManager. XML: Características: Simplicidad de uso. Edición y exportación en formato texto. 



Inconvenientes: Muy limitado: sólo diagramas de secuencia. Escasa variedad de opciones. 



75


CAPÍTULO 3: AN ÁLISIS En este capítulo se especifican en mayor detalle los requerimientos del sistema a desarrollar, partiendo de una especificación textual de l os mismos se extraerá una lista clasificada y se diseñaran 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 descripción de las clases encontradas. Finalmente se propone un formato base para la interfaz de usuario, que abarque las funcionalidades básicas descritas este capítulo y aporte una visión 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 tecnologías, librerías y herramientas descrito brevemente en la memoria de este documento. El campo de aplicación se generalizó para poder cubrir cualquier tipo de diagrama, centrando los objetivos del proyecto en la realización de un sistema lo más escalable posible y tratando de desarrollar un entorno que además permitiese la colaboración síncrona de los usuarios.

77


3.1.1. Especificación Textual La aplicación consta de dos partes: cliente y servidor. La parte servidor se desarrollará mediante el patrón Modelo-VistaControlador (MVC) junto con el empleo de diversas tecnologías de Web Semántica que aporten extensibilidad y simplifiquen en la medida de lo posible el diseño del modelo de datos y de comportamiento que servirá de lenguaje común 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 más amigable para el usuario, similar a las aplicaciones típicas de escritorio, que además no requiere que el usuario realice ninguna instalación adicional. También se valorará la viabilidad de implementar un entorno colaborativo dónde varios usuarios puedan interaccionar simultáneamente sobre el mismo diagrama de forma similar a las posibilidades que ofrece una pizarra compartida. compartida. Respecto a los requisitos funcionales, básicamente se espera conseguir la misma funcionalidad que cualquier otra aplicación de diseño de diagramas, circuitos, redes, etc. Añadiendo la posibilidad de diseñar nuevos objetos y tecnologías según 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 conexión a Internet.

78


3.1.2. Especificación de Requerimientos Funcionales A continuación de enumeran 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 especificación 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. También 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 – R1.1 – Alta, baja y modificación de diagramas.

R1.2 – R1.2 – Buscar diagramas. R1.3 – R1.3 – Publicar / compartir diagramas. R1.4 – R1.4 – Control de versiones de los diagramas.

3.1.2.2. R2 – Diseñar Diagramas El diseño de los diagramas abarca cualquier cambio que se desee realizar sobre el contenido o la disposición de un diagrama concreto. Se trata de desarrollar un entorno gráfico de dibujo dónde se buscará la forma de permitir a los usuarios trabajar trabajar de manera conjunta conjunta y remota sobre un mismo diagrama y a ser posible posible que los los cambios cambios se actua actualicen licen en tiempo tiempo real real en todos todos los clientes. Funciones de segundo nivel identificadas: R2.1 – R2.1 – Definir dimensiones del área de diseño.

R2.2 – R2.2 – Añadir y eliminar componentes. componentes. R2.3 – R2.3 – Realizar conexiones entre componentes. componentes. R2.4 – Aplicar transformaciones básicas (zoom, rotación…). R2.5 – R2.5 – Cortar, copiar y pegar. R2.6 – Historial de deshacer deshacer / rehacer. R2.7 – R2.7 – Guardar, exportar e importar. R2.8 – 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 gestión 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 diseño de diagramas. Al igual que con la gestión de diagramas se permitirá el acceso a versiones anteriores sin perder los cambios actuales. Funciones de segundo nivel identificadas: R3.1 – Alta, baja y modificación de componentes.

R3.2 – Buscar componentes. R3.3 – Publicar / compartir componentes. R3.4 – Control de versiones de los componentes.

3.1.2.4. R4 – Diseñar Componentes Este subsistema quizá sea uno de los más complejos de diseñar ya que se trata de un campo totalmente novedoso de investigación en el que se proponen mecanismos para extraer la lógica de negocio de una aplicación 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 – Añadir y eliminar formas básicas (geometrías, imágenes…).

R4.3 – Definir zonas de interconexión (puertos). R4.4 – Aplicar transformaciones básicas (zoom, rotación…). 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 modificación. R5.2 – Validar usuario (login).

R5.3 – Buscar usuarios. R5.4 – Consultar estadísticas y puntuaciones.

80


3.1.3. Especificación de Requerimientos No Funcionales En este apartado se recogen todos los requerimientos que no encajan en el apartado anterior, como puede ser cuestiones tecnológicas, sociales, académicas, comunicativas, colaborativas…

3.1.3.1. RNF 1: Requerimientos Generales A continuación se describen todos los requerimientos aprobados que por su naturaleza no se pueden encuadrar en una categoría concreta: RNF 1.1 – Enfoque a la libertad de acción 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 búsqueda de contenidos como en su progresión formativa. RNF 1.2 – Fomentar la colaboración y comunicación entre usuarios. La forma más segura y rápida de aumentar el volumen de contenidos y componentes es permitiendo que los usuarios compartan sus propios recursos. RNF 1.3 – Desarrollar el afán de superación de los usuarios. También puede resultar ventajoso, aunque arriesgado, proveer al proyecto de un sistema de ranking’s y estadísticas para poder tener una visión global de la evolución o las destrezas propias de cada usuario. Motivando a los usuarios a mejorar dicha situación a través de la realización de pruebas, añadiendo contenidos o componentes, con valoraciones positivas de otros usuarios… RNF 1.4 – Aplicar técnicas de esfuerzo-recompensa. Aportando un sistema de bonificación (acceso a recursos avanzados, nuevas funcionalidades o privilegios,…) se trata de conseguir una experiencia más 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 técnicas adecuadas de comunicación persona-máquina para lograr una interfaz lo más correcta posible, que permita una interacción accesible e intuitiva.

RNF 1.6 – Buscar el apoyo de soluciones de código abierto. Evitando en la medida de lo posible “reinventar la rueda”.

81


3.1.3.2. RNF 2: Requerimientos Técnicos Finalmente se presentan los requerimientos técnicos que debe cubrir el sistema a desarrollar:

RNF 2.1 – Emplear el patrón MVC para diseñar la arquitectura del sistema. El sistema final debe ser una aplicación Web de dominio público diseñada mediante el patrón MVC. RNF 2.2 – Emplear tecnologías AJAX en el desarrollo del cliente. Puesto que actualmente no se concibe un enfoque estático para una aplicación de estas características será necesario distribuir parte de la carga computacional en el cliente (navegador Web). RNF 2.3 – Dar soporte directo a la internacionalización de la interfaz. A la hora de elegir el entorno de desarrollo de la aplicación es aconsejable tener en cuenta las posibilidades que ofrece de internacionalización. RNF 2.4 – Dar soporte a los navegadores Web más 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 estándares del W3C (World Wide Web Consortium) con el objetivo de disponer de una aplicación que pueda visualizarse correctamente desde cualquier navegador (cross-browser ). RNF 2.5 – Evitar la necesidad de instalar plugin’s en los navegadores. Permitirá que los usuarios puedan tener acceso al sistema desde cualquier ordenador con un navegador Web y conexión a Internet. RNF 2.6 – Definir el modelo de datos mediante tecnologías 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 específico del domino para las conexiones. La lógica de negocio relativa a las reglas de interconexión podría estar definida mediante un lenguaje específico del dominio (DSL) y que además fuese extensible y adaptable. RNF 2.8 – Valorar el uso de meta-información en los recursos. Un paso más allá sería añadir meta-información a los recursos a través de RDF (Resource Description Format) y definir o reutilizar una ontología existente en OWL (Web Ontology Lenguaje). RNF 2.9 – Diseñar un sistema de control de accesos y seguridad adecuado. Se debe prestar especial atención al sistema control de accesos y seguridad que se implemente o sobre el que se implante la aplicación. 82


3.2. Especificación de Casos de Uso

Fig. 3-1. Diagrama de Casos de Uso

83


3.2.1. Actores En principio la aplicación no contempla diferentes tipos de usuarios por lo que los actores que se describen a continuación pueden representar a una misma persona en contextos diferentes.

3.2.1.1. Actor 1: Usuario Registrado Definición

Representa al usuario cuando interactúa con el sistema de cara a obtener información pública o compartida, es decir, cuando accede a contenidos sobre los que no tiene derechos de propietario.

Notas

Tiene acceso total a los contenidos públicos del sistema. Los permisos de este actor sobre los contenidos compartidos están definidos por el propietario de los mismos. Tabla 3.2-1. Actor 1: Usuario Registrado

3.2.1.2. Actor 2: Propietario Definición

Representa al usuario cuando accede a los contenidos sobre los que tiene derechos de propietario, incluyendo diagramas, componentes y datos personales.

Notas

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

3.2.1.3. Actor 3: Colaborador Definición

Representa al usuario cuando colabora de manera sincronizada con otros usuarios en el diseño de un diagrama.

Notas

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

84


3.2.2. Casos de Uso

3.2.2.1. Caso de Uso 1: Gestionar Diagramas (R1) Definición

Proporciona la funcionalidad necesaria para crear, eliminar, modificar, compartir y acceder a los diagramas. También se encarga del control de versiones.

Actores

Propietario / Usuario Registrado.

Prioridad

Alta.

Importancia

Alta.

Requerimientos

R1.1, R1.2, R1.3, R1.4.

Notas

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)

3.2.2.1.1. Escenario 1.1: Alta, baja y modificación de diagramas (R1.1)

Precondiciones

El usuario debe estar registrado en el sistema.

Poscondiciones

Los cambios deben actualizarse en la interfaz de usuario.

Iniciado por


Finalizado por


Secuencia de operaciones

El usuario solicita la operación. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en la interfaz de usuario.

Excepciones

El usuario no tiene permisos suficientes.

Notas

Los propietarios definen los permisos que tienen el resto de usuarios sobre sus diagramas. Tabla 3.2-5. Escenario 1.1: Alta, baja y modificación de diagramas (R1.1)

85


3.2.2.1.2. Escenario 1.2: Buscar diagramas (R1.2)

Precondiciones

Los criterios de búsqueda deben ser válidos.

Poscondiciones

Los resultados deben mostrarse en la interfaz de usuario.

Iniciado por


Finalizado por



El usuario establece los criterios de búsqueda. 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 ningún diagrama que cumpla los criterios de búsqueda establecidos.

Notas

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)

3.2.2.1.3. Escenario 1.3: Publicar / compartir diagramas (R1.3)

Precondiciones

El usuario debe tener derechos de propietario.

Poscondiciones


Iniciado por

Propietario.

Finalizado por

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

Sólo 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)

Precondiciones

El usuario debe tener permiso de edición sobre el diagrama

Poscondiciones


Iniciado por


Finalizado por



El usuario selecciona la versión 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

Los propietarios definen los permisos que tienen el resto de usuarios sobre sus diagramas. Tabla 3.2-8. Escenario 1.4: Control de versiones de los diagramas (R1.4)

87


3.2.2.2. Caso de Uso 2: Diseñar Diagramas (R2) Definición

El diseño de los diagramas abarca cualquier cambio que se desee realizar sobre el contenido o la disposición de un diagrama concreto. Se trata de desarrollar un entorno gráfico de dibujo dónde 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.

Actores

Propietario / Usuario Registrado / Colaborador.

Prioridad

Máxima.

Importancia

Máxima.

Requerimientos

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

Notas

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: Diseñar Diagramas (R2)

3.2.2.2.1. Escenario 2.1: Definir dimensiones del área de diseño (R2.1)

Precondiciones


Poscondiciones

Los cambios deben actualizarse en todos los clientes.

Iniciado por


Finalizado por



El usuario solicita redimensionar el área de diseño. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en todos los clientes conectados.

Excepciones


Notas

Los propietarios definen los permisos que tienen el resto de usuarios sobre sus diagramas. Tabla 3.2-10. Escenario 2.1: Definir dimensiones del área de diseño (R2.1)

88


3.2.2.2.2. Escenario 2.2: Añadir y eliminar componentes (R2.2)

Precondiciones


Poscondiciones


Iniciado por


Finalizado por



El usuario solicita la operación. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en todos los clientes conectados.

Excepciones


Notas

Los propietarios definen los permisos que tienen el resto de usuarios sobre sus diagramas. Tabla 3.2-11. Escenario 2.2: Añadir y eliminar componentes (R2.2)

3.2.2.2.3. Escenario 2.3: Realizar conexiones entre componentes (R2.3)

Precondiciones


Poscondiciones


Iniciado por


Finalizado por




Excepciones


Notas

Los propietarios definen los permisos que tienen el resto de usuarios sobre sus diagramas. Tabla 3.2-12. Escenario 2.3: Realizar conexiones entre componentes (R2.3)

89


3.2.2.2.4. Escenario 2.4: Aplicar transformaciones básicas (R2.4)

Precondiciones


Poscondiciones


Iniciado por


Finalizado por



El usuario solicita la transformación. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en todos los clientes conectados.

Excepciones


Notas

Los propietarios definen los permisos que tienen el resto de usuarios sobre sus diagramas. Tabla 3.2-13. Escenario 2.4: Aplicar transformaciones básicas (R2.4)

3.2.2.2.5. Escenario 2.5: Cortar, copiar y pegar (R2.5)

Precondiciones


Poscondiciones


Iniciado por


Finalizado por




Excepciones


Notas

Los propietarios definen los permisos que tienen el resto de usuarios sobre sus diagramas. 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)

Precondiciones


Poscondiciones


Iniciado por


Finalizado por



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

Los propietarios definen los permisos que tienen el resto de usuarios sobre sus diagramas. 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)

Precondiciones


Poscondiciones

Los cambios deben ser visibles en todo el sistema.

Iniciado por


Finalizado por



El usuario solicita la operación. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en todo el sistema.

Excepciones


Notas

Los propietarios definen los permisos que tienen el resto de usuarios sobre sus diagramas. 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)

Precondiciones


Poscondiciones

El usuario puede comunicarse con los demás colaboradores

Iniciado por

Colaborador.

Finalizado por

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

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 comunicación 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) Definición

Permite crear, borrar y modificar nuevos componentes o extender los ya existentes, con el fin de poder emplearlos en el diseño de diagramas. Al igual que con la gestión de diagramas se permitirá el acceso a versiones anteriores sin perder los cambios actuales.

Actores


Prioridad

Media.

Importancia

Alta.

Requerimientos

R3.1, R3.2, R3.3, R3.4.

Notas

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 modificación de componentes (R3.1)

Precondiciones


Poscondiciones


Iniciado por


Finalizado por




Excepciones


Notas

Los propietarios definen los permisos que tienen el resto de usuarios sobre sus componentes.

Tabla 3.2-19. Escenario 3.1: Alta, baja y modificación de componentes (R3.1)

93


3.2.2.3.2. Escenario 3.2: Buscar componentes (R3.2)

Precondiciones


Poscondiciones


Iniciado por


Finalizado por




Excepciones

No se encuentra ningún componente que cumpla los criterios de búsqueda establecidos.

Notas

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)

3.2.2.3.3. Escenario 3.3: Publicar / compartir componentes (R3.3)

Precondiciones

El usuario debe tener derechos de propietario.

Poscondiciones


Iniciado por

Propietario.

Finalizado por

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

Sólo 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)

Precondiciones

Tener permiso de edición sobre el componente.

Poscondiciones


Iniciado por


Finalizado por



El usuario selecciona la versión 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

Los propietarios definen los permisos que tienen el resto de usuarios sobre sus componentes.

Tabla 3.2-22. Escenario 3.4: Control de versiones de los componentes (R3.4)

95


3.2.2.4. Caso de Uso 4: Diseñar Componentes (R4) Definición

Este subsistema quizá sea uno de los más complejos de diseñar ya que se trata de un campo totalmente novedoso en el que se proponen mecanismos para extraer la lógica de negocio de una aplicación y dejarla en manos de los usuarios finales, de cara a mejorar su experiencia en el sistema.

Actores


Prioridad

Baja.

Importancia

Alta.

Requerimientos

R4.1, R4.2, R4.3, R4.4, R4.5, R4.6, R4.7.

Notas

No se contempla colaboración síncrona 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: Diseñar Componentes (R4)

3.2.2.4.1. Escenario 4.1: Definir dimensiones del componente (R4.1)

Precondiciones


Poscondiciones


Iniciado por


Finalizado por



El usuario solicita redimensionar el área de diseño. 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 propietarios definen los permisos que tienen el resto de usuarios sobre sus componentes. Tabla 3.2-24. Escenario 4.1: Definir dimensiones del componente (R4.1)

96


3.2.2.4.2. Escenario 4.2: Añadir y eliminar formas básicas (R4.2)

Precondiciones


Poscondiciones


Iniciado por


Finalizado por




Excepciones


Notas

Los propietarios definen los permisos que tienen el resto de usuarios sobre sus componentes. Tabla 3.2-25. Escenario 4.2: Añadir y eliminar formas básicas (R4.2)

3.2.2.4.3. Escenario 4.3: Definir zonas de interconexión (R4.3)

Precondiciones


Poscondiciones


Iniciado por


Finalizado por




Excepciones


Notas

Los propietarios definen los permisos que tienen el resto de usuarios sobre sus componentes. Tabla 3.2-26. Escenario 4.3: Definir zonas de interconexión (R4.3)

97


3.2.2.4.4. Escenario 4.4: Aplicar transformaciones básicas (R4.4)

Precondiciones


Poscondiciones


Iniciado por


Finalizado por



El usuario solicita la transformación. 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 propietarios definen los permisos que tienen el resto de usuarios sobre sus componentes. Tabla 3.2-27. Escenario 4.4: Aplicar transformaciones básicas (R4.4)

3.2.2.4.5. Escenario 4.5: Cortar, copiar y pegar (R4.5)

Precondiciones


Poscondiciones


Iniciado por


Finalizado por




Excepciones


Notas

Los propietarios definen los permisos que tienen el resto de usuarios sobre sus componentes. 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)

Precondiciones


Poscondiciones


Iniciado por


Finalizado por



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

Los propietarios definen los permisos que tienen el resto de usuarios sobre sus componentes. 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)

Precondiciones


Poscondiciones

Los cambios deben ser visibles en todo el sistema.

Iniciado por


Finalizado por



El usuario solicita la operación. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en todo el sistema.

Excepciones


Notas

Los propietarios definen los permisos que tienen el resto de usuarios sobre sus componentes. 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) Definición

Como cualquier otro sistema en el que intervengan usuarios es necesario disponer de mecanismo para crear, borrar y actualizar sus datos.

Actores


Prioridad

Media.

Importancia

Media.

Requerimientos

R5.1, R5.2, R5.3, R5.4.

Notas

Sólo 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 modificación de usuarios (R5.1)

Precondiciones


Poscondiciones


Iniciado por

Propietario.

Finalizado por

Propietario.



Excepciones


Notas

Sólo el propietario de la cuenta puede borrar o modificar los datos de la misma. Tabla 3.2-32. Escenario 5.1: Alta, baja y modificación de usuarios (R5.1)

100


3.2.2.5.2. Escenario 5.2: Validar usuario (R5.2)

Precondiciones

Los datos de identificación del usuario deben ser válidos.

Poscondiciones

El usuario puede acceder a sus contenidos privados.

Iniciado por

Propietario.

Finalizado por

Propietario.


El usuario introduce sus datos de identificación. El sistema comprueba que tiene los permisos adecuados. Se realizan las acciones pertinentes. Se actualizan los cambios en la interfaz de usuario.

Excepciones

Los datos de identificación son incorrectos.

Notas

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)

Precondiciones


Poscondiciones


Iniciado por


Finalizado por




Excepciones

No se encuentra ningún usuario que cumpla los criterios de búsqueda establecidos.

Notas

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)

101


3.2.2.5.4. Escenario 5.4: Consultar estadísticas y puntuaciones (R5.4)

Precondiciones


Poscondiciones

Los datos deben mostrarse en la interfaz de usuario.

Iniciado por


Finalizado por



El usuario selecciona la opción 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

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 estadísticas y puntuaciones (R5.4)

102


3.3. Análisis 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 aproximación del modelo de clases que será refinada posteriormente durante el diseño. Las responsabilidades de una clase definen la funcionalidad de esa clase, y están basadas en el estudio de los papeles que desempeñan sus objetos dentro de los distintos casos de uso [Métrica].

103


3.3.1. Identificación de Clases Asociadas a Casos de Uso

3.3.1.1. Análisis del Caso de Uso 1: Gestionar Diagramas (R1) Nombre de la clase / recurso Modelo

Tecnología

DiagramManager

Java

Diagram

Java

Vista

DiagramManager DiagramDynaActionForm (R1.1)

JSP + JavaScript XML / Struts

Controlador

AddDiagramAction.do (R1.1) RemoveDiagramAction.do (R1.1)

Java / Struts Java / Struts

EditDiagramAction.do (R1.1) QueryDiagramsAction.do (R1.2)


ShareDiagramAction.do (R1.3) RestoreDiagramAction.do (R1.4)


Tabla 3.3-1. Análisis del Caso de Uso 1: Gestionar Diagramas (R1)

3.3.1.2. Análisis del Caso de Uso 2: Diseñar Diagramas (R2) Nombre de la clase / recurso

Tecnología

Modelo

DiagramManager Diagram

Java Java

Vista

DiagramEditor

Controlador

CommitChangeAction.do (R2.x) QueryChangesAction.do (R2.x)


SaveChangesAction.do (R2.7) ExportDiagramAction.do (R2.7)


SendMessageAction.do (R2.8)

Java / Struts

JSP + JavaScript

Tabla 3.3-2. Análisis del Caso de Uso 2: Diseñar Diagramas (R2)

104


3.3.1.3. Análisis del Caso de Uso 3: Gestionar Componentes (R3) Nombre de la clase / recurso Modelo

ComponentManager

Java

Component

Java

ComponentManager

Vista

Controlador

Tecnología

JSP + JavaScript

ComponentDynaActionForm (R3.1)

XML / Struts

AddComponentAction.do (R3.1) RemoveComponentAction.do (R3.1)


EditComponentAction.do (R3.1) QueryComponentsAction.do (R3.2)


ShareComponentAction.do (R3.3)

Java / Struts

RestoreComponentAction.do (R3.4)

Java / Struts

Tabla 3.3-3. Análisis del Caso de Uso 3: Gestionar Componentes (R3)

3.3.1.4. Análisis del Caso de Uso 4: Diseñar Componentes (R4) Nombre de la clase / recurso Modelo

Tecnología

ComponentManager

Java

Component

Java

Vista

ComponentEditor

JSP + JavaScript

Controlador

CommitChangeAction.do (R4.x) QueryChangesAction.do (R4.x)


SaveChangesAction.do (R4.7)

Java / Struts

ExportComponentAction.do (R4.7)

Java / Struts

Tabla 3.3-4. Análisis del Caso de Uso 4: Diseñar Componentes (R4)

105


3.3.1.5. Análisis del Caso de Uso 5: Gestionar Usuarios (R5) Nombre de la clase / recurso Modelo

UserManager

Java

User

Java

UserManager

Vista

Controlador

Tecnología

JSP + JavaScript

UserDynaActionForm (R2.1)

XML / Struts

AddUserAction.do (R5.1) RemoveUserAction.do (R5.1)


EditUserAction.do (R5.1) LoginAction.do (R5.2)


QueryUsersAction.do (R5.3)

Java / Struts

QueryStatisticsAction.do (R5.4)

Java / Struts

Tabla 3.3-5. Análisis 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. Descripción de Clases (Preliminar) La descripción de las clases se subdivide en las tres capas del patrón MVC para facilitar su comprensión.

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 sesión, implementa las reglas de negocio y garantiza el almacenamiento persistente de los cambios realizados. 3.3.3.1.1. Clase DiagramManager Implementación

Java

Caso de Uso

Hereda de...

R1 – Gestionar Diagramas

Responsabilidades Requerimiento Descripción Alta, baja y modificación de diagramas R1.1 Buscar diagramas R1.2 Publicar / compartir diagramas R1.3 Control de versiones de diagramas R1.4 Observaciones

Puede diseñarse mediante el patrón Facade, delegando sus responsabilidades en otras clases diseñadas a tal efecto. Tabla 3.3-6. Clase DiagramManager (Modelo)

3.3.3.1.2. Clase Diagram Implementación

Java

Caso de Uso

Hereda de...

R2 – Diseñar Diagramas

Requerimiento

Responsabilidades Descripción

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

Definir dimensiones del área de diseño. Añadir y eliminar componentes. Realizar conexiones entre componentes. Aplicar transformaciones básicas (zoom, rotación…). Cortar, copiar y pegar. Historial de deshacer / rehacer. Guardar, exportar e importar. Colaborar mediante pizarra compartida y Chat. Observaciones

Para permitir la colaboración síncrona de varios usuarios es necesario que compartan la misma instancia de esta clase, bien a través de un repositorio en el contexto de la aplicación o bien mediante una base da datos. Tabla 3.3-7. Clase Diagram (Modelo)

108


3.3.3.1.3. Clase ComponentManager Implementación

Java

Caso de Uso

Hereda de...

R3 – Gestionar Componentes

Responsabilidades Requerimiento Descripción Alta, baja y modificación de componentes R3.1 Buscar componentes R3.2 Publicar / compartir componentes R3.3 Control de versiones de componentes co mponentes R3.4 Observaciones

Puede diseñarse mediante el patrón Facade, delegando sus responsabilidades en otras clases diseñadas a tal efecto. Tabla 3.3-8. Clase ComponentManager (Modelo)

3.3.3.1.4. Clase Component Implementación

Java

Caso de Uso

Hereda de...

R4 – Diseñar Componentes

Requerimiento


R4.1 R4.2 R4.3 R4.4 R4.5 R4.6 R4.7

Definir dimensiones del componente. Añadir y eliminar formas básicas. Definir zonas de interconexión (puertos). Aplicar transformaciones básicas (zoom, rotación…). 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 Implementación

Java

Caso de Uso

Hereda de...

R5 – Gestionar Usuarios

Responsabilidades Requerimiento Descripción Alta, baja y modificación de usuarios R5.1 Validar usuario R5.2 Buscar Usuarios R5.3 Consultar estadísticas y puntuaciones R5.4 Observaciones

Puede diseñarse mediante el patrón Facade, delegando sus responsabilidades en otras clases diseñadas a tal efecto. Tabla 3.3-10. Clase UserManager (Modelo)

109


3.3.3.1.6. Clase User Implementación

Java

Caso de Uso

Hereda de...

R5 – Gestionar Cuentas de Usuario

Responsabilidades Requerimiento Descripción Alta, baja y modificación de usuarios R5.1 Validar usuario R5.2 Observaciones

Puede implementarse una clase auxiliar tipo JavaBean que almacene los datos básicos 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 través de los datos depositados en la sesión, el contexto o la petición. 3.3.3.2.1. Clase DiagramManager Implementación

Caso de Uso

Hereda de...

JSP + JavaScript R1 – Gestionar Diagramas Responsabilidades Requerimiento Descripción Alta, baja y modificación de diagramas R1.1 Buscar diagramas R1.2 Publicar / compartir diagramas R1.3 Control de versiones de diagramas R1.4 Observaciones

El usuario solicita la página JSP que contiene el código 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 Implementación

Caso de Uso

Hereda de...

JSP + JavaScript R2 – Diseñar Diagramas Requerimiento


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

Definir dimensiones del área de diseño. Añadir y eliminar componentes. Realizar conexiones entre componentes. Aplicar transformaciones básicas (zoom, rotación…). Cortar, copiar y pegar. Historial de deshacer / rehacer. Guardar, exportar e importar. Colaborar mediante pizarra compartida y Chat. Observaciones

El usuario solicita la página JSP que contiene el código necesario para cargar un objeto JavaScript en el cliente, el cual delegará las operaciones al controlador mediante AJAX. Tabla 3.3-13. Clase DiagramEditor (Vista)

111


3.3.3.2.3. Clase ComponentManager Implementación

Caso de Uso

Hereda de...

JSP + JavaScript R3 – Gestionar Componentes Responsabilidades Requerimiento Descripción Alta, baja y modificación de componentes R3.1 Buscar componentes R3.2 Publicar / compartir componentes R3.3 Control de versiones de componentes co mponentes R3.4 Observaciones

El usuario solicita la página JSP que contiene el código necesario para cargar un objeto JavaScript en el cliente, el cual delegará las operaciones al controlador mediante AJAX. Tabla 3.3-14. Clase ComponentManager (Vista)

3.3.3.2.4. Clase ComponentEditor Implementación

Caso de Uso

Hereda de...

JSP + JavaScript R4 – Diseñar Componentes Requerimiento


R4.1 R4.2 R4.3 R4.4 R4.5 R4.6 R4.7

Definir dimensiones del componente. Añadir y eliminar formas básicas. Definir zonas de interconexión (puertos). Aplicar transformaciones básicas (zoom, rotación…). Cortar, copiar y pegar. Historial de deshacer / rehacer. Guardar, exportar e importar. Observaciones

El usuario solicita la página JSP que contiene el código necesario para cargar un objeto JavaScript en el cliente, el cual delegará las operaciones al controlador mediante AJAX. Tabla 3.3-15. Clase ComponentEditor (Vista)

3.3.3.2.5. Clase UserManager Implementación

Caso de Uso

Hereda de...

JSP + JavaScript R5 – Gestionar Usuarios Requerimiento

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

Responsabilidades Descripción Alta, baja y modificación de usuarios Validar usuario Buscar Usuarios Consultar estadísticas y puntuaciones Observaciones

El usuario solicita la página JSP que contiene el código necesario para cargar un objeto JavaScript en el cliente, el cual delegará las operaciones al controlador mediante AJAX. Tabla 3.3-16. Clase UserManager (Vista)

112


3.3.3.2.6. Clase DiagramDynaActionForm Implementación

XML / Struts

Caso de Uso

R1 – Gestionar Diagramas

Hereda de...

DynaActionForm

Responsabilidades Requerimiento Descripción Alta y modificación de diagramas d iagramas R1.1 Observaciones

No es una clase Java: los campos del formulario se definen en el archivo de configuración de Struts (Struts-config.xml) y las validaciones en el archivo de configuración del framework Struts Validator (validation.xml). Tabla 3.3-17. Clase DiagramDynaActionForm (Vista)

3.3.3.2.7. Clase ComponentDynaActionForm ComponentDynaActionForm Implementación

XML / Struts

Caso de Uso

R3 – Gestionar Componentes

Hereda de...

DynaActionForm

Responsabilidades Requerimiento Descripción Alta y modificación de componentes R3.1 Observaciones

No es una clase Java: los campos del formulario se definen en el archivo de configuración de Struts (Struts-config.xml) y las validaciones en el archivo de configuración del framework Struts Validator (validation.xml). Tabla 3.3-18. Clase ComponentDynaActionForm (Vista)

3.3.3.2.8. Clase UserDynaActionForm Implementación

XML / Struts

Caso de Uso

R5 – Gestionar Cuentas de Usuario

Hereda de...

DynaActionForm

Responsabilidades Requerimiento Descripción Alta y modificación de usuarios R5.1 Observaciones

No es una clase Java: los campos del formulario se definen en el archivo de configuración de Struts (Struts-config.xml) y las validaciones en el archivo de configuración del framework Struts Validator (validation.xml). Tabla 3.3-19. Clase UserDynaActionForm (Vista)

113


3.3.3.3. Controlador Se encarga de coordinar el flujo de la aplicación, conectando adecuadamente las peticiones de la Vista con servicios del Modelo y actualizando los resultados en la petición, la sesión 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 automáticamente el flujo de la aplicación a través de la configuración definida en el archivo ‘struts-config.xml’ y mediante la implementación de clases que deriven de la clase Action. Estas clases derivadas únicamente necesitan implementar el método ‘execute’, donde se definirán las llamadas a las clases del Modelo que se encargarán de realizar las operaciones de la lógica de negocio y mantener el estado.

114


3.4. Definición de Interfaces de Usuario

Fig. 3-3. Estructura General de la Interfaz de Usuario

115


3.4.1. Especificación de Principios Generales A continuación se recogen los principios generales a tener en cuenta en la definición de las interfaces de usuario: 







Enfoque a la libertad de acción de los usuarios (RNF 1.1). La interfaz de usuario debe ser accesible y usable (RNF 1.5). Emplear el patrón MVC (RNF 2.1). Emplear tecnologías AJAX en el desarrollo del cliente (RNF 2.2).



Dar soporte directo a la internacionalización de la interfaz (RNF 2.3). Dar soporte a los navegadores Web más empleados (RNF 2.4).



Evitar la necesidad de instalar plugin’s en los navegadores (RNF 2.5).











Los elementos deben distribuirse mediante layout’s. Los mensajes de error se mostrarán en una consola o un diálogo modal. Todos los elementos deben mostrar información contextual (tooltip’s). Dar soporte a la interacción por teclado para usuarios con limitaciones.

116


3.4.2. Especificación de Formatos Individuales Una vez definidos los principios generales se procede a la especificación del formato de cada pantalla de la aplicación, partiendo del estudio de los casos de uso identificados en este mismo capítulo.

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: Diseñar Diagramas (R2)

Fig. 3-5. Interfaz de Usuario 2: Diseñar 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: Diseñar Componentes (R4)

Fig. 3-7. Interfaz de Usuario 4: Diseñar 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. Especificación del Comportamiento Dinámico Inicialmente el usuario que acceda al sistema debe registrarse o crear una nueva cuenta que lo registrará automáticamente. El acceso a las diferentes interfaces de usuario principales se realiza a través del menú, mientras que las funciones de segundo nivel son accedidas desde dichas interfaces.

Fig. 3-9. Modelo de Navegación de la Interfaz de Usuario

120


3.5. Plan de Aceptación El plan de aceptación recoge las fases de puesta en marcha u aceptación del prototipo final, de manera que se pueda seguir una planificación estructura del diseño y construcción del mismo. Una vez pasadas todas pruebas recogidas en el plan se dará el prototipo por terminado. Se contemplarán pruebas tanto individuales, como de integración y de usabilidad a diferentes escalas y en función de la fase de desarrollo en la que se encuentre el proyecto y los subsistemas finalizados e integrados.

121


3.5.1. Fase 1: Construcción de Prototipos Básicos En esta primera fase se estudiarán las diferentes alternativas de viabilidad para el desarrollo de los interfaces de usuario dedicados al diseño de los diagramas y componentes. Principalmente se desarrollarán funcionalidades estáticas 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: Interconexión de componentes. Es necesario estudiar las diferentes posibilidades a la hora de construir objetos gráficos en un navegador que permitan un comportamiento dinámico, 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 diseño de la interfaz de usuario y su grado de proximidad en cuanto a componentes reutilizables disponibles para crear el entorno de diseño de los diagramas. Prototipo 3: Integración de capas del sistema. Finalmente se desarrollará un prototipo que valore el uso e integración de todas las capas del sistema, incluyendo el soporte de almacenamiento persistente y la colaboración síncrona de usuarios.

122


3.5.2. Fase 2: Diseño Detallado del Sistema Una vez aprobados los prototipos de la fase anterior se procederá al diseño exhaustivo del prototipo final a desarrollar, que incluirá al menos los subsistemas de gestión de usuario y diagramas, pero principalmente se buscará obtener un entorno de diseño de diagramas lo más completo y usable posible, siendo este el apartado prioritario del proyecto. Se deberían contemplar al menos las siguientes capas:

Modelo Responsable de mantener el estado de los objetos empleados por el usuario a lo largo de la sesión, 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 aplicación, conectando adecuadamente las peticiones de la vista con servicios del modelo y actualizando los resultados en la petición, la sesión o el contexto. Infraestructura Establece un lenguaje común entre las capas mediante la definición de clases de tipo ‘bean’, que facilite el intercambio de información.

123


3.5.3. Fase 3: Construcción del Prototipo Final Tras la aprobación del diseño detallado se procederá a la implementación del prototipo final, subdividiéndose el trabajo en las capas definidas durante el diseño, que faciliten la integración y ampliación 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 – Diseñar Diagramas Se trata de desarrollar un entorno gráfico de dibujo dónde se permita a los usuarios trabajar de manera síncrona 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 análisis y diseño del sistema, el enfoque elegido es de prototipado funcional, reutilizando los prototipos desarrollados para la construcción de los siguientes. El objetivo de estos prototipos es estudiar la viabilidad del desarrollo del cliente mediante tecnologías AJAX con el soporte de Dojo Toolkit [Dojo] y valorar las posibilidades de integración de los diferentes paquetes desarrollados.

125


3.6.1. Prototipo 1: Interconexión de Componentes Este prototipo permite definir objetos compuestos por varios componentes gráficos 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 comprobación ya que provee una capa de abstracción 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 específicas del resto de objetos del diagrama. Se trata de un prototipo extremadamente básico, pero que aporta una gran luz en la viabilidad de la realización del cliente mediante AJAX, ya que quedan patentes las enormes posibilidades que alberga y además permitirá implementar un entorno visual agradable y altamente interactivo.

Fig. 3-10. Prototipo 1: Interconexión de Componentes

Fecha

17/04/2007

Requerimientos funcionales

2.3, 2.4.

Requerimientos no funcionales

1.6, 2.2, 2.4, 2.5.

Tabla 3.6-1. Prototipo 1: Interconexión de Componentes

126


3.6.2. Prototipo 2: Formato de la Interfaz de Usuario Esta implementación permite desplazar libremente los componentes por el área de diseño, representado por una rejilla en la imagen superior. También se ha diseñado una estructura básica para la interfaz de diseño de los diagramas que se redistribuye automáticamente 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

Fecha

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: Integración de capas del Sistema. Este último prototipo integra de forma básica todas las capas del sistema, incluyendo el soporte de almacenamiento persistente con Oracle 10g y la colaboración síncrona de usuarios. Permite crear cuentas de usuario y diagramas, aunque el resto de información 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 automáticamente en el resto de usuarios conectados al mismo diagrama. También se diseña el aspecto o formato general para el gestor de contenidos a desarrollar como soporte.

Fig. 3-12. Prototipo 3: Integración de capas del Sistema

Fecha

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. Integración de capas del Sistema

128


129


CAPÍTULO 4: DISEÑO En este capítulo se describen brevemente los patrones de diseño empleados, se subdivide el sistema en paquetes o subsistemas y se diseñan los diagramas de clases. Una vez completados estos apartados se proponen los diagramas de secuencia y de estados más relevantes, el diagrama Entidad-Relación para la base de datos a desplegar, la descripción detallada de las clases y el diagrama de componentes.

130


4.1. Patrones de Diseño Para simplificar el diseño 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 patrón de diseño es una solución a un problema de diseño que ha demostrado resultar efectiva y que suele ser reutilizable. Los objetivos principales que tienen son: 

Proporcionar catálogos de elementos reutilizables.



Evitar la reiteración en la búsqueda de soluciones a problemas. Formalizar un vocabulario común entre diseñadores.



Estandarizar el modo en que se realiza el diseño.



Facilitar el aprendizaje de las nuevas generaciones de diseñadores.



Asimismo, no pretenden: 

Imponer ciertas alternativas de diseño frente a otras.

Eliminar la creatividad inherente al proceso de diseño. No es obligatorio utilizar los patrones siempre, solo en el caso de tener el mismo problema o similar que soluciona el patrón, 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. Patrón Modelo-Vista-Controlador (MVC) Este patrón 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 descripción de las capas que se expone a continuación se basa en la segunda opción.

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 sesión, 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 través de los datos depositados en la sesión, el contexto o la petición.

4.1.1.3. Controlador Se encarga de coordinar el flujo de la aplicación, conectando adecuadamente las peticiones de la vista con servicios del modelo y actualizando los resultados en la petición, la sesión 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 automáticamente el flujo de la aplicación a través de la configuración definida en el archivo ‘struts-config.xml’ y mediante la implementación de clases que deriven de la clase Action. Estas clases derivadas únicamente necesitan implementar el método ‘execute’, donde se definirán las llamadas a las clases del modelo que se encargarán de realizar las operaciones de la lógica 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 visión más localizada a ciertas responsabilidades.

4.1.2.1. Patrón Facade El patrón Facade será empleado en el diseño de las interfaces entre las diferentes capas del patrón MVC, de tal modo que cualquier petición de la vista será recogida por el ActionServlet y la redirigirá a la clase Action adecuada, que solicitará el servicio al modelo a través 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 encargarán de realizar todas las acciones necesarias de la lógica de negocio antes y/o después de acceder a la capa de persistencia, como puede ser la comprobación de privilegios o el procesamiento y serialización de datos. La comunicación entre el modelo y la capa de persistencia se realiza a través de la clase PersistenceFacade.

4.1.2.2. Patrón Data Access Objects (DAO) Este patrón 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. Además se creará una clase abstracta DAOFactory que permite crear diversas instancias de clases derivadas que incluyan soporte para algún tipo concreto de base de datos, en este caso únicamente se derivará la clase OracleDAOFactory. Finalmente se derivan clases de todas las interfaces diseñadas y se implementan las operaciones definidas en función del tipo de almacenamiento elegido.

4.1.2.3. Patrón Factory El único cometido de este patrón es apoyar el diseño del anterior mediante factorías que permitan una ampliación más 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 versión completamente funcional antes de diseñar el sistema completo. Además el diseño de estos casos de uso está estrechamente ligado al diseño de los casos de uso relacionados con los diagramas, por lo que una vez desarrollados y probados servirán de guía para el futuro diseño de los casos de uso no recogidos en esta versión. La arquitectura del sistema se basa en el patrón 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 aplicación, conectando adecuadamente las peticiones del subsistema “view” o vista con servicios del “model” o modelo, actualizando los resultados en la petición, la sesión o el contexto para que los cambios sean accesibles a la vista empleando las clases del paquete “common” para transferir información 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 patrón Singleton que se encarga de dirigir automáticamente el flujo de la aplicación a través de la configuración definida en el archivo ‘struts-config.xml’ y mediante la implementación de clases que extiendan el método ‘execute’ de la clase Action. También permite definir formularios dinámicamente en el archivo de configuración 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 configuración ‘tiles-defs.xml’, favoreciendo la reutilización de JSP’s, estilos y formato. También permite definir todos los mensajes de la vista en un archivo ‘.properties’ para su posterior internacionalización. Las clases derivadas de la clase Action realizarán llamadas a métodos de la clase ModelFacade, que implementa el patrón Facade para independizar el controlador del subsistema “model”, que se encargará de realizar las operaciones de la lógica 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 patrón DAO con soporte para Oracle 10g en esta versión y posibilidad de migración 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 patrón MVC la secuencia de acciones a seguir es muy similar en todas las operaciones, salvo los detalles específicos que se recogerán en la capa del modelo, tanto a nivel lógico, como a nivel de persistencia. En este apartado se detallan los tres tipos de operación más empleados en el sistema a desarrollar. Primero se diseña la interacción entre la vista y en controlador, es decir la interfaz con el usuario. La siguiente secuencia se corresponde con la comunicación y transferencia de datos entre el modelo y la persistencia, y finalmente el análisis y procesamiento de un archivo GraphML, empleados en la exportación e importación de diagramas.

142


4.3.1. Interacción Vista – Controlador

Fig. 4-8. Interacción Vista –Controlador

La interacción entre la vista y el controlador se puede generalizar perfectamente con el diagrama de secuencia anterior. Si la acción solicitada corresponde a la zona privada, el LoginFilter captura la petición y comprueba que el usuario está registrado mediante un acceso a la sesión del mismo. En el caso de una petición por formulario, el framework Struts Validator comprueba los campos del formulario y, en caso de encontrar alguno incorrecto, redirecciona de forma automática a la página de la solicitud con los errores correspondientes. Los Action implementados crearán los Bean’s adecuados del subsistema “common” para transferir y recibir información del modelo, mediante el Facade del mismo, el resto de operaciones se describen más adelante. Finalmente el framework Struts Tiles genera la respuesta HTTP mediante los JSP’s, los archivos de mensajes internacionalizados y los Bean’s disponibles.

143


4.3.2. Interacción Modelo – Persistencia

Fig. 4-9. Interacción 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 encargarán de realizar todas las acciones necesarias de la lógica de negocio antes y/o después de acceder a la capa de persistencia, como puede ser la comprobación de privilegios o el procesamiento y serialización de datos. La comunicación entre el modelo y la capa de persistencia se realiza a través de la clase PersistenceFacade que delega las acciones en las clases OracleEntityDAO, implementadas a partir de las interfaces genéricas 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 versión sólo 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 emplearán para recoger los diagramas al crear nuevas versiones, es decir, mientras una versión esté en edición 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-Relación Para almacenar los diagramas, usuarios y privilegios de la aplicación se ha optado por emplear Oracle 10g como base de datos. A continuación se muestra el diagrama Entidad-Relación diseñado a tal efecto:

Fig. 4-11. Diagrama Entidad-Relación

146


4.5. Diccionario de Datos Este apartado resume todas las clases que intervienen en el funcionamiento básico del sistema con los métodos y atributos a desarrollar. La estructura de este apartado se subdivide en paquetes para facilitar su entendimiento, de tal manera que los paquetes más representativos aparecen con un título 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

ModelFacade

Modo

Descripción

public Interfaz entre las capas del modelo y el controlador. Requerimientos

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

Métodos Nombre

public public public public public public

void void Collection UserBean boolean void

addUser exit getAllUsers getUser login addDiagram

public

void

changeDiagramPrivilege

public

void

commitDiagramChange

public

void

destroyDiagram

public

Collection

getAllDiagrams

public

DiagramBean

getDiagram

public

Collection

getDiagramPrivileges

public

DiagramBean

loadDiagram

public

String

queryDiagramChanges

Modo

Parámetros

virtual virtual virtual virtual virtual virtual

user : UserBean userId : String void userId : String user : TinyUserBean 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

Observaciones

Esta clase no realiza ningún procesamiento de los datos recibidos o devueltos. Tabla 4.5-1. Clase ModelFacade

148


4.5.1.2. Clase DiagramManager Nombre

DiagramManager

Modo

Descripción

public

Se encarga de realizar las acciones de la lógica de negocio correspondiente a los diagramas. Requerimientos

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

Alta, baja y modificación de diagramas Buscar diagramas Publicar / compartir diagramas Control de versiones de diagramas Definir dimensiones del área de diseño. Añadir y eliminar componentes. Realizar conexiones entre componentes. Aplicar transformaciones básicas (zoom, rotación…). Cortar, copiar y pegar. Historial de deshacer / rehacer. Guardar, exportar e importar. Colaborar mediante pizarra compartida y Chat. Diseñar un sistema de control de accesos y seguridad adecuado. Retorno

Métodos Nombre

public

void

addDiagram

public

void


public

void

commitDiagramChange

public

void

destroyDiagram

public

Collection

getAllDiagrams

public

DiagramBean

getDiagram

public

Collection


public

DiagramBean

loadDiagram

public

String

queryDiagramChanges

Modo

Parámetros

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

Observaciones

Esta clase realiza las operaciones de la lógica 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 Nombre

UserManager

Modo

Descripción

public

Se encarga de realizar las acciones de la lógica de negocio correspondiente a los usuarios. Requerimientos

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

Alta, baja y modificación de usuarios Validar usuario Buscar usuarios Consultar datos de usuarios Diseñar un sistema de control de accesos y seguridad adecuado.

Acceso

Métodos Nombre

public public public public public

Retorno

void void Collection UserBean boolean

addUser exit getAllUsers getUser login

Modo

virtual virtual virtual virtual virtual

Parámetros

user : UserBean userId : String void userId : String user : TinyUserBean

Observaciones

Esta clase realiza las operaciones de la lógica 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

PersistenceFacade

Modo

Descripción

public Interfaz entre las capas de la persistencia y el modelo. Requerimientos

R1, R2, R5 Proveer al modelo de todos los servicios de persistencia necesarios. RNF 1 Delegar las peticiones del modelo en el DAO adecuado. Acceso

Retorno

Métodos Nombre

private public public public public public public

DAOFactory void void Collection UserBean boolean void

getDAOFactory addUser exit getAllUsers getUser login addDiagram

public

void


public

void

commitDiagramChange

public

void

destroyDiagram

public

Collection

getAllDiagrams

public

DiagramBean

getDiagram

public

Collection


public

DiagramBean

loadDiagram

public

String

queryDiagramChanges

Modo

Parámetros

virtual virtual virtual virtual virtual virtual virtual

void user : UserBean userId : String void userId : String user : TinyUserBean 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

Observaciones

Esta clase no realiza ningún procesamiento de los datos recibidos o devueltos. Tabla 4.5-4. Clase PersistenceFacade

151


4.5.2.2. Clase DAOFactory Nombre

DAOFactory

Modo

Descripción

abstract

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

Crear el DAOFactory adecuado. Definir los tipos DAO que pueden ser creados. Atributos Acceso

public Acceso

public public public

Tipo / Clase

byte Retorno

Nombre

Static

ORACLE Métodos Nombre

DAOFactory getDAOFactory UserDAO getUserDAO DiagramDAO getDiagramDAO

SI Modo

Parámetros

virtual type : byte abstract void abstract void

Observaciones

Construye el DAOFactory adecuado en función del tipo de base de datos y define los tipos de DAO’s que se pueden crear. Tabla 4.5-5. Clase DAOFactory

152


4.5.2.3. Interfaz DiagramDAO Nombre

DiagramDAO

Modo

Descripción

public

Define las operaciones que se pueden realizar sobre la entidad Diagram de la base de datos. Requerimientos

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

Alta, baja y modificación de diagramas Buscar diagramas Publicar / compartir diagramas Control de versiones de diagramas Definir dimensiones del área de diseño. Añadir y eliminar componentes. Realizar conexiones entre componentes. Aplicar transformaciones básicas (zoom, rotación…). Cortar, copiar y pegar. Historial de deshacer / rehacer. Guardar, exportar e importar. Colaborar mediante pizarra compartida y Chat. Retorno

Métodos Nombre

public

void

addDiagram

public

void


public

void

commitDiagramChange

public

void

destroyDiagram

public

Collection

getAllDiagrams

public

DiagramBean getDiagram

public

Collection

public

DiagramBean loadDiagram

public

String


queryDiagramChanges

Modo

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

Observaciones Tabla 4.5-6. Interfaz DiagramDAO

153

Parámetros


4.5.2.4. Interfaz UserDAO Nombre

UserDAO

Modo

Descripción

public

Define las operaciones que se pueden realizar sobre la entidad User de la base de datos. Requerimientos

R5.1 R5.2 R5.3 R5.4 Acceso


Alta, baja y modificación de usuarios Validar usuario Buscar usuarios Consultar datos de usuarios Retorno


Métodos Nombre


Modo

abstract abstract abstract abstract abstract

Parámetros


Observaciones Tabla 4.5-7. Interfaz UserDAO

154


4.5.2.5. Paquete “model.persistence.oracle” 4.5.2.5.1. Clase OracleDAOFactory Nombre

OracleDAOFactory Extiende: DAOFactory

Modo

Descripción

public

Permite crear una conexión JDBC con Oracle 10g y 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. Atributos Acceso

public Acceso

Tipo / Clase

byte Retorno

Nombre

Static

ORACLE

SI Métodos Nombre

public

Connection

createConnection

public

void

freeResources

public public

UserDAO getUserDAO DiagramDAO getDiagramDAO

Modo

Parámetros

static

void stat : Statement static rs : ResultSet abstract void abstract void

Observaciones

Construye el DAOFactory adecuado en función del tipo de base de datos y define los tipos de DAO’s que se pueden crear. Tabla 4.5-8. Clase OracleDAOFactory

155


4.5.2.5.2. Clase OracleDiagramDAO Nombre

Modo

Descripción

OracleDiagramDAO Implementa las operaciones que se pueden realizar public Extiende: DiagramDAO sobre la entidad Diagram de la base de datos. Requerimientos

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

Alta, baja y modificación de diagramas Buscar diagramas Publicar / compartir diagramas Control de versiones de diagramas Definir dimensiones del área de diseño. Añadir y eliminar componentes. Realizar conexiones entre componentes. Aplicar transformaciones básicas (zoom, rotación…). Cortar, copiar y pegar. Historial de deshacer / rehacer. Guardar, exportar e importar. Colaborar mediante pizarra compartida y Chat. Retorno

Métodos Nombre

public

void

addDiagram

public

void


public

void

commitDiagramChange

public

void

destroyDiagram

public

Collection

getAllDiagrams

public

DiagramBean

getDiagram

public

Collection


public

DiagramBean

loadDiagram

public

String

queryDiagramChanges

Modo

Parámetros

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

Observaciones Tabla 4.5-9. Clase OracleDiagramDAO

156


4.5.2.5.3. Clase OracleUserDAO Nombre

OracleUserDAO Extiende: UserDAO

Modo

Descripción

public

Implementa las operaciones que se pueden realizar sobre la entidad User de la base de datos. Requerimientos

R5.1 R5.2 R5.3 R5.4 Acceso


Alta, baja y modificación de usuarios Validar usuario Buscar usuarios Consultar datos de usuarios Retorno


Métodos Nombre


Modo

virtual virtual virtual virtual virtual

Observaciones Tabla 4.5-10. Clase OracleUserDAO

157

Parámetros




4.5.3.1. Clase GraphMLFile Nombre

GraphMLFile

Modo

public

Descripción

Procesa los ficheros GraphML del sistema. Requerimientos

R2.7 Guardar, exportar e importar. RNF 2.6 Definir el modelo de datos mediante tecnologías XML. Atributos Acceso

private

Tipo / Clase

Nombre

Static

GraphMLDefaultHandler defaultHandler

Acceso

Retorno

Métodos Nombre


GraphMLErrorHandler Graph Graph

getErrorHandler load load

public

void

save

public

void

save

NO Modo

Parámetros

virtual void virtual filename : String virtual stream : Reader graph : Graph virtual filename : String graph : Graph virtual stream : Writer

Observaciones

Esta clase redefine la clase GraphMLFile de la librería JUNG para adaptarla a las necesidades del sistema. Tabla 4.5-11. Clase GraphMLFile

158


4.5.3.2. Clase GraphMLDefaultHandler Nombre

Modo

GraphMLDefaultHandler public

Descripción

Gestiona los eventos producidos por el SAXParser empleado para analizar el documento XML. Requerimientos

Generar un objeto de la clase Graph a partir de un documento GraphML Atributos Acceso

private private private private private private

Tipo / Clase

Graph Stack HashMap GraphMLErrorHandler StringLabeller boolean

Acceso

Retorno

Nombre

Static

graph elementStack keyMap errorHandler stringLabeller default_directed Métodos Nombre

NO NO NO NO NO NO Modo

public

void

startElement

virtual

public

void

endElement

virtual

public

void

characters

virtual

public public public public protected protected protected protected protected protected

void void void GraphMlErrorHandler Graph StringLabeller void void void void

warning error fatalError getErrorHandler getGraph getLabeller createGraph createVertex createEdge createKey

virtual virtual virtual virtual virtual virtual virtual virtual virtual virtual

protected void

createNestedElem. virtual

private private

Map void

getAttributeMap createTextData

virtual virtual

private

void

setUserData

virtual

private

void

addNestedElemen. virtual

Parámetros

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

Observaciones

Esta clase redefine la clase GraphMLDefaultHandler de la librería JUNG para adaptarla a las necesidades del sistema. Tabla 4.5-12. Clase GraphMLDefaultHandler

159


4.5.3.3. Clase GraphMLErrorHandler Nombre

GraphMLErrorHandler

Modo

Descripción

public

Captura las excepciones lanzadas por el SAXParser empleado para analizar el documento XML. Requerimientos

Recoger los errores y advertencias generados al analizar documentos GraphML. Atributos Acceso

private private private Acceso

public public public public public public private

Tipo / Clase

long long Vector Retorno

void void void long long Vector String

Nombre

Static

errorCount warnCount messages Métodos Nombre

warning error fatalError getWarningCount getErrorCount getMessages formatLineAndCol

NO NO NO Modo


Parámetros

e : SAXParseException e : SAXParseException e : SAXParseException void void void e : SAXParseException

Observaciones

Esta clase implementa los métodos de gestión 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 Nombre

GraphMLSerializer

Modo

Descripción

public

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

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


Tipo / Clase

boolean PrintStream int

Nombre

directed out level Métodos Nombre

Retorno

NO NO NO Modo

public

boolean

invalidXMLData

static

public

void

save

virtual

public

void

save

virtual

private private private private

void void void void

saveVerticesSection saveEdgesSection saveUserData saveNestedElement

virtual virtual virtual virtual

Parámetros

str : String graph : Graph filename : String graph : Graph stream : PrintStream graph : Graph graph : Graph udc : UserDataContainer elem : GraphMLElement

Observaciones Tabla 4.5-14. Clase GraphMLSerializer

161

Static



4.5.4.1. Clase JSONSerializer Nombre

Modo

Descripción

JSONSerializer

public

Clase auxiliar para convertir a formato JSON los objetos que se devuelven en las llamadas AJAX de la vista. Requerimientos

Convertir a formato JSON los objetos devueltos a la capa de la vista. Atributos Acceso


public public public private private private private

Tipo / Clase

boolean StringBuffer Graph Retorno

String String String void void void void

Stati c

Nombre

directed buffer graph Métodos Nombre

parseGraph parseVector parseArray parseVertices parseEdges parseShapes parseAttributes

NO NO NO Modo

Parámetros


graph : Graph vector : Vector array : Object[] void void void udc : UserDataContainer

Observaciones

Pueden añadirse tantos métodos como sean necesarios durante el desarrollo del sistema, también sería recomendable valorar el diseño de una interfaz adecuada para transferir parámetros a esta clase. Tabla 4.5-15. Clase JSONSerializer

162


4.5.4.2. Paquete “common.entity” 4.5.4.2.1. Clase DiagramBean Nombre

DiagramBean

Modo

public

Descripción

Almacena información de un diagrama. Requerimientos

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

Alta, baja y modificación de diagramas Buscar diagramas Publicar / compartir diagramas Control de versiones de diagramas Atributos

Acceso

public public public public public public public private private private private private private private

Tipo / Clase

byte byte byte byte byte byte byte String String String int String byte String

Nombre

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

Static

SI SI SI SI SI SI SI NO NO NO NO NO NO NO

Observaciones

Esta clase se emplea para la transferencia de información relativa a los diagramas, a través de todas las capas del sistema a desarrollar. Tabla 4.5-16. Clase DiagramBean

163


4.5.4.2.2. Clase DiagramPrivilegeBean Nombre

Modo

Descripción

DiagramPrivilegeBean

public

Almacena información del privilegio asignado a un usuario sobre un diagrama. Requerimientos

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

Alta, baja y modificación de diagramas Buscar diagramas Publicar / compartir diagramas Control de versiones de diagramas Diseñar un sistema de control de accesos y seguridad adecuado. Atributos

Acceso

private private private

Tipo / Clase

String String byte

Nombre

diagramId userId privilege

Static

NO NO NO

Observaciones

Esta clase se emplea para la transferencia de información relativa a los permisos de los usuarios sobre los diagramas, a través de todas las capas del sistema a desarrollar. Tabla 4.5-17. Clase DiagramPrivilegeBean

4.5.4.2.3. Clase DiagramChangeBean Nombre

DiagramChangeBean

Modo

Descripción

public

Almacena información de un cambio puntual en el diseño de un diagrama. Requerimientos

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

Definir dimensiones del área de diseño. Añadir y eliminar componentes. Realizar conexiones entre componentes. Aplicar transformaciones básicas (zoom, rotación…). Cortar, copiar y pegar. Historial de deshacer / rehacer. Guardar, exportar e importar. Colaborar mediante pizarra compartida y Chat. Atributos

Acceso

private private private private private

Tipo / Clase

String String String String String

Nombre

changeId diagramId userId jsonRedo jsonUndo

Static

NO NO NO NO NO

Observaciones

Esta clase se emplea para la transferencia de información 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 Nombre

TinyUserBean

Modo

Descripción

public

Almacena el identificador y la contraseña de un usuario. Requerimientos

R5.2 Validar usuario RNF 2.9 Diseñar un sistema de control de accesos y seguridad adecuado. Atributos Acceso

private private

Tipo / Clase

String String

Nombre

id password

Static

NO NO

Observaciones

Esta clase se emplea para la transferencia de información relativa al proceso de ‘login’ de los usuarios del sistema. Tabla 4.5-19. Clase TinyUserBean

4.5.4.2.5. Clase UserBean Nombre

Modo

Descripción

UserBean Extiende: TinyUserBean

public

Almacena información relativa a un usuario del sistema. Requerimientos

R5.1 R5.3 R5.4

Alta, baja y modificación de usuarios Buscar usuarios Consultar datos de usuarios Atributos

Acceso

private private private private

Tipo / Clase

String String String int

Nombre

firstName lastName email diagramCount

Static

NO NO NO NO

Observaciones

Esta clase se emplea para la transferencia de información 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 Nombre

FilterLogin

Modo

Descripción

public

Comprueba que el usuario esté registrado al solicitar un recurso privado del sistema. Requerimientos

R5.2 Validar usuario RNF 2.9 Diseñar un sistema de control de accesos y seguridad adecuado. Acceso

public

Retorno

void

Métodos Nombre Modo

doFilter

Parámetros

request : ServletRequest virtual response : ServletResponse chain : FilterChain Observaciones

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 página 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 Nombre

Modo

AddDiagramAction Extiende: Action

Descripción

public Añade un diagrama al sistema. Requerimientos

R1.1

Alta, baja y modificación de diagramas

Acceso

public


Retorno

ActionForward

execute

Parámetros

mapping : ActionMapping form : ActionForm virtual request : HttpServletRequest response : HttpServletResponse

Tabla 4.5-22. Clase AddDiagramAction

4.5.5.2.2. Clase QueryDiagramAction Nombre

Modo

QueryDiagramAction Extiende: Action

Descripción

public Consulta un diagrama del sistema. Requerimientos

R1.2 R2.8

Buscar diagramas Colaborar mediante pizarra compartida y Chat.

Acceso

public

Retorno

ActionForward


execute

Parámetros


Tabla 4.5-23. Clase QueryDiagramAction

4.5.5.2.3. Clase DestroyDiagramAction Nombre

Modo

DestroyDiagramAction Extiende: Action

Descripción

public Destruye por completo un diagrama. Requerimientos

R1.1 Acceso

public

Alta, baja y modificación de diagramas Retorno

ActionForward


execute


Tabla 4.5-24. Clase DestroyDiagramAction

167

Parámetros


4.5.5.2.4. Clase QueryDiagramChangeAction Nombre

Modo

Descripción

QueryDiagramChangeAction Extiende: Action

public

Consulta los cambios producidos en un diagrama a partir de un cambio dado.

Requerimientos

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

public

Definir dimensiones del área de diseño. Añadir y eliminar componentes. Realizar conexiones entre componentes. Aplicar transformaciones básicas (zoom, rotación…). Cortar, copiar y pegar. Historial de deshacer / rehacer. Guardar, exportar e importar. Colaborar mediante pizarra compartida y Chat. Retorno

ActionForward


execute

Parámetros


Tabla 4.5-25. Clase QueryDiagramChangeAction

4.5.5.2.5. Clase CommitDiagramChangeAction Nombre

Modo

CommitDiagramChangeAction public Extiende: Action

Descripción

Registra los cambios producidos en un diagrama.

Requerimientos

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

public

Definir dimensiones del área de diseño. Añadir y eliminar componentes. Realizar conexiones entre componentes. Aplicar transformaciones básicas (zoom, rotación…). Cortar, copiar y pegar. Historial de deshacer / rehacer. Guardar, exportar e importar. Colaborar mediante pizarra compartida y Chat. Retorno

ActionForward


execute

Parámetros


Tabla 4.5-26. Clase CommitDiagramChangeAction

168


4.5.5.2.6. Clase LoadDiagramAction Nombre

Modo

LoadDiagramAction Extiende: Action

Descripción

public Carga un diagrama del sistema en el editor. Requerimientos

R1.4 R2.6 R2.7 R2.8 Acceso

public

Control de versiones de diagramas Historial de deshacer / rehacer. Guardar, exportar e importar. Colaborar mediante pizarra compartida y Chat. Retorno

ActionForward


execute

Parámetros


Tabla 4.5-27. Clase LoadDiagramAction

4.5.5.2.7. Clase QueryAllDiagramsAction Nombre

Modo

Descripción

QueryAllDiagramsAction Consulta todos los diagramas a los que puede public Extiende: Action acceder el usuario. Requerimientos

R1.2 R1.3 Acceso

public

Buscar diagramas Publicar / compartir diagramas Retorno

ActionForward


execute

Parámetros


Tabla 4.5-28. Clase QueryAllDiagramsAction

4.5.5.2.8. Clase QueryDiagramPrivilegesAction Nombre

Modo

QueryDiagramPrivilegesAction public Extiende: Action

Descripción

Consulta los permisos de los usuarios del sistema sobre el diagrama.

Requerimientos

R1.3 R2.8 Acceso

public

Publicar / compartir diagramas Colaborar mediante pizarra compartida y Chat. Retorno

ActionForward


execute

virtual

Parámetros

mapping : ActionMapping form : ActionForm request : HttpServletRequest response : HttpServletResponse

Tabla 4.5-29. Clase QueryDiagramPrivilegesAction

169


4.5.5.2.9. Clase ChangeDiagramPrivilegeAction Nombre

Modo

Descripción

ChangeDiagramPrivilegeAction Consulta los permisos de los usuarios del public Extiende: Action sistema sobre el diagrama. Requerimientos

R1.3 R2.8 Acceso

public

Publicar / compartir diagramas Colaborar mediante pizarra compartida y Chat. Retorno

ActionForward


execute

virtual

Parámetros


Tabla 4.5-30. Clase ChangeDiagramPrivilegeAction

170


4.5.5.3. Paquete “controller.action.user” 4.5.5.3.1. Clase AddUserAction Nombre

Modo

AddUserAction Extiende: Action

Descripción

public Añade un usuario al sistema. Requerimientos

R5.1 Acceso

public

Alta, baja y modificación de usuarios Métodos Nombre Modo

Retorno

ActionForward

execute

virtual

Parámetros


Tabla 4.5-31. Clase AddUserAction

4.5.5.3.2. Clase QueryUserAction Nombre

Modo

QueryUserAction Extiende: Action

Descripción

public Consulta un usuario del sistema. Requerimientos

R5.3 R5.4 Acceso

public

Buscar usuarios Consultar datos de usuarios Métodos Nombre Modo

Retorno

ActionForward

execute

virtual

Parámetros


Tabla 4.5-32. Clase QueryUserAction

4.5.5.3.3. Clase QueryAllUsersAction Nombre

Modo

QueryAllUsersAction Extiende: Action

Descripción

public Consulta todos los usuarios del sistema. Requerimientos

R5.3 R5.4 Acceso

public

Buscar usuarios Consultar datos de usuarios Retorno

ActionForward


execute

virtual

Parámetros


Tabla 4.5-33. Clase QueryAllUsersAction

171


4.5.5.3.4. Clase LoginAction Nombre

Modo

LoginAction Extiende: Action

Descripción

public Registra un usuario en el sistema. Requerimientos

R5.2 Validar usuario RNF 2.9 Diseñar un sistema de control de accesos y seguridad adecuado. Acceso

public

Retorno

ActionForward


execute

virtual

Parámetros


Tabla 4.5-34. Clase LoginAction

4.5.5.3.5. Clase LoginCounterAction Nombre

Modo

Descripción

LoginCounterAction Extiende: Action

public

Almacena el número de usuarios registrados con éxito en el sistema.

Requerimientos

R5.2 Acceso

public

Validar usuario Retorno

ActionForward


execute

virtual

Parámetros


Tabla 4.5-35. Clase LoginCounterAction

4.5.5.3.6. Clase ExitAction Nombre

ExitAction Extiende: Action

Modo

Descripción

public Desconecta un usuario del sistema. Requerimientos

R5.2 Acceso

public

Validar usuario Retorno

ActionForward


execute

virtual

Parámetros


Tabla 4.5-36. Clase ExitAction

172


4.5.6. Paquete “view” 4.5.6.1.1. Clase DiagramEditor Nombre

DiagramEditor

Modo

Descripción

public

Gestiona todas las acciones de edición de diagramas en el navegador Web. Responsabilidades

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

Definir dimensiones del área de diseño. Añadir y eliminar componentes. Realizar conexiones entre componentes. Aplicar transformaciones básicas (zoom, rotación…). Cortar, copiar y pegar. Historial de deshacer / rehacer. Guardar, exportar e importar. Colaborar mediante pizarra compartida y Chat. Atributos

Acceso

private private private private private private Acceso

Tipo / Clase

Node[] Link[] Surface String String DIV Retorno

Nombre

nodes edges surface diagramId userId container Métodos Nombre

public

void

createNode

public

void

createLink

public public public public public public public

void void void void void void void

zoomIn zoomOut commitChange queryChanges onMouseDown onMouseMove onMouseUp

private

void

Static

handleXhrResponse


Parámetros

virtual node : Json sourceId : String virtual targetId : String virtual void virtual void virtual change : Json virtual void virtual e : Event virtual e : Event virtual e : Event response virtual HttpResponse ioArgs : xhrArgs

:

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 definición de clases de Dojo Toolkit. Tabla 4.5-37. Clase DiagramEditor

173


4.5.6.1.2. Clase Node Nombre

Node

Modo

Descripción

public

Almacena los datos necesarios para la representación e interacción de los objetos del diagrama a diseñar. Responsabilidades

R2.2 R2.3 R2.4

Añadir y eliminar componentes. Realizar conexiones entre componentes. Aplicar transformaciones básicas (zoom, rotación…). Atributos

Acceso

private private private private private private Acceso


Tipo / Clase

String Group Shape String Shapes[] Shapes[] Retorno

void void String

Nombre

Static

nodeId gfx boundingShape text shapes ports Métodos Nombre

createShapes createShape toJson


Parámetros

virtual shapes : Shape[] virtual shape : Shape virtual void

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 definición de clases de Dojo Toolkit. Tabla 4.5-38. Clase Node

174


4.5.6.1.3. Clase Link Nombre

Link

Modo

Descripción

public

Almacena los datos necesarios para la representación e interacción de las conexiones entre los nodos del diagrama a diseñar. Responsabilidades

R2.3 R2.4

Realizar conexiones entre componentes. Aplicar transformaciones básicas (zoom, rotación…). Atributos

Acceso

private private private private private Acceso

Tipo / Clase

String Shape String Node Node

Nombre

Static

linkId shape text source target

NO NO NO NO NO Métodos Nombre

Retorno

public

void

createLink

public

String

toJson

Modo

Parámetros

source : Node source : Node virtual void virtual

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 definición de clases de Dojo Toolkit. 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 librerías 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 interacción a grandes rasgos con los componentes a desarrollar.

Fig. 4-12. Diagrama de Componentes

176


177


CAPÍTULO 5: CONSTRUCCIÓN Este capítulo se dedica íntegramente a los archivos de configuración desarrollados, así como al código fuente y las páginas JSP.

178


5.1. Ficheros de Configuración Los ficheros de configuración contenidos en este apartado son los siguientes:

web.xml Este fichero se emplea para configurar las aplicaciones JEE, entre otras opciones se configuran los Servlet’s a emplear, las librerías de etiquetas, los filtros, los mapeos y los parámetros básicos. struts-config.xml Sirve para configurar el funcionamiento de Struts, pudiendo definir la cadena de acciones, el control de flujo, los formularios dinámicos, los mapeos de las acciones, el archivo de recursos internacionalizados y los plugin’s. 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 páginas JSP, disminuyendo el número de páginas a desarrollar y aumentando en gran medida la reutilización de código. build.xml Este archivo no es un fichero de configuración propiamente dicho, aunque sirve para especificar una serie de tareas automatizadas que den como resultado una nueva versión actualizada del proyecto. MessagesResources.properties Es el archivo de mensajes internacionalizados por defecto, en caso de querer traducir la aplicación a otro idioma bastaría con traducir las cadenas contenidas en este fichero, renombrándolo con el idioma en formato ISO al final, por ejemplo ‘MessagesResources_en.properties’ para inglés.

179


5.1.1. web.xml

Abstract Minds

Web 2.0 Enviroment for Object Interconection Diagram Design

index.jsp

action org.apache.struts.action.ActionServlet

config /WEB-INF/struts-config.xml

180


convertNull true

validating true

debug 2

detail 2

2

action *.do

LoginFilter abstractminds.controller.filter.LoginFilter

181


LoginFilter /app/*

/tags/struts-bean /WEB-INF/struts-bean.tld /tags/struts-html /WEB-INF/struts-html.tld /tags/struts-logic /WEB-INF/struts-logic.tld /tags/struts-nested /WEB-INF/struts-nested.tld /tags/struts-tiles /WEB-INF/struts-tiles.tld

182


5.1.2. struts-config.xml

183


184


185


type="abstractminds.controller.action.diagram.QueryDiagramPrivilegesAction">

186


187


className="org.apache.struts.validator.ValidatorPlugIn">

/>

188


5.1.3. validation.xml

minlength4 maxlength20 mask ^[0-9a-zA-Z_]*$ minlength4 maxlength20 mask ^[0-9a-zA-Z_]*$

189


minlength4 maxlength20 mask ^[0-9a-zA-Z_]*$ minlength4 maxlength20 mask ^[0-9a-zA-Z_]*$ maxlength50 mask ^[0-9a-zA-Z_ ]*$

190


maxlength100 mask ^[0-9a-zA-Z_ ]*$ maxlength50

maxlength50 mask ^[0-9a-zA-Z_ ]*$ maxlength500 mask ^[0-9a-zA-Z_]*$

191


5.1.4. tiles-defs.xml

192


193


194


5.1.5. build.xml

195


196


197


198


199


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=Contraseña form.user.first_name=Nombre form.user.last_name=Apellidos form.user.email=e-mail

form.diagram.id=ID form.diagram.version=Versión form.diagram.name=Nombre form.diagram.creator=Creador form.diagram.description=Descripción 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 contraseña 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 más de {1} caracteres. errors.invalid=El campo {0} contiene caracteres no válidos.

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 válida. errors.range=El campo {0} no está entre {1} y {2}. errors.creditcard=El campo {0} no es un numero de tarjeta de crédito válido. errors.email=El campo {0} no es una dirección de e-mail correcta.

202


5.2. Código Fuente En este apartado se incorpora el código fuente Java generado durante el desarrollo del proyecto, omitiéndose los comentarios JavaDoc para facilitar su lectura y economizar espacio. El código fuente también puede obtenerse directamente del CD que acompaña a este documento. Se ha respetado la organización empleada durante el diseño, subdividendo el sistema en los paquetes más importantes y separando de manera adecuada las responsabilidades. responsabilidades. Estos paquetes pueden contener otros paquetes internos con los que compartan responsabilidades. También se incluye un apartado de recursos adicionales dedicado a las páginas JSP y los ficheros CSS desarrollados. desarrollados.

203



5.2.1.1. ModelFacade.java 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 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 DiagramManager.java package abstractminds.model;

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 lse { Iterator it = changes.iterator(); change

= (DiagramChangeB ean) 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 lse { 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 lse { 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 (privilegeBe (privilegeBean.getPriv an.getPrivilege() ilege() < DiagramBean.DIAGRAM_PRIVILEGE_CREATOR){ new

PersistenceFacade().updateDiagramPrivilege(privilegeBean);

} else { throw new IllegalArgumentException("Privilege isn't valid."); } } else lse { 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 lse { throw new IllegalArgumentException("Insufficient privileges."); } return diagram; } }

208


5.2.1.3. UserManager.java UserManager.java package abstractminds.model;


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 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 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 package abstractminds.model.persistence;

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 package abstractminds.model.persistence;


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 package abstractminds.model.persistence;


import abstractminds.common.entity.TinyUserBean; import abstractminds.common.entity.UserBean;

public interface UserDAO {

public void insertUser(UserBean user) throws SQLException;

public Collection 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 package abstractminds.model.persistence.oracle;

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 v = new Vector(); 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 v = new Vector(); 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 v = new Vector(); 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 package abstractminds.model.persistence.oracle;

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 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 v = new Vector(); 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 ),

mDefaultHandler

);

} catch (Exception e) { throw new FatalException("Error loading graphml file: " + e); } return mDefaultHandler.getGraph(); }

public List 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 graphCollection = new ArrayList(); 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 package abstractminds.model.graphml;

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 elementsStack; private HashMap keysMap; private GraphMLErrorHandler errorHandler; private StringLabeller mLabeller; private boolean default_directed;

public GraphMLDefaultHandler() { elementsStack = new Stack(); keysMap = new HashMap(); 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 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, } }

233

attributeMap));


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 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 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 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 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 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 attributeMap) {

for (Iterator 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(); elementsStack.peek() .setUserDatum("nestedElements", ne, UserData.SHARED); } ne.add(nestedElement); }

private Map getAttributeMap(Attributes attrs) { Map map = new HashMap(); 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 package abstractminds.model.graphml;

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 messages = new Vector();

public long getErrorCount() { return errorCount; }

public long getWarningCount() { return warnCount; }

public Vector 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 package abstractminds.model.graphml;

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(""); out.println("
xmlns=\"http://graphml.graphdrawing.org/xmlns\"");

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("
242


if (directed) out.print("directed\""); else out.print("undirected\""); if (!saveUserData(g)) out.print(">"); saveVerticesSection(g); saveEdgesSection(g); newLine(); out.print(""); newLine(); out.print(""); }

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("
if (saveUserData(v)) { out.print(""); } 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("
// 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(""); } else { out.print("/>"); } } level--; }

244


private void saveNestedElements(Iterator 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(""); } else { out.print("/>"); } } } level--; if (data) newLine(); }

private boolean saveUserData(UserDataContainer udc) { Vector elements = new Vector();

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 data = (Vector) v.getUserDatum("nestedElements"); if (data.size() == 1 && data.lastElement().getQName().equalsIgnoreCase("data")) { Vector shapes = (Vector) data.lastElement().getUserDatum("nestedElements"); for (int i = 0;;) { GraphMLElement currentShape = shapes.get(i); Vector properties = (Vector) 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 package abstractminds.common.entity;

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 package abstractminds.common.entity;

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 package abstractminds.common.entity;

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 package abstractminds.common.entity;

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 package abstractminds.controller.action.diagram;


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 package abstractminds.controller.action.diagram;


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 package abstractminds.controller.action.diagram;



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 package abstractminds.controller.action.diagram;



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 package abstractminds.controller.action.diagram;

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 package abstractminds.controller.action.diagram;




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 package abstractminds.controller.action.diagram;



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 package abstractminds.controller.action.diagram;




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 package abstractminds.controller.action.user;




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 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.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 package abstractminds.controller.action.user;



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 package abstractminds.controller.action.user;




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 package abstractminds.controller.action.user;




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
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
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
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" %>

<tiles:getAsString name="appTitle"/> <bean:message name="titleKey" scope="request"/>

294


5.2.7.1.2. index.jsp <%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic"%>

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" %>

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" %>

: ( ) ( - )

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" %>

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" %>

">

">

">

">

">

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"%>

.

:

:

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"%>

:

:

:

:

:

298


5.2.7.1.9. user.jsp <%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean"%>

:

:

:

:

:

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"%>

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"%>

:

:

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"%>

:

:

:

:

:

key="form.diagram.description"/>:

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"%>

.

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"%>
: ''

" title="" >
">
"> ">

304


CHECKED> ">
CHECKED> ">
CHECKED> ">
CHECKED> ">
CHECKED> ">
CHECKED> ">
"/>

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"%>

" title="" >"/>

" title="" >"/>

" title="" >"/>

" title="" >"/>

306


&userId=&privilege=-1" title="" >"/>

" title="" >"/>

307


5.2.7.1.16. diagramEditor.jsp <%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %> Abstract Minds - <bean:message key="title.diagram.editor"/> <script type="text/javascript" src="../ajax/dojo/dojo.js.uncompressed.js" djConfig="parseOnLoad: true, isDebug: true">

<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:'', userId:'', objects: } ); } dojo.addOnLoad(initDiagramEditor);

308


309


Commits: 0

310


5.2.7.1.17. ajax.jsp <%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>

5.2.7.1.18. ajax_error.jsp <%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>{error:""}

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 pestañas*/ 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: }

315

#2956B2;


#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


CAPÍTULO 6: M ANU ALES Este capítulo incluye el manual de instalación del sistema con los pasos a seguir y los requisitos mínimos de hardware y software. También se describe el uso básico del entorno mediante un manual de usuario organizado por funcionalidades.

322


6.1. Manual de Instalación Este manual está destinado a describir los requisitos de instalación del sistema desarrollado, así como la enumeración de pasos a seguir para su correcta implantación y despliegue.

323


6.1.1. Requisitos Mínimos

6.1.1.1. Hardware Recurso

Mínimo

Recomendado

Disco Duro

500 MB

Más de 10 GB

Memoria RAM

500 MB

Más de 2 GB

Conexión a Internet

10 Mbps

Más de 100 Mbps

Tabla 6.1-1. Requisitos hardware

6.1.1.2. Software Recurso

Mínimo

Recomendado

Java JRE

1.5

1.5

JBOSS

4

4

Oracle

10g

10g

Struts

1

2

Dojo Toolkit

0.9.0

0.9.0

JUNG

1.7.6

1.7.6

Tabla 6.1-2. Requisitos software

324


6.1.2. Instalación 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, también 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 instalación de Oracle se realizará siguiendo los pasos indicados por el fabricante si es necesario. Basta con realizar una instalación típica 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 aplicación.

6.1.2.3. Despliegue El resto de componentes se incluyen en el archivo ‘AbstractMinds.war’ del directorio ‘despliegue’. Para poder acceder a la aplicación 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 dirección: 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 elaboración de este manual, algunas de las funcionalidades descritas no estaban completamente testadas o integradas por lo que podían observarse ligeras variaciones en el sistema final. También puede darse el caso de encontrar nuevas funcionalidades o interfaces no previstas durante su redacción, por lo que en última instancia se recomienda acceder a la versión ‘on-line’del mismo, disponible desde cualquiera de las interfaces descritas en este manual.

326


6.2.1. Gestión 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 automáticamente.

6.2.1.1. Conectar La forma más común de acceso es mediante el formulario de conexión al sistema, el cual requiere del usuario un identificador y una contraseña previamente especificados al crear la cuenta.

Fig. 6-1. Formulario de conexión

El usuario y la contraseña deben estar formados por un mínimo de cuatro caracteres y un máximo de veinte, sin espacios y sin símbolos especiales, únicamente letras, números y el carácter de subrayado (‘_’). En caso de introducir algún 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 creación de una nueva cuenta de usuario con un identificador y una contraseña como mínimo, además de otros datos opcionales que se irán ampliando en futuras versiones del sistema en función de las necesidades.

Fig. 6-2. Crear usuario

Al igual que en el formulario de conexión los mensajes que se muestran están 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 opción del menú correspondiente, como desde otras zonas más específicas. Al seleccionar un usuario concreto se mostrará una página con sus datos.

Fig. 6-3. Datos de la cuenta de usuario

329


6.2.2. Gestión de Diagramas El sistema permite crear, eliminar, compartir y acceder a los distintos diagramas creados, tanto propios como compartidos. También 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 recién creado no posee ningún 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 descripción.

Fig. 6-4. Crear diagrama

Sólo 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 gestión 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 botón , sin embargo esta opción es irreversible, por lo que deberá emplearse con cautela. Ningún 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 más importantes de la gestión de diagramas es la gestión de los privilegios asociados a cada usuario.

Fig. 6-6. Gestionar permisos sobre diagramas

Desde esta página podemos asignar los permisos apropiados para cada usuario del sistema. Sólo los usuarios con privilegio de control total o el propio creador pueden gestionar los permisos, es decir, inicialmente sólo el creador puede acceder a esta funcionalidad. Las acciones permitidas por cada privilegio son acumulables y van de menos a más funcionalidad.

332


Los privilegios disponibles se describen a continuación:

El usuario no puede listar el diagrama ni consultar sus datos.

Sólo puede consultar la información 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 síncrona con otros usuarios autorizados.

Añade 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. Edición de Diagramas El diseño de los diagramas abarca cualquier cambio que se desee realizar sobre el contenido o la disposición de un diagrama concreto. Se trata de un entorno gráfico de dibujo dónde varios usuarios pueden trabajar de manera síncrona sobre un mismo diagrama, actualizándose los cambios en tiempo real en todos los clientes.

Fig. 6-7. Edición de diagramas

Entre las acciones posibles destacan algunas como definir las dimensiones del área de diseño, añadir y eliminar componentes, realizar conexiones entre componentes, aplicar transformaciones básicas (zoom, rotación…), cortar, copiar y pegar, historial de deshacer / rehacer, guardar, exportar e importar.

334


335


CAPÍTULO 7: CONCLUSIONES Como capítulo final se exponen las conclusiones derivadas de todo el trabjo realizado para el análisis, diseño y construcción del prototipo final, así como para la elaboración de este documento. Adicionalmente se detalla el contenido de los entregables y el catálogo de ampliaciones que se proponen.

336


7.1. Resultados Este apartado comprende todas las conclusiones derivadas de la realización de este proyecto, tanto en los estudios previos como en las fases más avanzadas de desarrollo.

Estudios realizados Durante la mayor parte de este proyecto la actividad principal ha sido el estudio de las diferentes tecnologías, librerías y herramientas a emplear para cumplir los objetivos marcados. La metodología de trabajo empleada enfoca la solución al problema hacia la reutilización de componentes ya desarrollados, preferiblemente basados en código abierto. Lo cual a primera vista supone un ahorro de tiempo de desarrollo, pero que sin embargo requiere un esfuerzo continuo, más aún cuando es necesario realizar alguna función concreta a través de estos componentes. Quizá la mayor barrera sea la escasa documentación del código y las librerías empleadas, incluso la falta de madurez que llegan a presentar estos recursos al profundizar en sus funcionalidades más complejas. Para solver estos problemas, en muchas ocasiones se ha optado por consultar el código fuente directamente, como es el caso del módulo de gráficos vectoriales de Dojo, cuya documentación es mínima y que sin embargo se pueden conseguir resultados de gran calidad mediante el examen detallado del código fuente. De no haber elegido recursos de código abierto esto nunca hubiese sido posible y se podría haber convertido en una barrera más difícil de solucionar. De esta fase cabe destacar el conocimiento adquirido sobre tecnologías relativamente modernas como XML, AJAX, Web 2.0 y Struts entre otras. Planificación Este ha sido uno de los apartados en los que se ha hecho más notable la falta de experiencia con la que se afronta un proyecto de fin de carrera. Resulta muy complicado prever cuánto 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 aún 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 elaboración de los prototipos, que ha permitido ir acotando paulatinamente el alcance del prototipo final, consiguiendo ajustar adecuadamente los plazos de desarrollo y documentación del proyecto a las fechas previstas.

337


Prototipos La decisión de usar una metodología de desarrollo basada en prototipado ágil surge ya en la primera reunión con el director del proyecto. La motivación 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 más completos y fiables. Este hecho unido a la motivación de crear un proyecto de código 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 documentación adecuados. Incluso la colaboración de los usuarios puede ser directa mediante la modificación explícita del sistema o proponiendo modulos y ampliaciones adicionales. Análisis En esta fase también se ha hecho palpable la falta de experiencia anterior en la identificación y especificación de requerimientos. Se ha tratado de llevar un seguimiento exhaustivo de la especificación realizada al principio del análisis que ha permitido delimitar adecuadamente el grado de completitud de cada prototipo y que ha sido un gran apoyo de cara a afrontar el diseño 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. Diseño A partir de esta actividad el proyecto empieza a tomar forma y pueden probarse las funcionalidades más básicas mediante los prototipos que se han ido desarrollando con anterioridad. Los métodos empleados para diseñar el sistema han resultado más amigables y expresivos que los del análisis. Se define la arquitetura del sistema mediante el patrón 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 patrón Facade. Sin duda esta ha sido la actividad más laboriosa de completar, y quizá la más tensa, por la necesidad de acotar correctamente el alcance del prototipo final y disponer de tiempo suficiente para diseñar una arquitectura global y su posterior implementación.

338


Construcción El objetivo original de este proyecto es el desarrollo de un prototipo lo más completo y funcional posible de un entorno de diseño de diagramas de interconexión de objetos a través de Internet. Al ser una aplicación Web permite a los usuarios acceder a su funcionalidad desde cualquier ordenador con conexión a Internet. Además se ha construido mediante tecnologías Web 2.0, como AJAX y JSON, que aportan un grado mucho más elevado de interactividad y dinamismo a las interfaces de usuario. También se logró encontrar un vocabulario XML apropiado, GraphML, que es empleado en la representación de grafos y por tanto cubre perfectamente las necesidades del diseño de diagramas. Al final el requerimiento de colaboración síncrona entre usuarios ha sido prioritario respecto al resto por lo que ha podido ser completado con éxito y además se incluye un entorno de diseño y gestión 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 catálogo de alternativas más utilizadas por los usuarios, habiendo sido prubado con éxito en Internet Explorer 6, Mozilla Firefox 2. Opera 9 y Safari 3. Además no requiere de instalación alguna de plugin´s en ninguno de ellos. Gracias a las facilidades aportadas por Struts también 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 continuación:

Archivo ‘LEEME.txt’ Archivo de texto con la descripción del contenido del CD y la identificación del proyecto y del autor. Directorio ‘Entorno’ Entorno de desarrollo empleado en la construcción 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’ Código fuente, ficheros de configuración y librerías 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 elaboración. Directorio ‘Manuales’ Manuales de instalación y de usuario.

340


7.3. Ampliaciones La siguiente actividad a llevar a cabo antes de proseguir el desarrollo de prototipos es la especificación detallada de un plan de pruebas que incluya pruebas individuales exhaustivas de todos los componentes desarrollados, pruebas de integración de todos los subsistemas y pruebas de rendimiento para comprobar la escalabilidad del sistema y la correción de la gestión de recursos del hardware de cara a afrontar un gran numero de usuarios simultáneos. También es imprescindible realizar tests apropiados de usabilidad que garantizen la calidad de la interfaz de usuario en sucesivas versiones. Uno de los aspectos más destacables de la solución 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 continuación.

Mejorar el entorno de diseño de diagramas El editor de diagramas admite más 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 número de ocurrencias en los listados, en caso de querer gestionar una cantidad elevada de infomación sería conveniente añadir funcionalidades básicas de paginación de resultados. Mejorar el sistema de comunicación entre usuarios Cualquier ampliación que suponga una mejora en los mecanismos disponibles para fomentar la comunicación entre usuarios, puede suponer un gran avance en la usabilidad del subsistema de colaboración síncrona. Editor de componentes La incorporación de un subsistema de gestión y edición de componentes permitiría a los usuarios personalizar las herramientas empleadas en el diseño de los diagramas. Teoría de grafos Existen múltiples posibilidades de ampliación en este campo, entre las que destaca la posibilidad de distribuir los elementos del diagrama en estructura jerárquica, orgánica, circular... También podrían añadirse utilidades específicas para el diseño de grafos y la aplicación de algoritmos cuyos resultados se reflejen en el propio grafo.

341


342


343


GLOSARIO Componente

Objeto con entidad propia que tiene una representación gráfica y un comportamiento específicos dentro del editor de diagramas.

Conexión

Línea de unión entre dos componentes que representa un relación lógica determinada entre ambos.

Controlador

Capa encargada de coordinar el flujo de la aplicación y gestionar las peticiones del servidor en el patrón MVC.

Diagrama

Estructura formada por un conjunto componentes o nodos y las conexiones existentes entre ellos.

Modelo

Capa responsable de la lógica de negocio dentro del patrón de diseño MVC.

Patrón

Un patrón de diseño es una solución a un problema de diseño no trivial que es efectiva y reutilizable.

Sistema

Conjunto de módulos o subsistemas que se integran para proporcionar una funcionalidad completa.

Transformación

Cambio en las propiedades de un componente o diagrama que modifica su aspecto o su colocación.

Vista

Esta capa se encarga de mostrar los resultados al usuario y recoger sus solicitudes en el patrón MVC.

344


345


BIBLIOGRAFÍA [Cantero] Pedro Cantero Espadas. “Tutorial sobre Domótica e Inmótica”

Universidad de Oviedo, Escuela Politécnica Superior de Informática de Gijón. PFC 1042012, Enero de 2005.

[Chico] Grupo CHICO. “DomoSim-TPC”

Universidad de Castilla - La Mancha, Escuela Superior de Informática. 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/

[Redacción] José A. Mari Mutt. “Manual de Redacción Científica”

Universidad de Puerto Rico, Departamento de Biología. http://caribjsci.org/epub1/index.htm

[Redondo] Miguel Ángel Redondo Duque. “Planificación Colaborativa del Diseño en Entornos de Simulación para el Aprendizaje a Distancia”

Universidad de Castilla - La Mancha, Escuela Superior de Informática. 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). “Guías Breves de Tecnologías 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 ALFABÉTICO Domótica · 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 Análisis · 6, 60, 103, 104, 105, 106, 338

B Bean · 183

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 Clasificación · 69 Código Fuente · 203 Conexión · 310, 324 Configuración · 179 Construcción · 122, 124 Controlador · 4, 35, 78, 104, 105, 106, 111, 114, 123, 132, 143 CSS · 29, 33, 38, 203, 312

D Desarrollo · 23, 36, 38, 69, 70 Descripción 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 Diseñar · 79, 80, 82, 88, 96, 104, 105, 108, 109, 111, 112, 117, 118, 124, 149, 150, 164, 165, 166, 172 Diseño · 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

E Eclipse · 34, 35, 42, 43 Edición · 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 Especificación · 22, 78, 79, 81, 83, 116, 117, 120 Estructura · 6, 22, 115 Estudio · 6, 22, 49, 50, 51, 52, 66, 68

F Formato · 71, 74, 75, 122, 127 Formulario · 327 Framework · 41, 69, 75, 347

G Gestión · 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 Identificación · 22, 61, 62, 63, 104 Implementación · 108, 109, 110, 111, 112, 113 Instalación · 323, 325 Integración · 38, 42, 122, 128 Interconexión · 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

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


" title="" >	">	"> "> 304 Universidad de Oviedo – E.U.I.T.I.O. Entorno Web 2.0 para el Diseño de Diagramas de Interconexión de Objetos CHECKED> "> CHECKED> "> CHECKED> "> CHECKED> "> CHECKED> "> CHECKED> "> "/>

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

Recommend Documents

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

:

key="form.diagram.description"/>: