ZoomTI++
Especificación de Requerimientos de Software
Versión 2.0
Tabla de Contenido
Tabla de Contenido 1. Introducción
1.1 Propósito 1.2 Alcance
1.3 Definiciones, acrónimos y abreviaciones 1.4 Referencias
1.5 Visión general del documento 2. Descripción general
2.1 En relación al framework 2.2 En relación al usuario
2.3 En relación a las condiciones del framework 3. Especificación de los requerimientos
3.1 Interfaces
3.1.1 Interfaces de usuario:
3.1.2 Interfaces de hardware:
3.1.3 Interfaces de software:
3.8 Licenciamiento
4. Información complementaria 4.1 Anexos
4.1.1 Anexo 1: Selección Plataforma
4.1.2 Anexo 2: Priorización Requerimientos
1. Introducción
Este documento describe los requerimientos de ZoomTI++, framework para visualizar diagramas de software mediante el uso de Zoomable User Interfaces y tecnología multi-touch, desarrollado para la Facultad de Ingeniería de la Pontificia Universidad Javeriana de Bogotá. Se adopta el estándar de la IEEE (Std. 830 - 1998)[1] como formato base para esta especificación.
1.1 Propósito
El propósito de este documento es describir completamente la funcionalidad referente a la visualización de diagramas de software en el framework ZoomTI++, dirigido a desarrolladores que busquen seguir con la creación de una herramienta CASE (Computer Aided Software Engineering). Está constituido por las definiciones formales de los requerimientos del sistema (funcionales y no funcionales), así como por los aspectos de diseño y demás necesarios para comprender el framework.
1.2 Alcance
ZoomTI++ será un framework de visualización de diagramas de software, cuya estructura sea basada en grafos; conjunto de nodos relacionados por aristas. Razón por la cual, los requerimientos funcionales y no funcionales mencionados en este documento son estrictamente relacionados con la visualización de estos diagramas.
1.3 Definiciones, acrónimos y abreviaciones
● Arista: Elemento de un grafo que permite visualizar la relación entre dos nodos, puede incluir direccionalidad y un mensaje explicativo.
● Diagrama: Representación visual de un modelo, permite observar un segmento del modelo de una manera visualmente clara para el receptor. [3]
● Herramienta CASE - Computer Aided Software Engineering: “These tools automate methods that can improve software development practice and help improve software product quality” [2] Es decir que son herramientas para mejorar la calidad del trabajo realizado por el usuario al automatizar varias de las actividades a realizar.
● IEEE - The Institute of Electrical and Electronics Engineers: Instituto a nivel mundial que se encarga, entre otras labores, de la definición de estándares para el desarrollo de documentos.
● Layout: Distribución y organización de los elementos de un diagrama en pantalla
● Modelo: Especificación abstracta de una entidad del mundo real, la cual representa propiedades relevantes de dicha entidad (abstracción), puede ser usado para cumplir un propósito específico.
[3]
● Multi-Touch: Tecnología en la que el usuario interactúa con el framework sin necesidad de usar
● Punto de ancla: Punto sobre el borde de la superficie de un nodo, usado para realizar la conexión entre el nodo con un nodo diferente a través de una arista.
● SRS (Software Requirements Specification): Presenta los resultados del análisis de requerimientos. Describe las expectativas del cliente hacia el producto, el perfil de usuario y los aspectos importantes previos al diseño de la aplicación. [12].
● Transformación Geométrica: Conjunto de matrices, las cuales especifican características de un elemento gráfico, permitiendo realizar modificaciones sobre sus propiedades (tamaño, rotación, nivel de brillo, etc).
● ZUI - Zoomable User Interface: Son interfaces que se encargan de organizar la información en el espacio y permiten variar la información mostrada de acuerdo al nivel de zoom realizado por el usuario. [4]
1.4 Referencias
1. I. C. S. S. Engineering and ..., IEEE Recommended Practice for Software Requirements Specifications. Institute of Electrical and Electronics …, 1998.
2. L. Zucconi, “Selecting a CASE Tool,” SIGSOFT Softw. Eng. Notes, vol. 14, no. 2, pp. 42–44, Apr. 1989.
3. T. Kühne, “What is a Model,” in IBFI, 2005.
4. Villamor, C., Willis, D., Wroblewski, L.: Touch Gesture Reference Guide. (2010, April 15).
LukeW Ideation + design: http://static.lukew.com/TouchGestureGuide.pdf [Último acceso: 13- Mayo-2015].
5. K. Hornbæk, B. B. Bederson, and C. Plaisant, “Navigation Patterns and Usability of Zoomable User Interfaces with and Without an Overview,” ACM Trans. Comput.-Hum. Interact., vol. 9, no. 4, pp. 362–389, Dec. 2002.
6. E. Montenegro, D. Rico, “Especificación de Requerimientos”, Pontificia Universidad Javeriana:
http://pegasus.javeriana.edu.co/~CIS1510AP01/documents/Especificaci%C3%B3n%20de%20Re querimientos.xlsx [Último acceso: 23-Mayo-2015].
7. “Qt - Developer Resources - documentation, guides, forums,” Qt: http://www.qt.io/developers/
[Último acceso: 16-Mayo-2015].
8. “gnu.org.”: https://www.gnu.org/licenses/lgpl.html. [Último acceso: 16-Mayo-2015].
9. E. Montenegro, D. Rico, “Selección Plataforma V2.0”, Pontificia Universidad Javeriana:
http://pegasus.javeriana.edu.co/~CIS1510AP01/documents/Selección%20Plataforma%20V2.0.pd f [Último acceso: 23-Mayo-2015].
10. E. Montenegro, D. Rico, “Selección Framework”, Pontificia Universidad Javeriana:
http://pegasus.javeriana.edu.co/~CIS1510AP01/documents/Selección%20Framework.xlsx [Último acceso: 23-Mayo-2015].
11. E. Montenegro, D. Rico, “Priorización de requerimientos V2.0”, Pontificia Universidad Javeriana:
http://pegasus.javeriana.edu.co/~CIS1510AP01/documents/Priorización%20de%20requerimiento s%20V2.0.pdf [Último acceso: 23-Mayo-2015].
12. SRS, Disponible en:
http://sce.uhcl.edu/helm/RationalUnifiedProcess/webtmpl/templates/req/rup_srs.htm [Último acceso: 26-Mayo-2015]
1.5 Visión general del documento
La presente especificación de requerimientos se encuentra organizada en 4 secciones, descritas a continuación:
1. Introducción: Sección dedicada a especificar las bases para la correcta lectura del resto de la especificación, incluye entre otros:
a. Descripción del framework.
b. Conceptos claves.
2. Descripción general: Sección que busca presentar las consideraciones tenidas en cuenta al momento de contemplar la realización de ZoomTI++, así como las consideraciones acerca de los requerimientos. Se describen los siguientes elementos:
a. Perspectiva y características del framework.
b. Perfil del usuario.
c. Restricciones y dependencias.
3. Especificación de los requerimientos: Sección que detalla cada uno de los requerimientos del software, de acuerdo a su clasificación (funcional o no funcional), permitiendo a un desarrollador o a un encargado de pruebas, llevar a cabo sus labores de una forma clara y correcta. De igual manera se especifican consideraciones importantes a tener en cuenta para la implementación de ZoomTI++. Entre otros se describe:
a. Requerimientos funcionales.
b. Requerimientos No funcionales.
c. Interfaces.
4. Información complementaria: Sección que busca facilitar la navegación y la comprensión del documento. Incluye información acerca de:
a. Anexos.
2. Descripción general
Los requerimientos que se presentan en la sección posterior son el resultado de consideraciones acerca del tipo de usuario, el tipo de acciones que dichos usuarios deberían poder realizar de una manera rápida y sencilla, así como de restricciones determinadas durante la determinación del estado del arte de ZoomTI++.
2.1 En relación al framework
Se espera que ZoomTI++ haga parte de una futura herramienta CASE, definiendo el componente de visualización de diagramas; la herramienta final sería capaz de no solo visualizar, sino también de crear y guardar diagramas, por mencionar un par de sus potenciales características. Por esta razón ZoomTI++
se encuentra directamente enfocado a dos campos: Concentrarse en visualización (desde la carga de la especificación visual del modelo, hasta verlo en la pantalla) y en permitir el escalamiento del sistema; al ser un componente de una posible herramienta CASE, se buscará que un posible usuario futuro pueda agregar funcionalidades (soporte de más primitivas, distintos layouts, formatos adicionales para la lectura de diagramas) sin que ZoomTI++ sea una limitante para esto, sino por lo contrario, ZoomTI++ permita hacer uso de sus bondades con estos nuevos elementos sin necesidad de modificar componentes ya existentes.
Para lograr dicho objetivo el framework debe ser capaz de:
● Leer la información del diagrama, el cual representa de forma visual al modelo.
● Almacenar los datos de dichos diagramas en primitivas que almacenen la totalidad de la información.
● Visualizar en pantalla a partir de dichas primitivas, el diagrama.
● Permitir el uso de gestos multi-touch para navegar en el diagrama; tap, double tap, drag, pinch, spread, press, entre otros. [4]
● Variar la información mostrada en pantalla según el nivel de zoom; zoom semántico.
● Organización de la información según layouts específicos
ZoomTI++ brindará una manera de resolver dichas necesidades, sin embargo permitirá que un desarrollador sea capaz de agregar sistemas de lecturas de diagramas, siempre que sigan la estructura definida por el framework. De igual manera se brindará la posibilidad de agregar primitivas, más layouts, etc. ZoomTI++ se encontrará orientado hacia su continuo crecimiento.
Una herramienta CASE completa debería ser capaz de administrar modelos, es decir debería tener mínimo las siguientes funcionalidades: crear modelos, editar modelos, eliminar modelos y visualizar modelos. Esta es una manera general de enunciar y agrupar lo que se esperaría de una herramienta de este tipo. Como ya se indicó, el objetivo de ZoomTI++ está dirigido hacia la visualización de diagramas de software (la cual es una forma de representar visualmente el modelo). Los demás elementos que hacen parte de la administración de modelos, quedan fuera del alcance de ZoomTI++.
2.2 En relación al usuario
Un desarrollador que busque hacer uso de ZoomTI++ para fines de tomarlo como componente de una herramienta CASE, debe estar en capacidad de realizar la integración con otros sectores de la
herramienta. Debe ser capaz de comprender las estructuras definidas del sistema y por lo tanto implementar nuevas funcionalidades que se incorporen de una manera funcional al framework.
Desde el punto de vista de un usuario de ZoomTI++, se debe estar en capacidad de comprender el formato de entrada ya definido y de esta manera ser capaz de crear diagramas estructuralmente correctos para ser visualizados en el framework.
2.3 En relación a las condiciones del framework
Pese a ser una aproximación nueva en muchos aspectos, es de igual manera cierto el hecho de que no es la primera vez que se realiza un framework con las características ya descritas, por esta razón se tendrán en cuenta algunas dependencias y algunas restricciones para la elaboración de ZoomTI++.
En el contexto universitario sobre el cual fue planteado originalmente ZoomTI++, ya existían aproximaciones similares realizadas en Java y en HTML5. Por esta razón se ve como una restricción que la elaboración de ZoomTI++ sea usando un lenguaje de programación diferente a estos, en este caso, C++ fue la elección apropiada, debido a que refuerza otra de las dependencias a considerar, el rendimiento del framework.
Otra restricción radica en el dispositivo con soporte multi-touch a disposición, los drivers del mismo presentan un funcionamiento impecable sobre sistemas operativos Windows, razón por la cual se espera que ZoomTI++ sea elaborado tomando esto en consideración.
3. Especificación de los requerimientos
Fueron identificados 39 requerimientos los cuales son considerados suficientes para hacer frente a las necesidades expuestas en la sección anterior. Dichos requerimientos fueron clasificados como funcionales y no funcionales.
La hoja de cálculo “Especificación de Requerimientos” [6] presenta una descripción de cada uno de los requerimientos, así como su identificador único y su categorización. A partir de dicha hoja de cálculo se procede a labores de priorización de requerimientos para determinar cuáles de los requerimientos encontrados serán implementados por ZoomTI++.
Las consideraciones de dicha priorización están consignadas en el documento “Priorización de requerimientos” (Ver Anexo 2) el cual explica los diferentes valores en los que cada requerimiento fue evaluado y recoge los resultados obtenidos por la priorización, cruzando esa información con las apreciaciones del cliente.
3.1 Interfaces
Las características únicas de un framework como ZoomTI++ permite identificar y clasificar las interfaces en tres categorías, las cuales se exponen a continuación:
3.1.1 Interfaces de usuario:
El framework requiere para hacer uso del 100% de sus funcionalidades el uso de una pantalla con reconocimiento de gestos multi-touch, esto debido al alto número de funcionalidades dedicadas (pinch zoom, drag and drop, etc) que solamente pueden ser accedidas a través de la interacción con una pantalla multi-touch, lo cual la convierte en la interfaz única de comunicación del usuario con ZoomTI++.
3.1.2 Interfaces de hardware:
ZoomTI++ soportará funcionamiento con cualquier pantalla que acepte gestos multi-touch y cuyos controladores sean reconocidos por el sistema operativo Windows. De igual manera se recomienda hacer uso de un equipo con una tarjeta de video con aceleración de hardware para mejorar la calidad visual del diagrama durante la ejecución.
ZoomTI++ se desarrollará y probará en un equipo cuyas especificaciones sean suficientes para aprobar las pruebas definidas en el documento “Selección Plataforma” (Ver Anexo 1), debido a que de esta manera se puede garantizar un rendimiento adecuado en coherencia con el requerimiento de rendimiento.
3.1.3 Interfaces de software:
En concordancia con los resultados del documento “Selección Plataforma” (Ver Anexo 1) QT [7] es el conjunto de librerías a utilizar, haciendo uso del framework QT Creator para un manejo organizado de la información del proyecto. En el mismo documento se presenta una descripción más detallada de QT, incluyendo factores positivos y negativos del mismo.
3.8 Licenciamiento
Al desarrollar ZoomTI++ con QT, que cuenta con licencia LGPL v3, como se especifica en el documento
“Selección Plataforma” (Ver Anexo 1). Este tipo de licencia (Lesser General Public License) es licencia de uso abierto, la cual es recomendable que sea utilizada también por cualquier tipo de aplicación que haga uso de dicha librería [8]. Por esta razón ZoomTI++ será un framework open source con licencia LGPL v3.
4. Información complementaria
4.1 Anexos
4.1.1 Anexo 1: Selección Plataforma
El documento “Selección Plataforma” [9] presenta una evaluación de las diferentes herramientas que fueron consideradas para ser la base sobre la cual se elaborará ZoomTI++: incluye descripción de las ventajas y desventajas de cada herramienta, calificación de la compatibilidad de la herramienta para la implementación de requerimientos y resultados de la ejecución de pruebas de rendimiento.
La hoja de cálculo “Selección Framework” [10] incluye: el estudio completo de las herramientas, con puntajes por sección y la plantilla de las pruebas de ejecución para dos computadores con especificaciones diferentes.
4.1.2 Anexo 2: Priorización Requerimientos
El documento “Priorización de requerimientos” [11] resume el proceso de priorización aplicado sobre cada uno de los requerimientos: Asignación de puntuación en diferentes categorías para los requerimientos lo cual permite clasificarlos en orden descendente, partiendo de los requerimientos cuyo impacto es mayor para el desarrollo del framework.
Acompañada a dicha priorización se realizaron reuniones con el cliente para evaluar los resultados obtenidos, llegando a la conclusión de que algunos requerimientos no tienen importancia significativa para este, siendo descartados de la liberación y asignados a un posible trabajo futuro sobre el framework.
La priorización se encuentra soportada a mayor detalle y organización en la hoja de cálculo
“Especificación de Requerimientos”, hoja que adicionalmente brinda un sistema de control de avance en los requerimientos para poder rastrear el porcentaje de implementación del framework como un todo [6].
