trabajo de grado herramienta para el análisis de

1

Trabajo de Grado

Herramienta para el análisis de arquitectura de software utilizando una base de datos orientada a

grafos.

Juan David Riascos, Pablo Andrés Echeverry [email protected], [email protected]

Director Fernando Barraza

FACULTAD DE INGENIERÍA PROGRAMA INGENIERÍA DE SISTEMAS

SANTIAGO DE CALI 14 de septiembre de 2017

2

RESUMEN El presente documento tiene como objetivo describir un proyecto para el desarrollo de una herramienta de código libre que apoye a los arquitectos de software en sus labores de análisis. Comúnmente dichas labores requieren el poder recuperar una arquitectura de un repositorio de código fuente u objetos para posteriormente visualizarlos en una forma que represente la estructura del software. El usuario de la herramienta, dicho de otra forma, el arquitecto, podrá hacer uso de la herramienta en etapas tempranas y tardías del desarrollo de forma que pueda visualizar la arquitectura del software y establecer algunas de las propiedades inherentes a la misma. Estudios previos muestran la necesidad de una herramienta de acceso libre para la comunidad de arquitectos de software y de igual forma una baja oferta de las mismas. La herramienta se basa en la recuperación de los componentes y relaciones entre componentes de la arquitectura de un software desde una base de datos relacional para almacenarlos en una base de datos orientada a grafos y posteriormente permitir su visualización de una manera gráfica con una red dígrafo compuesta por nodos y arcos. El grafo permitirá realizar diversos tipos de análisis sobre la arquitectura de un software, ayudando así en la toma de decisiones sobre el desarrollo y las ventajas o desventajas que se pueden encontrar en el diseño de la arquitectura. Sobre esta base se implementarán una serie de casos de uso descritos más adelante los cuales están orientados en apoyar las labores del arquitecto de software.

3

AGRADECIMIENTOS Queremos agradecer a nuestro director de tesis Fernando Barraza Alvarado por la guía y el apoyo brindado a través de todo el proceso de ingeniería que se llevó acabo para la realización de este proyecto. También queremos agradecer al docente Iván Mauricio Cabezas Troyano por aconsejarnos y guiarnos en el proyecto de grado. Agradecemos también a todos los profesores que nos brindaron su conocimiento para poder culminar nuestra carrera y a la ingeniera Beatriz Eugenia Grass por estar siempre presente para nosotros. Queremos agradecerles a Dios y a nuestras familias por siempre estar presente para nosotros y apoyarnos en todo durante nuestra carrera. Mil gracias.

4

GLOSARIO

Componentes: es aquello que forma parte de la composición de un todo. Se trata de elementos que, a través de algún tipo de asociación o contigüidad, dan lugar a un conjunto uniforme. (https://definicion.de/componentes/, 2010)

Nodos: De forma muy general, un nodo es un punto de intersección o unión de varios elementos que confluyen en el mismo lugar. (https://www.ecured.cu/Nodo, 2010)

Grafo: Abstracción matemática definida por la relación G=<V, A> donde V es el conjunto de nodos o vértices y A es el conjunto de pares que definen los arcos o aristas que unen pares de vértices o lazos si unen a un vértice consigo mismo. (https://www.ecured.cu/Grafo)

Acoplamiento: Grado de interdependencia entre las unidades de software (módulos, funciones, subrutinas, bibliotecas, etc.) de un sistema informático. El acoplamiento da la idea de lo dependiente que son las unidades de software entre sí, es decir, el grado en que una unidad puede funcionar sin recurrir a otras. (http://www.alegsa.com.ar/Dic/acoplamiento.php, 2010)

Cohesión: En informática, la cohesión hace referencia a la forma en que agrupamos unidades de software (módulos, subrutinas...) en una unidad mayor.( http://www.alegsa.com.ar/Dic/cohesion.php, 2008)

JSON: formato ligero de intercambio de datos. (http://www.json.org/)

Triggers: Triggers son funciones de devolución de llamada de bases de datos, que se realizan de forma automática / invoca cuando se produce un evento de la base de datos especificado. (http://www.w3ii.com/es/postgresql/postgresql_triggers.html)

Funciones: también conocidos como procedimientos almacenados, le permiten llevar a cabo operaciones que normalmente tomaría varias consultas y de ida y vuelta en una sola función dentro de la base de datos. (http://www.w3ii.com/es/postgresql/postgresql_functions.html)

Vistas: Una vista de base de datos es un subconjunto de una base de datos y se basa en una consulta que se ejecuta en una o más tablas de base de datos. Las vistas de base de datos se guardan en la base de datos como consultas con nombre y se pueden utilizar para guardar consultas completas que se utilizan con frecuencia. (https://www.ibm.com/support/knowledgecenter/es/SSLKT6_7.6.0/com.ibm.mt.doc/configur/c_views.html)

Visualizador: Los visualizadores Web son objetos de presentaciones que permiten mostrar información de sitios Web en función de los datos de su base de datos. (http://www.filemaker.com/es/help/html/create_layout.9.38.html)

Tablas: Las tablas son objetos de base de datos que contienen todos sus datos. En las tablas, los datosse organizan con arreglo a un formato de filas y columnas, similar al de una hoja de cálculo. Cada fila representa un registro único y cada columna un campo dentro del registro. (https://docs.microsoft.com/es-es/sql/relational-databases/tables/tables,2017)

Jerarquía: Una jerarquía es una estructura en que se establece distintos grados de subordinación entre los elementos que la componen. Las jerarquías pueden establecerse entre personas, animales, valores, dignidades, ideas, leyes, etc. Por lo general, siguen un criterio de subordinación, donde cada elemento está supeditado al

https://definicion.de/elemento/

http://www.alegsa.com.ar/Dic/unidad%20de%20software.php

http://www.alegsa.com.ar/Dic/unidad%20de%20software.php

5

elemento de la escala de arriba, salvo el de arriba, que ostenta el rango superior, que no se encuentra sometido a ningún elemento. (https://www.significados.com/jerarquia/)

Modularidad: Término derivado de la programación de ordenadores y referido al hecho de que los distintos componentes de un programa deben ser lo más independientes entre sí, con lo cual cualquier falla puede atribuírse a uno de ellos en particular. (Parkin, A.J. Exploraciones en neuropsicología cognitiva. Madrid: Panamericana, pág 5,1999)

Versatilidad: Versátil es un adjetivo que hace referencia a la capacidad de algo o alguien de adaptarse con rapidez y facilidad a distintas funciones. (https://definicion.de/versatil/,2010)

6

TABLA DE CONTENIDO

1. INTRODUCCIÓN ................................................................................................................................... 10

1.1. Contexto ....................................................................................................................................... 10 1.2. Planteamiento del Problema ........................................................................................................ 10 1.3. Justificación del Problema ............................................................................................................ 10 1.4. Objetivo General ........................................................................................................................... 11 1.5 Objetivos Específicos ..................................................................................................................... 11 1.6 Descripción de la Solución ............................................................................................................ 11 1.6.1 Proceso de Ingeniería.................................................................................................................... 11 1.6.2 Productos de Software .................................................................................................................. 11

2. MARCO TEÓRICO ..................................................................................................................................... 13 3. PROCESO DE INGENIERÍA DE SOFTWARE ............................................................................................. 18

3.1 Modelo de proceso de desarrollo de software. ............................................................................ 18 3.1.1 Descripción de Iteraciones realizadas ............................................................................................... 18 3.2 Educción de Requisitos.................................................................................................................. 19 3.2.1 Técnica utilizada: .......................................................................................................................... 19 3.2.2 Requisitos funcionales documentados .......................................................................................... 19 3.3 Análisis y Diseño ........................................................................................................................... 21 3.3.1 Objetivos de Arquitectura y Limitaciones. .................................................................................... 21 3.3.2 Requisitos No Funcionales. ........................................................................................................... 22 3.4 Diseño de la Arquitectura. ............................................................................................................ 23 3.4.1 Vista Física. ................................................................................................................................... 25 3.4.2 Vista de Procesos. ......................................................................................................................... 37 3.4.3 Vista Lógica. .................................................................................................................................. 51 3.4.4 Vista de Desarrollo. ....................................................................................................................... 53 3.5 Patrones de Diseño Utilizados ...................................................................................................... 53 3.6 Justificación de Diseño .................................................................................................................. 53 3.7 Desarrollo ..................................................................................................................................... 54 3.7.1 Tecnologías utilizadas ................................................................................................................... 54 3.7.2 Tecnologías utilizadas y su Relación con los Atributos de Calidad. .............................................. 55 3.8 Prototipos del Software ................................................................................................................ 56 3.8.1 Desarrollo de prototipos Versión 1.0 (Iteración No 1) .................................................................. 56 3.8.2 Desarrollo de prototipos Versión 1.1 (Iteración No 2) .................................................................. 60 3.8.3 Desarrollo de prototipos Versión 1.2 (Iteración No 3) .................................................................. 64 3.8.4 Desarrollo de prototipos Versión 1.3 (Iteración No 4) ................................................................. 68 3.9 Pruebas y Evaluación de Software ................................................................................................ 71 3.9.1 Casos de Prueba ............................................................................................................................ 72 3.9.2 Resumen Pruebas Funcionales...................................................................................................... 73 3.10 Acceso a la Aplicación ................................................................................................................... 74 3.11 Estándares de ingeniería empleados durante el proyecto ............................................................ 74

4. ANÁLISIS DE RESULTADOS ................................................................................................................... 77

4.1 Análisis de Impactos ..................................................................................................................... 77 4.2 Utilización de herramientas .......................................................................................................... 77 4.3 Análisis de diseño de componentes .............................................................................................. 78 4.4 Cumplimiento de Objetivos ........................................................................................................... 78 4.5 Experiencia de diseño en ingeniería de software .......................................................................... 79 4.6 Trabajos Futuros ........................................................................................................................... 79

7

5. REFERENCIAS ....................................................................................................................................... 81 6. ANEXOS ............................................................................................................................................... 82

Caso de Prueba No 1 .................................................................................................................................. 82 Caso de Prueba No 2 .................................................................................................................................. 83 Caso de Prueba No 3 .................................................................................................................................. 84 Caso de Prueba No 4 .................................................................................................................................. 84 Caso de Prueba No 5 .................................................................................................................................. 85 Caso de Prueba No 6 .................................................................................................................................. 86 Caso de Prueba No 7 .................................................................................................................................. 87 Caso de Prueba No 8 .................................................................................................................................. 88 Caso de Prueba No 9 .................................................................................................................................. 89 Caso de Prueba No 10 ................................................................................................................................ 90 Caso de Prueba No 11 ................................................................................................................................ 91 Caso de Prueba No 12 ................................................................................................................................ 92 Caso de Prueba No 13 ................................................................................................................................ 93 Caso de Prueba No 14 ................................................................................................................................ 94 Caso de Prueba No 15 ................................................................................................................................ 95 Caso de Prueba No 16 ................................................................................................................................ 96 Caso de Prueba No 17 ................................................................................................................................ 97 Caso de Prueba No 18 ................................................................................................................................ 98 Caso de Prueba No 19 ................................................................................................................................ 99 Caso de Prueba No 20 .............................................................................................................................. 100 Caso de Prueba No 21 .............................................................................................................................. 101 Caso de Prueba No 22 .............................................................................................................................. 102 Caso de Prueba No 23 .............................................................................................................................. 102 Caso de Prueba No 24 .............................................................................................................................. 103 Caso de Prueba No 25 .............................................................................................................................. 104 Caso de Prueba No 26 .............................................................................................................................. 105 Caso de Prueba No 27 .............................................................................................................................. 106 Caso de Prueba No 28 .............................................................................................................................. 107 Caso de Prueba No 29 .............................................................................................................................. 108 Caso de Prueba No 30 .............................................................................................................................. 109

ÍNDICE DE FIGURAS

FIGURA 3.1 CASOS DE USO- DIAGRAMA DE CASOS DE USO. ........................................................................ 24 FIGURA 3.2 INGRESO DE USUARIO - DIAGRAMA DE DESPLIEGUE................................................................. 25 FIGURA 3.3 REGISTRO DE USUARIO - DIAGRAMA DE DESPLIEGUE. .............................................................. 27 FIGURA 3.4 REGISTRO DE BASE DE DATOS - DIAGRAMA DE DESPLIEGUE. .................................................... 29 FIGURA 3.5 GRAFICAR RED COMPLETA - DIAGRAMA DE DESPLIEGUE. ......................................................... 33 FIGURA 3.6 REGISTRAR USUARIO – DIAGRAMA DE ACTIVIDAD ................................................................... 37 FIGURA 3.7 INGRESO DE USUARIO – DIAGRAMA DE ACTIVIDAD.................................................................. 38 FIGURA 3.8 REGISTRAR BASE DE DATOS – DIAGRAMA DE ACTIVIDAD ......................................................... 39 FIGURA 3.9 GRAFICAR GRAFO COMPLETO – DIAGRAMA DE ACTIVIDAD ...................................................... 40 FIGURA 3.10 BUSCAR COMPONENTE – DIAGRAMA DE ACTIVIDAD .............................................................. 42 FIGURA 3.11 CAMBIAR JERARQUÍA– DIAGRAMA DE ACTIVIDAD ................................................................. 44 FIGURA 3.12 BORRAR GRAFO– DIAGRAMA DE ACTIVIDAD .......................................................................... 46 FIGURA 3.13 CALCULAR MEDIDAS– DIAGRAMA DE ACTIVIDAD ................................................................... 48 FIGURA 3.14 EXPORTAR GRAFO– DIAGRAMA DE ACTIVIDAD ...................................................................... 50 FIGURA 3.15 DIAGRAMA DE CLASES ............................................................................................................ 51 FIGURA 3.16 DIAGRAMA DE COMPONENTES ............................................................................................... 53 FIGURA 3.16 RESUMEN DE PRUEBAS FUNCIONALES. ................................................................................... 73

8

ÍNDICE DE TABLAS

TABLA 2.1 HERRAMINTAS DE RECUPERACION DE ARQUITECTURA DE SOFTWARE. ............................ 14 TABLA 2.2 HERRAMINTAS DE RECUPERACION DE ARQUITECTURA DE SOFTWARE. ............................ 15 TABLA 2.3 HERRAMINTAS DE RECUPERACION DE ARQUITECTURA DE SOFTWARE. ...................................... 15 TABLA 3.1 RESUMEN ITERACIONES, FASES Y ARTEFACTOS........................................................................... 19 TABLA 3.2 ESPECIFICACIÓN Y PRIORIZACIÓN DE REQUISITOS FUNCIONALES ............................................... 20 TABLA 3.3 MATRIZ DE ESPECIFICACIÓN Y CLASIFICACIÓN DE REQUISITOS NO FUNCIONALES. ..................... 22

9

1. INTRODUCCIÓN

1.1 Contexto 1.2 Planteamiento del problema 1.3 Justificación del Problema 1.4 Objetivo General 1.5 Objetivos Específicos 1.6 Descripción de la solución 1.6.1 Descripción Proceso de Ingeniería 1.6.2 Productos de Software

1.6.2.1.1.1.1.1.1 Objetiv

1.6.2.1.1.1.1.1.2

10

1. INTRODUCCIÓN

1.1. Contexto

En la actualidad los arquitectos de software requieren de una herramienta que les facilite la identificación de los riesgos que se pueden encontrar en la estructura de la arquitectura de un software, ya sea en etapas tempranas o tardías del desarrollo. Pero la escasez de herramientas con acceso libre o la desactualización de las mismas, dificultan al arquitecto encontrar una herramienta que permita realizar un análisis exhaustivo sobre la arquitectura de un software sin incurrir en costos excesivos o licencias de uso de productos comerciales.

Dentro de las herramientas disponibles actuales que permiten la recuperación de la arquitectura de un software se identifica un factor clave como lo es un formato grafico el cual permite visualizar de una forma más fácil e intuitiva la información de todos los componentes. Teniendo en cuenta lo anterior dicho se puede identificar la necesidad de un formato grafico que permita brindar información al arquitecto de software facilitándole así la visualización de todos los componentes y las relaciones que existen entre dichos componentes.

1.2. Planteamiento del Problema

La propuesta nace de la necesidad que tienen los arquitectos de software para realizar un análisis exhaustivo dentro de la arquitectura de un software, permitiendo identificar las ventajas y desventajas que sus componentes, relaciones y sus propiedades brindan a este. Otra situación que se presenta es la poca oferta de herramientas de acceso libre para la recuperación de la arquitectura de un software, encontrándose que en la mayoría de los casos estas herramientas no han sido actualizadas en los últimos años. También se identificó la necesidad de una herramienta que posea un visualizador el cual permita llevar de forma nativa el modelo de la arquitectura de un software a una forma de representación de grafo, donde se podrá realizar diferentes tipos de análisis y llevarlos al contexto de la arquitectura de un sistema. Entre esos análisis se pueden mencionar puntos únicos de falla, acoplamiento y cohesión entre componentes de la arquitectura.

En cuanto a la parte social se pudo identificar que algunas empresas de desarrollo de software requieren de una herramienta que les facilite la visualización y el análisis de la arquitectura de sus proyectos, proporcionándole así la posibilidad de entregar proyectos de software con mayor calidad.

1.3. Justificación del Problema

La herramienta nace de la necesidad de contar con un software actual de acceso libre que permita al arquitecto de software, obtener de una forma más rápida y sencilla la comprensión de la arquitectura de un software y la relación entre sus componentes. De esta forma el arquitecto de software tendrá un apoyo en la toma de decisiones sobre el diseño y mantenimiento de un software.

11

1.4. Objetivo General

● Desarrollar una herramienta para análisis de arquitectura de software siguiendo un enfoque de modelo de grafos.

1.5 Objetivos Específicos

● Diseñar y desarrollar un sistema que permita la recuperación de los componentes y

relaciones de la arquitectura de un sistema de software. ● Implementar la base de datos orientada a grafos que sirva como soporte funcional para la

implementación de los casos de uso base de la herramienta. ● Ejecutar los casos de prueba que validen los casos de uso implementados.

1.6 Descripción de la Solución

1.6.1 Proceso de Ingeniería

Educción de Requisitos: Para la extracción de requisitos se realizó un taller, en el cual un especialista sobre el tema se encargó de hablar sobre las herramientas que permitían el análisis de la arquitectura de un software y las bases de datos orientadas a grafos, mediante dicha charla los desarrolladores se encargaron de identificar los requisitos. Proceso de Desarrollo del Software: Haciendo uso del modelo en espiral se logró desarrollar un producto final, el cual fue optimizado gracias a las iteraciones que se fueron realizando. En cada iteración se realizaron prototipos que nos permitieron evidenciar fallos y riesgos que se encontraban dentro del software, de esta forma en cada iteración el software era mejorado y disminuían la cantidad de riesgos que podrían ocurrir en la ejecución del mismo. Dentro de estas mejoras también se tuvieron en cuenta optimizaciones sobre la interfaz de usuario. Pruebas de Software Para las pruebas funcionales del software se hizo uso de la técnica de caja negra, haciendo uso también de la técnica de partición equivalente, permitiendo así comprobar una gran cantidad de casos de pruebas y verificando que cada una de las funcionalidades del software funcionara de forma correcta con la salida esperada.

1.6.2 Productos de Software

• Manual de Instalación. • Código Fuente

12

2. MARCO TEORICO

2.1 La arquitectura de software y sus herramientas 2.2 Bases de datos orientadas a grafos 2.3 OrientDB 2.4 Vis.js

13

2. MARCO TEÓRICO 2.1 La arquitectura de software y sus herramientas

La arquitectura de software ha tomado mucha más importancia en los últimos años entre los profesionales de la industria [21], por lo que se han creado estándares, aplicaciones y herramientas que ayudan a llevar y mejorar esta importante etapa. Existen herramientas que permiten la recuperación de la arquitectura de software y son herramientas muy importantes para los arquitectos que hacen uso de éstas. Este tipo de herramientas permiten validar que la arquitectura establecida la cual se ha definido para la estructuración y el desarrollo del software se cumpla, de esta forma se podrá asegurar atributos de calidad que pueden ser parte de los requisitos no funcionales establecidos para el software, como lo son: la facilidad de modificación, escalabilidad, reutilización, confiabilidad entre otros. Para el planteamiento de este trabajo se inició con la búsqueda de herramientas de recuperación de arquitectura de software, se hizo especial énfasis en herramientas que fueran Open Source o permitieran realizar extensiones. Se documentaron algunas de las herramientas y sus características las cuales se pueden visualizar en la Tabla 1, Tabla2, Tabla 3. Algunas de las herramientas Open Source que se encontraron fueron: Bauhaus, Jmove, Softwarenaut y ArchStudio. Estas herramientas permiten el análisis de dependencias, observar limitaciones de arquitectura, también ayudan a entender el diseño para valorar la arquitectura de un software [4]. Sin embargo, el gran problema con la mayoría de este tipo de herramientas Open Source se encuentra en que han sido abandonadas y muchas de estas no han sido actualizadas en los últimos años, por lo cual ya no cuentan con un soporte que las respalde y traen consigo algunos problemas o errores que dificultan obtener un óptimo resultado. Por otra parte, hay herramientas de recuperación de arquitectura que están enfocadas a un uso más comercial, algunos ejemplos podrían ser: Structure 101, Stan4j y SonarJ (Sonargraph). Estas herramientas tienen un soporte detrás de ellas por lo que se actualizan con frecuencia. También cuentan con una comunidad y empresas importantes en la industria del software que hacen uso de estas herramientas. Por lo general este tipo de herramientas de recuperación son de pago, aunque algunas tienen una versión libre o dan la opción de instalar una versión gratuita la cual posee una licencia que solo dura por unos días.

ArchStudio Alborz Sonargraph-Explorer

Sonargraph-Architect

Versión 5 1 Desconocido Desconocido

Lenguaje Java Java Java, C# Java, C#

Código Abierto SI NA NA NA

Gratis SI SI SI NA

Dominio IDE-Eclipse IDE-Eclipse IDE-Eclipse IDE-Eclipse

14

Descripción Crea y manipula descripciones de la arquitectura basada en xADL, compara las descripciones de la arquitectura con diferentes criterios integrados en la herramienta

Las operaciones de esta herramienta se basan en técnicas como : la zona de minería de datos, búsqueda de patrones y algoritmos de agrupación (clustering).

Permite realizar un análisis estático centrado en la visualización de métricas y dependencias.

La herramienta permite la exploración del código y su compresión por medio de diagramas, evaluar la calidad mediante el análisis de métricas, encontrar código duplicado

Fecha 2012 2001 Desconocido Desconocido

Entradas Código fuente, Información dinámica, Experiencias Humanas.

Código fuente, Proyecto Java

Código fuente, Proyecto Java

Pagina http://isr.uci.edu/projects/archstudio/

http://www.cs.ecu.edu/sartipi/Tools/Alborz/index.htm

https://www.hello2morrow.com/products/sonargraph/explorer

https://www.hello2morrow.com/products/sonargraph/architect9

Version de Prueba NA NA NA SI

Tabla 2.1 Herramintas de Recuperacion de Arquitectura de Software.

ArchView Structure101 Softwarenaut Stan4j

Versión Desconocido Desconocido 4 2.x

Lenguaje Smalltalk, Java, C++, Modula

Java,.Net C,C++,Java,Smalltalk

Java

Código Abierto NA NA NA NA

Gratis NA NA SI SI

Dominio NA IDE-Eclipse NA IDE-Eclipse

Descripción Se basa en el reporte de errores por medio de herramientas como BugZilla

Permite entender la arquitectura del sistema, la forma en que están conectados los componentes y el grado de dependencia entre estos.

Softwarenaut es una herramienta destinada a la exploración de top-down de grandes sistemas de software.

Herramienta que permite la comprensión del código, así como también permite analizar la estructura de un software.

Fecha 2005 2004 2011 Desconocido

Entradas Código Fuente, Estático,Dinámico,

Paquetes, Proyectos Maven

Código Fuente. Código Fuente

15

Experiencias Humanas.

Pagina NA http://structure101.com/ http://scg.unibe.ch/softwarenaut

http://stan4j.com/

Versión de Prueba NA SI NA NA

Tabla 2.2 Herramintas de Recuperacion de Arquitectura de Software.

Bauhaus Rigi Jmove

Versión Desconocido 5.4.1 Desconocido

Lenguaje C, C++, C#, Java C,Cobol,C++ Java

Código Abierto NA SI Si

Gratis NA SI Si

Dominio NA NA IDE-Eclipse

Descripción Tiene como objetivo principal analizar y recuperar los métodos desarrollados de un software por medio de la comprensión de la arquitectura. Proporciona información valiosa para mejorar la calidad del software.

Graficador interactivo usado para la ingenieria reversa de un sofware usando el método de caja blanca. Permite la comprensión del programa.

Ayuda a entender el diseño y a valorar la arquitectura de un software hecho en java

Fecha 2005 Desconocido Desconocido

Entradas Código Fuente Código Fuente Código Fuente.

Pagina https://www.axivion.com/en http://www.rigi.cs.uvic.ca/Pages/download.html

http://www.jmove.org/

Version de Prueba SI NA NA Tabla 2.3 Herramintas de Recuperacion de Arquitectura de Software.

Debido a lo mencionado acerca de las herramientas de recuperación, se decidió enfocar el trabajo en crear una nueva herramienta Open Source, capaz de suplir algunas de las necesidades que tiene un arquitecto de software a la hora de analizar una arquitectura. Se incluyó en esta solución algo diferente como lo son las bases de datos orientadas a grafos la cual se encargará de gestionar la información recuperada. Estos gestores cuentan con un componente gráfico que ayudará al arquitecto a consultar la información que desea y analizarla de una forma más completa, intuitiva y fácil de entender. Estas bases de datos ayudan al usuario a identificar entidades y sus relaciones representándolas por medio de nodos y vértices. Existen varios gestores de bases de datos orientadas a grafos en la actualidad, dos de los más conocidos son: Neo4j y OrientDB.



16

2.2 Bases de datos Orientadas a grafos.

Las bases de datos orientadas a grafos permiten mostrar la información por medio de nodos y las relaciones entre datos por medio de arcos, lo cual facilita la representación de la arquitectura de un software permitiendo así la opción de aplicar distintos tipos de análisis o teorías de grafos para llevar un análisis al contexto de la arquitectura de un sistema. Una de las bases de datos orientadas a grafos más populares es Neo4j, esta se encuentra escrita en Java y puede ser integrada con múltiples lenguajes de programación en los que se encuentran PHP, Java y .Net. Se usa especialmente para modelar sistemas de recomendación y redes sociales, Neo4J cuenta con dos versiones: Community edition (libre) y la edición Enterprise [13], ésta última es recomendada si se quiere aprovechar todo el potencial que tiene este gestor de bases de datos. 2.3 OrientDB. OrientDB es un gestor de base de datos orientada a grafos de código abierto escrito en Java, también es una base de datos documental que permite manejar la conexión directa entre los registros de forma gráfica. Una de las características que tiene esta base de datos es que soporta el uso de SQL como lenguaje para las consultas, además es un gestor muy rápido capaz de almacenar 220.000 registros por segundo en un hardware común, también se puede integrar con la mayoría de lenguajes de programación más usados, como lo son: Java, Ruby, Python, entre otros. OrientDB cuenta con dos versiones, una Enterprise edition y otra Community edition [14].

Para la elección de la base de datos, se evaluaron los gestores Neo4j y OrientDB, se decidió escoger Orientdb debido a que su versión libre brinda algunas ventajas que ayudan a un uso e implementación más rápida de éste gestor. A continuación, se mencionan algunas ventajas:

Orientdb permite las consultas con lenguaje SQL.

Permite la creación y el uso de secuencias.

Cuenta con una API para Java lo cual facilita su implementación y uso.

Cuenta con una licencia “Commercial Friendly License”. 2.4 Vis.js Para el graficador se hizo una búsqueda de librerías para la web, de las cuales se encontraron algunas como: Sigma.js, D3.js, Chart.js. Sin embargo, se decidió utilizar Vis.js por la flexibilidad y las opciones que da para personalizar el grafo, además por ser una librería con buena documentación, ejemplos prácticos y una comunidad activa en foros para resolver inquietudes y mejorar la librería. Vis.js es una librería de código libre escrita en JavaScript la cual es usada para proyectos web facilitando la tarea de realizar distintos gráficos como son: Redes compuestas de nodos y arcos, Graficas 2D, Graficas 3D y Barras de Tiempo. Esta librería carga grandes cantidades de datos de manera dinámica y permite que el usuario pueda interactuar con el visualizador aportando así la opción de manipular los datos lo cual la hace apropiada para la implementación de la herramienta.

17

3. PROCESO DE INGENIERÍA DE SOFTWARE

3.1 Modelo de proceso de desarrollo de software 3.2 Educción de Requisitos 3.3 Análisis y Diseño 3.4 Diseño de la Arquitectura. 3.5 Patrones de Diseño Utilizados 3.6 Justificación de Diseño 3.7 Desarrollo 3.8 Prototipos del Software 3.9 Pruebas y Evaluación de Software 3.10 Acceso a la Aplicación 3.11 Estándares de ingeniería empleados durante el proyecto

18

3. PROCESO DE INGENIERÍA DE SOFTWARE

3.1 Modelo de proceso de desarrollo de software.

Se decidió hacer uso del modelo en espiral ya que este nos permitirá en cada iteración realizar mejoras en los requerimientos del software, generar prototipos que nos ayudarán a identificar riesgos y de esta forma ir construyendo un software de mejor calidad. Se tuvo en cuenta que nuestro software aún se encuentra sujeto a cambios y gracias a este modelo se podrán realizar modificaciones en cada iteración.

También se tuvo en cuenta que el modelo en espiral en la actualidad es uno de los enfoques más realistas para la realización del desarrollo de un software [19], y este al ser un modelo evolutivo que se enfoca en el análisis de riesgos nos permite mejorar el software en cada iteración e identificar de una forma más fácil los problemas y errores que pueden ocurrir en el sistema. Este modelo al dar la posibilidad de poder adaptarse y emplearse a lo largo de la vida del software, permitirá que en un futuro se le puedan realizar mejoras al proyecto de una forma más fácil haciendo uso del mismo modelo.

3.1.1 Descripción de Iteraciones realizadas

A continuación, se describe el proceso realizado en las iteraciones definidas: Iteración No.1 Prototipos de Pantalla

Artefactos de Entrada: Casos de uso, Diagramas UML.

Descripción: La primera iteración se centró en el análisis de los requerimientos y en la realización de los prototipos de pantalla que se relacionan con el producto final.

Artefactos de Salida: Prototipos de pantalla.

Fecha Inicio: 01-12-2016

Fecha Fin: 01-01-2017

Iteración No.2 Prototipo N.1

Artefactos de Entrada: Prototipos de Pantalla, Requisitos.

Descripción: En la segunda iteración se hizo énfasis en el desarrollo del software para satisfacer cada uno de los requerimientos establecidos.

Artefactos de Salida: Prototipo del Software N.1


Fecha Fin: 01-03-2017

Iteración No.3 Prototipo N.2

Artefactos de Entrada: Prototipo del Software N.1, Requerimientos.

Descripción: En la tercera iteración se realizaron ajustes en el software, dando así una mejora a cada una de las funcionalidades establecidas.

Artefactos de Salida: Prototipo del Software N.2

19


Fecha Fin: 01-05-2017

Iteración No.4 Software Versión Final V3.

Artefactos de Entrada: Prototipo del Software N.2, Requerimientos.

Descripción:

En la cuarta iteración se realizaron ajustes en la interfaz de usuario y se implementaron nuevas funcionalidades que permitían una mayor interacción con el grafo. Se agregó también mayor información y medidas sobre el grafo.

Artefactos de Salida: Software Final V3.


Fecha Fin: 15-07-2017

Tabla 3.1 Resumen iteraciones, fases y artefactos.

3.2 Educción de Requisitos

3.2.1 Técnica utilizada:

Para la identificación de requisitos se realizó un Taller, en la cual el especialista sobre el

tema concedió una charla sobre las herramientas que permiten el análisis de la arquitectura

de un software y las bases de datos orientadas a grafos, durante dicha charla los ingenieros

encargados del desarrollo se dieron la tarea de identificar los requisitos. También hay que

tener presente que se hizo uso de la lluvia de ideas para asistir el workshop y así incorporar

cambios o mejoras en los requisitos.

3.2.2 Requisitos funcionales documentados

Ref. Prioridad Descripción Requisito Fuente de Info.

RF-1 Alta

El sistema debe permitir al usuario registrarse por medio de un formulario. Para ello deberá ingresar los siguientes datos:

1. Usuario 2. Contraseña 3. Nombre 4. Correo

RF-2 Alta

Una vez el usuario se haya registrado, podrá acceder al sistema ingresando la siguiente información:

1. Usuario 2. Contraseña

RF-3 Alta

El sistema debe permitir a un usuario que ya se encuentre registrado, guardar una base de datos Postgres con sus respectivos componentes y relaciones por medio de un formulario. Para ello deberá ingresar los siguientes datos:

20

1. Nombre de la Conexión. 2. Usuario de la Base de datos 3. Contraseña de la Base de datos. 4. URL de conexión.

RF-4 Alta

El sistema debe permitir a un usuario, graficar la red compuesta por los componentes y relaciones almacenados.

RF-5 Media El sistema debe permitir a un usuario interactuar con los componentes graficados.

RF-6 Media El sistema debe permitir a un usuario realizar consultas con filtros y condiciones de búsqueda a los componentes graficados.

RF-7 Alta Una vez se haya graficado la red, el usuario podrá visualizar información sobre el grafo actual.

RF-8 Alta Una vez se haya graficado la red, el usuario podrá consultar las medidas del grafo actual.

RF-9 Alta Una vez se haya gratificado la red, el usuario podrá cambiar la visualización del grafo a un modo jerárquico.

RF-10 Bajo Una vez se haya graficado la red, el usuario podrá borrar el grafo del visualizador.

R-11 Alto El sistema debe permitir a un usuario seleccionar la base de datos que desea graficar.

Tabla 3.2 Especificación y priorización de requisitos funcionales

21

3.3 Análisis y Diseño

3.3.1 Objetivos de Arquitectura y Limitaciones.

En esta sección se hará una breve descripción sobre los atributos de calidad que tendrán un gran impacto sobre el diseño de la arquitectura del presente proyecto y las limitaciones que este tendrá.

Atributos de Calidad:

Usabilidad: El sistema posee una interfaz sencilla y fácil de comprender para los usuarios donde se utilizan mensajes guía para la adaptación del usuario con el sistema.

Portabilidad: El sistema debe estar en la capacidad de implementarse en diferentes plataformas, minimizando el desarrollo requerido para dicha implementación, debido a que gran parte del código fuente podrá ser reutilizado.

Mantenibilidad: El sistema debe estar en la capacidad de recibir mejoras o futuras modificaciones que mejoren la experiencia del usuario.

Eficiencia: El sistema debe estar en la capacidad de proporcionar tiempos de respuestas adecuados, bajo condiciones determinadas.

Extensibilidad: El software debe estar en la capacidad de facilitar la adaptación de nuevos requisitos o cambios en la especificación.

Interoperabilidad: El software debe estar en la capacidad de exportar la información obtenida para visualizarlas en otras herramientas.

Limitaciones del Software:

El sistema no debe graficar ningún componente a menos que un usuario haya seleccionado una base de datos.

La interfaz de usuario solamente estará disponible en idioma Español.

El sistema no debe mostrar ninguna base de datos que no haya sido registrada por el mismo usuario.

El sistema no debe permitir ingresar a un usuario a menos de que este se haya registrado.

22

3.3.2 Requisitos No Funcionales.

Ref. Descripción Requisito Interoperabilidad

Rendimiento

Seguridad

Usabilidad

RFN-1 El sistema proporciona mensajes de error que sean informativos y orientativos para el usuario.

X

RFN-2

La interfaz del sistema debe estar en la capacidad de adaptarse a distintas resoluciones de pantalla con el fin de garantizar la adecuada visualización en múltiple computadores personales.

X

RFN-3

El sistema debe tener una interfaz para el usuario que sea fácil de entender y manejar, por lo que el usuario no tendrá la necesidad de poseer mucho conocimiento técnico para poder manejar la plataforma.

X

RFN-4 El sistema debe estar en la capacidad de operar de forma adecuada con una base de datos que posea mucha información.

X

RFN-5 Una acción de búsqueda realizada por el usuario no debe exceder los 2 segundos en un grafo con una media de 100 nodos.

X

RFN-6 La carga de la aplicación no debe exceder los 5 segundos.

X

RFN-7 La información guardada de una base de datos debe estar asegurada con su respectivo “usuario” y “contraseña”.

X

RFN-8

Los grafos exportados por el sistema deben estar en la capacidad de visualizarse en otras herramientas.

X

Tabla 3.3 Matriz de especificación y clasificación de requisitos no funcionales.

23

3.4 Diseño de la Arquitectura.

Para el diseño de la arquitectura del software ARTool (Architecture Recovery Tool), se pretende alcanzar atributos de calidad que ayuden al software no sólo a realizar los requerimientos planteados en éste documento, si no también que pueda ser un software mantenible en el tiempo y además escalable, permitiendo de este modo el soporte de nuevos requerimientos que pueden ser desarrollados e implementados a futuro. Se opta por utilizar una arquitectura Cliente – Servidor, en la cual el servidor se encarga de gestionar la información a petición del cliente, además se decide trabajar con servicios Rest lo que permite que dicha información que se envía desde el servidor hacia el cliente sea en formato JSON y así lograr una mayor versatilidad a la hora de procesar y gestionar dicha información en el cliente, consiguiendo a su vez una mayor portabilidad para posibles plataformas en las que se podría enviar dicha información. Para mejorar la mantenibilidad del software, en la parte del servidor se decide implementar una arquitectura por capas apoyada por el paradigma de programación orientada a objetos, éste último ayuda a que la estructura del proyecto sea modular, organizada y facilita el entendimiento del código.

24

3.4.1 Vista de Escenarios.

Figura 3.1 Casos de uso- Diagrama de casos de Uso.

25

3.4.2 Vista Física.

Figura 3.2 Diagrama de Despliegue, Ingreso de Usuario.

Figura 3.2 Ingreso de Usuario - Diagrama de Despliegue.

Ingreso de Usuario – Diagrama de Despliegue: En la figura 3.2 se puede observar los componentes que permiten el ingreso del usuario a la aplicación y la relación que hay entre estos. A continuación se hará una breve explicación de cada uno de los componentes. CAPA DE PRESENTACIÓN:

LoginUI.html: Archivo HTML encargado de estructurar los componentes que se visualizan en el navegador web, específicamente el formulario de ingreso y de registro.

Login.js: Archivo JavaScript encargado de la parte lógica y gestión de los datos ingresados por el usuario en el componente LoginUI.html. Además envía y recibe información del usuario desde el componente ControladorService.java.

VisualizadorUI.html: Componente gráfico al cual se direcciona al usuario cuando ha ingresado sus datos de ingreso de manera correcta.

Visualizador.js: Componente que consume un servicio del ControladorService.java, con la información del usuario que ingresó, y la muestra por medio del componente VisualizadorUI.html.

26

CAPA DE SERVICIO:

ControladorService.java: Componente que se encarga de gestionar todos los servicios que consume el cliente.

CAPA DE LÓGICA:

BussinessDelegator.java: Componente encargado de administrar las responsabilidades de la capa lógica.

Usuario.java: Componente que administra los atributos del usuario.

UsuarioLogic.java: Componente encargado de establecer todas las reglas que se deben cumplir para el ingreso del usuario.

CAPA DE INTEGRACIÓN:

UsuarioDAO: Componente que se encarga de interactuar con la base de datos para consultar los datos del usuario.

CAPA DE RECURSOS:

Usuario: Tabla de la base de datos encargada de almacenar los datos del usuario.

27

Figura 3.3 Diagrama de Despliegue Registrar Usuario.

Figura 3.3 Registro de Usuario - Diagrama de Despliegue.

Ingreso de Usuario – Diagrama de Despliegue: En la figura 3.3 se puede observar los componentes que permiten el registro del usuario a la aplicación y la relación que hay entre estos. A continuación se hará una breve explicación de cada uno de los componentes. CAPA DE PRESENTACIÓN:



CAPA DE SERVICIO:


CAPA DE LÓGICA:



UsuarioLogic.java: Componente encargado de establecer todas las reglas que se deben cumplir para el registro del usuario.

28


UsuarioDAO: Componente que se encarga de interactuar con la base de datos para registrar los datos del usuario.

CAPA DE RECURSOS:


29

Figura 3.4 Diagrama de Despliegue, Registro de Base de Datos.

Figura 3.4 Registro de Base de Datos - Diagrama de Despliegue.

Registro de Usuario – Diagrama de Despliegue: En la figura 3.4 se puede observar los componentes que permiten el registro de la base de datos PostgreSQL a la aplicación y la relación que hay entre estos. A continuación se hará una breve explicación de cada uno de los componentes.

30

CAPA DE PRESENTACIÓN:





Conexiones.html: Componente gráfico el cual permite al usuario realizar el registro de una base de datos.

Conexiones.js: Archivo JavaScript encargado de la parte lógica y gestión de los datos ingresados por el usuario en el componente Conexiones.html. Además envía la información del registro a la base de datos atreves del ControladorService.java.

CAPA DE SERVICIO:


CAPA DE LÓGICA:




Db_Recovery.java: Componente que administra los atributos de la base de datos a registrar.

Db_RecoveryLogic.java: Componente encargado de establecer todas las reglas que se deben cumplir para registrar la base de datos.

Tabla.java: Componente que administra los atributos de las tablas.

31

TablaLogic.java: Componente encargado de establecer todas las reglas que se deben cumplir para la recuperación de las tablas que se encuentran registrados dentro de la base de datos PostgreSQL.

Vista.java: Componente que administra los atributos de las vistas.

VistaLogic.java: Componente encargado de establecer todas las reglas que se deben cumplir para la recuperación de las vistas que se encuentran registrados dentro de la base de datos PostgreSQL.

Función.java: Componente que administra los atributos de las funciones.

FunciónLogic.java: Componente encargado de establecer todas las reglas que se deben cumplir para la recuperación de las funciones que se encuentran registradas dentro de la base de datos PostgreSQL.

Trigger.java: Componente que administra los atributos de los triggers .

TriggerLogic.java: Componente encargado de establecer todas las reglas que se deben cumplir para la recuperación de los triggers que se encuentran registrados dentro de la base de datos PosgreSQL.


UsuarioDAO: Componente que se encarga de interactuar con la base de datos para registrar los datos del usuario.

Db_RecoveryDAO: Componente que se encarga de interactuar con la base de datos OrientDB para realizar el registro de toda la información que se extrae de la base de datos PostgreSQL.

TablaDAO: Componente que se encarga de interactuar con la base de datos para extraer las tablas.

VistaDAO: Componente que se encarga de interactuar con la base de datos para extraer las vistas.

FunciónDAO: Componente que se encarga de interactuar con la base de datos para extraer las funciones.

TriggerDAO: Componente que se encarga de interactuar con la base de datos extraer los triggers.

CAPA DE RECURSOS:


32

Db_Recovery: Tabla de la base de datos OrientDB encargada de almacenar la información de la base de datos PostgreSQL.

Tabla: Tabla de la base de datos encargada de almacenar todas las tablas de la base de datos postgres.

Vista: Tabla de la base de datos encargada de almacenar las vistas.

Función: Tabla de la base de datos encargada de almacenar las funciones.

Trigger: Tabla de la base de datos encargada de almacenar los triggers.

33

Figura 3.5 Diagrama de Despliegue, Graficar Red Completa

Figura 3.5 Graficar Red Completa - Diagrama de Despliegue.

Graficar Red Completa – Diagrama de Despliegue: En la figura 3.5 se puede observar los componentes que permiten la recuperación de todos los componentes que se encuentran dentro de la base de datos y la relación que hay entre ellos. A continuación se hará una breve explicación de cada uno de los componentes.

34

CAPA DE PRESENTACIÓN:





Conexiones.html: Componente gráfico el cual permite al usuario seleccionar la base de datos que desea graficar.

Conexiones.js: Archivo JavaScript encargado de la parte lógica y gestión de la base de datos seleccionada por el usuario en el componente Conexiones.html. Además recibe la información de las bases de datos desde el componente ControladorService.java.

CAPA DE SERVICIO:


CAPA DE LÓGICA:




Db_Recovery.java: Componente que administra los atributos de la base de datos a registrar.

Db_RecoveryLogic.java: Componente encargado de establecer todas las reglas que se deben cumplir para consultar las bases de datos registradas.

Tabla.java: Componente que administra los atributos de las tablas.

35

TablaLogic.java: Componente encargado de establecer todas las reglas que se deben cumplir para consultar las tablas que se encuentran registradas dentro de la base de datos.

Vista.java: Componente que administra los atributos de las vistas.

VistaLogic.java: Componente encargado de establecer todas las reglas que se deben cumplir para consultar las vistas que se encuentran registradas dentro de la base de datos.

Función.java: Componente que administra los atributos de las funciones.

FunciónLogic.java: Componente encargado de establecer todas las reglas que se deben cumplir para consultar las funciones que se encuentran registradas dentro de la base de datos.

Trigger.java: Componente que administra los atributos de los triggers .

TriggerLogic.java: Componente encargado de establecer todas las reglas que se deben cumplir para consultar los triggers que se encuentran registrados dentro de la base de datos.


UsuarioDAO: Componente que se encarga de interactuar con la base de datos para consultar los usuarios registrados.

Db_RecoveryDAO: Componente que se encarga de interactuar con la base de datos OrientDB para extraer todas las bases de datos de postgreSQL que se encuentren registradas.

TablaDAO: Componente que se encarga de interactuar con la base de datos para consultar las tablas.

VistaDAO: Componente que se encarga de interactuar con la base de datos para consultar las vistas.

FunciónDAO: Componente que se encarga de interactuar con la base de datos para consultar las funciones.

TriggerDAO: Componente que se encarga de interactuar con la base de datos para consultar los triggers.

CAPA DE RECURSOS:


36

Tabla: Tabla de la base de datos encargada de almacenar todas las tablas de la base de datos postgres.

Vista: Tabla de la base de datos encargada de almacenar las vistas.

Función: Tabla de la base de datos encargada de almacenar las funciones.

Trigger: Tabla de la base de datos encargada de almacenar los triggers.

Db_Recovery: Tabla de la base de datos encargada de almacenar los datos de la base de datos postgres.

37

3.4.3 Vista de Procesos.

Figura 3.6 Diagrama de Actividad, Registrar Usuario

Figura 3.6 Registrar Usuario – Diagrama de Actividad

Actividad 1 – Figura 3.6: Registrar usuario: Proceso en el cual el usuario realizará el registro en la aplicación luego de diligenciar un formulario con toda su información. El sistema realizará el registro luego de verificar que la información ingresada por el usuario no se encuentre ya registrada, en caso de que el usuario ingrese información de un usuario ya registrado el sistema le informará con un mensaje que ha ingresado información no valida.

38

Figura 3.7 Diagrama de Actividad, Ingreso de Usuario

Figura 3.7 Ingreso de Usuario – Diagrama de Actividad

Actividad 2 – Figura 3.7: Ingreso de usuario: Proceso en el cual un usuario ya registrado deberá diligenciar un formulario de ingreso para acceder a la pantalla del Visualizador. El sistema permitirá el acceso al usuario luego de verificar que la información diligenciada por este se encuentre registrada dentro de la base de datos, en caso de que el usuario ingrese información que no se encuentre registrada el sistema le informará por medio de un mensaje que ha ingresado información no valida.

39

Figura 3.8 Diagrama de Actividad, Registrar Base de Datos

Figura 3.8 Registrar base de datos – Diagrama de Actividad

Actividad 3 – Figura 3.8: Registrar base de datos: En esta actividad un usuario deberá diligenciar el formulario de ingreso con información válida para acceder a la pantalla del visualizador. Habiendo ya accedido a la pantalla del visualizador el usuario deberá seleccionar la pestaña de Conexiones, lo cual permitirá al usuario registrar una nueva base de datos diligenciando un formulario con la información requerida. Cuando el formulario ya se encuentre diligenciado el usuario deberá aceptar la información y el sistema realizará las validaciones correspondientes para verificar que la información ingresada sea válida de lo contrario se mostrará un mensaje informando que los datos no son válidos.

40

Figura 3.9 Diagrama de Actividad, Graficar Grafo Completo

Figura 3.9 Graficar Grafo Completo – Diagrama de Actividad

41

Actividad 4 – Figura 3.9: Graficar Grafo completo: En esta actividad un usuario deberá diligenciar el formulario de ingreso con información válida para acceder a la pantalla del visualizador. Luego de acceder a la pantalla del visualizador el usuario deberá seleccionar la pestaña de Conexiones, lo cual permitirá al usuario seleccionar la base de datos que desea graficar. Habiendo ya seleccionado la base de datos el usuario deberá volver a la web del visualizador y presionar la opción de “Graficar Red Completa”, lo cual permitirá al sistema comprobar que existan componentes dentro de la base de datos para luego graficarlos, en caso de que no se encuentre ningún componente dentro de la base de datos se mostrara una mensaje informando que no hay componentes para graficar.

42

Figura 3.10 Diagrama de Actividad, Buscar Componente

Figura 3.10 Buscar Componente – Diagrama de Actividad

43

Actividad 8 – Figura 3.10: Buscar Componente: En esta actividad un usuario deberá diligenciar el formulario de ingreso con información válida para acceder a la pantalla del visualizador. Luego de acceder a la pantalla del visualizador el usuario deberá seleccionar la pestaña de Conexiones, lo cual permitirá al usuario seleccionar la base de datos que desea graficar. Habiendo ya seleccionado la base de datos el usuario deberá volver a la web del visualizador y presionar la opción de “Graficar Red Completa”, lo cual permitirá la visualización de todos los componentes. Una vez el grafo sea graficado el usuario tendrá la posibilidad de ingresar el nombre de uno de los nodos en el buscador lo cual permitirá que se haga énfasis en el nodo ingresado.

44

Figura 3.11 Diagrama de Actividad, Cambiar Jerarquía

Figura 3.11 Cambiar Jerarquía– Diagrama de Actividad

45

Actividad 9- Figura 3.11:

Cambiar Jerarquía: En esta actividad un usuario deberá diligenciar el formulario de ingreso con información válida para acceder a la pantalla del visualizador. Luego de acceder a la pantalla del visualizador el usuario deberá seleccionar la pestaña de Conexiones, lo cual permitirá al usuario seleccionar la base de datos que desea graficar. Habiendo ya seleccionado la base de datos el usuario deberá volver a la web del visualizador y presionar la opción de “Graficar Red Completa”, lo cual permitirá la visualización de todos los componentes.

Una vez el grafo sea visible, el usuario deberá seleccionar la opción de diseño jerárquico, luego de esto el visualizador graficará el grafo con la jerarquía correspondiente.

46

Figura 3.12 Diagrama de Actividad, Borrar Grafo

Figura 3.12 Borrar Grafo– Diagrama de Actividad

47

Actividad 10 – Figura 3.12: Borrar Grafo: En esta actividad un usuario deberá diligenciar el formulario de ingreso con información válida para acceder a la pantalla del visualizador. Luego de acceder a la pantalla del visualizador el usuario deberá seleccionar la pestaña de Conexiones, lo cual permitirá al usuario seleccionar la base de datos que desea graficar. Habiendo ya seleccionado la base de datos el usuario deberá volver a la web del visualizador y presionar la opción de “Graficar Red Completa”, lo cual permitirá la visualización de todos los componentes. Una vez el grafo sea visible, el usuario podrá seleccionar una opción en el menú del visualizador para borrar el grafo actual.

48

Figura 3.13 Diagrama de Actividad, Calcular Medidas

Figura 3.13 Calcular Medidas– Diagrama de Actividad

49

Actividad 11 – Figura 3.13: Calcular Medidas: En esta actividad un usuario deberá diligenciar el formulario de ingreso con información válida para acceder a la pantalla del visualizador. Luego de acceder a la pantalla del visualizador el usuario deberá seleccionar la pestaña de Conexiones, lo cual permitirá al usuario seleccionar la base de datos que desea graficar. Habiendo ya seleccionado la base de datos el usuario deberá volver a la web del visualizador y presionar la opción de “Graficar Red Completa”, lo cual permitirá la visualización de todos los componentes. Una vez el grafo sea visible el usuario podrá seleccionar una opción en el menú derecho para visualizar las medidas del grafo actual. A continuación se hará una breve explicación de las medidas calculadas y su aporte en la herramienta: Beneficio de las Medidas Calculadas: Las medidas que se calcularon en el grafo están hechas para facilitar al arquitecto de software el análisis sobre la arquitectura. Medidas Calculadas en el Grafo:

Para el entendimiento de las medidas que se calcularon en el grafo se tendrá en cuenta los siguientes conceptos:

Un grafo se define de la siguiente forma: G (V, E) en donde “V” son los nodos y “E” los arcos.

“|V|” hace referencia a todos los nodos que se encuentran definidos dentro del grafo y |E| como todos los arcos.

Con lo anterior dicho las siguientes formulas hacen referencia a las medidas calculadas en la aplicación: Grado Medio: Para el cálculo del grado medio se usa la fórmula de (2*|E|)/|V|. Esta medida nos sirve para verificar la media del grado de los nodos. Grado del Grafo: Para calcular el grado de un grafo se suma los grados de todos los nodos, dicho valor equivale al doble del número de arcos. Esta medida nos sirve para verificar la conectividad total que existe en todos los nodos. Grado de los vértices: Es el número de arcos (E) que inciden en un nodo (V). Esta medida nos sirve para verificar el número de conexiones que tiene un nodo.

50

Figura 3.14 Diagrama de Actividad, Exportar grafo

Figura 3.14 Exportar grafo– Diagrama de Actividad

51

Actividad 12 – Figura 3.14: Exportar Grafo: En esta actividad un usuario deberá diligenciar el formulario de ingreso con información válida para acceder a la pantalla del visualizador. Luego de acceder a la pantalla del visualizador el usuario deberá seleccionar la pestaña de Conexiones, lo cual permitirá al usuario seleccionar la base de datos que desea graficar. Habiendo ya seleccionado la base de datos el usuario deberá volver a la web del visualizador y presionar la opción de “Graficar Red Completa”, lo cual permitirá la visualización de todos los componentes. Una vez el grafo sea visible el usuario deberá presionar la opción exportar y seleccionar entre los dos formatos disponibles “CSV” y “GraphML”, esto le permitirá al usuario descargar dicho formato para poder ser usado en otras herramientas y poder visualizar el grafo actual.

3.4.4 Vista Lógica.

Figura 3.15 Diagrama de Clases

Descripción del Modelo: Funciones:

Agregar Funciones: El sistema recupera las funciones que se encuentran registradas dentro de la base de datos PostgreSQL.

Obtener Información Funciones: El sistema consulta todas las funciones que se encuentren dentro de la base de datos OrientDB y los guarda en la base de datos OrientDB.

Base de Datos:

Registrar Base De Datos: El sistema registra en la base de datos OrientDB la información para la conexión a la base de datos PostgreSQL.

52

Consultar Base De Datos: El sistema se encarga de consultar todas las bases de datos que se encuentren registradas.

Usuario:

Registrar Usuario: El sistema permite registrar a un usuario dentro de la base de datos.

Consultar Usuario: El sistema se encarga de consultar todos los usuarios que se encuentren registrados dentro de la base de datos.

Vista:

Agregar Vista: El sistema recupera las vistas que se encuentran registradas dentro de la base de datos PostgreSQL y las guarda en la base de datos OrientDB.

Obtener Información Vistas: El sistema se encarga de consultar todas las vistas que se encuentren registradas dentro de la base de datos.

Tabla:

Agregar Tabla: El sistema recupera las tablas que se encuentran registradas dentro de la base de datos PostgreSQL y las guarda en la base de datos OrientDB.

Obtener Información Tabla: El sistema consulta todas las llaves primarias y llaves foráneas que se encuentren registrados dentro de la base de datos.

Triggers:

Agregar Trigger: El sistema recupera los triggers que se encuentran registradas dentro de la base de datos PostgreSQL y los guarda en la base de datos OrientDB.

Obtener Información Triggers: El sistema consulta todos los triggers que se encuentren registrados dentro de la base de datos.

53

3.4.5 Vista de Desarrollo.

Figura 3.16 Diagrama de Componentes

3.5 Patrones de Diseño Utilizados

Para el desarrollo del proyecto se usaron los siguientes patrones de diseño: Singleton: Patrón de diseño el cual limita a uno la creación de instancias de una clase, lo que garantiza que dicha clase solo tenga un único punto de acceso global.

Inyección de Dependencias: Patrón de diseño orientado a objetos. Dentro de este patrón se identifica un objeto el cual tiene como objetivo suministrar todas las dependencias a otro objeto que las requiera. DAO (Data Access Object): Patrón de diseño usado para acceder a la información de la base de datos lo cual permite registrar, modificar, eliminar y consultar información. En otras palabras el patrón de diseño DAO es usado para establecer una capa de persistencia. DTO (Data Transfer Object): Patrón utilizado para la transferencia de atributos en las capas y en los distintos procesos que ejecuta el cliente y el servidor.

3.6 Justificación de Diseño

Para cumplir con los atributos de calidad planteados en el diseño se implementaron los siguientes patrones de diseño y de arquitectura para los siguientes atributos:

Mantenibilidad:

Modelo en capas: El modelo en capas facilita el manejo de los modelos funcionales. También al ser un patrón bien estructurado permite que se realicen modificaciones en la

54

información sin que las operaciones que se encuentran dentro del sistema se vean afectadas.

Singleton: El patrón de diseño Singleton proporciona un apoyo a la mantenibilidad del software ya que por medio de este se garantiza el agrupamiento de código relacionado en un mismo punto lo cual facilita la localización de código y la modularidad.

Orientado a Objetos: El estilo arquitectónico Orientado a Objetos proporciona un apoyo a la mantenibilidad del software ya que por medio de este se logra desarrollar una estructura que fuera fácil de leer y de comprender, lo cual facilita la tarea de encontrar las problemáticas que se encuentren dentro del sistema.

Extensibilidad:

Modelo en capas: El modelo en capas permite apoyar a la extensibilidad del software porque permite la reutilización de código a la hora de agregar nuevas funcionalidades y al tener un orden de los componentes en cada una de las capas permite que se tenga un mayor entendimiento de la estructura del software, facilitando así la agregación de nuevas funcionalidades sin que otras se vean afectadas.

Orientado a Objetos:

Usabilidad:

Modelo en capas: El modelo en capas permite realizar un enfoque en la interfaz de usuario, debido que separa la parte del cliente con el servidor, lo cual nos permite desarrollar interfaces sencillas y fáciles de comprender para los usuarios. También se hizo uso también de mensajes guías que permiten al usuario adaptarse más fácil al sistema.

Interoperabilidad- Portabilidad:

REST: Por medio del patrón de arquitectura orientado a servicios se logra el envío de información desde el servidor al usuario en formato JSON, logrando así una mayor versatilidad a la hora de procesar y gestionar la información, de esta forma se obtiene una mayor portabilidad e interoperabilidad en el software.

3.7 Desarrollo

3.7.1 Tecnologías utilizadas

OrientDB: Gestor de base de datos orientada a grafos de código abierto escrito en java, la cual dentro de sus característica permite ser una base de datos documental y de gestión gráfica. Esta base de datos soporta el uso de SQL como lenguaje de consulta, además es un gestor muy rápido que puede llegar a almacenar 220.000 registros por segundo en un hardware común [14].

Bootstrap: Framework que permite la creación de interfaces con CSS, y Javascript permitiendo que el desarrollo web front-end sea de una forma más rápida y más fácil. Este

55

también permite adaptar la interfaz del sitio web al tamaño del dispositivo en el que se visualice [15].

Vis.js: Librería JavaScript de visualización diseñada especialmente para proyectos web la cual permite gestionar una suma alta de datos dinámicos y da la opción al usuario de interactuar con dichos datos. Esta librería da la posibilidad de usar varios tipos de gráficos, como los siguientes: Redes, Líneas temporales, Graficas 2D, Graficas 3D [16].

JavaScript: Lenguaje de programación interpretado, el cual se usa principalmente para la creación de páginas web dinámicas. [17]

JQuery: Biblioteca multiplataforma de JavaScript, la cual simplifica la interacción con los elementos HTML, manejar eventos, generar animaciones y la agregación de interacciones con la técnica AJAX a las páginas web. [18]

3.7.2 Tecnologías utilizadas y su Relación con los Atributos de Calidad.

Eficiencia: OrientDB permitirá que el software proporcione tiempos adecuados de respuesta, ya que esta base de datos es caracterizada por ser un gestor muy rápido y trabajar con más de 220.000 registros por segundo. Usabilidad: Bootstrap al ser un framework que se enfoca principalmente en la creación de interfaces, nos da la posibilidad de establecer prioridades en el desarrollo de interfaces sencillas y fáciles de entender para el usuario final. Extensibilidad: Vis.js da la posibilidad que en futuros cambios de la herramienta se pueda hacer uso de otros tipos de gráficos que esta librería brinda.

56

3.8 Prototipos del Software

3.8.1 Desarrollo de prototipos Versión 1.0 (Iteración No 1)

Escena que representa: Pantalla de Ingreso para el usuario.

Funcionalidades: Formulario que permite al usuario ingresar a la aplicación.

Tipo Usuario: Usuario de negocio.

Iteración 1 - Skecth No.1 – Ingreso de Usuario

57

Escena que representa: Pantalla de Registro para el usuario.

Funcionalidades: Formulario que permite al usuario registrarse a la aplicación.


Iteración 1 - Skecth No.2 – Registrar Usuario

58

Escena que representa: Pantalla de Visualizador del grafo.

Funcionalidades: Pantalla que le permite al usuario graficar los componentes y sus relaciones.


Iteración 1 - Skecth No.3 – Visualizador

59

Escena que representa: Pantalla de Conexiones.

Funcionalidades: Pantalla que le permite al usuario registrar una o muchas bases de datos.


Iteración 1 - Skecth No.4 – Conexiones

60


Escena que representa: Pantalla de Ingreso.



Iteración 2 - Skecth No.1 - Ingreso

61

Escena que representa: Pantalla de Registro para el usuario.



Iteración 2 - Skecth No.2 – Registrar Usuario

62





63





64






65

Escena que representa: Pantalla de Registro.



Iteración 3 - Skecth No.2 – Registro - Login

66





67





68






69

Escena que representa: Pantalla de Registro.



Iteración 4 - Skecth No.2 – Registro - Login

70





71




3.9 Pruebas y Evaluación de Software

Se utilizó las pruebas de caja negra, haciendo uso de la Técnica de Partición Equivalente, lo cual permitió diseñar casos de prueba que abarquen todas las funcionalidades del software y así evaluar las salidas esperadas de cada una de estas. Para la ejecución de pruebas se tuvieron en cuenta los siguientes tipos:

Pruebas de Aceptación: Con las pruebas de aceptación se busca determinar la aceptación o rechazo del software por parte del cliente. Pruebas Funcionales: Con las pruebas funcionales se busca asegurar el trabajo apropiado de los requisitos funcionales establecidos para el software, incluyendo la navegación, entrada de datos, procesamiento y obtención de resultados. Pruebas de Usabilidad: Por medio de las pruebas de usabilidad, se busca determinar qué tan fácil es de entender el software para el usuario.


72

Pruebas de Volumen: Con las pruebas de volumen se verificó que la aplicación funcione de manera adecuada bajo unos escenarios correspondientes como: Un número alto de componentes guardados, graficados y un número alto de bases de datos guardadas. En el proceso de ejecución las no conformidades se clasificaron de acuerdo al peso de los errores, de esta forma cada clasificación va acorde a la severidad del error. Esto nos permitió identificar de una forma más eficiente los errores que deben ser arreglados de forma inmediata. La clasificación de los errores se realizó de la siguiente forma: bloqueantes, funcionales y de presentación. 1. Bloqueantes: Hacen referencia a errores que detienen por completo la aplicación. 2. Funcionales: Hacen referencia a errores que impiden una funcionalidad establecida del software, pero el usuario puede continuar trabajando en otras funciones. 3. Presentación: Hace referencia a errores en la interfaz de usuario que no impiden la funcionalidad del software.

3.9.1 Casos de Prueba

Los casos de prueba que se identificaron para verificar el funcionamiento correcto del software se pueden apreciar en el (Anexo 1).

73

3.9.2 Resumen Pruebas Funcionales

Número de Casos de Prueba: 30

Figura 3.16 Resumen de Pruebas Funcionales.

Informe de Iteración 1: OK: 25 NOK: 5 PDTES: 0 En la primera iteración de la ejecución de los casos de prueba se pudieron evidenciar 25 casos OK, 5 casos NOK y 0 PDTES. Los 5 casos encontrados como NOK se clasificaron como Urgentes.

Casos NOK: Caso 11, Caso 15, Caso 18, Caso 21, Caso 27. Informe de Iteración 2: OK: 29 NOK: 1 PDTES: 0 En la segunda iteración de la ejecución de los casos de prueba se pudieron evidenciar 29 casos OK, 1 caso NOK y 0 PDTES. El caso encontrado como NOK se clasifico como Urgente. Casos NOK: Caso 27.

25

29 30

5

1 0

0

5

10

15

20

25

30

35

Iteración 1 Iteración 2 Iteración 3

Casos de prueba OK

Casos de prueba NOK

Casos de prueba PDTE

74

Informe de Iteración 3: OK: 30 NOK: 0 PDTES: 0 En la tercera iteración de la ejecución de los casos de prueba se pudieron evidenciar 30 casos OK, 0 NOK Y O PDTES.

3.10 Acceso a la Aplicación

Se realizó un video para mostrar el funcionamiento y uso de la aplicación desarrollada a manera de guía para los usuarios. El código fuente de la aplicación está alojado en el repositorio de Github el cual se encuentra a continuación:

Acceso 1. Video: https://youtu.be/T0HscWmBFfA

2. Repositorio (Github): https://github.com/Juan2293/ARtool

3.11 Estándares de ingeniería empleados durante el proyecto

Para el desarrollo del software se hizo uso de algunas técnicas de codificación que permitieron desarrollar un código más legible y entendible para otros desarrolladores. Técnicas Comentarios en el código:

Se hizo uso de comentarios en el código que facilitaran a los desarrolladores la comprensión del código. Dentro de estos comentarios se evitará hacer uso de caracteres especiales y también se evitará hacer uso de muchos comentarios.

Nombre de las clases: Todos los nombres establecidos en cada una de las clases deberán comenzar con la primera letra en mayúscula, seguido de letras minúsculas. Se nombrarán las clases con palabras simples, completas y que sean descriptivas para el desarrollador. Se evitará hacer uso de acrónimos o abreviaturas. (Se permite DAO, DTO). Interfaces: Todos los nombres establecidos en cada una de las interfaces deberán comenzar con la letra “I” en mayúscula, seguido de letras minúsculas. Se nombrarán las interfaces con palabras simples,

75

completas y que sean descriptivas para el desarrollador. Se evitará hacer uso de acrónimos o abreviaturas. (Se permite DAO, DTO). Métodos: Los métodos del software serán nombrados con verbos en infinitivo y deberán ser lo suficientemente descriptivos para el desarrollador, el nombre será una combinación de minúsculas y mayúsculas comenzando con la primera letra en minúscula. Se evitará hacer uso de caracteres especiales. Variables: Las variables del software deberán ser lo suficientemente descriptivos para el desarrollador, el nombre será una combinación de minúsculas y mayúsculas comenzando con la primera letra en minúscula. Se evitará hacer uso de caracteres especiales y de establecer nombres a las variables sin ningún significado funcional exceptuando los bucles. Se evitará asignar un mismo valor sobre muchas variables en una misma sentencia, ya que esto puede causar confusión.

Visibilidad de atributos de instancia y de clase: Todos los atributos de clase y de instancian deberán ser privados. Para acceder a los atributos de una clase se hará uso de los métodos “get” y “set” correspondientes a cada atributo. Declaraciones de variables: Se realizarán una declaración por línea, la inicialización se debe realizar al momento de la declaración a menos que su valor dependa de algún valor que deba ser calculado previamente.

Paquetes: Los nombres de los paquetes se escribirán en minúsculas y sin caracteres especiales. El prefijo del paquete corresponderá al dominio de la compañía al revés y además se agregará otro nivel extra dentro del paquete definiendo el nombre del módulo.

Valores de retorno: Todos los valores de retorno deberán ser simples y fáciles de comprender.

76

4. ANÁLISIS DE RESULTADOS

4.1 Análisis de Impactos 4.2 Utilización de herramientas 4.3 Análisis de diseño de componentes 4.4 Cumplimiento de Objetivos 4.5 Experiencia de diseño en ingeniería de software 4.6 Trabajos Futuros

77

4. ANÁLISIS DE RESULTADOS 4.1 Análisis de Impactos

La propuesta de ingeniería discutida en el presente documento tiene diferentes impactos en el escenario en el cual se contextualiza el problema. Estos impactos pueden ser analizados y discutidos desde las siguientes dimensiones o perspectivas: social, económica, técnica, e individual.

Social: Las empresas que se encargan del desarrollo de software y sus empleados se verán beneficiadas con la propuesta pues en consecuencia los empleados tendrán la posibilidad de identificar de una forma más fácil las ventajas y desventajas de la arquitectura de un proyecto de software, dando así la posibilidad de tomar decisiones para mejorar la calidad y el tiempo estimado de los de los proyectos que la empresa debe entregar.

Económico: La herramienta al permitir el análisis de la arquitectura de un software dará la posibilidad de identificar las ventajas o desventajas que se encuentran dentro de la arquitectura, permitiendo que se puedan tomar decisiones en edades tempranas o tardías del desarrollo disminuyendo así los posibles escenarios negativos que se puedan presentar. Esto permitirá que tanto la calidad como los tiempos estimados de entrega cumplan con las expectativas.

Técnica: Para el planteamiento de la presente propuesta se realizó una investigación sobre herramientas que permitieran la recuperación de la arquitectura de un software en donde se pudo observar que la mayoría de estas se encuentran obsoletas, ya que no han sido actualizadas en los últimos años. La presente propuesta dará la posibilidad de hacer uso de una herramienta actual que permita la recuperación de la arquitectura de software y además se diseñó la herramienta de tal forma que se puedan implementar nuevas funcionalidades y mejorar las que ya existen.

Individual: La presente propuesta tiene un impacto sobre los arquitectos de software, ya que la herramienta les apoya en los labores de análisis de la arquitectura sin incurrir en costos de licencias de productos comerciales. 4.2 Utilización de herramientas

Las herramientas tecnológicas que se usaron para el desarrollo del proyecto son las siguientes:

OrientDB: Gestor de base de datos orientada a grafos la cual permite ser una base de datos documental y de gestión gráfica. [14] Bootstrap: Framework que permite la creación de interfaces con CSS, y Javascript permitiendo que el desarrollo web front-end sea de una forma más rápida y más fácil. Este framework permite crear interfaces más agradables para el usuario. [15] Vis.js: Librería JavaScript usada especialmente para el visualizador del proyecto, esta librería da la posibilidad de gestionar una suma alta de datos dinámicos y posee una amplia cantidad de funcionalidades que permiten al usuario interactuar con el grafo. [16]

78

JavaScript: Lenguaje de programación interpretado el cual es utilizado principalmente para la parte del cliente, permitiendo realizar mejoras en la interfaz de usuario y páginas web dinámicas. [16] JQuery: Biblioteca multiplataforma de JavaScript, la cual simplifica la interacción con los elementos HTML, manejar eventos, generar animaciones y la agregación de interacciones con la técnica AJAX a las páginas web. [18] Spring Tool Suite: Entorno de desarrollo basado en Eclipse que permite desarrollar y desplegar aplicaciones Java.

4.3 Análisis de diseño de componentes

Durante el proceso de ingeniería de software realizado se utilizaron las siguientes vistas: Vista Física: La vista física se encarga de detallar el sistema desde la perspectiva de un ingeniero de sistemas, en la vista física se pueden observar los componentes de software y la relación que existen entre estos componentes. Esta vista también es conocida como vista de despliegue. Para la representación de esta vista se hizo uso del Diagramas de despliegue. Vista de procesos: La vista de procesos se encarga de explicar los comportamientos del sistema en tiempo de ejecución. Para la representación de esta vista se hizo uso del diagrama de actividad. Vista Lógica: La vista lógica se encarga de explicar la estructura y la funcionalidad que proporciona el sistema al usuario. Para la representación de esta vista se hizo uso del diagrama de clases. Vista de desarrollo: La vista de desarrollo se encarga de mostrar el sistema desde la perspectiva del programador. Para la representación de esta vista se hizo uso del diagrama de componentes.

4.4 Cumplimiento de Objetivos

A continuación se nombraran los objetivos que se plantearon y fueron cumplidos para el presente proyecto.

Diseñar y desarrollar un sistema que permita la recuperación de los componentes y relaciones de la arquitectura de un sistema de software.

Implementar la base de datos orientada a grafos que sirva como soporte funcional para la implementación de los casos de uso base de la herramienta.

Ejecutar los casos de prueba que validen los casos de uso implementados. Para el cumplimiento de los objetivos anteriormente mencionados se desarrollaron los siguientes casos de uso sobre la herramienta:

79

● La herramienta permita recuperar los componentes y las relaciones de arquitectura desde

una base de datos postgreSQL y almacenar dicha información en una base de datos orientada a grafos.

● La herramienta permita graficar la red compuesta por los componentes y relaciones

previamente almacenados de forma que se pueda visualizar la arquitectura como un grafo de componentes (nodos) y las dependencias (arcos) entre los mismos.

● La herramienta permita al usuario interactuar con los componentes que se grafiquen

visualizando la información relacionada con dichos componentes como nombre, tipo y grado de conectividad.

● La herramienta permita al usuario realizar consultas con filtros y condiciones de búsqueda

que faciliten la visualización de clúster dentro del grafo correspondiente a relaciones jerárquicas de dependencia entre componentes.

Adicionalmente sobre el proyecto se decidió plantear un nuevo objetivo el cual era primordial para la interoperabilidad de la herramienta:

La herramienta permita exportar la información obtenida para graficarla en otros visualizadores.

4.5 Experiencia de diseño en ingeniería de software

El objetivo de esta sección es explicar de una manera clara los conocimientos que se emplearon para realizar este proyecto, conocimientos que se adquirieron a lo largo del proceso de aprendizaje durante la carrera de Ingeniería de Sistemas, los cuales se mencionarán a continuación:

Capacidad para analizar la problemática de las escasas herramientas actuales que permiten el análisis de la arquitectura de un software e identificar una posible solución en el campo de ingeniera de sistemas.

Capacidad para desarrollar el presente proyecto haciendo uso de herramientas citadas en el punto 4.2 las cuales resultaron ser optimas en el desarrollo de la herramienta. Esto fue validado verificando que los casos de uso fueran cumplidos.

Capacidad para identificar, analizar, seleccionar e integrar técnicas de ingeniería de software para el desarrollo de la herramienta haciendo uso del modelo en espiral.

Se logró trabajar en un equipo de dos personas, asignando tareas e integrando dichas tareas, demostrando así la posibilidad de seguir un método de ingeniería de software de dos personas.

4.6 Trabajos Futuros

Como trabajos futuros se propone el soporte para otros gestores de bases de datos. En el visualizador se propone agregar nuevas medidas que permitan realizar otros tipos de análisis sobre el grafo, también se propone nuevas formas de visualización para el grafo y mejorar la interoperabilidad de la herramienta para que pueda exportar el grafo en otros formatos.

80

5. REFERENCIAS

81

5. REFERENCIAS [1] D. Pollet, S. Ducasse, L. Poyet, I. Alloui, S. Cimpan and H. Verjus, "Towards A Process-Oriented Software Architecture Reconstruction Taxonomy," 11th European Conference on Software Maintenance and Reengineering (CSMR'07), Amsterdam, 2007, pp. 137-148.

[2] C. R. L. Neto, M. P. S. Cardoso, C. v. F. G. Chavez and E. S. d. Almeida, "Initial Evidence for Understanding the Relationship between Product Line Architecture and Software Architecture Recovery," Components, Architectures and Reuse Software (SBCARS), 2015 IX Brazilian Symposium on, Belo Horizonte, 2015, pp. 40-49.

[3] J. Garcia, I. Ivkovic and N. Medvidovic, "A comparative analysis of software architecture recovery techniques," Automated Software Engineering (ASE), 2013 IEEE/ACM 28th International Conference on, Silicon Valley, CA, 2013, pp. 486-496.

[4] Software Architecture Recovery: http://es.slideshare.net/mircea.lungu/software-architecture-recovery-in-five-questions-presentation

[5] ArchStudio: http://isr.uci.edu/projects/archstudio/

[6] Bauhaus: http://www2.informatik.uni-stuttgart.de/iste/ps/bauhaus/demo/index.html

[7] Jmove: http://www.jmove.org/

[8] Softwarenaut: http://scg.unibe.ch/softwarenaut

[9] ArgoUML: http://argouml.tigris.org/

[10] Imagix4D: https://www.imagix.com/products/source-code-analysis.html

[11] Sonargraph: https://www.hello2morrow.com/products/sonargraph/architect9

[12] Lattix: http://lattix.com/product-overview [13] Neo4J: https://neo4j.com/

[14] Orientdb: http://orientdb.com/orientdb/

[15] Bootstap: http://getbootstrap.com/

[16] Vis.js: http://visjs.org/

[17] JavaScript: https://www.javascript.com/

[18] Jquery: https://jquery.com/

[19] Modelo en Espiral: http://www.ojovisual.net/galofarino/modeloespiral.pdf

[20] Stan4j: http://stan4j.com/

[21]Arquitectura de Software:http://www.icesi.edu.co/unicesi/2015/06/11/importancia-de-la-arquitectura-de-software-en-las-organizaciones/

http://lattix.com/product-overview

82

6. ANEXOS ANEXO 1. Casos de Prueba

Caso de Prueba No 1

ID CP-1

Nombre del Caso de Prueba: Gestionar formulario para Registrar usuario con información valida

Proceso o Funcionalidad: El sistema registra a un usuario en la base de datos.

Descripción: Realizar el registro de un usuario ingresando información permitida en el formulario para realizar la inscripción correspondiente de la aplicación.

ID de los Requisitos Relacionados:

Tipo de Prueba:

Funcional

Pasos para Ejecución:

Precondiciones: 1. URL de la aplicación

1. Ingresar a la aplicación 2. Seleccionar la opción de “Registro” 3. Diligenciar campo Login 4. Diligenciar campo Password 5. Diligenciar campo Nombre 6. Diligenciar campo Correo 7. Presionar “Registrar”

Variables de Entrada:

1. Login 2. Password 3. Nombre 4. Correo

Resultados Esperados: Verificar que el botón “Registrar”

- El usuario sea registrado en la base de datos

Observaciones:

Estado: OK Tipo de Error:

83

Caso de Prueba No 2

ID CP-2

Nombre del Caso de Prueba: Gestionar formulario para Registrar usuario sin información requerida

Proceso o Funcionalidad: El sistema no permite registra a un usuario en la base de datos.

Descripción: Realizar el registro de un usuario sin ingresar información en el formulario para realizar la inscripción.


Tipo de Prueba:

Funcional



1. Ingresar a la aplicación 2. Seleccionar la opción de “Registro” 3. No ingresar información en el campo “Login” 4. No ingresar información en el campo “Password” 5. No ingresar información en el campo campo

“Nombre” 6. No ingresar información en el campo “Correo” 7. Presionar “Registrar”


1. Registro 2. Login 3. Password 4. Correo

Resultados Esperados:

1. Verificar que el botón “Registrar” - El usuario no se registre en la base de datos - Se muestre un mensaje de error informando que

no se ha ingresado información en los campos obligatorios.

2. Verificar que los siguientes campos sean obligatorios:

- Registro - Login - Password - Correo

Observaciones:


84

Caso de Prueba No 3

ID CP-3

Nombre del Caso de Prueba: Gestionar formulario para Registrar usuario con información invalida

Proceso o Funcionalidad: El sistema no permite realizar el registro de un usuario que ya existe en la base de datos.

Descripción: Realizar el registro de un usuario ingresando información invalida en el formulario para realizar la inscripción


Tipo de Prueba:

Funcional



1. Ingresar a la aplicación 2. Seleccionar la opción de “Registro” 3. Diligenciar campo “Login” con información ya

registrada. 4. Diligenciar campo “Password” 5. Diligenciar campo “Nombre” con información ya

registrada. 6. Diligenciar campo “Correo” con información ya

registrada. 7. Presionar “Registrar”


1. Registro 2. Login 3. Password 4. Correo


Verificar que el botón “Registrar” - El usuario no se registre en la base de datos - Se muestre un mensaje de error informando que

los valores ingresados ya han sido registrados.

Observaciones:


Caso de Prueba No 4

ID CP-4

Nombre del Caso de Prueba: Gestionar Formulario para Realizar Logueo con información valida

85

Proceso o Funcionalidad: El sistema permite loguear a un usuario que ya se encuentre registrado en la base de datos.

Descripción: Realizar logueo de un usuario ingresando información valida en el formulario para realizar el logueo.


Tipo de Prueba:

Funcional


Precondiciones: 1. URL de la aplicación 2. Registrarse en la aplicación

1. Ingresar a la aplicación 2. Diligenciar campo “Login” con información valida. 3. Diligenciar campo “Password” con información

valida. 4. Presionar “Aceptar”

Variables de Entrada: 1. Login 2. Password


Verificar que el botón “Aceptar” - El sistema lleve al usuario a la página del

visualizador.

Observaciones:


Caso de Prueba No 5

ID CP-5

Nombre del Caso de Prueba: Gestionar formulario para Realizar Logueo sin ingresar información requerida

Proceso o Funcionalidad: El sistema no permite al usuario realizar el logueo si no se ingresa información.

Descripción: Realizar logueo de un usuario sin ingresar información en los campos obligatorios.


Tipo de Prueba:

Funcional



1. Ingresar a la aplicación

86

2. No ingresar información en el campo “Login”. 3. No ingresar información en el campo “Password” 4. Presionar “Aceptar”



1. Verificar que el botón “Aceptar” - El sistema muestre un mensaje de error

informando al usuario que debe diligenciar los campos obligatorios

2. Verificar que los siguientes campos sean obligatorios:

- Login - Password

Observaciones:


Caso de Prueba No 6

ID CP-6

Nombre del Caso de Prueba: Gestionar formulario para Realizar Logueo con información invalida.

Proceso o Funcionalidad: El sistema no permite al usuario loguearse si no se ingresa información de un usuario registrado.

Descripción: Realizar logueo de un usuario ingresando información invalida.


Tipo de Prueba:

Funcional



1. Ingresar a la aplicación 2. Diligenciar campo “Login” con información que no

se encuentre registrada. 3. Diligenciar campo “Password” con información

que no se encuentre registrada. 4. Presionar “Aceptar”

87



1. Verificar que el botón “Aceptar” - El sistema muestre un mensaje de error

informando al usuario que la información ingresada no es válida.

Observaciones:


Caso de Prueba No 7

ID CP-7

Nombre del Caso de Prueba: Gestionar formulario para Registrar base de datos con información valida

Proceso o Funcionalidad: El sistema permite a un usuario realizar el registro de una base de datos postgres.

Descripción: Realizar el registro de una base de datos postgres ingresando información permitida en el formulario para realizar la inscripción.


Tipo de Prueba:

Funcional




valida. 4. Presionar “Aceptar” 5. Presionar “Conexiones” 6. Diligencia campo “Nombre de Base de datos” con

información valida 7. Diligencia campo “Usuario de la base de datos”

con información valida. 8. Diligencia campo “Password de la base de datos”

con información valida. 9. Diligencia campo “URL de Conexión” con

información valida. 10. Presiona “Guardar”

88


1. Login 2. Password 3. Nombre de la base de datos 4. Usuario de la base de datos 5. Password de la base de datos 6. URL de Conexión


1. Verificar que el botón “Aceptar” - Los componentes se guarden en la base de datos

de OrientDB. - La base de datos guardada aparezca en la lista de

base de datos registrados.

Observaciones:


Caso de Prueba No 8

ID CP-8

Nombre del Caso de Prueba: Registrar base de datos con más de 100 tablas.

Proceso o Funcionalidad: El sistema permite a un usuario realizar el registro de una base de datos postgres que posee más de 100 tablas.

Descripción: Realizar el registro de una base de datos postgres que posee 100 tablas, ingresando información permitida en el formulario para realizar la inscripción.


Tipo de Prueba:

Volumen




valida. 4. Presionar “Aceptar” 5. Presionar “Conexiones” 6. Diligencia campo “Nombre de Base de datos” con

información valida 7. Diligencia campo “Usuario de la base de datos”

con información valida. 8. Diligencia campo “Password de la base de datos”

con información valida. 9. Diligencia campo “URL de Conexión” con

información valida.

89

10. Presiona “Guardar”




1. Verificar que el botón “Aceptar” - Los componentes se guarden sin problemas en la

base de datos de OrientDB. - La base de datos guardada aparezca en la lista de

base de datos registrados.

Observaciones:


Caso de Prueba No 9

ID CP-9

Nombre del Caso de Prueba: Gestionar Formulario para Registrar base de datos sin ingresar información requerida.

Proceso o Funcionalidad: El sistema no permite a un usuario realizar el registro de una base de datos postgres si no ingresa la información necesaria.

Descripción: Realizar el registro de una base de datos postgres sin ingresar información en los campos obligatorios del formulario para realizar la inscripción.


Tipo de Prueba:

Funcional




valida. 4. Presionar “Aceptar” 5. Presionar “Conexiones”

90

6. No ingresar información en el campo “Nombre de Base de datos”

7. No ingresar información en el campo “Usuario de la base de datos”.

8. No ingresar información en el campo “Password de la base de datos”.

9. No ingresar información en el campo “URL de Conexión”





1. Verificar que el botón “Guardar” - No se registre ninguna base de datos - Se muestre un mensaje de error informando al

usuario que no diligencio los campos obligatorios 2. Verificar que los campos obligatorios sean: - Nombre de la base de datos - Usuario de la base de datos - Password de la base de datos - URL de Conexión

Observaciones:


Caso de Prueba No 10

ID CP-10

Nombre del Caso de Prueba: Gestionar formulario para Registrar base de datos con información invalida.

Proceso o Funcionalidad: El sistema no permite a un usuario realizar el registro de una base de datos postgres si ingresa información inválida.

Descripción: Realizar el registro de una base de datos postgres ingresando información invalida en los campos obligatorios del formulario para realizar la inscripción.


Tipo de Prueba:

Funcional

91




valida. 4. Presionar “Aceptar” 5. Presionar “Conexiones” 6. Diligenciar campo “Nombre de Base de datos”. 7. Diligenciar campo “Usuario de la base de datos”

con información que no coincida con la base de datos de postgres.

8. Diligenciar campo “Password de la base de datos” con información que no coincida con la base de datos de postgres.

9. Diligenciar campo “URL de Conexión” con información que no coincida con la base de datos postgres.





1. Verificar que al presionar botón “Guardar” - No se registre ninguna base de datos - Se muestre un mensaje de error informando que

los valores ingresados son inválidos.

Observaciones:



ID CP-11

Nombre del Caso de Prueba: Graficar Red Completa

Proceso o Funcionalidad: El sistema permite al usuario graficar la red completa con todos los componentes y relaciones.

92

Descripción: Graficar la red completa de todos los componentes y relaciones de una de las bases de datos registrada por el usuario.


Tipo de Prueba:

Funcional


Precondiciones: 1. URL de la aplicación 2. Registrarse en la aplicación 3. Registrar una base de datos en la aplicación.


valida. 4. Presionar “Aceptar” 5. Presionar “Conexiones” 6. Seleccionar una de las bases de datos registradas. 7. Presionar Visualizador 8. Presiona “Graficar Red Completa”



1. Verificar se muestren todas las bases de datos registradas

2. Verificar que al presionar el botón “Graficar Red Completa”:

- Se pueda visualizar la red con todos los componentes y relaciones que se encuentren registrados en la base de datos.

Observaciones:



ID CP-12

Nombre del Caso de Prueba: Graficar Red Completa con más de 100 componentes

Proceso o Funcionalidad: El sistema permite al usuario graficar la red completa con más de 100 componentes.

Descripción: Graficar la red completa de todos los componentes y relaciones de una de las bases de datos registrada que posea más de 100 componentes.


Tipo de Prueba:

Volumen

93


Precondiciones: 1. URL de la aplicación 2. Registrarse en la aplicación 3. Registrar una base de datos con más de 100 tablas en la aplicación.


valida. 4. Presionar “Aceptar” 5. Presionar “Conexiones” 6. Seleccionar una de las bases de datos registradas

que posea más de 100 componentes. 7. Presionar “Visualizador” 8. Presiona “Graficar Red Completa”



1. Verificar que se muestren todas las bases de datos registradas

2. Verificar que al presionar el botón “Graficar Red Completa”:

- Se pueda visualizar la red con todos los componentes y relaciones.

Observaciones:



ID CP-13

Nombre del Caso de Prueba: Gestionar Visualización de Red Completa cuando no hay bases de datos registradas.

Proceso o Funcionalidad: El sistema no permite la visualización de la red completa.

Descripción: Validar que la visualización de la red completa de todos los componentes y relaciones no se muestre cuando no hay ninguna base de datos registrada.


Tipo de Prueba:

Funcional

Pasos para Ejecución: Precondiciones: 1. URL de la aplicación 2. Registrarse en la aplicación

94


valida. 4. Presionar “Aceptar” 5. Presionar “Conexiones” 6. No seleccionar ninguna base de datos. 7. Presionar “Visualizador” 8. Presiona “Graficar Red Completa”



1. Verificar que no se muestre ninguna base de datos registrada.

2. Verificar que al presionar el botón “Graficar Red Completa”

- No se visualice ningún grafo

Observaciones:



ID CP-14

Nombre del Caso de Prueba: Gestionar Visualización de Red Completa cuando no hay componentes registrados.

Proceso o Funcionalidad: El sistema no grafica ningún componente ni ninguna relación en el visualizador.

Descripción: Validar que la visualización de la red completa no se muestre cuando no hay ningún componente guardado dentro de la base de datos.


Tipo de Prueba:

Funcional




95

valida. 4. Presionar “Aceptar” 5. Presionar “Conexiones” 6. Seleccionar una base de datos que se encuentre

vacía 7. Presionar “Visualizador” 8. Presiona “Graficar Red Completa”



1. Verificar que se visualicen todas las bases de datos registradas.

2. Verificar que al presionar el botón “Graficar Red Completa”


Observaciones:



ID CP-15

Nombre del Caso de Prueba: Graficar PK Y FK

Proceso o Funcionalidad: El sistema permite al usuario graficar los componentes PK y FK y las relaciones que existen entre estos.

Descripción: Graficar los componentes que son tablas primarias y tablas foráneas y las relaciones existen entre estos de una base de datos registrada por el usuario.


Tipo de Prueba:

Funcional



1. Ingresar a la aplicación

96

2. Diligenciar campo “Login” con información valida. 3. Diligenciar campo “Password” con información

valida. 4. Presionar “Aceptar” 5. Presionar “Conexiones” 6. Seleccionar una de las bases de datos registradas. 7. Presiona “Graficar PK y FK”




2. Verificar que al presionar el botón “Graficar PK Y FK”:

- Se pueda visualizar los componentes que son tablas primarias y tablas foráneas que se encuentran dentro de la base de datos seleccionada y las relaciones que existen entre dichos componentes.

Observaciones:



ID CP-16

Nombre del Caso de Prueba: Gestionar Visualización de PK Y FK cuando no hay tablas primarias o tablas foráneas registrados en la base de datos.

Proceso o Funcionalidad: El sistema no permite la visualización del grafo.

Descripción: Validar que la visualización del grafo no se muestre cuando no hay ningún componente como tabla primaria o tabla foránea guardado dentro de la base de datos.


Tipo de Prueba:

Funcional




valida.

97

4. Presionar “Aceptar” 5. Presionar “Conexiones” 6. No seleccionar ninguna base de datos. 7. Seleccionar “Visualizador” 8. Presiona “Graficar PK Y FK”



1. Verificar que se muestren todas las bases de datos registradas.

2. Verificar que al presionar el botón “Graficar PK Y FK”


Observaciones:



ID CP-17

Nombre del Caso de Prueba: Gestionar Visualización de PK Y FK cuando no hay bases de datos registradas.

Proceso o Funcionalidad: El sistema no permite la visualización de las PK Y FK.

Descripción: Validar que la visualización grafo no se muestre cuando no hay ninguna base de datos registrada.


Tipo de Prueba:

Funcional




valida. 4. Presionar “Aceptar” 5. Presionar “Conexiones” 6. No seleccionar ninguna base de datos.

98

7. Presionar “Visualizador” 8. Presiona “Graficar PK Y FK”




2. Verificar que al presionar el botón “Graficar PK Y FK”


Observaciones:



ID CP-18

Nombre del Caso de Prueba: Graficar Tablas Y Vistas

Proceso o Funcionalidad: El sistema permite al usuario graficar los componentes Tablas y Vistas y las relaciones que existen entre estos.

Descripción: Graficar los componentes que son Tablas y Vistas que se encuentren dentro de la base de datos registrada por el usuario y las relaciones existen entre dichos componentes.


Tipo de Prueba:

Funcional




valida. 4. Presionar “Aceptar” 5. Presionar “Conexiones” 6. Seleccionar una de las bases de datos registradas. 7. Presionar “Visualizador” 8. Presiona “Graficar Tablas y Vistas”

99




2. Verificar que al presionar el botón “Graficar Tablas Y Vistas”:

- Se pueda visualizar los componentes y relaciones de las tablas y vistas que se encuentran ligados a la base de datos seleccionada.

Observaciones:



ID CP-19

Nombre del Caso de Prueba: Gestionar Visualización de Tablas Y Vistas cuando no hay Tablas o Vistas registradas en la base de datos.

Proceso o Funcionalidad: No se visualice ningún grafo.

Descripción: Validar que la visualización del grafo no se muestre cuando no hay ningún componente como Tablas o Vistas guardadas dentro de la base de datos.


Tipo de Prueba:

Funcional




valida. 4. Presionar “Aceptar” 5. Presionar “Conexiones” 6. No seleccionar ninguna base de datos. 7. Presionar “Visualizador” 8. Presiona “Graficar Tablas Y Vistas”


100



2. Verificar que al presionar el botón “Graficar Tablas Y Vistas”


Observaciones:



ID CP-20

Nombre del Caso de Prueba: Gestionar Visualización de Tablas Y Vistas cuando no hay bases de datos registradas.

Proceso o Funcionalidad: El sistema no permite la visualización de las Tablas y Vistas. El sistema no muestra ninguna base de datos registrada.



Tipo de Prueba:

Funcional




valida. 4. Presionar “Aceptar” 5. Presionar “Conexiones” 6. No seleccionar ninguna base de datos. 7. Presionar “Visualizador” 8. Presiona “Graficar Tablas y Vistas”



1. Verificar que no se muestre ninguna base de datos.

2. Verificar que al presionar el botón “Graficar Tablas y Vistas”


Observaciones:

101



ID CP-21

Nombre del Caso de Prueba: Graficar Tablas Y Funciones

Proceso o Funcionalidad: El sistema permite al usuario graficar los componentes Tablas y Funciones y las relaciones que existen entre estos.

Descripción: Graficar los componentes que son Tablas y Funciones que se encuentren dentro de la base de datos registrada por el usuario y las relaciones existen entre dichos componentes.


Tipo de Prueba:

Funcional




valida. 4. Presionar “Aceptar” 5. Presionar “Conexiones” 6. Seleccionar una de las bases de datos registradas. 7. Presionar “Visualizador” 8. Presiona “Graficar Tablas y Funciones”




2. Verificar que al presionar el botón “Graficar Tablas Y Funciones”:

- Se pueda visualizar los componentes y relaciones de las tablas y funciones que se encuentran ligados dentro de la base de datos seleccionada.

Observaciones:


102


ID CP-22

Nombre del Caso de Prueba: Gestionar Visualización de Tablas Y Funciones cuando no hay Tablas o Funciones registradas en la base de datos.

Proceso o Funcionalidad: No se visualice ningún grafo.

Descripción: Validar que la visualización del grafo no se muestre cuando no hay ningún componente como Tablas o Funciones guardadas dentro de la base de datos.


Tipo de Prueba:

Funcional




valida. 4. Presionar “Aceptar” 5. Presionar “Conexiones” 6. Seleccionar base de datos vacia. 7. Presionar “Visualizador” 8. Presiona “Graficar Tablas Y Vistas”




2. Verificar que al presionar el botón “Graficar Tablas Y Funciones”

- No se visualice ningún grafo -

Observaciones:



ID CP-23

103

Nombre del Caso de Prueba: Gestionar Visualización de Tablas Y Funciones cuando no hay bases de datos registradas.

Proceso o Funcionalidad: El sistema no permite la visualización de las Tablas y Funciones.



Tipo de Prueba:

Funcional




valida. 4. Presionar “Aceptar” 5. Presionar “Conexiones” 6. No seleccionar ninguna base de datos. 7. Presionar “Visualizador” 8. Presionar “Graficar Tablas y Funciones”




2. Verificar que al presionar el botón “Graficar Tablas y Funciones”


Observaciones:



ID CP-24

Nombre del Caso de Prueba: Buscar nodo existente

Proceso o Funcionalidad: El sistema permite buscar un nodo dentro del grafo.

Descripción: Validar que la visualización del nodo ingresado se muestre cuando el componente existe.

104


Tipo de Prueba:

Funcional




valida. 4. Presionar “Aceptar” 5. Presionar “Conexiones” 6. Seleccionar base de datos registrada. 7. Presionar “Visualizador” 8. Presionar “Graficar Red Completa” 9. Presionar en el buscador y ingresar nombre del

nodo existente.



1- Verificar que se muestren las bases de datos registradas

2- Verificar que al presionar el botón “Graficar Red Completa”

- Se visualice el grafo 3- Verificar que al ingresar el nombre del nodo

existente el visualizador lo muestre.

Observaciones:



ID CP-25

Nombre del Caso de Prueba: Buscar nodo no existente

Proceso o Funcionalidad: El sistema no muestra ningún nodo dentro del grafo.

Descripción: Validar que la visualización del nodo ingresado no se muestre.


Tipo de Prueba:

Funcional

105




valida. 4. Presionar “Aceptar” 5. Presionar “Conexiones” 6. Seleccionar base de datos registrada. 7. Presionar “Visualizador” 8. Presionar “Graficar Red Completa” 9. Presionar en el buscador y ingresar nombre de un

nodo no existente.





- Se visualice el grafo 3- Verificar que al ingresar el nombre del nodo el

visualizador no lo muestre.

Observaciones:



ID CP-26

Nombre del Caso de Prueba: Cambiar layout de grafo a modo jerárquico

Proceso o Funcionalidad: El sistema cambia el layout del grafo al modo jerárquico.

Descripción: Validar que la visualización del grafo sea con el layout jerárquico.


Tipo de Prueba:

Funcional



106


valida. 4. Presionar “Aceptar” 5. Presionar “Conexiones” 6. Seleccionar base de datos registrada. 7. Presionar “Visualizador” 8. Presionar “Graficar Red Completa” 9. Presionar “Layour jerarquico”





- Se visualice el grafo 3- Verificar que el layout del grafo cambie a un modo

jerarquico.

Observaciones:



ID CP-27

Nombre del Caso de Prueba: Cambiar layout de grafo a modo random

Proceso o Funcionalidad: El sistema cambia el layout del grafo al modo random.

Descripción: Validar que la visualización del grafo sea con el layout random.


Tipo de Prueba:

Funcional




valida. 4. Presionar “Aceptar”

107

5. Presionar “Conexiones” 6. Seleccionar base de datos registrada. 7. Presionar “Visualizador” 8. Presionar “Graficar Red Completa” 9. Presionar “Layour random”





- Se visualice el grafo 6- Verificar que el layout del grafo cambie a un modo

random.

Observaciones:



ID CP-28

Nombre del Caso de Prueba: Graficar Tablas y Triggers.

Proceso o Funcionalidad: El sistema permite al usuario graficar los componentes Tablas y Triggers y las relaciones que existen entre estos.

Descripción: Graficar los componentes que son Tablas y Triggers que se encuentren dentro de la base de datos registrada por el usuario y las relaciones existen entre dichos componentes


Tipo de Prueba:

Funcional




valida. 5. Presionar “Aceptar” 6. Presionar “Conexiones”

108

7. Seleccionar una de las bases de datos registradas. 8. Presiona “Graficar Tablas y Triggers”




2. Verificar que al presionar el botón “Graficar Tablas y Triggers”:

- Se pueda visualizar los componentes que son tablas y triggers que se encuentran dentro de la base de datos seleccionada y las relaciones que existen entre dichos componentes.

Observaciones:



ID CP-29

Nombre del Caso de Prueba: Gestionar Visualización de Tablas Y Triggers cuando no hay tablas o triggers registrados en la base de datos.

Proceso o Funcionalidad: El sistema no permite la visualización del grafo.

Descripción: Validar que la visualización del grafo no se muestre cuando no hay ningún componente como tabla y trigger guardado dentro de la base de datos.


Tipo de Prueba:

Funcional




valida. 4. Presionar “Aceptar” 5. Presionar “Conexiones” 6. No seleccionar ninguna base de datos. 7. Seleccionar “Visualizador” 8. Presiona “Graficar Tablas y Triggers”

109




2. Verificar que al presionar el botón “Graficar Tablas y Triggers”


Observaciones:



ID CP-30

Nombre del Caso de Prueba: Gestionar Visualización de tablas y triggers cuando no hay bases de datos registradas.

Proceso o Funcionalidad: El sistema no permite la visualización de las tablas y triggers.



Tipo de Prueba:

Funcional




valida. 4. Presionar “Aceptar” 5. Presionar “Conexiones” 6. No seleccionar ninguna base de datos. 7. Presionar “Visualizador” 8. Presiona “Graficar Tablas y Triggers”


110



2. Verificar que al presionar el botón “Graficar Tablas y Triggers”


Observaciones:


trabajo de grado herramienta para el análisis de

Documents