Diseño e Implementación de una Herramienta CASE...

Diseo e Implementacin de una

Herramienta CASE para la Generacin de

Capas de Acceso a Datos .Net

Trabajo de Grado Especializacin

Mara Fernanda Rodrguez Zambrano

Pablo Yanod Mrquez Restrepo

Especializacin en Ingeniera de Software

Facultad de Ingeniera

Universidad Distrital Francisco Jos de Caldas

Bogot D.C. Mayo 2017

Documento maquetado con TEXiS v.1.0+.

Este documento est preparado para ser impreso a doble cara.

Diseo e Implementacin de una

Herramienta CASE para la Generacin de

Capas de Acceso a Datos .Net

Memoria que presenta para optar al ttulo de Especialista en Ingeniera de Software



Dirigida por el Doctor

Sandro Javier Bolaos Castro

Revisado por la M. Sc.

Nancy Yaneth Gelvez Garca

Especializacin en Ingeniera de Software

Facultad de Ingeniera

Universidad Distrital Francisco Jos de Caldas

Bogot D.C. Mayo 2017

Copyright c Mara Fernanda Rodrguez y Pablo Yanod Mrquez

Al duque de Bjary

a t, lector carsimo

En dos ocasiones me han preguntado:"Si pone datos incorrectos en la mquina,

saldrn las respuestas correctas?".Soy absolutamente incapaz de hacerme una idea

del tipo de confusin de ideasque pueden provocar que alguien haga

una pregunta asCharles Babbage

Agradecimientos

A todos los que la presente viereny entendieren.

Inicio de las Leyes Orgnicas.

Juan Carlos I

Agradezco este trabajo a la suma de mis historias y mltiples ancdotas con sus respectivosactores principales y secundarios; permitiendo el desarrollo de un camino a nuevo conocimientoy mejores practicas en mi labores, tambin a quienes obstaculizaron mi andar para incentivarmi ingenio y motivarlo a la creatividad. Agradezco a mi mami por apoyarme dentro de suscapacidades y en cada oportunidad en la que encontr un espacio. Por ultimo y por ende msespecial agradezco a mi pareja al recorrer este trayecto a mi lado creciendo para un futuro conms oportunidades.


Al culminar este trabajo no puedo menos que pensar en todo aquello que sum a que estemomento se de. En esa larga lista de personas que me han apoyado debo destacar a mi padre,quin no solo con su ejemplo me oriento en la va acadmica sino que fue el primero en darmeuna leccin de programacin sin estar vinculado con la ingeniera de sistemas, a mi madre porensearme a nunca rendirme, a Julin y Eliseo, por haberse embarcado en tantas empresasconmigo, a doa suegra por ese apoyo ms all de lo moral y sobre todo a mi encantadoraesposa quien prcticamente me arrastr para ingresar a la especializacin y da a da se asegurque asistiera a clases.


ix

Resumen

La simplicidad llevada al extremo,se convierte en elegancia.

Jon Franklin

La meta general de este trabajo fue el desarrollo e implementacin de una herramientaCASE1 para la generacin de capas de acceso a datos en .Net para la empresa SolucionesLgicas Yayan Gaia con el n de estandarizar la codicacin de la capa de acceso a datos ydisminuir los tiempos de desarrollo en dicha empresa.

Para el diseo y desarrollo del producto se emplearon diversas metodologas que permitie-ron alcanzar los objetivos planteados entregando la documentacin acorde a lo convenido conla empresa. Tambin se aplic patrones como puente y estrategia sobre la misma, permitiendocodicar la herramienta para que sea fcil de mantener y extensible a nuevas funcionalida-des como la implementacin de motores de bases de datos diferentes a los entregados en estaversin y nuevos lenguajes de programacin.

Se realizaron las pruebas correspondientes sobre el aplicativo y las mediciones pertinentesde los tiempos de la herramienta contra aplicativos similares en el mercado.

Palabras clave

Diseo de Software, Implementacin, Capa de Acceso a Datos, Modelo de desarrollo, MapeoObjeto-Relacional, Framework, Modelo Entidad Relacin, Casa de software, Tiempo Desarrollo

1Computer Aided Software Engineering

xi

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 forthe generation of data access layers in .Net for the company Soluciones Logicas Yayan Gaiawith the nal purpose to standardize the coding of the data access layer and decrease thetimes of development in the company.

For the design and development of the product were use several methodologies and thatallowed get the stated objectives by delivering the documentation according to the agreedwith the company. Also applies patterns such as bridge and strategy over it, allowing encodethe tool to be easy to maintain and extendable to new functionalities like the implementationof dierent database engines from the ones delivered in this version and new programminglanguages.

The corresponding tests were carried out on the application and the measurements Of thetimes of the tool in the market.

Keywords

Software Desing, Implemention, Data Access Layer, Development Model, Object Relationlamapping, Framework, Relatonship Entity Model, Software Factory, Development Time

xiii

ndice

Agradecimientos ix

Resumen xi

Abstract xiii

Introduccin xxv

I Fundamentacin de la Investigacin 1

1. Descripcin de la Investigacin 3

1.1. Denicin del Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1. Descripcin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.2. Formulacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2. Hiptesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3.2. Objetivos Especcos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4. Justicacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.1. Social . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.2. Ecolgica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.3. Tecnolgica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Marco de Referencia 7

2.1. Marco Terico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

xv

xvi ndice

2.1.5. Archimate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.6. ADM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2. Marco Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3. Marco Espacial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.1. Soluciones Lgicas Yayan Gaia . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.2. Estrategia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.3. Estructura Organizativa . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.4. Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.5. Productos y Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3. Aspectos Metodolgicos 19

3.1. Tipo de Estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2. Mtodo de investigacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.1. Metodologa de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.2. Mtrica Asociada al Producto . . . . . . . . . . . . . . . . . . . . . . . . 21

II Desarrollo de la investigacin 23

4. Anlisis 25

4.1. Capa de Negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.1. Punto de vista Organizacin . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1.2. Punto de vista Cooperacin de Actor . . . . . . . . . . . . . . . . . . . . 27

4.1.3. Punto de vista Funcin de Negocio . . . . . . . . . . . . . . . . . . . . . 28

4.1.4. Punto de vista Proceso de Negocio . . . . . . . . . . . . . . . . . . . . . 29

4.1.5. Punto de vista Cooperacin de Proceso de Negocio . . . . . . . . . . . . 30

4.1.6. Punto de vista Producto . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2. Capa de Aplicacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2.1. Punto de vista Uso de Aplicacin . . . . . . . . . . . . . . . . . . . . . . 32

4.2.2. Punto de vista Comportamiento de Aplicacin . . . . . . . . . . . . . . 33

4.2.3. Punto de vista Cooperacin de Aplicacin . . . . . . . . . . . . . . . . . 34

4.2.4. Punto de vista Estructura de Aplicacin . . . . . . . . . . . . . . . . . . 35

4.3. Capa de Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3.1. Punto de vista Infraestructura . . . . . . . . . . . . . . . . . . . . . . . 36

4.3.2. Punto de vista Uso de Infraestructura . . . . . . . . . . . . . . . . . . . 36

4.3.3. Punto de vista Implementacin y Despliegue . . . . . . . . . . . . . . . . 37

4.3.4. Punto de vista Estructura de Informacin . . . . . . . . . . . . . . . . . 38

4.3.5. Punto de vista Realizacin del Servicio . . . . . . . . . . . . . . . . . . . 39

4.3.6. Punto de vista Niveles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

ndice xvii

4.4. Capa de Motivacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4.1. Punto de vista Stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4.2. Punto de vista Realizacin de Objetivos . . . . . . . . . . . . . . . . . . 42

4.4.3. Punto de vista Contribucin de Objetivos . . . . . . . . . . . . . . . . . 43

4.4.4. Punto de vista Principios . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.4.5. Punto de vista Realizacin de Requerimientos . . . . . . . . . . . . . . . 45

4.4.6. Punto de vista Motivacional . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.5. Capa de Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.5.1. Punto de vista Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.5.2. Punto de vista Migracin . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.5.3. Punto de vista Migracin e Implementacin . . . . . . . . . . . . . . . . 48

5. Diseo 49

5.1. Diagramas de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.2. Diagramas de Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.3. Diagramas de Secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.4. Diagramas de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.4.1. API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.4.2. Engine ADO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.4.3. Capa de Acceso a Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6. Codicacin 65

6.1. API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.1.1. DbStructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.1.2. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.2. Implementaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.2.1. MapperManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.2.2. CodierManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.2.3. IConnectionAdo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.2.4. Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.2.5. DatabaseFactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6.3. Capa de Acceso a Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6.3.1. xxxDatabaseManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6.3.2. xxxDatabaseManager.Designer . . . . . . . . . . . . . . . . . . . . . . . 85

6.3.3. Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

6.4. Interfaz Grca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

7. Pruebas 115

7.1. Pruebas de Aceptacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

xviii ndice

III Cierre de la investigacin 119

8. Conclusiones 121

8.1. Resultados y discusin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

8.1.1. Tiempo de ejecucin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

8.1.2. Lneas de cdigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

8.1.3. Matenibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

8.1.4. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

8.2. Vericacin, contraste y evaluacin de los objetivos . . . . . . . . . . . . . . . . 126

8.3. Sntesis del modelo propuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

8.3.1. Trabajos de Investigacin futuros . . . . . . . . . . . . . . . . . . . . . . 127

IV Apndices 129

A. Formato IEEE830 131

B. Manual del Usuario 143

Bibliografa 201

Lista de Acrnimos 203

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 Organizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2. Punto de vista Cooperacin de Actor . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3. Punto de vista Funcin de Negocio . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.4. Punto de vista Proceso de Negocio . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.5. Punto de vista Cooperacin de Proceso de Negocio . . . . . . . . . . . . . . . . 30

4.6. Punto de vista Producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.7. Punto de vista Uso de Aplicacin . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.8. Punto de vista Comportamiento de Aplicacin . . . . . . . . . . . . . . . . . . . 33

4.9. Punto de vista Cooperacin de Aplicacin . . . . . . . . . . . . . . . . . . . . . 34

4.10. Punto de vista Estructura de Aplicacin . . . . . . . . . . . . . . . . . . . . . . 35

4.11. Punto de vista Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.12. Punto de vista Uso de Infraestructura . . . . . . . . . . . . . . . . . . . . . . . 36

4.13. Punto de vista Implementacin y Despliegue . . . . . . . . . . . . . . . . . . . . 37

4.14. Punto de vista estructura de informacin . . . . . . . . . . . . . . . . . . . . . . 38

4.15. Punto de vista realizacin 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 Realizacin de Objetivos . . . . . . . . . . . . . 42

4.19. Caso de estudio punto de vista Contribucin de objetivos . . . . . . . . . . . . 43

4.20. Caso de estudio punto de vista Principios . . . . . . . . . . . . . . . . . . . . . 44

4.21. Caso de estudio punto de vista Realizacin 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 Migracin e Implementacin . . . . . . . . . . . . . . . . . . . . 48

xix

xx ndice de figuras

5.1. Diagrama de Casos de uso - Arquitecto de informacin . . . . . . . . . . . . . . 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 - Denicin API . . . . . . . . . . . . . . . . . . . . . . . . 54

5.6. Diagrama de clases - Implementacin 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 - Implementacin . . . . . . . . . . . . . . . 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 conguracin de la capa de acceso a datos 66

6.2. Interface grca - Inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

6.3. Interface grca - Formulario MDI . . . . . . . . . . . . . . . . . . . . . . . . . 111

6.4. Interface grca - Diseador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

6.5. Interface grca - Esquemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

6.6. Interface grca - Filtros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

6.7. Interface grca - Procedimientos almacenados . . . . . . . . . . . . . . . . . . 113

8.1. Tiempo ejecucin Init() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

8.2. Tiempo ejecucin SELECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

8.3. Tiempo ejecucin INSERT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

8.4. Tiempo ejecucin UPDATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

8.5. Tiempo ejecucin DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

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. Lneas de cdigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

8.2. Mantenibilidad del cdigo fuente . . . . . . . . . . . . . . . . . . . . . . . . . . 125

8.3. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

xxi

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

xxiii

Introduccin

La diferencia entre la teora y la prctica es que,en teora, no hay diferenciaentre la teora y la prctica.

Richard Moore, desarrollador de KDE

En el desarrollo de sistemas transaccionales para clientes empresariales, unos de los puntoscrticos corresponden al almacenamiento de la informacin y gran cantidad de los esfuerzos dedesarrollo se orientan a la interaccin entre los mdulos cliente y los servidores de bases dedatos.

Este es el caso de SLYG2, una casa de desarrollo de software que divide sus esfuerzos entrelos desarrollos a la medida y el soporte a productos de software propios, donde se requiereaumentar la productividad de su equipo de desarrollo estandarizando la codicacin de lacapa de acceso a datos y disminuyendo el esfuerzo requerido para la generacin de la misma.

En el presente trabajo se plantea el desarrollo de una herramienta CASE que automatice lageneracin del cdigo de objetos de acceso a datos tipo ORM3 y lo combine con la generacindinmica de sentencias de un CRUD4 permitiendo minimizar los esfuerzos de la creacin dela DAL5 en un proyecto de desarrollo de software que requiera de persistencias de datos,ganando las ventajas del cdigo con objetos fuertemente tipados que garantiza al momentode la compilacin encontrar errores de sincronizacin con la estructura de la base de datos ypermitan el desarrollo de lgica de negocio independiente del motor de bases de datos utilizadoen tiempo de ejecucin y aprovechar las funcionalidades especcas de este ltimo.

2Soluciones Lgicas Yayan Gaia S.A.S.3Object-Relational Mapping4Create, Read, Update and Delete5Data Access Layer

xxv

Parte I

Fundamentacin de la Investigacin

Esta primera parte dene los fundamentos de la investigacin esbozando el planteamiento delproblema, los marcos tericos de la investigacin y la metodologa de la investigacin.

Captulo 1

Descripcin de la Investigacin

El valor de una idea radicaen el uso de la misma

Tomas A. Edison

Resumen: El presente capitulo permite explorar el planteamiento del problema tratado,

la justicacin, hiptesis, objetivos y la metodologa seguida.

1.1. Denicin del Problema

1.1.1. Descripcin

En un entorno empresarial de desarrollo de software, la creacin de la capa de acceso adatos es un proceso altamente operativo, por lo que se requiere una inversin importante detiempo; es as como el 80% de las acciones empleadas en esta actividad es repetitiva y desgas-tante. Al momento de requerir que una aplicacin en tiempo de ejecucin pueda conectarse adiferentes motores de bases de datos se cuenta con dos opciones: usar ODBC1, o programar unmodelo 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 opcionesdisponibles empezarn a tornarse inmanejables puesto que, por un lado las soluciones artesa-nales propias de las empresas se construyen a partir de copiar y pegar cdigo a los diferentesaplicativos y mdulos sin un estndar denido, y de otro lado, al utilizar Entity Framework,aunque permite la generacin automtica de la capa de acceso a datos, presenta el problema

1Open DataBase Connectivity

3

4 Captulo 1. Descripcin de la Investigacin

que las sentencias son complejas por la utilizacin de LINQ2, y requiere desarrollos adicionalespara el manejo de mltiples motores de bases de datos. Es por esto que estas opciones, que sonlas ms usadas en el mercado, generan una gran complejidad en su implementacin y trabajoadicional de mantenimiento.

Por lo anteriormente expuesto, se hace necesario desarrollar una herramienta que permitamapear la base de datos, independiente del motor que emplee, y genere automticamenteel cdigo de acceso a datos con objetos fuertemente tipados, que permitan detectar error almomento de la compilacin y requieran una mnima interaccin o modicacin por parte deldesarrollador, de tal manera que garantice que con solo cambios en la conguracin de lacadena de conexin, se pueda acceder a diferentes motores de bases de datos en tiempo deejecucin.

1.1.2. Formulacin

De qu manera es posible automatizar el proceso de mapeo de una base de datos paragenerar automticamente el cdigo de acceso, teniendo en cuenta que requiera realizar nica-mente los ajustes en la cadena de conexin, independientemente del motor de la base de datosde que se utilice?

1.2. Hiptesis

Una herramienta CASE puede disminuir el esfuerzo de desarrollo y mantenimiento en lasactividades de interaccin con la base de datos si genera de manera automtica la capa deacceso a datos con una mnima interaccin del desarrollador, teniendo en cuenta que requierarealizar nicamente los ajustes en la cadena de conexin, independiente del motor de la basede datos de que se utilice en tiempo de ejecucin.

1.3. Objetivos

1.3.1. Objetivo General

Disear e implementar una herramienta CASE en la empresa SLYG que permita generarautomticamente una capa de acceso a datos en aplicaciones .Net, conectndose indistintamen-te a Oracle, SQL Server y PostgreSQL, mediante objetos fuertemente tipados y nicamente apartir de cambios en la cadena de conexin.

1.3.2. Objetivos Especcos

Elaborar el diseo de la arquitectura de la herramienta CASE de manera que cumplacon los principios de diseo de software, mediante la aplicacin de la arquitectura acorde

2Language Integrated Query

1.4. Justicacin 5

con el tipo de desarrollo a realizar.

Desarrollar los artefactos propuestos en la fase de diseo aplicando un modelo de desa-rrollo de software pertinente para asegurar la calidad del producto.

Implementar una mtrica que permita realizar la comparacin entre los tiempos de de-sarrollo previos y posteriores al desarrollo de la herramienta.

1.4. Justicacin

1.4.1. Social

En un entorno econmico donde iniciar un nuevo emprendimiento en el sector de tecnologasy desarrollo de software es una hazaa gigantesca; puesto que las diferentes actividades deadministracin y mercadeo de una pequea o mediana empresa consume un porcentaje altodel tiempo de sus trabajadores dejando porcentajes bajos del mismo para el desarrollo deprocesos misionales aumentando la posibilidad de fracaso.

Bajo la perspectiva de lo antes expuesto cualquier esfuerzo encaminado a disminuir lostiempos de desarrollo y aumentar la productividad en la creacin de piezas de software mejoralas probabilidades de que las empresas salgan adelante y se vuelvan generadoras de empleo.

1.4.2. Ecolgica

El consumo de energa de forma irracional genera un alto impacto ambiental o alteracinnegativa en el medio ambiente; repercutiendo en la calidad de vida y salud de la humanidaden general, puesto que usualmente la produccin de energa encuentra su fuente en procesosque implementan combustible fsil donde se utiliza el calentamiento de un alto volumen deagua para generar vapor contaminando el aire y fuentes hdricas.

Actualmente la produccin y uso de energa se cataloga como una de las principales causasde las emisiones de gases de efecto invernadero, que a su vez son los directamente responsablesdel cambio climtico, aumento de temperaturas, subida de nivel de mar, y disminucin deprecipitaciones.

Por lo anterior se considera que un aporte positivo a esta problemtica es la reduccin delconsumo energtico, minimizando tiempos de uso de los equipos de computo al decrecer eltiempo de desarrollo y de procesamiento haciendo las aplicaciones ms ecientes.

1.4.3. Tecnolgica

En la actualidad las empresas de desarrollo de software de tamao mediano o pequeoenfrentan uctuaciones en la demanda de sus servicios y productos lo que conlleva a que endeterminados periodos cuenten con un alto nivel de trabajo y en otros periodos, con ndicesmuy bajos de ocupacin. Esto impide a estas empresas, contar con un nmero de personal

6 Captulo 1. Descripcin de la Investigacin

suciente para atender los picos de alta demanda, situacin en la que se encuentra SolucionesLgicas Yayan Gaia, que cuenta con un nmero reducido de desarrolladores, equipo de soportey capacitacin. La alta demanda de servicios de soporte, generacin de nuevos requerimientosexigen ms tiempo de atencin; por consiguiente, al analizar las actividades que requierenmayor inversin en tiempo dentro de los procesos propios de un desarrollo, se encuentra que esla codicacin de la capa de acceso a datos y requiere an ms tiempo cuando los desarrollosdeben permitir la conexin a diferentes motores de bases de datos dependiendo de cul tengalicenciado el cliente.

Las actividades relacionadas con el acceso a datos para una aplicacin o sistema puedenser estandarizadas mediante una solucin informtica que permita minimizar los tiempos decodicacin, realizar un mantenimiento ecaz a los desarrollos en curso, eliminando las tareasrepetitivas mediante la automatizacin de la generacin del cdigo requerido en dicho proceso ypor consiguiente reduciendo el tiempo de desarrollo de las aplicaciones, lo que le permitir a laempresa optimizar los tiempos de entrega de las mismas y de igual manera para el desarrolladorle permitir mitigar los errores de codicacin y mejorar su tiempo de trabajo enfocndose enoperaciones de mayor criticidad.

Captulo 2

Marco de Referencia

Rem tene, verba sequentur (Si dominas el tema,las palabras vendrn solas)

Catn el Viejo

2.1. Marco Terico

Para el desarrollo de sistemas transaccionales, uno de los puntos crticos corresponde a lapersistencia de la informacin y gran cantidad de los esfuerzos de desarrollo se orientan a lainteraccin entre mdulos cliente y los servidores de bases de datos. Mediante este artculose pretende validar algunas de las soluciones existentes para el entorno de desarrollo .Net yel respectivo desempeo de las mismas de tal manera que permita al lector decantarse por lasolucin ms conveniente para su gestin.

El dato, en trminos generales para el diccionario de la real academia proviene del latnDatum Lo que se da y en su primera denicin arma que es informacin sobre algo enconcreto que permite su conocimiento exacto o sirve para deducir las consecuencias derivadasde un hecho (RAE, 2016) para los trminos de este articulo un dato es la parte ms pequeade lo que pueda considerarse como informacin conforme al criterio y experiencia del autor ya la aplicacin dada en las diferentes comparaciones aqu evidenciadas.

Un dato puede contar con diferentes niveles de abstraccin; Fsico que describe como sealmacenan los datos, Lgico que es el nivel ms alto que conserva la relacin entre datos y si sealmacenan en una base de datos o no, y por ultimo nivel de vistas el cual muestra nicamenteuna fraccin de la base de datos. (Silberschatz, 2002)

La persistencia es permitir a los datos en una aplicacin 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 noprocedimiento que se reere a los resultados de una operacin (Oppel y Sheldon, 2009) donde

7

8 Captulo 2. Marco de Referencia

generalmente la arquitectura a utilizar es por capas para garantizar que cada capa dimen-sionada se encargue de una funcin en particular, las capas superiores se comunican con lasinferiores y solo dependen de la comunicacin directa con la inmediatamente inferior.

Como es bien conocido el modelo en esencia consta de tres capas: presentacin, lgica delnegocio y persistencia; permitiendo reducir la complejidad del desarrollo (Kuat et al., 2008)donde la capa de datos puede ser manejada mediante codicacin manual, para el caso de.Net mediante herramientas ADO.Net o mediante una herramienta que permita la generacinde dicho cdigo de forma automtica utilizando el mapeo de objetos relacionales (ORM) quese dene como la traduccin de objetos a entidades relacionales o viceversa siendo el puenteque permite manipular objetos y proveyendo diferentes caractersticas para automatizar elalmacenamiento de datos lo ms transparente posible (Kuat et al., 2008) y posteriormenteimplementar operaciones CRUD o de manipulacin de datos, donde usualmente se utilizan losDataSets que son una representacin de los datos en memoria que corresponden al origen dedatos, 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 conexin y acceso a datos, proporcio-nando acceso coherente a diferentes orgenes de datos y es el mtodo ms directo para realizareste proceso (Microsoft, 2016c).

Los DataReaders permiten recuperar a ujos de datos de solo lectura y solo avance de unabase de datos, un DataAdapter se utiliza para recuperar datos de un origen de datos y llenartablas 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 programacin orientada a objetos trabajar sin un co-

1Entity Framework

2.1. Marco Terico 9

nocimiento profundo en SQL2 o su respectiva programacin, trabajar en la persistencia de lasaplicaciones bajo estas caractersticas, 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 quepermite fcilmente identicar sobre que objeto de la base de datos se est trabajando, im-plementando consultas con nombres y propiedades adecuados, para ser comprendidos por elmanejador de bases de datos correspondientes, para esto cuenta con dos APIs3 de consulta.

La primera se denomina HQL4 que permite usar cdigo SQL pero a su vez muchas carac-tersticas de la programacin orientada a objetos ya que ofrece funciones de acceso a cdigoestndar SQL tales como: agregacin, propsito general, matemticas, cadenas de texto, entreotras, se encuentra que no soporta Outer Joins, no permite seleccionar todos los registros dela tabla, el SELECT es opcional, entre otras cosas.

La segunda es QBC5 que provee un conjunto de clases que permite crear consultas a laeleccin del programador siendo un manejo ms conceptual y permite realizar las consultas endiferentes pasos, lo que lo hace un poco ms complejo y menos intuitivo (Kuat et al., 2008)(Peres, 2014).

Nhibernate permite una gran gama de conexiones a diferentes motores de bases de datosdentro 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-cin, pero no asegura la independencia total de la base de datos, adicional a que siempre seencontrar 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 superponervarias capas de abstraccin sobre un almacn relacional con el n de hacer posible una pro-gramacin ms conceptual (basada en los conceptos del dominio con el que se trabaja) y dereducir a una mnima expresin el desajuste de impedancias causado por las diferencias entrelos modelos de programacin relacional y orientado a objetos.(Castro, 2011)

Esta herramienta permite trabajar tres maneras como se muestra en la grca 2.1:

Base de datos primero.

Modelo primero.

Cdigo primero.

Como se evidencia en el grco anterior se puede trabajar desde una base de datos existente,desde un modelo existente o desde un modelo de datos que parten clases (orientacin a objetos).

2Structured Query Language3Application Programming Interfaces4Hibernate Query Language5Query by Creteria API


Para las dos primeras opciones se requiere del EDM6, el cual permite la creacin de los modelosconceptuales y cuenta con: ambiente para gracar los diagramas, ventana de detalles demapeo, ventana navegacin por el modelo y ventana de herramientas operando en conarchivos de tipo edmx correspondientes al tipo de archivo que maneja EF para su modelo deentidades(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 tambin es posible el manejo agnstico al momento trabajar con diferentes motoresde bases de datos,ofreciendo la posibilidad a los desarrollos de ser multi-base de datos ypermitiendo interactuar con algunos de los siguientes manejadores: Oracle, Mysql, SqlLite,PostgreSQL(Castro, 2011).

6Modelo de Entidades

2.1. Marco Terico 11

2.1.4. Dapper

Dapper framework fue creado por Samm Saron, y tiene un alto desempeo por usarmtodos dinmicos de generacin para asignar valores de columna a propiedades(liangwu,2012).

Provee asistentes para: ejecutar consultas y mapear objetos fuertemente tipados, ejecutarconsultas y mapear sus resultados a una lista dinmica de objetos, ejecutar comandos endiferentes momentos(Gravell, 2016).

Las cualidades ms destacadas de esta herramienta son: velocidad y rapidez en su rendi-miento, pocas lneas de cdigo, mapeo de objetos, enlace de objetos estticos, enlace a objetosdinmicos, fcil manejo de consultas SQL y procedimientos almacenados, soporte a diferen-tes consultas, opera directamente en la clase IDBConection entre otras caractersticas, que leotorgan un alto desempeo y le permiten la ejecucin de operaciones CRUD.(Parikh, 2015)

2.1.5. Archimate

El lenguaje de modelado Archimate permite representar la Arquitectura Empresarial deuna organizacin bajo tres bsicas perspectivas: negocio, sistemas y tecnologa.

El lenguaje Archimate sirve para disear Arquitecturas Empresariales que faciliten laadopcin de tecnologa en las empresas, vinculando los procesos de negocio con los activostecnolgicos. facilita la administracin de proyectos de tecnologa y cambio organizacional,permitiendo que los expertos de negocio puedan priorizar los requerimientos de alto nivel ygenerar proyectos que impacten positivamente la organizacin. Este modelo Archimate de-ne un conjunto de elementos estndar para el diseo de Arquitecturas Empresariales, lo cualayuda signicativamente a tener un lenguaje comn entre expertos de negocio y de tecnologa.

TOGAF7 en trminos simples es una herramienta para asistir en la aceptacin, creacin,uso y mantenimiento de arquitecturas. Basado en un modelo iterativo de procesos apoyadopor las mejores prcticas y un conjunto reutilizable de activos arquitectnicos existentes.

Se puede utilizar para desarrollar una amplia variedad de arquitecturas empresariales;adems complementa y se puede usar en conjunto con otros marcos de referencia que estnbasados en entregables especcos para sectores particulares. La clave de TOGAF es el mtodode desarrollo de la arquitectura ADM8, para desarrollar una arquitectura empresarial queaborda las necesidades de negocio.

Esta referencia arquitectnica es desarrollada y mantenida por el foro de arquitectura TheOpen Group. Este foro ha desarrollado versiones sucesivas de TOGAF con regularidad lascuales son publicadas en si sitio publico web.(TOGAF, 2017)

7The Open Group Architecture Framework8Architecture Development Method


2.1.6. ADM

El lenguaje ArchiMate, complementa a TOGAF brindando independencia de vendedor, yse centra en los conceptos, incluyendo representaciones grcas que ayudan a crear consistenciae integracin a travs de las diferentes guras y vistas de TOGAF.

La estructura del ncleo del lenguaje ArchiMate se corresponde estrechamente con las tresArquitecturas 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 ncleo de ArchiMate. Parcialmente, estoes porque el alcance de TOGAF es ms amplio y se ocupa tanto de estrategias de alto nivelcomo de aspectos del desarrollo de sistemas, mientras el ncleo de ArchiMate esta limitadonivel de abstraccin de la arquitectura empresarial.

Figura 2.2: Correspondencia entre ArchiMate y TOGAF

2.2. Marco Conceptual

Con los avances de la ingeniera de software y la evolucin de los procesos de desarrollose di cabida a los modelos de desarrollo por capas y con ellos el surgimiento de las capas deacceso a datos o DAL, en las cuales se encapsula toda la lgica de interaccin con la base dedatos aislndola de la lgica de negocio y la de presentacin.

2.3. Marco Espacial 13

En sistemas transaccionales la DAL cobra gran importancia y tiende a estar compuestaspor grandes cantidades de lneas de cdigo convirtindose en uno de los principales orgenesde fallos y requiriendo la inversin de esfuerzo tanto de desarrollo como de pruebas y soporte.

La estandarizacin de los mtodos de acceso a datos da por resultado un sinnmero delneas de cdigo relativamente similar para soportar las instrucciones bsicas de acceso a losobjetos de la base de datos. Los CRUD, se centran en la reduccin de este cdigo redundantepero al depender de sentencias creadas dinmicamente a partir de cadenas de texto que denenlos nombres de las entidades en la bases de datos crean otro punto susceptible a fallos cuandolos cambios en la estructura de la base de datos no es correctamente actualizada en las cadenasde texto y los procesos de compilacin no detectan los errores correspondientes.

Los ORM, solventan los inconvenientes de los CRUD al ligar la estructura relacional de labase de datos con objetos en el cdigo del cliente, permitiendo una mayor abstraccin de lalgica de acceso a datos y volvindola independiente del motor de base de datos pero agregandoun nuevo nivel de complejidad a las instrucciones de interaccin con los datos y la necesidadnuevamente de escribir gran cantidad de lneas de cdigo para denir las clases que representanlas entidades y cheros de conguracin que relacionan las propiedades de los objetos con lasentidades 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 ejecucin y que el uso deuno u otro motor solo requiera el cambio de la cadena de conexin nos encontramos con quelas lneas de cdigo necesarias para soportar esta interaccin crecen exponencialmente o queel mantenimiento de las conguraciones en un ORM se vuelven inmanejables y restringen eluso de funcionalidades especcas de cada motor de base de datos.

2.3. Marco Espacial

2.3.1. Soluciones Lgicas Yayan Gaia

SLYG9, es una empresa conformada por un grupo de profesionales expertos en diseo ydesarrollo de software moderno, amigable, rpido y seguro. Surgi como proveedora de softwarepor demanda a empresas prestadoras de servicios al sector nanciero, una actividad exigenteen trminos de los tiempos de respuesta y de la conabilidad necesaria. De esta han salidoaplicaciones que el Grupo Brinks10 usa para prestar servicios a empresas del sector nanciero.11

Con la certeza de que el diseo y desarrollo de productos propios genera mejores oportu-nidades y luego reforzados por una eventual reduccin de actividades del Grupo Brinks, en elao 2013 se aceler el cambio de nfasis desde el desarrollo de software por demanda hacia eldiseo y desarrollo de software propietario.

9Soluciones Lgicas Yayan Gaia S.A.S.10Brinks, Procesos & Canje, Domesa y ePago11Banco Agrario, AV Villas, Citibank, Davivienda, Coomeva, Credivalores, Crediservicios, Connanciera,

Pensiones y Cesantas Horizonte


En el ao 2011 el 75% de los ingresos operacionales se originaban en desarrollo por demanday 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 tenan su origen el desarrollo y suministro de personal,pero ya un 32% correspondi al ingreso por licencias de nuestros productos y actividadesrelacionadas12.

Para el ao 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. Misin

SLYG tiene como misin disear, desarrollar e implementar herramientas y sistemas desoftware que sean de apoyo a las organizaciones, personas y sociedad en la que cual operamos,para de esta manera convertirse en un proveedor estratgico para dichas empresas.

2.3.2.2. Visin

SLYG se propone convertirse en un aliado estratgico para las empresas, personas y socie-dad, brindndoles a nuestros clientes las mejores soluciones del mercado en cuanto a sistemasde informacin de apoyo crtico 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.

12Capacitacin, Implementacin y Hosting


2.3.3. Estructura Organizativa

2.3.4. Stakeholders

Al ser SLYG una SAS13, es dirigida por una Asamblea General de Accionistas, como sepuede ver en la gura 2.3, cuyo peso en las decisiones se ve reejado en su participacinaccionaria.

La tabla 2.1 muestra el listado de accionistas de SLYG y su participacin accionaria.

Accionista Identicacin Participacin

Libardo Yanod Mrquez Aldana 17.307.559 35%Eliseo Roa Piramanrique 79.902.959 30%Myriam Isaura Gutirrez Flores 51.636.007 22%Pablo Yanod Mrquez Restrepo 86.057.718 10%Julin David Duque Castro 80.019.536 3%

Tabla 2.1: Accionistas.

2.3.4.1. Organigrama

La gura 2.3 muestra de forma grca la estructura organizativa de la empresa SLYG quese encuentra dividida en dos Direcciones: Direccin de Desarrollo y Direccin de Relacionescon el Cliente. Rindiendo informe a la Asamblea General se encuentra el Gerente encargado deaplicar las directrices denidas por esta. Bajo la gerencia se encuentra un Coordinador Generalquien se encarga de las labores administrativas y a quien presentan informe las direcciones deDesarrollo y Relaciones con el Cliente.

13Sociedad por Acciones Simplicada


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 siguientemanera:

La Direccin de Desarrollo concentra las actividades referentes a los servicios de desarrollode software, soporte a las aplicaciones existentes y asesoras en arquitectura de software.

La Direccin de Relaciones con el Cliente se encarga de los procesos comerciales comopresentaciones, cotizaciones y ventas, as como del servicio de soporte para primer nivel.


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 lesbrinda actualizacin y soporte, el producto que actualmente requiere ms recursos por contarcon el ms alto nivel de demana en el mercado corresponde a Block.

Producto Descripcin

SLYG Block es un sistema de informacin Web que permi-te registrar los procesos de planeacin, Control y Gestin deProyectos de Construccin. Contiene mdulos de presupues-to, programacin de actividades/compras, almacn, rdenesde pedido/alquiler, sub-contratos, ventas y autorizaciones enlnea.

Fluxus BPM (Business Process Management) es un soft-ware especializado en Sistematizacin y Control de Procesossensibles de la compaa donde los tiempos de respuesta, ladenicin de responsabilidades y la integracin con diver-sos sistemas son fundamentales. Es el sistema perfecto paraprocesos como: Fbrica de Crdito, Aprobacin de Facturas,Compras, PQRS, Contratacin, entre otros.

Capturing Es un sistema para creacin y calicacin deexmenes tipo ICFES por Reconocimiento de Formatos Es-tndar, destinado a centros educativos especializados en lapreparacin de estudiantes para los mismos.

Tabla 2.2: Productos.


2.3.5.2. Servicios

La tabla 2.3 muestra un resumen de los servicios ofrecidos por SLYG donde el serviciocon mayor demanda corresponde al desarrollo de aplicaciones Web para diferentes tipos deempresas y personas naturales y juridicas .

Servicio Descripcin

Desarrollo de Software a la Medida. Servicio de diseoy desarrollo de plataformas empresariales de alto desempeopara soporte de procesos core del negocio.

Presupuesto Elaboracin de presupuestos de obras de cons-truccin, en este servicio se ofrece el clculo de cantidadesde obra, elaboracin de anlisis de precios unitarios, progra-macin de obra y ujo de caja.

Interventora Control e interventora de obras de cons-truccin, seguimiento de contratos e informes de avance deobra.

Tabla 2.3: Servicios.

Captulo 3

Aspectos Metodolgicos

La mejor estructura no garantizar los resultadosni el rendimiento. Pero la estructura equivocada es

una garanta de fracaso.

Peter Drucker

Resumen: En este captulo se aborda el tipo de estudio, la metodologa de investigacin

y el mtodo de desarrollo aplicado en este proyecto.

3.1. Tipo de Estudio

El tipo de estudio es descriptivo, puesto que se va a automatizar la generacin de cdigode la capa de acceso a datos para aplicaciones en .NET mediante un modelo lineal o cascada.

3.2. Mtodo de investigacin

En un contexto de ingeniera y por consiguiente un problema planteado en este mismo,es clave contar con una denicin clara del problema puesto que de lo contrario la propuestadar solucin a necesidades inexistentes, as como tambin es clave el diseo que le permite alingeniero pensar , proyectar y maquetar un artefacto que benecie a las personas.

Bajo la premisa que un ingeniero cuenta con un mtodo de diseo de una solucin, seconsidera el mtodo de anlisis el ms cercano al objetivo de este proyecto, puesto que permiteidenticar los componentes que interactan en el problema y validar la relacin causa- efectoen un entorno empresarial.

19

20 Captulo 3. Aspectos Metodolgicos

3.2.1. Metodologa de Desarrollo

El modelo lineal secuencial o modelo en cascada es el primer modelo conocido en el procesode desarrollo de software y comprende cinco etapas que se adelantan de manera secuencial oen cascada, de all el origen de su nombre.

Se selecciona este modelo puesto que cuenta con una implementacin simple, el recursorequerido para implementar el modelo es mnimo, por lo que es aplicable a un equipo detrabajo conformado por dos integrantes. Adicionalmente permite una documentacin en cadafase 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. Anlisis y denicin de los requisitos del sistema: Consiste en la recoleccin deinformacin de diferentes fuentes documentales, entrevistas, observacin, entre otras,para obtener el dominio del negocio y de esta forma entender realmente que es lo quese quiere, para luego plasmarlo en un documento tcnico de requerimientos, los cualesmuestran de forma prctica para el cliente y consistente para el desarrollador del softwaretoda 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. Tambinsirven para medir el avance en la elaboracin del software.

Para efectos de formalizar los requisitos en este proyecto se implementar la plantillaIEEE380.

2. Diseo: Es el proceso mediante el cual se hace una representacin del software, gene-ralmente se hace con diagramas UML1, los cuales permiten abordar el desarrollo delsoftware en cuatro atributos:

Estructura de datos.

Arquitectura del software.

Representacin 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. Codicacin: Consiste en llevar el diseo a lenguaje de mquina, su xito depende delcorrecto desarrollo de las fases de requerimientos y de diseo. Dentro de los entregablesen esta fase se cuenta con:

1Unied Modeling Language

3.2. Mtodo de investigacin 21

Cdigo fuente.

4. Pruebas: Consiste en vericar que los procesos internos del software funcionen, as comolas funcionalidades externas, de acuerdo a lo planteado en los requerimientos.

El modelo cascada cuenta con una quinta fase denominada mantenimiento, la cual no aplicapara este proyecto ya que el alcance del mismo se establece nicamente hasta las pruebas.

3.2.2. Mtrica Asociada al Producto

Con el n de determinar que el producto, obtenido mediante la herramienta CASE, cumplao no con la hiptesis planteada, se ha determinado una mtrica que permita denir el costetotal en tiempo y esfuerzo requerido por el desarrollador al momento de crear la capa de accesoa datos contrastada con el desempeo en tiempo de ejecucin del cdigo fuente generado.

Teniendo en cuenta las particularidades propias de la aplicacin y sondeando herramientassimilares en el mercado, se precisaron las siguientes variables de evaluacin con sus respectivosrangos de calicacin para cada herramienta a implementar:

1. Tiempo ejecucin: Se realiza a partir de la medicin del tiempo de ejecucin, enmilisegundos, de las instrucciones CRUD para 4.000 registros. El puntaje se calculacomo el resultado de la operacin (1-x/m)*100 donde x es el tiempo obtenido y m eltiempo mximo de comparacin. Cualquier valor con un tiempo mayor al mximo decomparacin se le asigna un puntaje 0.

2. Lneas de cdigo: Se calcula como la sumatoria del total de lneas de cdigo y con-guracin requeridas para realizar la ejecucin de las instrucciones CRUD. El puntaje secalcula como el resultado de la operacin (1-x/m)*100 donde x es la cantidad de lneasde cdigo y m la cantidad de lneas de cdigo mximas de comparacin.

3. Mantenibilidad: En esta variable se calcula la facilidad de detectar un error en elcdigo fuente una vez realizado un cambio en la estructura de la base de datos, paraesto 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 automticamente por la herramienta.

El resultado nal por herramienta se obtendr del promedio de los tres indicadores.

2Data Access Objects

Parte II

Desarrollo de la investigacin

Esta segunda parte contiene los captulos de desarrollo de la investigacin. Dene la arquitec-tura empresarial, desarrolla la metodologa propuesta y presenta los artefactos desarrollados.

Captulo 4

Anlisis

El alma nunca piensasin una imagen mental.

Aristteles

Resumen: En este captulo se aborda el anlisis de la arquitectura empresarial mode-

lndola con los puntos de vista de Archimate.

En la fase de anlisis de este trabajo se incluye la arquitectura empresarial; donde seidentica a la organizacin en un contexto de negocio en el que sus procesos misionales seenfocan en el desarrollo de sistemas de informacin y aplicaciones, por lo que en sus actividadesse identica al desarrollador y al arquitecto de informacin como los actores principales endichos procesos. La prioridad fue determinada por el proceso clave el cual es el desarrollo,puntualizando en la generacin de la capa de acceso a datos. Todo lo anterior se dimensionaen una infraestructura standalone que eventualmente se conectar a red dependiendo de laubicacin fsica de la base de datos, de igual manera para esta fase se realiz el renamientode los requerimientos a travs de el punto de vista motivacional que provee las restricciones yrequisitos a los proyectos.

Para la especicacin de los requerimientos se tom como base el formato IEEE830 elcual permite acercar al la empresa un documento formal donde se detallan los requerimientosconstruidos en conjunto y aquellos se identicaron implcitamente en esta fase. El formatopuede ser consultado en el apndice A.

4.1. Capa de Negocio

Un punto de vista en ArchiMate es una seleccin de un subconjunto relevante de losconceptos de ArchiMate (y sus relaciones) y la representacin de la parte de una arquitectura

25

26 Captulo 4. Anlisis

que se expresa en diferentes diagramas. Un conjunto de tales puntos de vista fue desarrolladobasado en la experiencia prctica.

Algunos de estos puntos de vista tienen un alcance limitado a una sola capa o aspecto. As,los puntos de vista de funcin de negocio y de proceso de negocio muestran las dos principalesperspectivas sobre el comportamiento del negocio; el punto de vista de organizacin representala estructura de la empresa en trminos de sus departamentos, roles, etc.

Otros puntos de vista vinculan mltiples capas o aspectos: el punto de vista de cooperacinde actor y producto se relacionan con la empresa a su entorno.

4.1.1. Punto de vista Organizacin

La gura 4.1 muestra el diagrama del punto de vista de organizacin que para este casoes SLYG una empresa que inici operacin en octubre de 2008, en su primera sede ubicadaen Nicols de Federman con tres empleados, en la actualidad se encuentra en el barrio AndesNorte, calle 94A # 60C - 45 ocina 202, y cuenta con ms de tres departamentos claramentedenidos, y con tres productos terminados de los cuales SLYG Block se esta abriendo paso enel mercado del software de construccin a pasos grandes y acelerados.

Los departamentos que soportan la operacin misional de SLYG son desarrollo y arquitec-tura de informacin puesto que son aquellos que generan nuevos productos y dan soporte alos vigentes.

Figura 4.1: Punto de vista Organizacin

4.1. Capa de Negocio 27

4.1.2. Punto de vista Cooperacin de Actor

La gura 4.2 muestra el diagrama del punto de vista de cooperacin de actor, para laempresa SLYG se cuenta con una colaboracin denominada Equipo de Desarrollo por Pro-yecto la cual est compuesta por dos roles: desarrollador SLYG y arquitecto de estructura deinformacin.

Un equipo de desarrollo es denido por el actor Unidad de Desarrollo que se encarga derealizar los desarrollos a las plataformas de software de la empresa determinado por el proyectoen particular, para una empresa cliente.

Figura 4.2: Punto de vista Cooperacin de Actor


4.1.3. Punto de vista Funcin de Negocio

La gura 4.3 muestra el diagrama del punto de vista de funcin de negocio para la empresaque abarca este proyecto este punto de vista se cuenta con tres (3) funciones principales: disearla base de datos, codicar el diseo y vericar el diseo. La funcin de codicar el diseo a suvez se compone de tres (3) sub funciones: generar capa de acceso a datos, generar lgica denegocio y generar interfaces grcas. Todas estas funciones componen el rol desarrollador.

Figura 4.3: Punto de vista Funcin de Negocio

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 casode estudio predomina la necesidad de facilitar y agilizar la implementacin de sistemas deinformacin como servicio clave. Para ello el proceso de desarrollo se inicia con el eventoEntregar un Diseo de Alto Nivel a partir del cual se inicia el sub proceso diseo de datos,continua el sub proceso de implementacin de la capa de acceso a datos y naliza con el subproceso de QA. Las pruebas de QA realiza las prueba y la aprobacin del producto de software.

Figura 4.4: Punto de vista Proceso de Negocio


4.1.5. Punto de vista Cooperacin de Proceso de Negocio

La gura 4.5 muestra el diagrama del punto de vista de cooperacin de proceso de negocio,donde se evidencia uno de los roles principales el cual es el desarrollador quien debe contarcon un perl acorde a un ingeniero de sistemas con las competencias otorgadas por el titulopara realizar el proceso de la implementacin de la capa de acceso a datos.

Figura 4.5: Punto de vista Cooperacin de Proceso de Negocio

4.2. Capa de Aplicacin 31

4.1.6. Punto de vista Producto

La gura 4.6 muestra el diagrama del punto de vista de producto que permite evidenciar losvalores principales del producto denido como DAL Designer, estos son: portabilidad de data,facilidade de uso y dimisnucin de los tiempo de desarrollo. De igual manera la herramientaen cuestin es privativa por lo que cuenta con una licencia de uso comercial y su principalnalidad es facilitar la abstraccin de la estructura de datos.

Figura 4.6: Punto de vista Producto

4.2. Capa de Aplicacin

El punto de vista de comportamiento, cooperacin y estructura de aplicacin contiene lasaplicaciones y componentes, y sus relaciones mutuas; el punto de vista de uso de aplicacin sereere a aplicaciones para su uso, por ejemplo, procesos de negocio.

Adems, el punto de vista de la aplicacin trata acerca de las aplicaciones de software quesoportan los componentes del negocio con servicios de aplicaciones, componentes de aplicacinreusables, e interfaces de comunicacin para estos componentes.


4.2.1. Punto de vista Uso de Aplicacin

La gura 4.7 muestra el diagrama del punto de vista de uso de aplicacin que modelael componente DAL Designer el cual presta el servicio de generacin de cdigo automticorepresentado para el proceso de codicacin de la capa de acceso a datos, que inicialmente sedescribi en modelado en la capa de negocio.

Figura 4.7: Punto de vista Uso de Aplicacin

4.2. Capa de Aplicacin 33

4.2.2. Punto de vista Comportamiento de Aplicacin

La gura 4.8 muestra el diagrama del punto de vista de comportamiento de aplicacindonde se describe el componente DAL Designer y sus interacciones con tres sub componentesque son: un Mapper encargado de leer el modelo de la base de datos e interpretar la estructurade la misma, un Codier encargado de generar el cdigo fuente de la capa de acceso a datos enconjunto con el tercer sub componente que es el Engine que facilita las instrucciones conformeal motor de base de datos.

Figura 4.8: Punto de vista Comportamiento de Aplicacin


4.2.3. Punto de vista Cooperacin de Aplicacin

La gura 4.9 muestra el diagrama del punto de vista de cooperacin de aplicacin dondedescribe la divisin de los paquetes del DAL Designer en Front Oce y Back Oce. Estasociado al Front el Componente DAL- Designer y el componente Client DAL, mientras queal Back Oce encontramos al Mapper y el Codier

Figura 4.9: Punto de vista Cooperacin de Aplicacin

4.3. Capa de Infraestructura 35

4.2.4. Punto de vista Estructura de Aplicacin

La gura 4.10 muestra el diagrama del punto de vista de estructura de aplicacin donde semodelan las interfaces de cada uno de los sub paquetes asociados al DAL Designer: IMapperdescribe las interacciones del paquete Mapper, ICodier describe las interacciones del paqueteCodier y por ultimo IConnection describe la paquete Client CAL, tambin se evidencia elData Object que permite relacionar el componente principal con el del cliente.

Figura 4.10: Punto de vista Estructura de Aplicacin

4.3. Capa de Infraestructura

Muchos de los conceptos de esta capa han sido inspirados en UML 2.0, y este es el dominiode este lenguaje en efecto describe las aplicaciones de software y la infraestructura, esta capabusca dibujar la analoga entre el negocio y la capa de aplicacin.


4.3.1. Punto de vista Infraestructura

La gura 4.11 muestra el diagrama del punto de vista infraestructura donde se modela lainfraestructura general del caso de estudio, donde la herramienta se encuentra en un equipoinstalada y permitir conectarse localmente o a un servidor de base de datos para mapear labase 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 aplicacin donde se modelauso de la infraestructura dispuesta para la aplicacin, con los respectivos componentes, comose puede observar la aplicacin modelada es standalone y dependiendo de la ubicacin de labase de datos requerir acceso a la red.

Figura 4.12: Punto de vista Uso de Infraestructura


4.3.3. Punto de vista Implementacin y Despliegue

La gura 4.13 muestra el diagrama del punto de vista de implementacin y desplieguedonde se puntaliza quee el despliegue se centrara en un PC sobre sistema operativo Windowsy bajo cdigo 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 enla misma maquina.

Figura 4.13: Punto de vista Implementacin y Despliegue


4.3.4. Punto de vista Estructura de Informacin

La gura 4.14 muestra el diagrama del punto de vista de estructura de informacin don-de se muestra las diferentes estructuras de informacin administrada por la herramienta, seencuentran objetos de datos como devoluciones, ltros, campos y relaciones de campos parasoportar las diversas funcionalidades de la herramienta

Figura 4.14: Punto de vista estructura de informacin


4.3.5. Punto de vista Realizacin del Servicio

La gura 4.15 muestra el diagrama del punto de vista de realizacin del servicio dondese relaciona la capa de aplicacin con la de negocio y permite realizar un sondeo claro delservicio principal implementado en la aplicacin junto con los objetos de datos con los queeste interacta, que para este caso es es la generacin de cdigo automtico.

Figura 4.15: Punto de vista realizacin del servicio


4.3.6. Punto de vista Niveles

La gura 4.16 muestra el diagrama del punto de vista Capas o niveles permite visualizarun todos los componentes principales detectados en capa actual y las previas.

Figura 4.16: Punto de vista niveles

4.4. Capa de Motivacin 41

4.4. Capa de Motivacin

La motivacin en una arquitectura empresarial, inuencia, orienta y limita el diseo. Esclave 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,tambin llamados preocupaciones, estn asociados con las partes interesadas, que pueden per-sonas o algn 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 identicael Stakeholder principal el cual es el desarrollador, cuyo conductor corresponde a plasmar losdiseos de software on compromiso de calidad para facilitar la implementacin de sistemas deinformacin.

Figura 4.17: Punto de vista StakeHolder


4.4.2. Punto de vista Realizacin de Objetivos

La gura 4.18 muestra el diagrama del punto de vista Realizacin de Objetivos permitiendovislumbrar los objetivos de SLYG y las restricciones as como sus requerimientos propios de laorganizacin enfocndose en el desarrollo e implementacin de sistemas de informacin y enel ofrecimiento de servicios TI

Figura 4.18: Caso de estudio punto de vista Realizacin de Objetivos


4.4.3. Punto de vista Contribucin de Objetivos

La gura 4.19 muestra el diagrama del punto de vista Contribucin de Objetivos que Per-mite visualizar la interaccin entre objetivos, restricciones y principios generando inuenciaspositivas que para el caso de estudio generando reducciones en tiempos de desarrollo.

Figura 4.19: Caso de estudio punto de vista Contribucin de Objetivos


4.4.4. Punto de vista Principios

La gura 4.20 muestra el diagrama del punto de vista Principios en este punto de vista seevidencia los principios que caracterizan a la organizacin en lo correspondiente a la imple-mentacin de sistemas de informacin y prestacin de servicios relacionados con tecnologasde la informacin donde la empresa se caracteriza por contar con conanza, respaldo y sereciente.

Figura 4.20: Caso de estudio punto de vista Principios


4.4.5. Punto de vista Realizacin de Requerimientos

La gura 4.21 muestra el diagrama del punto de vista Realizacin de Requerimientosque evidencia los requisitos tanto de plataformas como de contextos propios de los pilaresde la organizacin y del proceso en el que se centra este proyecto. Por ello para facilitar laimplentacin de sistemas de informacin se cuenta con el requerimiento de solo estar disponiblepara C# y Visual Basic, contar con plataforma graca y solo aplicado a modelos relacionales.

Figura 4.21: Caso de estudio punto de Realizacin de Requerimientos


4.4.6. Punto de vista Motivacional

La gura 4.22 muestra el diagrama del punto de vista Motivacional en donde nos acercaa puntualizar el rol del desarrollador con el respectivo conductor que tiene por denicinel plasmar los diseos de software con el compromiso de calidad, de igual manera para elobjetivo principal que es facilitar la implementacin de sistemas de informacin se toma comorestriccin 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

La gura 4.23 muestra el diagrama del punto de vista Proyecto que permite agrupar con-ceptos y componentes de otros puntos de vista para mostrarnos el cambio de arquitectura quepuede presentarse en el proyecto.

4.5. Capa de Proyecto 47

Figura 4.23: Punto de vista Proyecto

4.5.2. Punto de vista Migracin

La gura 4.24 muestra el diagrama del punto de vista de migracin donde se muestra latransicin entre la arquitectura existente y la deseada.

Figura 4.24: Punto de vista Migracin


4.5.3. Punto de vista Migracin e Implementacin

La gura 4.25 muestra el diagrama del punto de vista Migracin e Implementacin quepermite divisar el alcance de los proyectos y programas, integrando elementos de negocio,motivacin y migracin.

Figura 4.25: Punto de vista Migracin e Implementacin

Captulo 5

Diseo

Programar sin una arquitectura o diseo en mentees como explorar una gruta slo con una linterna:

no sabes dnde ests, dnde has estadoni hacia dnde vas.

Danny Thorpe

Resumen: En este captulo se aborda el diseo del sistema y se presentan los diagramas

UML generados durante la etapa de diseo.

5.1. Diagramas de Casos de Uso

Para el modelamiento de casos de uso del sistema, se plantean dos actores principales:

Arquitecto de informacin: Encargado del diseo de la base de datos.

Desarrollador: Encargado de la codicacin de la capa de acceso a datos.

5.1.0.1. Casos de uso Arquitecto de Informacin

En el proceso de creacin de una capa de acceso a datos se parte de la existencia de unabase de datos implementada sobre un determinado motor de bases de datos. El Arquitectode informacin es el encargado del diseo de la base de datos y dentro de sus funciones seencuentra el modelamiento de la base de datos y su implementacin.

La gura 5.1 muestra el diagrama de caso de uso donde interacta el Arquitecto de infor-macin.

49

50 Captulo 5. Diseo

Figura 5.1: Diagrama de Casos de uso - Arquitecto de informacin

5.1.0.2. Casos de uso Desarrollador

El proceso de codicacin de la capa de acceso a datos es realizado por el Desarrollador ycontempla cuatro casos de uso:

Crear Conexin: Corresponde a la conguracin de la conexin al motor de base dedatos.

Mapear estructura: Corresponde al proceso de mapeo de la estructura de la base dedatos y la denicin por parte del Desarrollador de que objetos sern usados en a capade acceso a datos y los parmetros de ltrado de la data. Este caso de uso cuenta contres casos de uso relacionados:

Mapear tabla. Mapear vista. Mapear procedimiento almacenado.

Generar cdigo fuente: Corresponde a la generacin del cdigo fuente de la capa deacceso a datos por parte de la herramienta CASE.

Usar objetos generados: Corresponde a las labores de codicacin por parte delDesarrollador del cdigo fuente de uso de la capa de acceso a datos en una determinadaaplicacin.

La gura 5.2 muestra el diagrama de caso de uso donde interacta el Desarrollador.

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 diseo orientado a componentes, dondecada componente se implementa en una DLL independiente.

Los componentes se agrupan en:

Abstractos: Corresponde los componentes que agrupan a las clases e interfaces denidasen el API de la herramienta.

Semiabstractos: Corresponde los componentes que agrupan las implementaciones de losManager de componentes de mapeo, codicacin y conexin, as como la implementacindel Engine usado por la capa de acceso a datos en tiempo de ejecucin.

Concretos: Corresponde los componentes que agrupan las implementaciones para cadauno de los motores de base de datos y los generadores de cdigo fuente de la capa deacceso a datos.

La gura 5.3 muestra el diagrama de componentes propuesto para la herramienta CASE.

52 Captulo 5. Diseo

Figura 5.3: Diagrama de Componentes

5.3. Diagramas de Secuencia

La gura 5.4 muestra el diagrama de secuencia, en tiempo de ejecucin, de las instruccionesde acceso a datos del cdigo generado por la herramienta CASE.

Figura 5.4: Diagrama de Secuencia

5.4. Diagramas de clases 53

5.4. Diagramas de clases

5.4.1. API

5.4.1.1. Denicin

El API contiene las interfaces que denen los contratos de interaccin de los componentesde todo el sistema, as como el administrador de componentes, el cual se encarga de cargardinmicamente en tiempo de ejecucin cada uno de los componentes de extensin del sistema.

IExtend: Interfaz que permite identicar todas las clases que corresponden a un com-ponente a ser cargado dinmicamente, 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 basesde datos.

ICodier: Interfaz que dene el comportamiento de los componentes de generacin decdigo de las capas de acceso a datos.

IConnection: Interfaz que dene el comportamiento de los componentes que proveenla conexin a los diferentes motores de bases de datos para la capa de acceso a datos entiempo de ejecucin.

ExtendTypeEnum: Enumeracin que identica los tipos de componentes de extensindel sistema.

Codier. Connection. Mapper.

ExtendManager: Administrador de componentes de extensin. Encargado de cargardinmicamente los componentes en tiempo de ejecucin.

La gura 5.5 muestra el diagrama de clases de la denicin del API.

5.4.1.2. Implementacin

Dentro del alcance del proyecto actual se contempla la implementacin de componentespara los motores de bases de datos ORACLE, PostgreSQL y SQL Server, y generadores decdigo para la capa de acceso a datos ADO en C# y Visual Basic.

La gura 5.6 muestra el diagrama de clases de las implementaciones de las interfacesdenidas en el API.

54 Captulo 5. Diseo

Figura 5.5: Diagrama de clases - Denicin API

5.4.2. Engine ADO

5.4.2.1. Denicin

El cdigo 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 sentenciasSQL para cada motor de base de datos soportado por el sistema. Para el alcance del presenteproyecto 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 conexin a la capa de acceso a datos.

Database: Administra la conexin al servidor de base de datos.

SchemaManager: Administra el acceso a los objetos de un determinado esquema en labase de datos.

ObjectManager: Dene las funciones base para todos los manejadores objetos de base


Figura 5.6: Diagrama de clases - Implementacin 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 Procedimientoalmacenado.

DatabaseFactory: Fabrica encargada de crear las instancias de los objetos Databaseimplementados para cada motor de bases de datos.

La gura 5.7 muestra el diagrama de clases de las estructuras Manager.

Como soporte para la administracin de los objetos de acceso a datos se denieron unaserie de clases que permitan dar soporte a funcionalidades auxiliares y dar soporte para laherencia de clases especcas para los objetos mapeados.

DbNulls: Clase auxiliar que permite crear instancias DalNullable para diferentestipos de datos.

56 Captulo 5. Diseo

Figura 5.7: Diagrama de clases - Engine ADO - Manager

ObjectEnum: Clase base para la identicacin de objetos mapeados.

ObjectEnum: Clase base para la creacin de clases con listados de objetos mapeados.

XmlBase: Clase base para la creacin de objetos de representacin de registros de unaconsulta que puedan ser serializados.

ConectionStringHelper: Clase auxiliar que provee mtodos para manipulacin decadenas de conexin a los motores de bases de datos.

SchemaMappingManager: Permite administrar la conguracin de Alias para losesquemas de base de datos en tiempo de ejecucin.

La gura 5.8 muestra el diagrama de clases auxiliares.


Figura 5.8: Diagrama de clases - Engine ADO - Utils

5.4.2.2. Implementacin

El modelamiento por componentes permite que el sistema se pueda expandir horizontal-mente implementado funcionalidades para nuevos motores de bases de datos sin necesidad demodicar los desarrollos existentes.

La gura 5.9 muestra el diagrama de clases de la implementacin de la clase Database parados diferentes motores de bases de datos del Engine ADO.

5.4.3. Capa de Acceso a Datos

El cdigo generado para la capa de acceso a datos estar compuesto por dos grupos declases: las clases envolventes de los procesos de acceso a datos y las clases de los objetos tipadospara la manipulacin de datos.

58 Captulo 5. Diseo

Figura 5.9: Diagrama de clases - Engine ADO - Implementacin

5.4.3.1. DatabaseManager

El envolvente del proceso de acceso a datos estar compuestos por las siguientes clases:

xxxDatabaseManager: Corresponde al administrador principal de la capa de accesoa datos, hereda de DatabaseManager y contiene instancias de las clases encargadas deacceder a cada uno de los esquemas de la base de datos. El prejo xxx corresponde alnombre congurado por el usuario para identicar la clase. En la gura 5.10 se muestraun ejemplo de esta clase al que se ha denominado DbPruebaDatabaseManager.


yyySchema: Corresponde a los administradores de acceso a cada uno de los esquemasde la base de datos, heredan de SchemaManager y se encargan de agrupar las instanciasde acceso a cada uno de los objetos de la base de datos. El prejo yyy corresponde alnombre congurado por el usuario para el esquema al que se est accediendo. En lagura 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 labase de datos, heredan de TableManager y se encargan de agrupar los mtodos de accesoa datos de la tabla mapeada. El prejo ttt corresponde al nombre de la tabla a la quese est accediendo. En la gura 5.10 se muestra un ejemplo de esta clase al que se hadenominado t_hijoTable.

vvvView: Corresponde a los administradores de acceso a cada una de las vistas de labase de datos, heredan de ViewManager y se encargan de agrupar los mtodos de accesoa datos de la vista mapeada. El prejo vvv corresponde al nombre de la vista a la quese est accediendo. En la gura 5.10 se muestra un ejemplo de esta clase al que se hadenominado v_hijoView.

sssStoreProcedure: Corresponde a los administradores de acceso a cada uno de losprocedimientos almacenados de la base de datos, heredan de StoreProcedureManager yse encargan de agrupar los mtodos de acceso a datos del procedimientos almacenadosmapeado. El prejo sss corresponde al nombre del procedimientos almacenados al quese est accediendo. En la gura 5.10 se muestra un ejemplo de esta clase al que se hadenominado p_hijo_getStoreProcedure.

La gura 5.10 muestra el diagrama de clases del envolvente del proceso de acceso a datoscon 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 administradoresde objetos de base de datos.

5.4.3.2. Objetos Tipados

Una de las principales virtudes del diseo propuesto para la generacin de la capa de accesoa datos son los objetos fuertemente tipados que describen los resultados de las consultas. Paracumplir con este objetivo se modelan clases que permitan describir un conjunto de resultadosdevueltos por el motor de bases de datos y que corresponden a tablas y vistas. Estas clasesheredan de la clase DataTable de ADO.Net, la cual a su vez representa un conjunto registrosde tipo DataRow.

Para facilitar la visualizacin de datos con los objetos provistos por .Net se implementaronDataSets a partir de los esquemas de la base de datos los cuales agrupan objetos DataTabletipados. La gura 5.12 muestra el diagrama de implementacin de los DataSets.

Debido a la restriccin que tienen los objetos tipo DataRow que solo pueden ser creadospor un DataTable y ante la necesidad de poder contar con objetos que representen un registro

60 Captulo 5. Diseo

Figura 5.10: Diagrama de clases - DAL - DatabaseManager

de datos que facilite su manipulacin, sin la necesidad de crear un DataTable, se disearonobjetos xxxType y xxxSimpleType.

La siguiente lista describe los objetos tipados creados en la capa de acceso a datos generadapor la herramienta CASE. Para cada uno de los tems el prejo xxx representa el nombre delobjeto de base de datos mapeado.


Figura 5.11: Diagrama de clases - DAL - Managers

xxxDataTable: Representa un conjunto de registros devuelto por una consulta y quecorresponden a la estructura de una tabla o vista.

xxxDataRow: Representa un registro de un resultado de una consulta asociado a unDataTable tipado.

xxxType: Representa un registro de una tabla o vista, similar a un DataRow pero que

62 Captulo 5. Diseo

Figura 5.12: Diagrama de clases - DAL - DataSet

no requiere la existencia de un DataTable. Estos pueden ser instanciados autnomamenteo creados a partir de un DataRow.

xxxSimpleType: Representa una versin simplicada de un xxxType que no permitealmacenar datos null.

xxxEnum: Enumeracin con los nombres de las columnas de una tabla o vista mapea-da. Son utilizadas para procesos de ordenamiento de resultados de consultas o paso deparmetros a asistentes de visualizacin de datos que requieren el uso de cadenas de


texto para identicar las columnas.

xxxEnumList: Representa una lista de instancias de xxxEnum.

Las guras 5.13 y 5.14 muestra el diagrama de clases de los objetos tipados generados porla herramienta CASE.

Figura 5.13: Diagrama de clases - DAL - Objetos tipados 1

64 Captulo 5. Diseo

Figura 5.14: Diagrama de clases - DAL - Objetos tipados 2

Captulo 6

Codicacin

Est bien investigar y resolver misteriososasesinatos, pero no deberas necesitar

hacerlo con el cdigo.Simplemente deberas poder leerlo.

Steve McConnell

Resumen: Este captulo se aborda el proceso de codicacin y contiene la descripcin

de los componentes desarrollados.

6.1. API

El API del sistema se encuentra codicado en la librera SLYG.DAL.Api.d

Diseño e Implementación de una Herramienta CASE...

Documents

Transcript of Diseño e Implementación de una Herramienta CASE...