Módulo de anotaciones y colaboración para Archinotes web

(1)

UNIVERSIDAD DE LOS ANDES

Módulo de anotaciones y colaboración

Para Archinotes web

Reporte de proyecto de grado

Alejandro Casas Caro Mayo de 2014

(2)

ÍNDICE DE CONTENIDO

Índice de contenido ... 2

Índice de Figuras ... 3

Índice de Tablas ... 3

Resumen ... 4

1 Introducción ... 4

1.1 Motivación y descripción del problema ... 4

1.2 Diseño e implementación ... 6

1.3 Resultados obtenidos ... 6

1.4 Estructura del documento ... 6

1.5 Terminología y definiciones ... 6

1.6 Grupo de trabajo ... 7

2 Descripción general ... 7

2.1 Objetivos ... 7

2.2 Antecedentes ... 7

2.3 Identificación del problema y de su importancia ... 9

3 Diseño y especificaciones ... 11

3.1 Definición del problema ... 11

3.2 Especificaciones... 11

3.3 Restricciones ... 16

4 Desarrollo del diseño ... 18

4.1 Interfaz grafica ... 18

4.2 Sistema ... 21

5 Implementación ... 24

5.1 Implementación de Funcionalidades ... 24

5.2 Implementación Técnica ... 26

5.3 Resultados esperados y obtenidos ... 26

6 Validación ... 31

6.1 Métodos ... 31

6.2 Validación de resultados ... 31

7 Conclusiones... 32

(3)

7.2 Trabajo futuro ... 32

8 Referencias ... 32

ÍNDICE DE FIGURAS

Figura 0

Primera version Archinotes Android ... 7 Figura 1

Arbol de utilidad ... 13 Figura 2

Captura de pantalla de trabajo del trabajo de grado ... 18 Figura 3

Drop down menu ... 19 Figura 5

Captura de pantalla de trabajo del trabajo de grado ... 31

ÍNDICE DE TABLAS

Tabla 0

Integrantes del equipo ... 7 Tabla 1

Ejemplos tipos de anotaciones ... 11 Tabla 2

Requerimiento Funcional

Ver tipos de anotaciones ... 12 Tabla 3

Eliminar anotacion ... 12 Tabla 4

Registrar tipo de anotacion ... 12 Tabla 5

(4)

Anotar elementos ... 13 Tabla 6

Ver tipos de anotaciones en diagrama ... 13 Tabla 7

Ver anotaciones de tipo de anotacion en un diagrama ... 13 Tabla 8

Ver detalles de anotacion... 14 Tabla 9

Atributo de calidad

Usabilidad... 15 Tabla 10

Atributo de calidad

Flexibilidad ... 15 Tabla 11

Atributo de calidad

Modificabilidad ... 15 Tabla 12

Atributo de calidad

Confidencialidad ... 15 Tabla 13

Restriccion

Lengiaje de programacion... 17 Tabla 14

Restriccion

Frameworks... 17 Tabla 15

Restriccion

Base de datos ... 17 Tabla 16

Restriccion

Tiempo de desarrollo ... 18

RESUMEN

Esta tesis se desarrolla en el contexto de Archinotes, una herramienta que facilita el trabajo en equipo sobre proyectos de arquitectura de software. Específicamente, el propósito es facilitar la comunicación sobre detalles específicos en diagramas de proyectos. El resultado esperado es un módulo nuevo para su aplicación web.

1 INTRODUCCIÓN

1.1 Motivación y descripción del problema

El Sistema Archinotes, es un sistema de colaboración y definición de arquitecturas de software en equipo. Archinotes ha existido ya hace un tiempo en su primera versión desarrollada principalmente por Juan Sebastián Urrego la cual está desarrollada con un back end basado en JEE y un front end

(5)

en aplicación móvil desarrollado para la tecnología de Android. Archinotes en términos de funcionalidades fue definido para este proyecto y la aplicación móvil actual refleja todo este trabajo. El reto inicial en esta tesis fue, en un comienzo, el de crear el front-end web para la misma aplicación. Específicamente esta tesis propone ahora definir todo el sistema de comunicación a través de anotaciones sobre los diferentes diagramas de la arquitectura. El reto se incrementa cuando decidimos migrar el back-end también a una tecnología basada en Python, por lo cual el reto se convierte en realizar la totalidad de la aplicación.

El proyecto está dirigido a un público objetivo muy específico. Estamos hablando de los arquitectos de software que trabajan en colaboración y en general distribuidos geográficamente. Esto trae algunos retos interesantes. Primero la necesidad es muy específica y por esto el software debe estar hecho para la necesidad precisa de estos usuarios. El segundo reto es que realmente debe aportar algo ya sea facilitando procesos o simplemente ayudando con el orden para que los usuarios adopten la tecnología. Por último la idea del software es eliminar el uso de múltiples sistemas de colaboración al enfrentarse al desarrollo de una arquitectura de software, por lo que el sistema debe ser completo en su funcionalidad.

Estos retos me llamaron mucho la atención y me interese en hacer parte de este proyecto. Una de las ramas de la ingeniaría de sistemas que más atrae mi atención es la de la arquitectura de software y colaborar en el desarrollo de un software para arquitectos me pareció como una muy buena opción. El problema para esta tesis fue definido desde el inicio de una manera general. El problema a resolver es muy simple, un sistema para manejo de anotaciones sobre los diagramas de la arquitectura. Las anotaciones van sobre N elementos y los diferentes tipos de anotación que se pueden realizar se deben poder definir por los usuarios (arquitectos) que trabajaran en el proyecto.

El problema tiene algunas restricciones importantes. Las restricciones las podemos dividir en dos grupos, restricciones de negocio y restricciones de tecnología.

1.1.1 Restricciones de negocio y diseño

 Tipos de anotaciones:

o Los tipos de anotaciones que aplican para un proyecto en específico, debían ser configurables por los usuarios del sistema.

o Cada tipo de anotación debía tener un título, una corta descripción y N campos. Cada campo está definido por su nombre y su tipo (String, Imagen, Video etc)  Anotaciones:

o Las anotaciones se debían poder hacer a uno o más elementos.

o Al ver las anotaciones, esto no debe interrumpir con la visualización del diagrama.

1.1.2 Restricciones de tecnología

 General: En general el lenguaje de programación utilizado es Python.  Back end: El desarrollo del back end está basado en el framework CherryPy.  Base de datos: La base de datos es MongoDB.

(6)

o Servidor: El servidor del front end está basado en el framework Django.

o Cliente: El sistema de plantillas está hecho con Jade y el CSS está basado en Twitter Bootstrap.

1.2 Diseño e implementación

Esta tesis siguió un proceso de desarrollo Top-Down, esto quiere decir que primero se definieron las vistas y sus funcionalidades a nivel lógico. Luego se definieron los servicios necesarios para el funcionamiento correcto de estas vistas y por último se diseñaron los modelos de datos.

El diseño e implementación fueron fuertemente enmarcados por las tecnologías usadas. Para el back end, la base de datos cuenta con dos colecciones. Una para la definición de los tipos de anotación, y otra para las anotaciones en sí.

El back end, enmarcado por el framework CherryPy simplemente ofrecía unos web services RESTful los cuales insertan datos en la base de datos u obtienen datos y los retornan en formato JSON. Los servicios se describirán en detalle más adelante.

El front end Django enmarca totalmente el diseño del código con un sistema muy simple pero muy poderoso de MVC (Model View Controller) y el diseño de la interfaz gráfica fue definido en conjunto con los mentores del proyecto.

En términos más específicos, se diseñaron las colecciones de la base de datos como estructuras JSON (Java Script Object Notation) que básicamente es un formato en el que se definen estructuras de datos basadas en colecciones y arreglos. La base de datos MongoDB se define a partir de estructuras JSON.

Se definieron los servicios web que soportaría el back end siguiendo el standard CRUD. Se diseñó todo el MVC de Django para soportar la aplicación web siguiendo los estándares de Django y por último se diseñó e implemento la interfaz web del módulo en su totalidad.

1.3 Resultados obtenidos

Los resutados obtenidos fueron un nuevo modulo completo y funcional para la aplicación web de Archinotes. El modulo como ya fue mencionado anteriormente incluye todas las capas del software desde interfaz grafica hasta la base de datos.

Los resultados fueron satisfactorios y resuelven la necesidad y problema descrito en este documento con éxito. El modulo incluye: creación eliminación y visualización de tipos de anotaciones y creación y visualización manipulable de anotaciones sobre modelos.

1.4 Estructura del documento

El documento se divide en siete capítulos, El primer capítulo es introductorio. El segundo capítulo hace una descripción general del proyecto. El tercer capito describe todo el proceso de diseño y desarrollo del proyecto, encapsula las funcionalidades, casos de uso etc. El cuarto capítulo, modela el diseño en múltiples puntos de vista. Luego el quinto capítulo describe el proceso de implementación del software. Los capítulos seis y siete son de validaciones y conclusiones respectivamente.

(7)

 CRUD: “Create Read Update Delete” son las funcionalidades básicas de un sistema transaccional.

 MVP: “Minimum Viable Product” es el producto minimo con completa funcionalidad y diseño.

1.6 Grupo de trabajo

Integrantes Rol

Alejandro Casas Desarrollador del módulo de anotaciones y colaboración de la aplicación web de Archinotes.

Darío Ernesto Correal Asesor y líder del proyecto

Juan Sebastián Urrego Asesor asistente y desarrollador de la primera versión de Archinotes y aplicación móvil Android.

Andrés Felipe Arenas Desarrollador del módulo de información y documentación de la aplicación web de Archinotes

Ernesto Soto Desarrollador del módulo de diagramas y

puntos de vista de la aplicación web de Archinotes

Tabla 0: Integrantes del equipo

2 DESCRIPCIÓN GENERAL

2.1 Objetivos

El proyecto de grado como ya fue mencionado anteriormente es un módulo de la aplicación web de Archinotes, tanto back como front end del módulo. El propósito de este módulo es facilitar la comunicación y colaboración sobre puntos específicos de diagramas dentro de la arquitectura para equipos de arquitectos. El propósito es la capacidad de definir anotaciones para luego utilizar estas para anotar elementos de arquitectura.

2.1.1 Objetivos específicos

 Crear tipos de anotaciones: El objetivo es poder definir las anotaciones que van a ser usadas durante el desarrollo del proyecto.

 Crear anotaciones sobre elementos de diagramas: El objetivo es poder anotar los elementos de los diagramas con alguno de los tipos de anotaciones definidos previamente.

 Ver anotaciones sobre diagramas: Poder visualizar las anotaciones hechas previamente sobre los elementos de un diagrama. Este objetivo se debe realizar de una manera óptima en términos de usabilidad.

(8)

Como yo se ha mencionado anteriormente, este proyecto de grado se basa en un sistema ya existente llamado Archinotes. La primera versión de Archinotes fue un back end usando la tecnología JEE de Java la cual implementa entidades y beans. JEE significa Java Enterprise Edition. JEE es una plataforma robusta que ofrece Oracle para soluciones empresariales. Maneja capa de servicios a través de los beans y maneja una capa de persistencia a través de las entidades. El problema de JEE es que es confuso y requiere de varias líneas de código para realizar funciones relativamente sencillas. Por esta razón el back end de la primera versión de Archonotes es muy grande y requiere de mucho cuidado hacerle cualquier tipo de modificación.

El front end de Archinotes en su primera versión, fue una aplicación móvil para dispositivos Android y fue realizado por Juan Sebastian Urrego.

Figura 0: Primera version Archinotes Android

El sistema definio las funcionalidades del software y analizo todos los posibles casos de uso y demás. Por esta razón cuando inicio el proyecto de grado, la intensión fue hacer un cliente web nuevo que consumiera los servicios expuestos por el back end hecho en JEE. Luego con la intensión de mejorar la tecnología, se decidió migrar las funcionalidades del back end a un back end moderno y optimizado usando CherryPy y MongoDB.

La aplicación inicial, cubría las funcionalidades propuestas y operaba en tiempo real al realizar diagramas en conjunto con más de un usuario. Esto quiere decir que si un arquitecto estaba editando un diagrama, los demás arquitectos pueden ver en tiempo real lo que está haciendo.

Al inicio de este módulo, se pensó en implementar en tiempo real los servicios de anotaciones de manera similar a un chat. Se desarrolló el sistema y se implementó una prueba con éxito. Este valor agregado no está integrado a al producto final.

Algunos de los antecedentes o inspiraciones de Archinotes son grandes software de modelamiento. El ejemplo más popular es Enterprise Architect (EA). EA es un software muy completo para hacer diagramas de todo tipo, ingeniería inversa y muchísimas funcionalidades más para arquitectos de software. El diferenciador principal de Archinotes con EA es que Archinotes está pensado para trabajar en equipo.

(9)

2.3 Identificación del problema y de su importancia

Desde sus inicios el valor agregado de Archinotes era el de facilitar el trabajo en equipo sobre proyectos de arquitectura de software. Para los arquitectos de software, es realmente una necesidad y un reto muy grande poder trabajar en conjunto con otros arquitectos o colaboradores en un mismo proyecto. En general las técnicas que se usan para poder trabajar en equipo son basadas en múltiples herramientas lo cual hace muy tedioso el trabajo por la inexistencia de una herramienta especializada para este trabajo.

Esta entonces es la motivación para los inicios del proyecto. El desarrollo de la aplicación web, se divide entonces en tres grandes ramas distribuidas entre los tres colaboradores del desarrollo nombrados anteriormente. Esta tesis como ya fue mencionado se enfoca en el desarrollo del sistema de comunicación a través de anotaciones sobre elementos de arquitectura. Otro de los módulos es el de definición de todas las entradas desde el punto de vista del negocio y definición del sistema desde los atributos de calidad. El último módulo es la diagramación de todas las posibles vistas dentro de un proyecto de arquitectura. Las vistas deben incluir un sistema de ‘versionamiento’ y su funcionalidad fue definida como un simple “drag and drop”. Con estos tres módulos principales, se definió la totalidad del sistema.

El problema para los diferentes módulos se describe a continuación:

2.3.1 Módulo de negocio y entradas no diagramadas.

Este módulo define todas las entradas normales de un SAD (Software Architecture Document). Es muy importante definir los casos de uso del sistema, stakeholders y demás. Todo este módulo es de documentación y planeación inicial del sistema. Atributos de calidad juegan un papel importante así como las descripciones básicas generales del proyecto.

2.3.2 Módulo de diagramación

Este módulo define los diagramas del sistema, diagramas de clases, diagramas de despliegue y diagramas componente y conector. Estos son los tres tipos generales de diagramas pero el módulo también soporta diagramas de flujo y en general se presenta un amplio grupo de elementos que pueden ser utilizados para diagramar varios tipos de diagramas dependiendo de las necesidades de los usuarios.

2.3.3 Módulo de anotaciones

2.3.3.1 Identificación del problema

Este módulo es en el que se centra esta tesis. El módulo de anotaciones es totalmente necesario para facilitar el trabajo en equipo sobre un mismo proyecto. Básicamente un proyecto tiene varios diagramas asociados, sobre cada uno de estos diagramas se ven reflejadas decisiones de arquitectura o restricciones o simplemente situaciones en las cuales no es evidente porque fue definido de esta manera. El módulo de anotaciones permite anotar los elementos de manera totalmente dinámica para facilitar el entendimiento de los diagramas.

Para aclarar más aun la importancia de este módulo, es necesario hacer algunas analogías. Para un desarrollador de software que está trabajando en conjunto con un equipo de desarrollo, le es muy complicado entender el código de otro desarrollador en algún momento dado. Para este problema, se inventaron las anotaciones en código donde un desarrollador describe lo que hace en un método o función específica del código si lo ve necesario. Un ejemplo muy exitoso de esto es Javadoc para el lenguaje de programación Java de Oracle. Este sistema ahorra mucho tiempo en los desarrollos de software al facilitar la lectura del código.

(10)

Otra analogía un poco más apartada del mundo de la ingeniería de sistemas es la de las personas que trabajan escribiendo documentos, libros y demás. Estas personas van anotando diferentes secciones de los documentos al hacer revisiones sobre ellos. Word de Microsoft, una de las herramientas más utilizadas en el mundo como procesador de texto, ofrece un sistema muy completo de anotaciones, el cual es muy intuitivo y facilita mucho la corrección y revisión de documentos de texto.

Archinotes define un módulo de anotaciones sobre los diagramas para facilitar le lectura de los diagramas, así como permitir la discusión y colaboración sobre puntos específicos de diagramas de la arquitectura.

2.3.3.2 Beneficios para los usuarios

Este módulo tiene una amplia utilidad. El modulo es una manera de documentar los diagramas, esto abre las puertas a resolver varias necesidades cuando los usuarios se enfrentan al diseño de arquitectura de software.

Imaginemos la siguiente situación, un equipo de arquitectos toma la decisión en un diagrama de agregar un firewall para crear una zona militarizada y así proteger el servidor de back end del sistema en el que están trabajando. En el diagrama quedara el firewall y todas las conexiones entre el servidor de front end y el de back end pasaran por este firewall. Unos meses después van a implementar la arquitectura diseñada. Cuando van a contratar los servicios de los servidores no comprenden la necesidad de este firewall. En ese momento deciden ver los comentarios hechos sobre el diagrama y ven un comentario sobre los elementos del back end que describe como esta zona es militarizada y el filtro lo hace este firewall. En esta situación vemos como el modulo ayuda a recordar rápidamente una decisión de arquitectura que fue olvidada por el paso del tiempo.

Otra situación común, es en la que un equipo de arquitectos está trabajando sobre un proyecto. Uno de los arquitectos toma ciertas decisiones de arquitectura que generan puntos de sensibilidad innecesarios. La manera más óptima de comunicarse entre los arquitectos para resolver esta situación es de alguna manera tener un “chat” sobre estos puntos en específico. Este chat se resuelve con las anotaciones, se anota los elementos de tal manera que los demás colaboradores del proyecto entiendan la posición y se resuelva el problema.

Como se mencionó los beneficios para los usuarios son infinitos, tener la posibilidad de anotar los elementos de arquitectura de manera específica y detallada, abre las puertas para facilitar y agilizar el desarrollo de proyectos de arquitectura de software.

Algunos ejemplos de tipos de anotaciones que los usuarios podrían definir se presentan a continuación con el objetivo de ejemplificar el uso que se le puede dar al módulo.

Nombre Descripción Entradas

Opinión Úselo cuando tenga una opinión específica sobre uno o más

elementos.

Título, Palabras clave, Restricciones y

Razonamiento Clarificación Úselo cuando necesite explicar

mejor una decisión de arquitectura.

Título, Palabras clave, Descripción

General Use esta anotación cuando ninguna otra le funcione

Título, Descripción

Punto de sensibilidad Una propiedad de uno o más componentes que es crítica para

Descripción, Atributo de calidad

(11)

cumplir con algún atributo de calidad

Tradeoff Una decisión que limita al sistema de alguna forma para favorecer algún otro atributo de

calidad.

Descripción, Atributos de calidad

Táctica Una decisión de arquitectura que está basada en una táctica

ya existente e influye en el control de respuesta de un

atributo de calidad.

Nombre de la táctica, Atributo de calidad

Tabla 1: Ejemplos tipos de anotaciones

3 DISEÑO Y ESPECIFICACIONES

3.1 Definición del problema

Comunicarse de manera eficiente en elementos puntuales del diseño de un modelo de arquitectura de software.

3.2 Especificaciones

3.2.1 Stakeholders

 Líderes del proyecto: Los lideres del proyecto definen los casos de uso del sistema asi como los atributos de calidad. Estos stakeholders también guían el proyecto mediante retroalimentación.

 Equipo de desarrollo: Es el equipo encargado de documentar, diseñar e implementar la solución web para la aplicación e Archinotes.

 Arquitectos de software: Son los usuarios del sistema que definen las arquitecturas de software haciendo uso de la herramienta.

3.2.2 Requerimientos Funcionales

A continuación se presentan los requerimientos funcionales del módulo. Como convención, N significa que el número de entradas es definido por el usuario.

ID Requerimiento: 0 Nombre: Ver tipos de anotaciones

Entradas: N/A

Descripción: El sistema retorna todos los tipos de anotaciones.

Salidas: Se presenta una lista de todos los tipos de anotaciones y detalles. Excepciones: El sistema no registra ningún tipo de anotación.

(12)

Tabla 2: Requerimiento Funcional: Ver tipos de anotaciones

ID Requerimiento: 1 Nombre: Eliminar Anotación

Entradas: Id_tipo_anotación

Descripción: El sistema marca el tipo de anotación como eliminado

Salidas: Se notifica al usuario y se re-direcciona a la página donde se enlistan los tipos de anotaciones.

Excepciones: El tipo de anotación ya tiene anotaciones asociadas. No se puede eliminar.

Tabla 3: Requerimiento Funcional: Eliminar anotacion

ID Requerimiento: 2 Nombre: Registrar tipo de anotación

Entradas: Nombre, Descripcion, entrada_nombre _N, Input_type_N

Descripción: El sistema registra un nuevo tipo de anotación en la base de datos. Salidas: Se re-direcciona al usuario a la página de ver tipos de anotaciones, la

cual ahora incluye la anotación nueva. Excepciones: N/A

Tabla 4: Requerimiento Funcional: Registrar tipo de anotacion

ID Requerimiento: 3 Nombre: Anotar elementos

Entradas: Id_elemento_M, Anotación_type, Input_name_N, Input_value_N, Id_diagrama

Descripción: Se anotan los M elementos asociados con las entradas definidas en el tipo de anotación seleccionada. Input_name es el nombre de la entrada definida en el tipo de anotación e Input_value es el valor que el usuario le da en el momento de hacer la anotación.

Salidas: Se re-direcciona al mismo diagrama, con el sistema de anotaciones en ON para continuar el trabajo en el punto en el que quedó.

Excepciones: Ya existe una anotación asociada a ese diagrama con el mismo Input_value_0.

No hay ningún elemento seleccionado para realizar la anotación. Tabla 5: Requerimiento Funcional: Anotar elementos

(13)

Entradas: Id_diagrama

Descripción: El sistema presenta los tipos de anotaciones relevantes para el diagrama. Solo presenta los nombres de cada tipo de anotacion. Los tipos de anotaciones relevantes son los que tienen asociadas una o más anotaciones de los elementos del diagrama.

Salidas: Se presentan gráficamente en una lista.

Excepciones: No hay ningún tipo de anotación asociado, en dado caso la lista es vacía. Tabla 6: Requerimiento Funcional: Ver tipos de anotaciones en diagrama

ID Requerimiento: 5 Nombre: Ver anotaciones de tipo de anotación en un diagrama

Entradas: Id_diagrama, Id_tipo_anotacion

Descripción: El sistema muestra las anotaciones relacionadas a uno o más tipos de anotación en un diagrama. Las muestra en una lista de manera seleccionable. Lo que muestra de cada anotación es el Input_value_0 es decir el valor del primer input del tipo de anotación.

Salidas: Se carga la lista de manera dinámica Excepciones: N/A

Tabla 7: Requerimiento Funcional: Ver anotaciones de tipo de anotacion en un diagrama

ID Requerimiento: 6 Nombre: Ver detalles de anotacion

Entradas: Id_anotación

Descripción: El sistema resalta los componentes del diagrama asociados a la anotación seleccionada. Así mismo carga la lista de todos los inputs y sus valores para que el usuario pueda ver los detalles de la anotación que fue realizada sobre los elementos de arquitectura del diagrama. Salidas: El usuario puede ver la totalidad de la anotación.

Excepciones: N/A

(14)

3.2.3 Árbol de utilidad

Figura 1: Arbol de utilidad

La siguiente tabla se representa la priorización de la siguente manera: <impacto para stakeholders>, <impacto para la arquitectura>, donde cada uno de estos puede estar representado por las letras ‘A’ (alto), ‘M’ (medio) y ‘B’ (bajo).

ID Atributo de calidad: 0 Nombre: Usabilidad

Descripción: El sistema debe tener en cuenta de manera prioritaria la usabilidad. El modulo no debe interferir de ninguna manera con el desarrollo del proyecto. Debe facilitar el uso de la herramienta y agilizar el proceso. Por estas razones la usabilidad del módulo es de total importancia.

Prioridad A,B

Medida y Rango Porcentaje de usuarios que interactúan por primera vez con el modulo (crear una anotación o leen anotaciones) y lo siguen haciendo de manera intuitiva. Rango {0-100%}

Tabla 9: Atributo de calidad: Usabilidad

(15)

Descripción: El sistema es flexible en el uso que le da el usuario. Este requerimiento no funcional es muy importante para el modulo dado que los tipos de anotaciones pueden ser definidos por el usuario. Esto hace que la flexibilidad del sistema en las anotaciones sea absoluta.

Prioridad A,A

Medida y Rango Promedio de tipos de anotaciones diferentes definidas para un proyecto. Rango {0-20}

Tabla 10: Atributo de calidad: Flexibilidad

ID Atributo de calidad: 2 Nombre: Modificabilidad

Descripción: El sistema es distribuido y por lo tanto desacoplado, lo cual favorece mucho su modificabilidad.

Prioridad B,M

Medida y Rango Cantidad de capas independientes del sistema. Rango {0-5} Tabla 11: Atributo de calidad: Modificabilidad

ID Atributo de calidad: 3 Nombre: Confidencialidad

Descripción: El sistema de anotaciones puede tratar con anotaciones de carácter confidencial para los usuarios del sistema. Por esta razón el modulo debe garantizar la confidencialidad de los datos registrados en las anotaciones.

Prioridad M,M

Medida y Rango N/A

Tabla 12: Atributo de calidad: Confidencialidad

3.2.4 Casos de uso

A continuación se presentan los casos de uso del módulo.

Familia: Casos de Uso

(16)

Convenciones:

Uso

Caso de Uso

Actor

Titulo:

Casos de uso del modulo

Nivel: 0

Nomenclatura: UML

3.3 Restricciones

ID Restricción: RT0

Tipo:

Tecnología ( X )

Negocio ( )

Nombre: Lenguaje de programación

Descripción: El lenguaje utilizado debe ser Python Establecida por: Líder de proyecto

(17)

Alternativas: N/A

Observaciones: Es un lenguaje nuevo para los desarrolladores. Tabla 13: Restriccion: Lengiaje de programacion

Tipo:

Tecnología ( X )

Negocio ( )

Nombre: Frameworks

Descripción: Los frameworks usados deben ser Django y CherryPy Establecida por: Equipo del proyecto

Observaciones: Son frameworks nuevos para los desarrolladores. Tabla 14: Restriccion: Frameworks

Tipo:

Tecnología ( X )

Negocio ( )

Nombre: Base de datos

Descripción: La base de datos usada debe ser MongoDB Establecida por: Equipo del proyecto

Observaciones: Es una base de datos diferente y nueva para los desarrolladores. Tabla 15: Restriccion: Base de datos

Tipo:

Tecnología ( )

Negocio ( X )

Nombre: Tiempo de desarrollo

Descripción: El tiempo de desarrollo del proyecto es de alrededor de 3 meses. Establecida por: Líder de proyecto

(18)

4 DESARROLLO DEL DISEÑO

4.1 Interfaz grafica

4.1.1 Recolección de Información

Las fuentes de información para construir la interfaz gráfica del proyecto fueron varias. Principalmente la documentación oficial de Bootstrap. Pero segundo, algunos proyectos realizados anteriormente por mi parte, SportsAround, Adqui y Leavapp son tan solo algunos de ellos. Estos proyectos resuelven retos gráficos en muchos casos similares. Por esta razón el código de dichos proyectos fue tomado como ejemplo para realizar las funcionalidades similares en el módulo de la tesis.

4.1.2 Proceso de construcción

La primera fase del proyecto fue la del diseño de la interfaz gráfica del módulo. Básicamente el módulo se divide en dos partes. La primera parte es de definición y manejo de tipos de anotaciones. La segunda parte es la de definición y manejo de anotaciones en sí. Cada una de estas partes se divide en dos sub partes a su vez. Una es la de creación, que gráficamente se ve reflejada en un formulario. La otra es la de visualización, que cambia radicalmente entre los tipos de anotaciones y las anotaciones.

La interfaz gráfica está basada en los estilos propuestos por Twitter Bootstrap. El diseño de la interfaz fue planeado en conjunto con el equipo de desarrollo. Poco a poco algunos motivadores fueron definiendo la interfaz.

Al principio se habló de la interfaz para los tipos de anotaciones. Inicialmente se habló de tener los tipos de anotaciones pre-definidos, pero luego que se cambió a que fueran definidos por el usuario, la primera propuesta hecha se basó en el funcionamiento de un proyecto previo realizado por mi personalmente llamado SportsAround. La interfaz incluía dinámicamente el número de inputs que el usuario encontrara pertinentes de manera dinámica. La visualización era detallada en todos los casos y se presentaba en una lista Figura 2.

Luego de la retroalimentación del equipo, se definieron algunos cambios mínimos y se introdujo una página principal previa donde se enlistaban todos los tipos de anotaciones. Este fue el diseño final para el alcance del proyecto en la parte de los tipos de anotaciones.

(19)

Figura 2: Captura de pantalla de trabajo del trabajo de grado

Para la parte de las anotaciones, Inicialmente se habló de tipos e anotaciones fijos como podemos ver en la Figura 3. El diseño tenía que estar en conjunto con el diseño del módulo de diagramas. Por esta razón este diseño tomo más tiempo para tener claridad sobre cómo iba a quedar. Inicialmente se pensó en presentar los elementos con un pequeño drop-down menu con la lista de tipos de anotaciones que tenían una o más anotaciones asociadas a este elemento. El diseño incluía que al hacer ‘click’ en uno de estos tipos de anotaciones, saliera la lista con los títulos de las anotaciones y al hacer click en alguno de ellos de desplegara un Modal de bootstrap que básicamente es una ventana que se sobrepone en frente a todo. El modal contendría entonces los detalles de la anotación y en el fondo se resaltarían los otros elementos que estuvieran asociados a esa misma anotación.

(20)

Figura 3: Captura de pantalla de trabajo del trabajo de grado

El diseño no tuvo mucho éxito dado que tapaba visualmente el diagrama. Esto no tenía mucho sentido pues la idea de todo el módulo de anotaciones es ser lo menos atravesado posible para facilitar el uso de la herramienta y no complicarlo. Sin el drop down menú se dejó finalmente como podemos observar en la figura 4. Por lo tanto se definió en conjunto con todo el equipo la propuesta de ver las listas en un menú flotante al lado derecho de la ventana del browser. Este menú contendría el botón para agregar una nueva anotación y los acordeones donde se desplegarían los datos nombrados anteriormente. Los acordeones se dividirían en tres grupos, tipos de anotaciones, anotaciones y detalles de anotación. Como se puede intuir, esto se comportaría como un árbol donde las entradas iniciales serían los tipos de anotación y de una anotación se desplegarían los detalles de la misma.

(21)

La solución pareció resolver el problema desde el punto de vista del diseño y así fue el resultado final. Se habló de una segunda iteración donde el menú inicial contuviera los tipos de anotación relacionados al elemento como inicialmente se había pensado y que cuando se hiciera ‘click’ sobre alguno, se desplegaran las anotaciones relacionadas a ese elemento en el acordeón de anotaciones ya existente. Sin embargo esta parte se dejó como opcional ya que se salía del alcance del proyecto desde el punto de vista gráfico y por esto no hace parte del resultado final del proyecto.

4.2 Sistema

4.2.1 Punto de vista de despliegue

Familia: Despliegue Convenciones:

Dispositivo

Titulo:

Modelo de despliegue

Nivel: 0

Nomenclatura: UML

(22)

En este punto de vista podemos observar la distribución del sistema. Como se puede ver hay cuatro máquinas que interactúan entre ellas, la máquina del cliente, el servidor web, el servidor de back end y la máquina que contiene la base de datos. Lo interesante en esta arquitectura es que esta desacoplada y maneja seguridad. Es evidente que tiene una zona segura que contiene los datos y una insegura que simplemente es el servidor web.

4.2.2 Punto de vista de componente y conector

Familia:

Componente & Conector Convenciones:

Componente

(23)

Titulo:

Modelo de componente & conector técnico.

Nivel: 0

Nomenclatura: UML

En este punto de vista podemos observar como la funcionalidad del sistema es bastante lineal a nivel técnico. Es un modelo cinco capas. La primera capa siendo la de las vistas, la segunda capa es la del enrutamiento web del servidor, la tercera capa es los controladores de la aplicación web, la cuarta capa son los servicios expuestos por el back end y por último la capa de persistencia. Cinco capas hacen de la aplicación una aplicación desacoplada y segura.

Familia:

Componente & Conector Convenciones:

Componente

Titulo:

Modelo de componente & conector lógico.

Nivel: 0

Nomenclatura: UML

(24)

En este punto de vista lógico, podemos ver como el modulo se divide en dos ramas separadas. Una rama maneja todo lo relacionado con los tipos de anotaciones y la otra maneja lo relacionado con las anotaciones. Vale la pena aclarar que las anotaciones dependen de los tipos de anotaciones definidor previamente.

4.2.3 Diagrama de clases (datos)

Familia: Clases

Convenciones:

Modelo

Titulo:

Modelo de datos

Nivel: 0

Nomenclatura: UML

Este diagrama de clases muestra la información que contiene la base de datos. Como nos podemos dar cuenta, un tipo de anotación tiene N entradas definidas por el usuario. Una anotación está asociada a un tipo de anotación y tiene N datos de anotación los cuales a su vez están asociados a una entrada cada uno.

5 IMPLEMENTACIÓN

La solución implementada, se puede ver desde dos puntos de vista, desde la funcionalidad y desde la parte técnica.

Todas las funcionalidades se manejan de manera muy similar en la parte técnica, por lo tanto vamos a discutir primero las funcionalidades implementadas.

5.1 Implementación de Funcionalidades

Como fue comentado en la descripción del proceso de desarrollo del diseño, el desarrollo de funcionalidades también se dividió en dos grandes secciones. La sección de tipos de anotaciones y la sección de las anotaciones en sí. La implementación para estas dos secciones tuvo retos y complicaciones.

(25)

El proceso comenzó con la sección de tipos de anotaciones. Esta sección pareció simple en un inicio pues básicamente se definían los tipos de anotaciones y se guardaban en la base de datos. En conclusión era un formulario básico. La segunda funcionalidad definida es poderlos ver y eliminarlos lo cual hace parte de un CRUD básico. El reto apareció cuando nos encontramos con la necesidad de definir N campos para el tipo de anotación. Cada campo está compuesto por un nombre (ej, Palabras Clave) y un tipo (ej, String). La solución a este problema está basada en la base de datos MongoDB. Esta es una base de datos compuesta por colecciones, cada colección es equivalente a una tabla en una base de datos relacional como MySQL. Lo interesante de estas colecciones para el problema al que nos enfrentábamos, es que una misma colección puede contener ‘tuplas’ con diferente número de campos y diferentes nombres. Esto hace que el manejo y orden de esta colección quede en manos del programador en tiempo de ejecución. Para el problema fue una solución perfecta, simplemente insertábamos ‘tuplas’ con N columnas donde el patrón de las columnas era Nombre_N, Tipo_N, Nombre_N+1, Tipo_N+1 etc.

Para poder ver los tipos de comentarios definidos en la base de datos, el problema entonces se redujo a una interpretación de un JSON a un objeto JS, al recorrer los atributos de dicho elemento N veces y desplegarlos gráficamente. Acá el reto no fue tan simple, pues desconocíamos de ese N totalmente variable entre tipos de anotaciones. La respuesta fue ir preguntando uno por uno y si el atributo tenía algún contenido, existía y se agregaba gráficamente.

Completado entonces el reto de guardar diferentes tipos de anotaciones con una cantidad de columnas variables en la base de datos. Así mismo superado el reto de desplegarlos y eliminarlos.

5.1.2 Anotaciones

Entramos en la descripción de la sección dos de la tesis, anotaciones. Esta sección a su vez de dividió en dos partes principales: crear una anotación y visualizar anotaciones previas.

5.1.2.1 Crear Anotación

Para poder crear una anotación, dos cosas tenían que suceder, la primera era necesario que el usuario pudiera definir qué elementos estarían asociados a la anotación antes de realizarla, lo segundo que tenía que suceder es que el sistema debía cargar los tipos de anotaciones disponibles para que el usuario pudiera definir cómo anotar dichos elementos.

Para seleccionar los elementos se definieron dos posibles estados en un diagrama. El estado normal donde se puede editar el diagrama y el estado donde se leen y realizan anotaciones. Para cambiar de estado se hace a nivel del cliente (JS) y un switch gráfico. Una vez se encuentra en estado de colaboración ON, se pueden seleccionar los elementos que se van a anotar.

Luego el sistema debía cargar los tipos de anotaciones- Este reto trataba de generar un formulario dinámicamente con los datos que venían de la base de datos.

5.1.2.2 Ver Anotaciones

Para ver las anotaciones de un diagrama, tres pasos tenían que suceder, primero cargar los tipos de anotaciones, segundo al seleccionar uno o más tipos de anotaciones, desplegar las anotaciones relacionadas a esos tipos de anotación, tercero al seleccionar una anotación, se debían desplegar los detalles de esta anotación y resaltar los elementos asociados a la anotación.

Cargar los tipos de anotaciones fue bastante sencillo ya que se había hecho algo muy similar en la sección de los tipos de anotaciones anteriormente.

Con toda la información cargada en JS, el proceso de los pasos dos y tres fue un simple manejo de los datos. La solución como se intuye, fue cargar dos variables JSON al momento de abrir un

(26)

diagrama. La primera variable JSON contiene todos los tipos de anotaciones asociados al diagrama. La segunda variable contiene todas las anotaciones asociadas al diagrama. Con simples funciones apoyadas en el framework de JQuery, se solucionó toda la funcionalidad de lectura de anotaciones en un diagrama.

5.2 Implementación Técnica

La implementación técnica y no lógica se dividió en tres capas, Back end, servidor web y cliente. La capa del back end realizada con un framework llamado CherryPy. Es un framework que reduce la cantidad de código sustancialmente. No solamente esto sino también facilita muchísimo la programación de servicios web tipo RESTful. Todo el código del back end del módulo contiene tan solo unas cien líneas de código aproximadamente. El back end ofrece servicios muy básicos de CRUD para los dos modelos de la aplicación que son los tipos de anotaciones, y anotaciones. A continuación se va a detallar el proceso de desarrollo del servidor web basado en el famoso framework Django. Django es un framework muy simple que sigue el patrón MVC para Python. Dado que el back end se ubicaría en otro servidor de manera desacoplada con CherryPy, en este proyecto no se hace uso de los modelos de Django. Es decir que solo utilizamos el VC (views y controllers). Los controladores están definidos en un archivo llamado views.py. Son funciones básicas enrutadas por el archivo urls.py que es el encargado de hacer el enrutamiento. Finalmente las vistas están desarrolladas usando Jade que aunque no hace parte de Django, es una manera simplificada de escribir en HTML. Desde el punto de vista del servidor web, estas vistas pueden controlar variables y funcionalidades como condicionales y bucles para preparar el archivo HTML que se le enviara al cliente con los datos correctos.

Las funciones definidas en views.py de Django son muy similares a las del back end, lo que quiere decir que básicamente el servidor web actúa como proxy con el objetivo de tener el back end en una zona militarizada y el servidor web desmilitarizado.

Finalmente se detallará el proceso de desarrollo del cliente. El cliente está basado en JQuery, y contiene estructuras de datos para facilitar el manejo de variables en caliente. Aproximadamente el 80% del módulo está desarrollado en javascript y tan solo consume unos servicios básicos de los controladores del servidor web. El desarrollo se hizo usando el debuger de Chrome para ver el DOM, las variables JS y los llamados AJAX.

5.3 Resultados esperados y obtenidos

Los resultados esperados eran los suficientes para un MVP (Minimum Viable Product). El sistema debía funcionar exitosamente dentro del marco de las restricciones de negocio y tecnología mencionadas anteriormente. El proyecto siguió los estándares de todas las tecnologías empleadas que no dejan mucho margen al error. Con esto quiero decir que el sistema si funciona, cierra muchas posibilidades de bugs, huecos de seguridad y demás.

Los resultados obtenidos fueron los de un módulo totalmente funcional, respetando las reglas de diseño e implementación propuestas para el proyecto. El sistema está totalmente estable y se puede confiar en su implementación.

Para detallar un poco más en los resultados obtenidos, a continuación se muestran unas imágenes del sistema final. Vale la pena aclarar que en términos de diseño hubo unos retoques mínimos posteriores a la entrega final del proyecto. La funcionalidad no cambió en nada, los esquemas de presentación tampoco. Tan solo unos detalles que mejoran estéticamente el módulo.

(27)

En la figura 5 podemos ver el despliegue de todos los tipos de anotaciones actualmente. En esta misma vista hay un link para agregar un nuevo tipo de anotación así como ver los detalles de algún tipo de anotación.

Figura 5: Captura de pantalla de trabajo del trabajo de grado Fuente: http://157.253.238.150/collaboration/settings/

En la figura 6 podemos ver los detalles de los tipos de anotaciones. Podemos seleccionar los tipos de anotaciones y ver sus detalles. También esta la posibilidad de crear un tipo de anotación nuevo o eliminar uno ya existente.

(28)

Figura 6: Captura de pantalla de trabajo del trabajo de grado Fuente: http://157.253.238.150/collaboration/settings/?q=Tradeoff

La figura 7 es la última vista de la sección de tipos de anotación. Esta vista permite agregar entradas dinámicamente a la anotación y agregar la anotación al sistema.

(29)

Figura 7: Captura de pantalla de trabajo del trabajo de grado Fuente: http://157.253.238.150/collaboration/create_annotation/

A continuación se presentan las vistas de la sección de anotaciones. Recordemos que esto se hace desde la vista de diagramas.

En la figura 8 podemos observar un diagrama con el sistema de colaboración ON. Podemos ver los elementos del diagrama que tienen anotaciones y en la parte de arriba a la derecha una flecha que saca el menú de anotaciones como se observa en la figura 9.

Figura 8: Captura de pantalla de trabajo del trabajo de grado Fuente:

(30)

En el menu que se muestra en la Figura 9, podemos observar la posibilidad de crear una nueva anotacion y de ver anotaciones existentes actualmente. La visualización de anotaciones actuales se divide en los tres grupos descritos anteriormente en la implementacion. Como “filtro”, la lista de los tipos de anotaciones relevantes para el diagrama. En “anotaciones” se muestra la lista de anotaciones relacionadas a los tipos de anotación seleccionados en el filtro y por último en la “anotación seleccionada” podemos ver los detalles de la anotación.

http://157.253.238.150/editor/UDC/canvas/?viewpoint=Context&diagram_name=context&diagram_version=6&mode=move

En la figura 10 podemos ver una anotación seleccionada. Se observan los detalles y cómo los elementos del diagrama relacionados están resaltados.

En esta figura 11 podemos ver cómo hay elementos seleccionados, con un borde naranja para una anotación. Podemos ver cómo se despliegan todos los tipos de anotaciones disponibles para el proyecto y se cargan dinámicamente los formularios para crear una nueva anotación.

(31)

6 VALIDACIÓN

6.1 Métodos

El sistema de pruebas usado en el proyecto fue pruebas manuales. Dado que el alcance del proyecto fue el de desarrollo completo del módulo, se salía del alcance del proyecto realizar un módulo de pruebas unitarias o similar.

La manera de hacer debugs y pruebas de funcionalidades fue con banderas. Básicamente trata de imprimir ya sea en consola o en pantalla los datos que actualmente contiene una variable para conocer su estado en un dado momento de la ejecución. De esta manera se construyó el código del sistema.

Dentro del sistema de banderas se utilizaron dos estrategias. Desde el punto de vista del front end, se imprimió en consola o se le dio uso a la función alert() de javascript. Para hacer el debug del back end y la base de datos, se imprimió en pantalla los resultados obtenidos de los servicios RESTful y se manejó la consola de MongoDB la cual es altamente poderosa y da la posibilidad de manipular la base de datos y realizar pruebas exhaustivas.

6.2 Validación de resultados

La validación de los resultados se hizo por parte de los líderes del proyecto y asesor de tesis Darío Correal. La validación fue en caliente simulando un usuario real del sistema. Nuevamente dado que el alcance del proyecto era un MVP, la validación fue exitosa al realizar todas las pruebas de funcionalidad y el sistema responder como lo esperado. Quedaría faltando un sesión de pruebas exhaustivas sobre la aplicación para eliminar todos los bugs o escenarios no considerados en el sistema.

LA validación se hizo simulando un proyecto real realizado para la Universidad de Cartagena. El proyecto es un software para el proceso de consulta interna de votaciones. La propuesta enviada

(32)

por Novcat S.A.S, fue tomada como ejemplo para probar el sistema. Se llenaron todos los datos tal cual se hubiera hecho si la arquitectura hubiese sido diseñada con Archinotes web. Se crearon siete diagramas y se anotaron los diagramas con las anotaciones pertinentes definidas para el proyecto. El sistema respondió como se esperaba y se dio por concluido el proyecto de grado. Luego de esta sesión, el proyecto fue presentado en una conferencia llamada Saturn en Estados Unidos de America, en el año 2014.

7 CONCLUSIONES

7.1 Discusión

Los resultados del proyecto fueron satisfactorios, se completó la totalidad de los requerimientos funcionales que se estipularon dentro del alcance del proyecto. Aprendí a trabajar en equipo en un proyecto de desarrollo de software de tamaño mediano. Asimismo aprendí a trabajar con herramientas de colaboración como GIT y a usar frameworks sencillos y poderosos, como Django y CherryPy. Aún quedaría pendiente verificar casos específicos donde se puedan presentar bugs en el sistema.

Otra conclusión es que por limitaciones de tiempo, el código no es tan ordenado como lo esperado, principalmente en el código JS ya que Django y CherryPy estructuran el código Python por defecto. Por último, el módulo trabaja de manera independiente del módulo general y de negocio, por lo que no se es posible definir, por ahora, los tipos de entradas de tipos de anotaciones relacionadas con otras instancias del proyecto.

7.2 Trabajo futuro

En un futuro se puede conectar el módulo de anotaciones con el general y de negocio. Actualmente el módulo de anotaciones solamente es funcional para elementos gráficos dentro de diagramas de la arquitectura. Sería ideal si se pudiera anotar cualquier cosa en toda la arquitectura, ya sean Atributos de calidad, Stakeholders, Diagramas completos, Elementos o cualquier cosa que sea definida por los usuarios del sistema que pueda necesitar de una anotación.

Otro campo sobre el cual se puede expandir es el de minería de datos. Todas estas anotaciones registradas en las bases de datos, se pueden consultar de diferentes formas para crear dimensiones diferentes y así poder analizar los datos desde otra perspectiva. Un ejemplo de esto podría ser consultar todas las anotaciones sobre puntos de sensibilidad. Esto con el objetivo de identificar puntos de sensibilidad innecesarios y optimizar la arquitectura desarrollada. Como este ejemplo puede haber infinitas formas de consultar estas anotaciones para sacarles el mayor provecho posible.

Por último, dado el producto es un MVP, se podría trabajar en documentación y limpieza del código actual. Esto con el objetivo de mejorar la modificabilidad que es uno de los atributos de calidad prioritario para el proyecto.

8 REFERENCIAS

@fat, @. a. (s.f.). Get Boot Strap. Recuperado el 25 de Marzo de 2014, de http://getbootstrap.com/

(33)

Foundation, D. S. (2002 -2014). django project. Recuperado el 12 de Marzo de 2014, de https://www.djangoproject.com/

Foundation, P. S. (2001 - 2014). Python. Recuperado el 30 de Marzo de 2014, de https://www.python.org/doc/

Jade node template engine. (s.f.). Recuperado el 26 de Marzo de 2014, de http://jade-lang.com/

MongoDB, I. (2013). Mongodb. Recuperado el 27 de Marzo de 2014, de http://www.mongodb.org/

Murillo, R. (2001 - 2014). Cherry Py. Recuperado el 25 de Marzo de 2014, de http://www.cherrypy.org/