Diseño e Implementación de una
Herramienta CASE para la Generación de
Capas de Acceso a Datos .Net
Trabajo de Grado Especialización
María Fernanda Rodríguez Zambrano Pablo Yanod Márquez Restrepo Especialización en Ingeniería de Software
Facultad de Ingeniería
Diseño e Implementación de una
Herramienta CASE para la Generación de
Capas de Acceso a Datos .Net
Memoria que presenta para optar al título de Especialista en Ingeniería de Software María Fernanda Rodríguez Zambrano
Pablo Yanod Márquez Restrepo
Dirigida por el Doctor Sandro Javier Bolaños Castro
Revisado por la M. Sc. Nancy Yaneth Gelvez García
Especialización en Ingeniería de Software Facultad de Ingeniería
Universidad Distrital Francisco José de Caldas
Al duque de Béjar y
Agradecimientos
A todos los que la presente vieren y entendieren. Inicio de las Leyes Orgánicas. Juan Carlos I
Agradezco este trabajo a la suma de mis historias y múltiples anécdotas con sus respectivos actores principales y secundarios; permitiendo el desarrollo de un camino a nuevo conocimiento y mejores practicas en mi labores, también a quienes obstaculizaron mi andar para incentivar mi ingenio y motivarlo a la creatividad. Agradezco a mi mami por apoyarme dentro de sus capacidades y en cada oportunidad en la que encontró un espacio. Por ultimo y por ende más especial agradezco a mi pareja al recorrer este trayecto a mi lado creciendo para un futuro con más oportunidades.
María Fernanda Rodríguez Zambrano
Al culminar este trabajo no puedo menos que pensar en todo aquello que sumó a que este momento se de. En esa larga lista de personas que me han apoyado debo destacar a mi padre, quién no solo con su ejemplo me oriento en la vía académica sino que fue el primero en darme una lección de programación sin estar vinculado con la ingeniería de sistemas, a mi madre por enseñarme a nunca rendirme, a Julián y Eliseo, por haberse embarcado en tantas empresas conmigo, a doña suegra por ese apoyo más allá de lo moral y sobre todo a mi encantadora esposa quien prácticamente me arrastró para ingresar a la especialización y día a día se aseguró que asistiera a clases.
Pablo Yanod Márquez Restrepo
Resumen
La simplicidad llevada al extremo, se convierte en elegancia. Jon Franklin
La meta general de este trabajo fue el desarrollo e implementación de una herramienta CASE1 para la generación de capas de acceso a datos en .Net para la empresa Soluciones
Lógicas Yayan Gaia con el n de estandarizar la codicación de la capa de acceso a datos y disminuir los tiempos de desarrollo en dicha empresa.
Para el diseño y desarrollo del producto se emplearon diversas metodologías que permitie-ron alcanzar los objetivos planteados entregando la documentación acorde a lo convenido con la empresa. También se aplicó patrones como puente y estrategia sobre la misma, permitiendo codicar la herramienta para que sea fácil de mantener y extensible a nuevas funcionalida-des como la implementación de motores de bases de datos diferentes a los entregados en esta versión y nuevos lenguajes de programación.
Se realizaron las pruebas correspondientes sobre el aplicativo y las mediciones pertinentes de los tiempos de la herramienta contra aplicativos similares en el mercado.
Palabras clave
Diseño de Software, Implementación, Capa de Acceso a Datos, Modelo de desarrollo, Mapeo Objeto-Relacional, Framework, Modelo Entidad Relación, Casa de software, Tiempo Desarrollo
1Computer Aided Software Engineering
Abstract
Simplicity, carried to an extreme, becomes elegance. Jon Franklin
The overall goal of this work was the development and implementation of a tool CASE for the generation of data access layers in .Net for the company Soluciones Logicas Yayan Gaia with the nal purpose to standardize the coding of the data access layer and decrease the times of development in the company.
For the design and development of the product were use several methodologies and that allowed get the stated objectives by delivering the documentation according to the agreed with the company. Also applies patterns such as bridge and strategy over it, allowing encode the tool to be easy to maintain and extendable to new functionalities like the implementation of dierent database engines from the ones delivered in this version and new programming languages.
The corresponding tests were carried out on the application and the measurements Of the times of the tool in the market.
Keywords
Software Desing, Implemention, Data Access Layer, Development Model, Object Relationla mapping, Framework, Relatonship Entity Model, Software Factory, Development Time
Índice
Agradecimientos ix
Resumen xi
Abstract xiii
Introducción xxv
I Fundamentación de la Investigación 1
1. Descripción de la Investigación 3
1.1. Denición del Problema . . . 3
1.1.1. Descripción . . . 3
1.1.2. Formulación . . . 4
1.2. Hipótesis . . . 4
1.3. Objetivos . . . 4
1.3.1. Objetivo General . . . 4
1.3.2. Objetivos Especícos . . . 4
1.4. Justicación . . . 5
1.4.1. Social . . . 5
1.4.2. Ecológica . . . 5
1.4.3. Tecnológica . . . 5
2. Marco de Referencia 7 2.1. Marco Teórico . . . 7
2.1.1. ADO .Net DataReaders Y DataAdapters . . . 8
2.1.2. Nhibernate . . . 8
2.1.3. Entity Framework . . . 9
2.1.4. Dapper . . . 11
2.1.5. Archimate . . . 11
3. Aspectos Metodológicos 19 3.1. Tipo de Estudio . . . 19
3.2. Método de investigación . . . 19
3.2.1. Metodología de Desarrollo . . . 20
3.2.2. Métrica Asociada al Producto . . . 21
III Cierre de la investigación 119
8. Conclusiones 121
8.1. Resultados y discusión . . . 121
8.1.1. Tiempo de ejecución . . . 121
8.1.2. Líneas de código . . . 124
8.1.3. Matenibilidad . . . 125
8.1.4. Resultados . . . 125
8.2. Vericación, contraste y evaluación de los objetivos . . . 126
8.3. Síntesis del modelo propuesto . . . 126
8.3.1. Trabajos de Investigación futuros . . . 127
IV Apéndices 129
A. Formato IEEE830 131
B. Manual del Usuario 143
Bibliografía 201
Índice de guras
2.1. Tipos de Trabajo EF . . . 10
2.2. Correspondencia entre ArchiMate y TOGAF . . . 12
2.3. Organigrama . . . 16
4.1. Punto de vista Organización . . . 26
4.2. Punto de vista Cooperación de Actor . . . 27
4.3. Punto de vista Función de Negocio . . . 28
4.4. Punto de vista Proceso de Negocio . . . 29
4.5. Punto de vista Cooperación de Proceso de Negocio . . . 30
4.6. Punto de vista Producto . . . 31
4.7. Punto de vista Uso de Aplicación . . . 32
4.8. Punto de vista Comportamiento de Aplicación . . . 33
4.9. Punto de vista Cooperación de Aplicación . . . 34
4.10. Punto de vista Estructura de Aplicación . . . 35
4.11. Punto de vista Infraestructura . . . 36
4.12. Punto de vista Uso de Infraestructura . . . 36
4.13. Punto de vista Implementación y Despliegue . . . 37
4.14. Punto de vista estructura de información . . . 38
4.15. Punto de vista realización del servicio . . . 39
4.16. Punto de vista niveles . . . 40
4.17. Punto de vista Stakeholder . . . 41
4.18. Caso de estudio punto de vista Realización de Objetivos . . . 42
4.19. Caso de estudio punto de vista Contribución de objetivos . . . 43
4.20. Caso de estudio punto de vista Principios . . . 44
4.21. Caso de estudio punto de vista Realización de Requerimientos . . . 45
4.22. Punto de vista Motivacional . . . 46
4.23. Punto de vista Proyecto . . . 47
4.24. Punto de vista Migracion . . . 47
4.25. Punto de vista Migración e Implementación . . . 48
5.1. Diagrama de Casos de uso - Arquitecto de información . . . 50
5.2. Diagrama de Casos de uso - Desarrollador . . . 51
5.3. Diagrama de Componentes . . . 52
5.4. Diagrama de Secuencia . . . 52
5.5. Diagrama de clases - Denición API . . . 54
5.6. Diagrama de clases - Implementación API . . . 55
5.7. Diagrama de clases - Engine ADO - Manager . . . 56
5.8. Diagrama de clases - Engine ADO - Utils . . . 57
5.9. Diagrama de clases - Engine ADO - Implementación . . . 58
5.10. Diagrama de clases - DAL - DatabaseManager . . . 60
5.11. Diagrama de clases - DAL - Managers . . . 61
5.12. Diagrama de clases - DAL - DataSet . . . 62
5.13. Diagrama de clases - DAL - Objetos tipados 1 . . . 63
5.14. Diagrama de clases - DAL - Objetos tipados 2 . . . 64
6.1. Estructura de almacenamiento de la conguración de la capa de acceso a datos 66 6.2. Interface gráca - Inicio . . . 110
6.3. Interface gráca - Formulario MDI . . . 111
6.4. Interface gráca - Diseñador . . . 111
6.5. Interface gráca - Esquemas . . . 112
6.6. Interface gráca - Filtros . . . 112
6.7. Interface gráca - Procedimientos almacenados . . . 113
8.1. Tiempo ejecución Init() . . . 122
8.2. Tiempo ejecución SELECT . . . 122
8.3. Tiempo ejecución INSERT . . . 123
8.4. Tiempo ejecución UPDATE . . . 123
Índice de Tablas
2.1. Accionistas. . . 15
2.2. Productos. . . 17
2.3. Servicios. . . 18
6.1. Cong. . . 67
6.2. Connecions. . . 67
6.3. Schemas. . . 67
6.4. GenericTypes. . . 68
6.5. Objects. . . 68
6.6. SpReturns. . . 68
6.7. Filters. . . 69
6.8. FilterFields. . . 69
6.9. FieldRelations. . . 69
6.10. Fields. . . 70
7.1. Caso de Prueba 01 . . . 116
7.2. Caso de Prueba 02 . . . 116
7.3. Caso de Prueba 03 . . . 117
8.1. Líneas de código . . . 125
8.2. Mantenibilidad del código fuente . . . 125
8.3. Resultados . . . 126
Listings
Code/IExtend.cs . . . 70 Code/IMapper.cs . . . 70 Code/ICodier.cs . . . 71 Code/IConnection.cs . . . 71 Code/ExtendManager.cs . . . 71 Code/MapperManager.cs . . . 74 Code/CodierManager.cs . . . 81 Code/IConnectionAdo.cs . . . 81 Code/Database.cs . . . 82 Code/DatabaseFactory.cs . . . 84 Code/DbPruebaDatabaseManager.cs . . . 84 Code/DbPruebaDatabaseManager.Designer.cs . . . 85 Code/Example.cs . . . 109
Introducción
La diferencia entre la teoría y la práctica es que, en teoría, no hay diferencia entre la teoría y la práctica. Richard Moore, desarrollador de KDE
En el desarrollo de sistemas transaccionales para clientes empresariales, unos de los puntos críticos corresponden al almacenamiento de la información y gran cantidad de los esfuerzos de desarrollo se orientan a la interacción entre los módulos cliente y los servidores de bases de datos.
Este es el caso de SLYG2, una casa de desarrollo de software que divide sus esfuerzos entre
los desarrollos a la medida y el soporte a productos de software propios, donde se requiere aumentar la productividad de su equipo de desarrollo estandarizando la codicación de la capa de acceso a datos y disminuyendo el esfuerzo requerido para la generación de la misma.
En el presente trabajo se plantea el desarrollo de una herramienta CASE que automatice la generación del código de objetos de acceso a datos tipo ORM3 y lo combine con la generación
dinámica de sentencias de un CRUD4 permitiendo minimizar los esfuerzos de la creación de
la DAL5 en un proyecto de desarrollo de software que requiera de persistencias de datos,
ganando las ventajas del código con objetos fuertemente tipados que garantiza al momento de la compilación encontrar errores de sincronización con la estructura de la base de datos y permitan el desarrollo de lógica de negocio independiente del motor de bases de datos utilizado en tiempo de ejecución y aprovechar las funcionalidades especícas de este último.
2Soluciones Lógicas Yayan Gaia S.A.S. 3Object-Relational Mapping
4Create, Read, Update and Delete 5Data Access Layer
Parte I
Fundamentación de la Investigación
Capítulo 1
Descripción de la Investigación
El valor de una idea radica en el uso de la misma Tomas A. Edison
Resumen: El presente capitulo permite explorar el planteamiento del problema tratado, la justicación, hipótesis, objetivos y la metodología seguida.
1.1. Denición del Problema
1.1.1. Descripción
En un entorno empresarial de desarrollo de software, la creación de la capa de acceso a datos es un proceso altamente operativo, por lo que se requiere una inversión importante de tiempo; es así como el 80 % de las acciones empleadas en esta actividad es repetitiva y desgas-tante. Al momento de requerir que una aplicación en tiempo de ejecución pueda conectarse a diferentes motores de bases de datos se cuenta con dos opciones: usar ODBC1, o programar un
modelo de acceso a datos por cada motor requerido. Para solventar lo anteriormente expuesto, tradicionalmente las casas de desarrollo de software crean sus propias estructuras base de acce-so a datos, las cuales replican entre proyectos. Con el panorama anterior, a futuro las opciones disponibles empezarán a tornarse inmanejables puesto que, por un lado las soluciones artesa-nales propias de las empresas se construyen a partir de copiar y pegar código a los diferentes aplicativos y módulos sin un estándar denido, y de otro lado, al utilizar Entity Framework, aunque permite la generación automática de la capa de acceso a datos, presenta el problema
1Open DataBase Connectivity
que las sentencias son complejas por la utilización de LINQ2, y requiere desarrollos adicionales
para el manejo de múltiples motores de bases de datos. Es por esto que estas opciones, que son las más usadas en el mercado, generan una gran complejidad en su implementación y trabajo adicional de mantenimiento.
Por lo anteriormente expuesto, se hace necesario desarrollar una herramienta que permita mapear la base de datos, independiente del motor que emplee, y genere automáticamente el código de acceso a datos con objetos fuertemente tipados, que permitan detectar error al momento de la compilación y requieran una mínima interacción o modicación por parte del desarrollador, de tal manera que garantice que con solo cambios en la conguración de la cadena de conexión, se pueda acceder a diferentes motores de bases de datos en tiempo de ejecución.
1.1.2. Formulación
¾De qué manera es posible automatizar el proceso de mapeo de una base de datos para generar automáticamente el código de acceso, teniendo en cuenta que requiera realizar única-mente los ajustes en la cadena de conexión, independienteúnica-mente del motor de la base de datos de que se utilice?
1.2. Hipótesis
Una herramienta CASE puede disminuir el esfuerzo de desarrollo y mantenimiento en las actividades de interacción con la base de datos si genera de manera automática la capa de acceso a datos con una mínima interacción del desarrollador, teniendo en cuenta que requiera realizar únicamente los ajustes en la cadena de conexión, independiente del motor de la base de datos de que se utilice en tiempo de ejecución.
1.3. Objetivos
1.3.1. Objetivo General
Diseñar e implementar una herramienta CASE en la empresa SLYG que permita generar automáticamente una capa de acceso a datos en aplicaciones .Net, conectándose indistintamen-te a Oracle, SQL Server y PostgreSQL, medianindistintamen-te objetos fuerindistintamen-temenindistintamen-te tipados y únicamenindistintamen-te a partir de cambios en la cadena de conexión.
1.3.2. Objetivos Especícos
1.4. Justicación 5
con el tipo de desarrollo a realizar.
Desarrollar los artefactos propuestos en la fase de diseño aplicando un modelo de desa-rrollo de software pertinente para asegurar la calidad del producto.
Implementar una métrica que permita realizar la comparación entre los tiempos de de-sarrollo previos y posteriores al dede-sarrollo de la herramienta.
1.4. Justicación
1.4.1. Social
En un entorno económico donde iniciar un nuevo emprendimiento en el sector de tecnologías y desarrollo de software es una hazaña gigantesca; puesto que las diferentes actividades de administración y mercadeo de una pequeña o mediana empresa consume un porcentaje alto del tiempo de sus trabajadores dejando porcentajes bajos del mismo para el desarrollo de procesos misionales aumentando la posibilidad de fracaso.
Bajo la perspectiva de lo antes expuesto cualquier esfuerzo encaminado a disminuir los tiempos de desarrollo y aumentar la productividad en la creación de piezas de software mejora las probabilidades de que las empresas salgan adelante y se vuelvan generadoras de empleo.
1.4.2. Ecológica
El consumo de energía de forma irracional genera un alto impacto ambiental o alteración negativa en el medio ambiente; repercutiendo en la calidad de vida y salud de la humanidad en general, puesto que usualmente la producción de energía encuentra su fuente en procesos que implementan combustible fósil donde se utiliza el calentamiento de un alto volumen de agua para generar vapor contaminando el aire y fuentes hídricas.
Actualmente la producción y uso de energía se cataloga como una de las principales causas de las emisiones de gases de efecto invernadero, que a su vez son los directamente responsables del cambio climático, aumento de temperaturas, subida de nivel de mar, y disminución de precipitaciones.
Por lo anterior se considera que un aporte positivo a esta problemática es la reducción del consumo energético, minimizando tiempos de uso de los equipos de computo al decrecer el tiempo de desarrollo y de procesamiento haciendo las aplicaciones más ecientes.
1.4.3. Tecnológica
suciente para atender los picos de alta demanda, situación en la que se encuentra Soluciones Lógicas Yayan Gaia, que cuenta con un número reducido de desarrolladores, equipo de soporte y capacitación. La alta demanda de servicios de soporte, generación de nuevos requerimientos exigen más tiempo de atención; por consiguiente, al analizar las actividades que requieren mayor inversión en tiempo dentro de los procesos propios de un desarrollo, se encuentra que es la codicación de la capa de acceso a datos y requiere aún más tiempo cuando los desarrollos deben permitir la conexión a diferentes motores de bases de datos dependiendo de cuál tenga licenciado el cliente.
Capítulo 2
Marco de Referencia
Rem tene, verba sequentur (Si dominas el tema, las palabras vendrán solas) Catón el Viejo
2.1. Marco Teórico
Para el desarrollo de sistemas transaccionales, uno de los puntos críticos corresponde a la persistencia de la información y gran cantidad de los esfuerzos de desarrollo se orientan a la interacción entre módulos cliente y los servidores de bases de datos. Mediante este artículo se pretende validar algunas de las soluciones existentes para el entorno de desarrollo .Net y el respectivo desempeño de las mismas de tal manera que permita al lector decantarse por la solución más conveniente para su gestión.
El dato, en términos generales para el diccionario de la real academia proviene del latín Datum Lo que se da y en su primera denición arma que es información sobre algo en concreto que permite su conocimiento exacto o sirve para deducir las consecuencias derivadas de un hecho (RAE, 2016) para los términos de este articulo un dato es la parte más pequeña de lo que pueda considerarse como información conforme al criterio y experiencia del autor y a la aplicación dada en las diferentes comparaciones aquí evidenciadas.
Un dato puede contar con diferentes niveles de abstracción; Físico que describe como se almacenan los datos, Lógico que es el nivel más alto que conserva la relación entre datos y si se almacenan en una base de datos o no, y por ultimo nivel de vistas el cual muestra únicamente una fracción de la base de datos. (Silberschatz, 2002)
La persistencia es permitir a los datos en una aplicación ser almacenados (Kuaté et al., 2008), este almacenamiento abarca diferentes tipos de medios y arquitecturas entre estas en-contramos las bases de datos relacionales, las cuales actualmente cuentan con diferentes ma-nejadores y son manipuladas mediante el lenguaje SQL el cual es el lenguaje relacional de no procedimiento que se reere a los resultados de una operación (Oppel y Sheldon, 2009) donde
generalmente la arquitectura a utilizar es por capas para garantizar que cada capa dimen-sionada se encargue de una función en particular, las capas superiores se comunican con las inferiores y solo dependen de la comunicación directa con la inmediatamente inferior.
Como es bien conocido el modelo en esencia consta de tres capas: presentación, lógica del negocio y persistencia; permitiendo reducir la complejidad del desarrollo (Kuaté et al., 2008) donde la capa de datos puede ser manejada mediante codicación manual, para el caso de .Net mediante herramientas ADO.Net o mediante una herramienta que permita la generación de dicho código de forma automática utilizando el mapeo de objetos relacionales (ORM) que se dene como la traducción de objetos a entidades relacionales o viceversa siendo el puente que permite manipular objetos y proveyendo diferentes características para automatizar el almacenamiento de datos lo más transparente posible (Kuaté et al., 2008) y posteriormente implementar operaciones CRUD o de manipulación de datos, donde usualmente se utilizan los DataSets que son una representación de los datos en memoria que corresponden al origen de datos, conteniendo las respectivas tablas (Microsoft, 2016b).
En este documento se pretende explorar las siguientes herramientas disponibles en el mer-cado para realizar el acceso a datos en un marco de desarrollo como .Net:
ADO .Net con DataReaders ADO .Net con DataAdapters EF1 CodeFirst
EF DatabaseFirst Nhibernate Dapper
2.1.1. ADO .Net DataReaders Y DataAdapters
Son las herramientas que por defecto ofrece .Net para conexión y acceso a datos, proporcio-nando acceso coherente a diferentes orígenes de datos y es el método más directo para realizar este proceso (Microsoft, 2016c).
Los DataReaders permiten recuperar a ujos de datos de solo lectura y solo avance de una base de datos, un DataAdapter se utiliza para recuperar datos de un origen de datos y llenar tablas con un DataSet (Microsoft, 2016a).
2.1.2. Nhibernate
Esta herramienta permite realizar el mapeo objeto-relacional, que permite a aquellos pro-gramadores con altas competencias en programación orientada a objetos trabajar sin un
2.1. Marco Teórico 9
nocimiento profundo en SQL2 o su respectiva programación, trabajar en la persistencia de las
aplicaciones bajo estas características, transformando tablas en clases, columnas en propieda-des y registros en instancias de objetos (Peres, 2014).
Al trabajar con Nhibernate permite al desarrollador cargar y salvar entidades, lo que permite fácilmente identicar sobre que objeto de la base de datos se está trabajando, im-plementando consultas con nombres y propiedades adecuados, para ser comprendidos por el manejador de bases de datos correspondientes, para esto cuenta con dos APIs3 de consulta.
La primera se denomina HQL4 que permite usar código SQL pero a su vez muchas
carac-terísticas de la programación orientada a objetos ya que ofrece funciones de acceso a código estándar SQL tales como: agregación, propósito general, matemáticas, cadenas de texto, entre otras, se encuentra que no soporta Outer Joins, no permite seleccionar todos los registros de la tabla, el SELECT es opcional, entre otras cosas.
La segunda es QBC5 que provee un conjunto de clases que permite crear consultas a la
elección del programador siendo un manejo más conceptual y permite realizar las consultas en diferentes pasos, lo que lo hace un poco más complejo y menos intuitivo (Kuaté et al., 2008) (Peres, 2014).
Nhibernate permite una gran gama de conexiones a diferentes motores de bases de datos dentro de los que se encuentran SqlLite, DB2, Informix, Mysql, Oracle, PostgreSQL, Sybase, entre otros (Peres, 2014) lo que garantiza en determinado nivel la portabilidad de la aplica-ción, pero no asegura la independencia total de la base de datos, adicional a que siempre se encontrará supeditado a las restricciones del propietario de dicho motor(Kuaté et al., 2008).
2.1.3. Entity Framework
ADO.NET EF es un marco de trabajo para la plataforma .NET que permite superponer varias capas de abstracción sobre un almacén relacional con el n de hacer posible una pro-gramación más conceptual (basada en los conceptos del dominio con el que se trabaja) y de reducir a una mínima expresión el desajuste de impedancias causado por las diferencias entre los modelos de programación relacional y orientado a objetos.(Castro, 2011)
Esta herramienta permite trabajar tres maneras como se muestra en la gráca 2.1:
Base de datos primero. Modelo primero. Código primero.
Como se evidencia en el gráco anterior se puede trabajar desde una base de datos existente, desde un modelo existente o desde un modelo de datos que parten clases (orientación a objetos).
2Structured Query Language
3Application Programming Interfaces 4Hibernate Query Language
Para las dos primeras opciones se requiere del EDM6, el cual permite la creación de los modelos
conceptuales y cuenta con: ambiente para gracar los diagramas, ventana de detalles de mapeo, ventana navegación por el modelo y ventana de herramientas operando en con archivos de tipo edmx correspondientes al tipo de archivo que maneja EF para su modelo de entidades(Castro, 2011).
Figura 2.1: Tipos de Trabajo EF
EDM permite abstraer el modelo de datos (entidades y relaciones) mediante EntityType (representan un tipo especial de datos), EntitySet (es un contenedor de instancias EntityType) y EntityContainer (Contenedor) pero sin lograr el modelamiento de relaciones muy complejas, por lo que se sugiere minimizar las relaciones existentes en los modelos(Castro, 2011).
Para EF también es posible el manejo agnóstico al momento trabajar con diferentes motores de bases de datos,ofreciendo la posibilidad a los desarrollos de ser multi-base de datos y permitiendo interactuar con algunos de los siguientes manejadores: Oracle, Mysql, SqlLite, PostgreSQL(Castro, 2011).
2.1. Marco Teórico 11
2.1.4. Dapper
Dapper framework fue creado por Samm Saron, y tiene un alto desempeño por usar métodos dinámicos de generación para asignar valores de columna a propiedades(liangwu, 2012).
Provee asistentes para: ejecutar consultas y mapear objetos fuertemente tipados, ejecutar consultas y mapear sus resultados a una lista dinámica de objetos, ejecutar comandos en diferentes momentos(Gravell, 2016).
Las cualidades más destacadas de esta herramienta son: velocidad y rapidez en su rendi-miento, pocas líneas de código, mapeo de objetos, enlace de objetos estáticos, enlace a objetos dinámicos, fácil manejo de consultas SQL y procedimientos almacenados, soporte a diferen-tes consultas, opera directamente en la clase IDBConection entre otras características, que le otorgan un alto desempeño y le permiten la ejecución de operaciones CRUD.(Parikh, 2015)
2.1.5. Archimate
El lenguaje de modelado Archimate permite representar la Arquitectura Empresarial de una organización bajo tres básicas perspectivas: negocio, sistemas y tecnología.
El lenguaje Archimate sirve para diseñar Arquitecturas Empresariales que faciliten la adopción de tecnología en las empresas, vinculando los procesos de negocio con los activos tecnológicos. facilita la administración de proyectos de tecnología y cambio organizacional, permitiendo que los expertos de negocio puedan priorizar los requerimientos de alto nivel y generar proyectos que impacten positivamente la organización. Este modelo Archimate de-ne un conjunto de elementos estándar para el diseño de Arquitecturas Empresariales, lo cual ayuda signicativamente a tener un lenguaje común entre expertos de negocio y de tecnología. TOGAF7 en términos simples es una herramienta para asistir en la aceptación, creación,
uso y mantenimiento de arquitecturas. Basado en un modelo iterativo de procesos apoyado por las mejores prácticas y un conjunto reutilizable de activos arquitectónicos existentes.
Se puede utilizar para desarrollar una amplia variedad de arquitecturas empresariales; además complementa y se puede usar en conjunto con otros marcos de referencia que están basados en entregables especícos para sectores particulares. La clave de TOGAF es el método de desarrollo de la arquitectura ADM8, para desarrollar una arquitectura empresarial que
aborda las necesidades de negocio.
Esta referencia arquitectónica es desarrollada y mantenida por el foro de arquitectura The Open Group. Este foro ha desarrollado versiones sucesivas de TOGAF con regularidad las cuales son publicadas en si sitio publico web.(TOGAF, 2017)
2.1.6. ADM
El lenguaje ArchiMate, complementa a TOGAF brindando independencia de vendedor, y se centra en los conceptos, incluyendo representaciones grácas que ayudan a crear consistencia e integración a través de las diferentes guras y vistas de TOGAF.
La estructura del núcleo del lenguaje ArchiMate se corresponde estrechamente con las tres Arquitecturas de la TOGAF ADM. Esto se ilustra en la gura 2.2 visualizando la correspon-dencia entre las vistas TOGAF y los puntos de vista ArchiMate.
Algunas vistas de TOGAF no concuerdan en el núcleo de ArchiMate. Parcialmente, esto es porque el alcance de TOGAF es más amplio y se ocupa tanto de estrategias de alto nivel como de aspectos del desarrollo de sistemas, mientras el núcleo de ArchiMate esta limitado nivel de abstracción de la arquitectura empresarial.
Figura 2.2: Correspondencia entre ArchiMate y TOGAF
2.2. Marco Conceptual
2.3. Marco Espacial 13
En sistemas transaccionales la DAL cobra gran importancia y tiende a estar compuestas por grandes cantidades de líneas de código convirtiéndose en uno de los principales orígenes de fallos y requiriendo la inversión de esfuerzo tanto de desarrollo como de pruebas y soporte. La estandarización de los métodos de acceso a datos da por resultado un sinnúmero de líneas de código relativamente similar para soportar las instrucciones básicas de acceso a los objetos de la base de datos. Los CRUD, se centran en la reducción de este código redundante pero al depender de sentencias creadas dinámicamente a partir de cadenas de texto que denen los nombres de las entidades en la bases de datos crean otro punto susceptible a fallos cuando los cambios en la estructura de la base de datos no es correctamente actualizada en las cadenas de texto y los procesos de compilación no detectan los errores correspondientes.
Los ORM, solventan los inconvenientes de los CRUD al ligar la estructura relacional de la base de datos con objetos en el código del cliente, permitiendo una mayor abstracción de la lógica de acceso a datos y volviéndola independiente del motor de base de datos pero agregando un nuevo nivel de complejidad a las instrucciones de interacción con los datos y la necesidad nuevamente de escribir gran cantidad de líneas de código para denir las clases que representan las entidades y cheros de conguración que relacionan las propiedades de los objetos con las entidades de la base de datos.
Al aumentar la complejidad del problema con el requerimiento que el sistema pueda so-portar el uso de diferentes motores de bases de datos en tiempo de ejecución y que el uso de uno u otro motor solo requiera el cambio de la cadena de conexión nos encontramos con que las líneas de código necesarias para soportar esta interacción crecen exponencialmente o que el mantenimiento de las conguraciones en un ORM se vuelven inmanejables y restringen el uso de funcionalidades especícas de cada motor de base de datos.
2.3. Marco Espacial
2.3.1. Soluciones Lógicas Yayan Gaia
SLYG9, es una empresa conformada por un grupo de profesionales expertos en diseño y
desarrollo de software moderno, amigable, rápido y seguro. Surgió como proveedora de software por demanda a empresas prestadoras de servicios al sector nanciero, una actividad exigente en términos de los tiempos de respuesta y de la conabilidad necesaria. De esta han salido aplicaciones que el Grupo Brinks10usa para prestar servicios a empresas del sector nanciero.11
Con la certeza de que el diseño y desarrollo de productos propios genera mejores oportu-nidades y luego reforzados por una eventual reducción de actividades del Grupo Brinks, en el año 2013 se aceleró el cambio de énfasis desde el desarrollo de software por demanda hacia el diseño y desarrollo de software propietario.
9Soluciones Lógicas Yayan Gaia S.A.S. 10Brinks, Procesos & Canje, Domesa y ePago
En el año 2011 el 75 % de los ingresos operacionales se originaban en desarrollo por demanda y el 25 % restante por suministro de personal para desarrollo en la sede de nuestros clientes. El ingreso por desarrollos propios fue nulo.
En el 2013 el 68 % de los ingresos tenían su origen el desarrollo y suministro de personal, pero ya un 32 % correspondió al ingreso por licencias de nuestros productos y actividades relacionadas12.
Para el año 2015 el 60 % de los ingresos operativos correspondieron al rubro de licencias, y se espera que para el 2016 supere el 80 %.
2.3.2. Estrategia
2.3.2.1. Misión
SLYG tiene como misión diseñar, desarrollar e implementar herramientas y sistemas de software que sean de apoyo a las organizaciones, personas y sociedad en la que cual operamos, para de esta manera convertirse en un proveedor estratégico para dichas empresas.
2.3.2.2. Visión
SLYG se propone convertirse en un aliado estratégico para las empresas, personas y socie-dad, brindándoles a nuestros clientes las mejores soluciones del mercado en cuanto a sistemas de información de apoyo crítico para el éxito de sus proyectos . De igual forma SLYG se vi-sualiza como una empresa que brinda a sus empleados una de las mejores opciones de trabajo, brindando un muy buen clima laboral y calidad de vida.
2.3. Marco Espacial 15
2.3.3. Estructura Organizativa 2.3.4. Stakeholders
Al ser SLYG una SAS13, es dirigida por una Asamblea General de Accionistas, como se
puede ver en la gura 2.3, cuyo peso en las decisiones se ve reejado en su participación accionaria.
La tabla 2.1 muestra el listado de accionistas de SLYG y su participación accionaria.
Accionista Identicación Participación
Libardo Yanod Márquez Aldana 17.307.559 35 %
Eliseo Roa Piramanrique 79.902.959 30 %
Myriam Isaura Gutiérrez Flores 51.636.007 22 %
Pablo Yanod Márquez Restrepo 86.057.718 10 %
Julián David Duque Castro 80.019.536 3 %
Tabla 2.1: Accionistas.
2.3.4.1. Organigrama
La gura 2.3 muestra de forma gráca la estructura organizativa de la empresa SLYG que se encuentra dividida en dos Direcciones: Dirección de Desarrollo y Dirección de Relaciones con el Cliente. Rindiendo informe a la Asamblea General se encuentra el Gerente encargado de aplicar las directrices denidas por esta. Bajo la gerencia se encuentra un Coordinador General quien se encarga de las labores administrativas y a quien presentan informe las direcciones de Desarrollo y Relaciones con el Cliente.
Figura 2.3: Organigrama
2.3.4.2. Funciones
Las funciones correspondientes a la empresa se distribuyen en las dos direcciones existentes, de tal manera que se puede discriminar los diferentes macroprocesos existentes de la siguiente manera:
La Dirección de Desarrollo concentra las actividades referentes a los servicios de desarrollo de software, soporte a las aplicaciones existentes y asesorías en arquitectura de software.
2.3. Marco Espacial 17
2.3.5. Productos y Servicios
2.3.5.1. Productos
La tabla 2.2 muestra un resumen de los productos ofrecidos por SLYG a los cuales se les brinda actualización y soporte, el producto que actualmente requiere más recursos por contar con el más alto nivel de demana en el mercado corresponde a Block.
Producto Descripción
SLYG Block es un sistema de información Web que permi-te registrar los procesos de planeación, Control y Gestión de Proyectos de Construcción. Contiene módulos de presupues-to, programación de actividades/compras, almacén, órdenes de pedido/alquiler, sub-contratos, ventas y autorizaciones en línea.
Fluxus BPM (Business Process Management) es un soft-ware especializado en Sistematización y Control de Procesos sensibles de la compañía donde los tiempos de respuesta, la denición de responsabilidades y la integración con diver-sos sistemas son fundamentales. Es el sistema perfecto para procesos como: Fábrica de Crédito, Aprobación de Facturas, Compras, PQRS, Contratación, entre otros.
Capturing Es un sistema para creación y calicación de exámenes tipo ICFES por Reconocimiento de Formatos Es-tándar, destinado a centros educativos especializados en la preparación de estudiantes para los mismos.
2.3.5.2. Servicios
La tabla 2.3 muestra un resumen de los servicios ofrecidos por SLYG donde el servicio con mayor demanda corresponde al desarrollo de aplicaciones Web para diferentes tipos de empresas y personas naturales y juridicas .
Servicio Descripción
Desarrollo de Software a la Medida. Servicio de diseño y desarrollo de plataformas empresariales de alto desempeño para soporte de procesos core del negocio.
Presupuesto Elaboración de presupuestos de obras de cons-trucción, en este servicio se ofrece el cálculo de cantidades de obra, elaboración de análisis de precios unitarios, progra-mación de obra y ujo de caja.
Interventoría Control e interventoría de obras de cons-trucción, seguimiento de contratos e informes de avance de obra.
Capítulo 3
Aspectos Metodológicos
La mejor estructura no garantizará los resultados ni el rendimiento. Pero la estructura equivocada es una garantía de fracaso. Peter Drucker
Resumen: En este capítulo se aborda el tipo de estudio, la metodología de investigación y el método de desarrollo aplicado en este proyecto.
3.1. Tipo de Estudio
El tipo de estudio es descriptivo, puesto que se va a automatizar la generación de código de la capa de acceso a datos para aplicaciones en .NET mediante un modelo lineal o cascada.
3.2. Método de investigación
En un contexto de ingeniería y por consiguiente un problema planteado en este mismo, es clave contar con una denición clara del problema puesto que de lo contrario la propuesta dará solución a necesidades inexistentes, así como también es clave el diseño que le permite al ingeniero pensar , proyectar y maquetar un artefacto que benecie a las personas.
Bajo la premisa que un ingeniero cuenta con un método de diseño de una solución, se considera el método de análisis el más cercano al objetivo de este proyecto, puesto que permite identicar los componentes que interactúan en el problema y validar la relación causa- efecto en un entorno empresarial.
3.2.1. Metodología de Desarrollo
El modelo lineal secuencial o modelo en cascada es el primer modelo conocido en el proceso de desarrollo de software y comprende cinco etapas que se adelantan de manera secuencial o en cascada, de allí el origen de su nombre.
Se selecciona este modelo puesto que cuenta con una implementación simple, el recurso requerido para implementar el modelo es mínimo, por lo que es aplicable a un equipo de trabajo conformado por dos integrantes. Adicionalmente permite una documentación en cada fase del modelo y el tipo de desarrollo que se requiere se adapta al contexto de este proyecto.
Las etapas del modelo que se van a implementar son:
1. Análisis y denición de los requisitos del sistema: Consiste en la recolección de información de diferentes fuentes documentales, entrevistas, observación, entre otras, para obtener el dominio del negocio y de esta forma entender realmente que es lo que se quiere, para luego plasmarlo en un documento técnico de requerimientos, los cuales muestran de forma práctica para el cliente y consistente para el desarrollador del software toda su funcionalidad.
Dichos requerimientos deben ser avalados por las dos partes (Cliente Desarrollador) para delimitar el software y para garantizar que se desarrolla lo que se quiere. También sirven para medir el avance en la elaboración del software.
Para efectos de formalizar los requisitos en este proyecto se implementará la plantilla IEEE380.
2. Diseño: Es el proceso mediante el cual se hace una representación del software, gene-ralmente se hace con diagramas UML1, los cuales permiten abordar el desarrollo del
software en cuatro atributos:
Estructura de datos. Arquitectura del software. Representación de interfaz. Procedimientos.
El producto de esta fase cuenta en este trabajo con los siguientes diagramas UML como: Diagrama de casos de uso.
Diagrama de clases. Diagrama de secuencia.
3. Codicación: Consiste en llevar el diseño a lenguaje de máquina, su éxito depende del correcto desarrollo de las fases de requerimientos y de diseño. Dentro de los entregables en esta fase se cuenta con:
3.2. Método de investigación 21
Código fuente.
4. Pruebas: Consiste en vericar que los procesos internos del software funcionen, así como las funcionalidades externas, de acuerdo a lo planteado en los requerimientos.
El modelo cascada cuenta con una quinta fase denominada mantenimiento, la cual no aplica para este proyecto ya que el alcance del mismo se establece únicamente hasta las pruebas.
3.2.2. Métrica Asociada al Producto
Con el n de determinar que el producto, obtenido mediante la herramienta CASE, cumpla o no con la hipótesis planteada, se ha determinado una métrica que permita denir el coste total en tiempo y esfuerzo requerido por el desarrollador al momento de crear la capa de acceso a datos contrastada con el desempeño en tiempo de ejecución del código fuente generado.
Teniendo en cuenta las particularidades propias de la aplicación y sondeando herramientas similares en el mercado, se precisaron las siguientes variables de evaluación con sus respectivos rangos de calicación para cada herramienta a implementar:
1. Tiempo ejecución: Se realiza a partir de la medición del tiempo de ejecución, en milisegundos, de las instrucciones CRUD para 4.000 registros. El puntaje se calcula como el resultado de la operación (1-x/m)*100 donde x es el tiempo obtenido y m el tiempo máximo de comparación. Cualquier valor con un tiempo mayor al máximo de comparación se le asigna un puntaje 0.
2. Líneas de código: Se calcula como la sumatoria del total de líneas de código y con-guración requeridas para realizar la ejecución de las instrucciones CRUD. El puntaje se calcula como el resultado de la operación (1-x/m)*100 donde x es la cantidad de líneas de código y m la cantidad de líneas de código máximas de comparación.
3. Mantenibilidad: En esta variable se calcula la facilidad de detectar un error en el código fuente una vez realizado un cambio en la estructura de la base de datos, para esto se asume que las herramientas que usan DAOs2 tienen una mejor mantenibilidad.
Los puntajes asignados corresponden a:
0 puntos, si no requiere el uso de DAOs.
50 puntos, si requiere el uso de DAOs y el usuario los crea manualmente. 100 puntos, si los DAOs son generados automáticamente por la herramienta.
El resultado nal por herramienta se obtendrá del promedio de los tres indicadores.
Parte II
Desarrollo de la investigación
Capítulo 4
Análisis
El alma nunca piensa sin una imagen mental. Aristóteles
Resumen: En este capítulo se aborda el análisis de la arquitectura empresarial mode-lándola con los puntos de vista de Archimate.
En la fase de análisis de este trabajo se incluye la arquitectura empresarial; donde se identica a la organización en un contexto de negocio en el que sus procesos misionales se enfocan en el desarrollo de sistemas de información y aplicaciones, por lo que en sus actividades se identica al desarrollador y al arquitecto de información como los actores principales en dichos procesos. La prioridad fue determinada por el proceso clave el cual es el desarrollo, puntualizando en la generación de la capa de acceso a datos. Todo lo anterior se dimensiona en una infraestructura standalone que eventualmente se conectará a red dependiendo de la ubicación física de la base de datos, de igual manera para esta fase se realizó el renamiento de los requerimientos a través de el punto de vista motivacional que provee las restricciones y requisitos a los proyectos.
Para la especicación de los requerimientos se tomó como base el formato IEEE830 el cual permite acercar al la empresa un documento formal donde se detallan los requerimientos construidos en conjunto y aquellos se identicaron implícitamente en esta fase. El formato puede ser consultado en el apéndice A.
4.1. Capa de Negocio
Un punto de vista en ArchiMate es una selección de un subconjunto relevante de los conceptos de ArchiMate (y sus relaciones) y la representación de la parte de una arquitectura
que se expresa en diferentes diagramas. Un conjunto de tales puntos de vista fue desarrollado basado en la experiencia práctica.
Algunos de estos puntos de vista tienen un alcance limitado a una sola capa o aspecto. Así, los puntos de vista de función de negocio y de proceso de negocio muestran las dos principales perspectivas sobre el comportamiento del negocio; el punto de vista de organización representa la estructura de la empresa en términos de sus departamentos, roles, etc.
Otros puntos de vista vinculan múltiples capas o aspectos: el punto de vista de cooperación de actor y producto se relacionan con la empresa a su entorno.
4.1.1. Punto de vista Organización
La gura 4.1 muestra el diagrama del punto de vista de organización que para este caso es SLYG una empresa que inició operación en octubre de 2008, en su primera sede ubicada en Nicolás de Federman con tres empleados, en la actualidad se encuentra en el barrio Andes Norte, calle 94A # 60C - 45 ocina 202, y cuenta con más de tres departamentos claramente denidos, y con tres productos terminados de los cuales SLYG Block se esta abriendo paso en el mercado del software de construcción a pasos grandes y acelerados.
Los departamentos que soportan la operación misional de SLYG son desarrollo y arquitec-tura de información puesto que son aquellos que generan nuevos productos y dan soporte a los vigentes.
4.1. Capa de Negocio 27
4.1.2. Punto de vista Cooperación de Actor
La gura 4.2 muestra el diagrama del punto de vista de cooperación de actor, para la empresa SLYG se cuenta con una colaboración denominada Equipo de Desarrollo por Pro-yecto la cual está compuesta por dos roles: desarrollador SLYG y arquitecto de estructura de información.
Un equipo de desarrollo es denido por el actor Unidad de Desarrollo que se encarga de realizar los desarrollos a las plataformas de software de la empresa determinado por el proyecto en particular, para una empresa cliente.
4.1.3. Punto de vista Función de Negocio
La gura 4.3 muestra el diagrama del punto de vista de función de negocio para la empresa que abarca este proyecto este punto de vista se cuenta con tres (3) funciones principales: diseñar la base de datos, codicar el diseño y vericar el diseño. La función de codicar el diseño a su vez se compone de tres (3) sub funciones: generar capa de acceso a datos, generar lógica de negocio y generar interfaces grácas. Todas estas funciones componen el rol desarrollador.
4.1. Capa de Negocio 29
4.1.4. Punto de vista Proceso de Negocio
La gura 4.4 muestra el diagrama del punto de vista de proceso de negocio para el caso de estudio predomina la necesidad de facilitar y agilizar la implementación de sistemas de información como servicio clave. Para ello el proceso de desarrollo se inicia con el evento Entregar un Diseño de Alto Nivel a partir del cual se inicia el sub proceso diseño de datos, continua el sub proceso de implementación de la capa de acceso a datos y naliza con el sub proceso de QA. Las pruebas de QA realiza las prueba y la aprobación del producto de software.
4.1.5. Punto de vista Cooperación de Proceso de Negocio
La gura 4.5 muestra el diagrama del punto de vista de cooperación de proceso de negocio, donde se evidencia uno de los roles principales el cual es el desarrollador quien debe contar con un perl acorde a un ingeniero de sistemas con las competencias otorgadas por el titulo para realizar el proceso de la implementación de la capa de acceso a datos.
4.2. Capa de Aplicación 31
4.1.6. Punto de vista Producto
La gura 4.6 muestra el diagrama del punto de vista de producto que permite evidenciar los valores principales del producto denido como DAL Designer, estos son: portabilidad de data, facilidade de uso y dimisnución de los tiempo de desarrollo. De igual manera la herramienta en cuestión es privativa por lo que cuenta con una licencia de uso comercial y su principal nalidad es facilitar la abstracción de la estructura de datos.
Figura 4.6: Punto de vista Producto
4.2. Capa de Aplicación
El punto de vista de comportamiento, cooperación y estructura de aplicación contiene las aplicaciones y componentes, y sus relaciones mutuas; el punto de vista de uso de aplicación se reere a aplicaciones para su uso, por ejemplo, procesos de negocio.
4.2.1. Punto de vista Uso de Aplicación
La gura 4.7 muestra el diagrama del punto de vista de uso de aplicación que modela el componente DAL Designer el cual presta el servicio de generación de código automático representado para el proceso de codicación de la capa de acceso a datos, que inicialmente se describió en modelado en la capa de negocio.
4.2. Capa de Aplicación 33
4.2.2. Punto de vista Comportamiento de Aplicación
La gura 4.8 muestra el diagrama del punto de vista de comportamiento de aplicación donde se describe el componente DAL Designer y sus interacciones con tres sub componentes que son: un Mapper encargado de leer el modelo de la base de datos e interpretar la estructura de la misma, un Codier encargado de generar el código fuente de la capa de acceso a datos en conjunto con el tercer sub componente que es el Engine que facilita las instrucciones conforme al motor de base de datos.
4.2.3. Punto de vista Cooperación de Aplicación
La gura 4.9 muestra el diagrama del punto de vista de cooperación de aplicación donde describe la división de los paquetes del DAL Designer en Front Oce y Back Oce. Está asociado al Front el Componente DAL- Designer y el componente Client DAL, mientras que al Back Oce encontramos al Mapper y el Codier
4.3. Capa de Infraestructura 35
4.2.4. Punto de vista Estructura de Aplicación
La gura 4.10 muestra el diagrama del punto de vista de estructura de aplicación donde se modelan las interfaces de cada uno de los sub paquetes asociados al DAL Designer: IMapper describe las interacciones del paquete Mapper, ICodier describe las interacciones del paquete Codier y por ultimo IConnection describe la paquete Client CAL, también se evidencia el Data Object que permite relacionar el componente principal con el del cliente.
Figura 4.10: Punto de vista Estructura de Aplicación
4.3. Capa de Infraestructura
4.3.1. Punto de vista Infraestructura
La gura 4.11 muestra el diagrama del punto de vista infraestructura donde se modela la infraestructura general del caso de estudio, donde la herramienta se encuentra en un equipo instalada y permitirá conectarse localmente o a un servidor de base de datos para mapear la base de datos correspondiente.
Figura 4.11: Punto de vista Infraestructura
4.3.2. Punto de vista Uso de Infraestructura
La gura 4.12 muestra el diagrama del punto de vista de uso de aplicación donde se modela uso de la infraestructura dispuesta para la aplicación, con los respectivos componentes, como se puede observar la aplicación modelada es standalone y dependiendo de la ubicación de la base de datos requerirá acceso a la red.
4.3. Capa de Infraestructura 37
4.3.3. Punto de vista Implementación y Despliegue
La gura 4.13 muestra el diagrama del punto de vista de implementación y despliegue donde se puntaliza quee el despliegue se centrara en un PC sobre sistema operativo Windows y bajo código C# o Visual Basic y apuntando a motores de bases de datos como Postgres, ORACLE y SQL Server, que bien puede encontrarse en otro nodo en la red o localmente en la misma maquina.
4.3.4. Punto de vista Estructura de Información
La gura 4.14 muestra el diagrama del punto de vista de estructura de información don-de se muestra las diferentes estructuras don-de información administrada por la herramienta, se encuentran objetos de datos como devoluciones, ltros, campos y relaciones de campos para soportar las diversas funcionalidades de la herramienta
4.3. Capa de Infraestructura 39
4.3.5. Punto de vista Realización del Servicio
La gura 4.15 muestra el diagrama del punto de vista de realización del servicio donde se relaciona la capa de aplicación con la de negocio y permite realizar un sondeo claro del servicio principal implementado en la aplicación junto con los objetos de datos con los que este interactúa, que para este caso es es la generación de código automático.
4.3.6. Punto de vista Niveles
La gura 4.16 muestra el diagrama del punto de vista Capas o niveles permite visualizar un todos los componentes principales detectados en capa actual y las previas.
4.4. Capa de Motivación 41
4.4. Capa de Motivación
La motivación en una arquitectura empresarial, inuencia, orienta y limita el diseño. Es clave para entender los factores a menudo referidos por los conductores, que inuyen los ele-mentos motivaciones. Pueden originarse desde dentro o fuera de la empresa. Los conductores, también llamados preocupaciones, están asociados con las partes interesadas, que pueden per-sonas o algún grupo de seres humanos, como un equipo de proyecto, empresa o sociedad.
4.4.1. Punto de vista Stakeholder
La gura 4.17 muestra el diagrama del punto de vista Stakeholder en el que se identica el Stakeholder principal el cual es el desarrollador, cuyo conductor corresponde a plasmar los diseños de software on compromiso de calidad para facilitar la implementación de sistemas de información.
4.4.2. Punto de vista Realización de Objetivos
La gura 4.18 muestra el diagrama del punto de vista Realización de Objetivos permitiendo vislumbrar los objetivos de SLYG y las restricciones así como sus requerimientos propios de la organización enfocándose en el desarrollo e implementación de sistemas de información y en el ofrecimiento de servicios TI
4.4. Capa de Motivación 43
4.4.3. Punto de vista Contribución de Objetivos
La gura 4.19 muestra el diagrama del punto de vista Contribución de Objetivos que Per-mite visualizar la interacción entre objetivos, restricciones y principios generando inuencias positivas que para el caso de estudio generando reducciones en tiempos de desarrollo.
4.4.4. Punto de vista Principios
La gura 4.20 muestra el diagrama del punto de vista Principios en este punto de vista se evidencia los principios que caracterizan a la organización en lo correspondiente a la imple-mentación de sistemas de información y prestación de servicios relacionados con tecnologías de la información donde la empresa se caracteriza por contar con conanza, respaldo y ser eciente.
4.4. Capa de Motivación 45
4.4.5. Punto de vista Realización de Requerimientos
La gura 4.21 muestra el diagrama del punto de vista Realización de Requerimientos que evidencia los requisitos tanto de plataformas como de contextos propios de los pilares de la organización y del proceso en el que se centra este proyecto. Por ello para facilitar la implentación de sistemas de información se cuenta con el requerimiento de solo estar disponible para C# y Visual Basic, contar con plataforma graca y solo aplicado a modelos relacionales .
4.4.6. Punto de vista Motivacional
La gura 4.22 muestra el diagrama del punto de vista Motivacional en donde nos acerca a puntualizar el rol del desarrollador con el respectivo conductor que tiene por denición el plasmar los diseños de software con el compromiso de calidad, de igual manera para el objetivo principal que es facilitar la implementación de sistemas de información se toma como restricción clave que este solo aplica para modelos relaciones.
Figura 4.22: Punto de vista Motivacional
4.5. Capa de Proyecto
4.5.1. Punto de vista Proyecto
4.5. Capa de Proyecto 47
Figura 4.23: Punto de vista Proyecto
4.5.2. Punto de vista Migración
La gura 4.24 muestra el diagrama del punto de vista de migración donde se muestra la transición entre la arquitectura existente y la deseada.
4.5.3. Punto de vista Migración e Implementación
La gura 4.25 muestra el diagrama del punto de vista Migración e Implementación que permite divisar el alcance de los proyectos y programas, integrando elementos de negocio, motivación y migración.
Capítulo 5
Diseño
Programar sin una arquitectura o diseño en mente es como explorar una gruta sólo con una linterna: no sabes dónde estás, dónde has estado ni hacia dónde vas. Danny Thorpe
Resumen: En este capítulo se aborda el diseño del sistema y se presentan los diagramas UML generados durante la etapa de diseño.
5.1. Diagramas de Casos de Uso
Para el modelamiento de casos de uso del sistema, se plantean dos actores principales:
Arquitecto de información: Encargado del diseño de la base de datos.
Desarrollador: Encargado de la codicación de la capa de acceso a datos.
5.1.0.1. Casos de uso Arquitecto de Información
En el proceso de creación de una capa de acceso a datos se parte de la existencia de una base de datos implementada sobre un determinado motor de bases de datos. El Arquitecto de información es el encargado del diseño de la base de datos y dentro de sus funciones se encuentra el modelamiento de la base de datos y su implementación.
La gura 5.1 muestra el diagrama de caso de uso donde interactúa el Arquitecto de infor-mación.
Figura 5.1: Diagrama de Casos de uso - Arquitecto de información
5.1.0.2. Casos de uso Desarrollador
El proceso de codicación de la capa de acceso a datos es realizado por el Desarrollador y contempla cuatro casos de uso:
Crear Conexión: Corresponde a la conguración de la conexión al motor de base de datos.
Mapear estructura: Corresponde al proceso de mapeo de la estructura de la base de datos y la denición por parte del Desarrollador de que objetos serán usados en a capa de acceso a datos y los parámetros de ltrado de la data. Este caso de uso cuenta con tres casos de uso relacionados:
• Mapear tabla.
• Mapear vista.
• Mapear procedimiento almacenado.
Generar código fuente: Corresponde a la generación del código fuente de la capa de acceso a datos por parte de la herramienta CASE.
Usar objetos generados: Corresponde a las labores de codicación por parte del Desarrollador del código fuente de uso de la capa de acceso a datos en una determinada aplicación.
5.2. Diagramas de Componentes 51
Figura 5.2: Diagrama de Casos de uso - Desarrollador
5.2. Diagramas de Componentes
La herramienta CASE propuesta cuenta con un diseño orientado a componentes, donde cada componente se implementa en una DLL independiente.
Los componentes se agrupan en:
Abstractos: Corresponde los componentes que agrupan a las clases e interfaces denidas en el API de la herramienta.
Semiabstractos: Corresponde los componentes que agrupan las implementaciones de los Manager de componentes de mapeo, codicación y conexión, así como la implementación del Engine usado por la capa de acceso a datos en tiempo de ejecución.
Concretos: Corresponde los componentes que agrupan las implementaciones para cada uno de los motores de base de datos y los generadores de código fuente de la capa de acceso a datos.
Figura 5.3: Diagrama de Componentes
5.3. Diagramas de Secuencia
La gura 5.4 muestra el diagrama de secuencia, en tiempo de ejecución, de las instrucciones de acceso a datos del código generado por la herramienta CASE.
5.4. Diagramas de clases 53
5.4. Diagramas de clases
5.4.1. API
5.4.1.1. Denición
El API contiene las interfaces que denen los contratos de interacción de los componentes de todo el sistema, así como el administrador de componentes, el cual se encarga de cargar dinámicamente en tiempo de ejecución cada uno de los componentes de extensión del sistema.
IExtend: Interfaz que permite identicar todas las clases que corresponden a un com-ponente a ser cargado dinámicamente, para ello implementa una propiedad de tipo Ex-tendTypeEnum que identica el tipo de componente.
IMapper: Interfaz que dene el comportamiento de los componentes de mapeo de bases de datos.
ICodier: Interfaz que dene el comportamiento de los componentes de generación de código de las capas de acceso a datos.
IConnection: Interfaz que dene el comportamiento de los componentes que proveen la conexión a los diferentes motores de bases de datos para la capa de acceso a datos en tiempo de ejecución.
ExtendTypeEnum: Enumeración que identica los tipos de componentes de extensión del sistema.
• Codier.
• Connection.
• Mapper.
ExtendManager: Administrador de componentes de extensión. Encargado de cargar dinámicamente los componentes en tiempo de ejecución.
La gura 5.5 muestra el diagrama de clases de la denición del API.
5.4.1.2. Implementación
Dentro del alcance del proyecto actual se contempla la implementación de componentes para los motores de bases de datos ORACLE, PostgreSQL y SQL Server, y generadores de código para la capa de acceso a datos ADO en C# y Visual Basic.
Figura 5.5: Diagrama de clases - Denición API
5.4.2. Engine ADO
5.4.2.1. Denición
El código generado de la capa de acceso a datos encapsulará los llamados a el motor de pro-cesamiento de instrucciones encargado de convertir las instrucciones del cliente en sentencias SQL para cada motor de base de datos soportado por el sistema. Para el alcance del presente proyecto se contempló el desarrollo de un motor (Engine) ADO con soporte para DataTables. El Engine ADO será soportado por por un conjunto de clases denominadas Manager en-cargadas de proveer el funcionamiento base de los objetos de acceso a datos.
DatabaseManager: Administra toda la conexión a la capa de acceso a datos. Database: Administra la conexión al servidor de base de datos.
SchemaManager: Administra el acceso a los objetos de un determinado esquema en la base de datos.
5.4. Diagramas de clases 55
Figura 5.6: Diagrama de clases - Implementación API
de datos mapeados.
TableManager: Manejador de objetos de base de datos tipo Tabla.
ViewManager: Manejador de objetos de base de datos tipo Vista.
StoreProcedureManager: Manejador de objetos de base de datos tipo Procedimiento almacenado.
DatabaseFactory: Fabrica encargada de crear las instancias de los objetos Database implementados para cada motor de bases de datos.
La gura 5.7 muestra el diagrama de clases de las estructuras Manager.
Como soporte para la administración de los objetos de acceso a datos se denieron una serie de clases que permitan dar soporte a funcionalidades auxiliares y dar soporte para la herencia de clases especícas para los objetos mapeados.
Figura 5.7: Diagrama de clases - Engine ADO - Manager
ObjectEnum: Clase base para la identicación de objetos mapeados.
ObjectEnum: Clase base para la creación de clases con listados de objetos mapeados. XmlBase: Clase base para la creación de objetos de representación de registros de una consulta que puedan ser serializados.
ConectionStringHelper: Clase auxiliar que provee métodos para manipulación de cadenas de conexión a los motores de bases de datos.
SchemaMappingManager: Permite administrar la conguración de Alias para los esquemas de base de datos en tiempo de ejecución.
5.4. Diagramas de clases 57
Figura 5.8: Diagrama de clases - Engine ADO - Utils
5.4.2.2. Implementación
El modelamiento por componentes permite que el sistema se pueda expandir horizontal-mente implementado funcionalidades para nuevos motores de bases de datos sin necesidad de modicar los desarrollos existentes.
La gura 5.9 muestra el diagrama de clases de la implementación de la clase Database para dos diferentes motores de bases de datos del Engine ADO.
5.4.3. Capa de Acceso a Datos
Figura 5.9: Diagrama de clases - Engine ADO - Implementación
5.4.3.1. DatabaseManager
El envolvente del proceso de acceso a datos estará compuestos por las siguientes clases:
5.4. Diagramas de clases 59
yyySchema: Corresponde a los administradores de acceso a cada uno de los esquemas de la base de datos, heredan de SchemaManager y se encargan de agrupar las instancias de acceso a cada uno de los objetos de la base de datos. El prejo yyy corresponde al nombre congurado por el usuario para el esquema al que se está accediendo. En la gura 5.10 se muestra un ejemplo de esta clase al que se ha denominado BaseSchema. tttTable: Corresponde a los administradores de acceso a cada una de las tablas de la base de datos, heredan de TableManager y se encargan de agrupar los métodos de acceso a datos de la tabla mapeada. El prejo ttt corresponde al nombre de la tabla a la que se está accediendo. En la gura 5.10 se muestra un ejemplo de esta clase al que se ha denominado t_hijoTable.
vvvView: Corresponde a los administradores de acceso a cada una de las vistas de la base de datos, heredan de ViewManager y se encargan de agrupar los métodos de acceso a datos de la vista mapeada. El prejo vvv corresponde al nombre de la vista a la que se está accediendo. En la gura 5.10 se muestra un ejemplo de esta clase al que se ha denominado v_hijoView.
sssStoreProcedure: Corresponde a los administradores de acceso a cada uno de los procedimientos almacenados de la base de datos, heredan de StoreProcedureManager y se encargan de agrupar los métodos de acceso a datos del procedimientos almacenados mapeado. El prejo sss corresponde al nombre del procedimientos almacenados al que se está accediendo. En la gura 5.10 se muestra un ejemplo de esta clase al que se ha denominado p_hijo_getStoreProcedure.
La gura 5.10 muestra el diagrama de clases del envolvente del proceso de acceso a datos con ejemplos de nombrado de clases de acuerdo a la estructura de la base de datos.
La gura 5.11 muestra de forma detallada la herencia implementada en los administradores de objetos de base de datos.
5.4.3.2. Objetos Tipados
Una de las principales virtudes del diseño propuesto para la generación de la capa de acceso a datos son los objetos fuertemente tipados que describen los resultados de las consultas. Para cumplir con este objetivo se modelan clases que permitan describir un conjunto de resultados devueltos por el motor de bases de datos y que corresponden a tablas y vistas. Estas clases heredan de la clase DataTable de ADO.Net, la cual a su vez representa un conjunto registros de tipo DataRow.
Para facilitar la visualización de datos con los objetos provistos por .Net se implementaron DataSets a partir de los esquemas de la base de datos los cuales agrupan objetos DataTable tipados. La gura 5.12 muestra el diagrama de implementación de los DataSets.
Figura 5.10: Diagrama de clases - DAL - DatabaseManager
de datos que facilite su manipulación, sin la necesidad de crear un DataTable, se diseñaron objetos xxxType y xxxSimpleType.
