Para dar solución al problema planteado se define el objetivo general: Desarrollar un componente de búsqueda dinámica utilizando estructuras JSON en PostgreSQL de manera que contribuya a un mayor rendimiento y estandarización de los reportes para los proyectos CEGEL. Implementar un componente de búsqueda dinámica para contribuir a una mayor eficiencia y estandarización de los informes de los proyectos CEGEL.
FUNDAMENTACIÓN TEÓRICA DEL COMPONENTE PARA BÚSQUEDAS DINÁMICAS
- Conceptos asociados a la investigación
- Sistemas homólogos
- Metodología de desarrollo desoftware
- Arquitectura de software
- HerramientasCASE
- Visual Paradigm for UML
- Lenguaje de programación
- Java
- JavaScript
- Lenguaje de Consulta Estructurada
- Entorno de desarrollointegrado
- Netbeans 8.2
- Sistema de Gestor de Base de datos
- PostgreSQL 11.0
- Control de versionesGit
- Conclusionesparciales
El método Hipotético-Deductivo que analiza y define la idea a defender, se investiga o contrasta con el desarrollo de la investigación, para llegar a conclusiones concretas. El modelado hace diagramas necesarios en el proceso de desarrollo de software, hace una representación abstracta de la solución que por lo tanto facilita su desarrollo.
ANÁLISIS, DISEÑO E IMPLEMENTACIÓN DEL COMPONENTE PARA BÚSQUEDAS
Descripción de la propuesta de solución
Además, contiene implementación de modelos y gestión de valor para lograr el correcto funcionamiento del servicio de búsqueda dinámica. Teniendo esto en cuenta, se listará toda la nomenclatura de todos los datos o simplemente se podrán aplicar algunos criterios de búsqueda para un filtrado más eficiente. Una vez que cada uno de estos datos se captura en el componente, el servicio de búsqueda dinámica puede usarlos indistintamente.
Finalmente, la propuesta incluye el desarrollo de un servicio que permitirá realizar búsquedas dinámicas sobre los datos incluidos en el modelo previamente cargado y correspondientes al proyecto en cuestión. Además, este servicio define una estructura JSON, tanto para recibir los elementos necesarios para simplificar el objeto de búsqueda, como para responder con la información recibida.
Requisitos de software
- Requisitos funcionales
- Requisitos no funcionales
RF/1 Agregar conexión El sistema permite al usuario agregar una nueva conexión a la base de datos. RF/26 Eliminación de tipos de datos El sistema permite al usuario eliminar tipos de datos seleccionados. El sistema permite al usuario agregar operadores a los atributos según el tipo de datos que contenga.
El sistema permite al usuario cambiar los operadores a las propiedades de acuerdo al tipo de datos que contienen. El sistema permite asignar a cada operador teniendo en cuenta el tipo de datos que posee.
Historias de usuario
Descripción: Funcionalidad que permite agregar una nueva conexión a elección del administrador de la base de datos por parte del usuario. Nombre del enlace: un campo de texto o numérico donde el usuario especifica un nombre para el nuevo enlace. Host: campo numérico donde se escribe la IP de la base de datos a la que el usuario decidió conectarse.
Puerto: campo numérico donde se registra el puerto de la base de datos al que el usuario decidió conectarse. Datos iniciales: campo de texto donde se registra el nombre de la base de datos.
Arquitectura del sistema
Business con las capas Business Entity y Business Component, y en otro nivel físico la capa Data Access que interactúa con un servidor donde se encuentra el SGBD y la base de datos. Esto enviará mensajes a los objetos en esta capa comercial o intermedia, que responderán directamente o mantendrán un diálogo con la capa de la base de datos, que proporcionará los datos que se enviarán en respuesta a la capa de presentación. Se puede decir que es el que se le presenta al usuario, también llamado formulario o interfaz de presentación, captura los datos del usuario en el formulario e invoca la capa de negocio, transmitiendo el requerimiento del usuario, ya sea de almacenamiento, edición o recuperación del información para la respectiva consulta (Research Gate, 2014).
Estos objetos a menudo se denominan objetos comerciales y son los que contienen el rango normal de constructores, métodos para establecer y obtener variables, métodos para realizar cálculos y métodos, generalmente privados, para comunicarse con la capa de la base de datos. Es en esta capa donde se reciben las solicitudes del usuario y se envían las respuestas después del proceso, a pedido de la capa de presentación.
Patrones de diseño
- Patrones GRASP (General Responsibility Assignment Software Patterns)
- Patrones GoF (Gang of Four)
Este patrón se observa en las clases de gestión empresarial y las clases de interfaz de presentación (Docsity, 2017). Cohesión alta: este modelo tiene como objetivo asignar responsabilidades para que la cohesión se mantenga alta. Este modelo se muestra en las clases de interfaz de presentación y los administradores de negocios asegurando que en ellos solo existan las características y funcionalidades necesarias (Docsity, 2017). Instancia única o Singleton: permitirá crear una instancia única de las clases que se necesiten (Docsity, 2017), en la siguiente figura se muestra la clase de entidad Dresumen.java, una de las.
Decorador: el objetivo principal de este patrón es agregar de forma dinámica y transparente responsabilidades a objetos específicos sin afectar a otros objetos. Este patrón proporciona más flexibilidad que la herencia estática y evita que las clases superiores en la jerarquía se sobrecarguen con funcionalidad y complejidad.
Diagrama de clases dediseño
Las asociaciones entre dos clases están representadas por una línea que las une y pueden contener una serie de elementos gráficos que expresan ciertas características de la asociación (Pressman, 2010). El diagrama anterior muestra la relación entre las clases involucradas en la implementación de la propuesta de solución, las cuales están organizadas en paquetes que corresponden a la arquitectura del componente.
Modelo de datos
A continuación se muestra el modelo de datos de la solución propuesta, el cual es un diseño basado en conceptos y la semántica de cómo organizar la información en modelos de datos relacionales, el modelo de datos obtenido tiene un total de 10 tablas, las cuales son: report.natribute;. La descripción de las tablas muestra de forma sintetizada el objetivo que persigue la representación en la base de datos de cada entidad. La Tabla 4 documenta las tablas de la base de datos relacionadas con la descripción de los requisitos analizados.
Ndata Entidad que almacena la información sobre los tipos de datos asociados a los atributos.
Diagrama de despliegue
Consistirá en una computadora cliente que representa las computadoras que los usuarios utilizarán para comunicarse con la aplicación de escritorio instalada que se comunicará con cada uno de los servidores de base de datos de cada proyecto a través de la extensión ODBC.
Estándares decodificación
Las clases de lógica empresarial de acceso a datos comienzan con el acrónimo Rtry. Los números están permitidos en los nombres de las funciones, pero no se recomiendan en la mayoría de los casos. Cuando el nombre de una función consta de más de una palabra, la primera letra de cada nueva palabra debe estar en mayúscula.
Los nombres de funciones deben ser lo suficientemente significativos para describir su propósito y comportamiento. Los nombres de las variables comienzan con una letra minúscula, pero si tienen más de una palabra, cada nueva palabra debe comenzar con una letra mayúscula.
Conclusiones parciales
VALIDACIÓN DEL COMPONENTE PARA BÚSQUEDAS DINÁMICAS
Validación de requisitos
Para medir la calidad de la especificación de requisitos de software, se aplica la métrica Specification Quality (CE). donde Nui es el número de requisitos para los cuales todos los evaluadores tuvieron interpretaciones idénticas. En el caso de los requisitos obtenidos, cinco interpretaciones produjeron contradicciones (RF2, RF4, RF7, RF8 y RF11).
Teniendo en cuenta el resultado anterior, igual a 0,91, se concluye que en el 91% de las solicitudes se recibió una sola interpretación. Como parte del proceso de verificación de requisitos funcionales, se crearon casos de prueba para cada requisito.
Métricas para la evaluación del diseño
Al cliente se le mostró un modelo factible que le permitió tener una vista previa de cómo se vería este componente en los sistemas y al interactuar con él se verificó la satisfacción y aprobación del cliente, estos prototipos fueron aprobados satisfactoriamente. producto del trabajo de la disciplina Requerimiento, se detallan los prototipos tomados para la propuesta de solución para el caso de la solicitud que se toma como ejemplo en este documento. Relación entre clases: el resultado de aplicar la métrica de relación entre clases (RC) viene dado por el número de relaciones de uso que se establecen entre una clase y otras clases existentes. Complejidad de mantenimiento: un aumento en RC significa un aumento en la complejidad de mantenimiento de la clase.
Reutilización: un aumento de RC implica una disminución del grado de reutilización de la clase. Número de Pruebas: Un aumento en RC implica un aumento en la cantidad de pruebas necesarias para probar una clase.
Validación del diseño
Estos resultados demuestran la calidad del diseño de la solución propuesta, ya que con bajos niveles de responsabilidad y complejidad, junto con un alto nivel de reutilización de clases, se facilita enormemente la implementación del componente como resultado de la solución propuesta. Por otro lado, se muestran las medidas de parámetros de calidad obtenidas tras aplicar la métrica RC para formar una clase de componente de búsqueda dinámica, teniendo en cuenta las categorías por atributos y los criterios de evaluación de tablas descritos en el apartado anterior. Como se puede observar en la figura, el acoplamiento tiene un nivel bajo, por lo que existen pocas dependencias entre clases, lo que resulta en una alta probabilidad de reutilización.
También se puede observar que existe un bajo nivel de complejidad de mantenimiento, por lo que al momento de optimizar métodos y otras operaciones, no es necesario realizar una gran cantidad de pruebas, lo que minimiza el tiempo de implementación y prueba del componente propuesto.
Validación de la implementación
- Pruebas internas
- Pruebas funcionales
Utilizando este método, es posible desarrollar pruebas que garanticen la ejecución, al menos una vez, de caminos independientes7 (Pressman, 2010). Para obtener los casos de prueba de la técnica elegida, se debe construir el diagrama de flujo correspondiente al código del método buscarattributor(). Partición de equivalencia: esta técnica divide el dominio de entrada de un programa en clases de datos de las que se pueden derivar casos de prueba.
El método intenta definir un caso de prueba que detecte ciertas clases de errores, reduciendo así el número total de casos de prueba que necesitan desarrollarse. Es una técnica de diseño de casos de prueba que complementa la partición de equivalencia.
Conclusiones parciales
Citado el: 27/11/2019.] https://searchdatacenter.techtarget.com/es/definicion/SQL-o-language-of-structured-queries. Esta encuesta se considera anónima y personal, dirigida a los especialistas del proyecto CEGEL, que han interactuado en la elaboración de productos y soluciones de software, cuyo objetivo es la gestión de temas. El objetivo de la encuesta es determinar el tiempo promedio que suelen tomar estos especialistas para realizar las actividades involucradas, por lo que el criterio de su desempeño es muy importante para el mejoramiento de la investigación.
