Tesis Persistencia Maestria

UNIVERSIDAD FRANCISCO GAVIDIA
UNIDAD DE POSTGRADOS
Desarrollo de un Motor de Persistencia para la Plataforma Microsoft .Net

TRABAJO DE GRADUACION PREPARADO PARA LA UNIDAD DE POSTGRADOS PARA OPTAR AL GRADO DE:
MASTER EN INFORMATICA APLICADA A REDES
PRESENTADO POR: Francisco Jos Fernndez Escobar Ernesto Armando Zavaleta William Alexie Rebolone
DICIEMBRE 2006 SAN SALVADOR EL SALVADOR CENTROAMERICA
Maestra en Informtica Aplicada a Redes
Tabla de Contenidos
I. INTRODUCCIN .................................................................................................................................. 4 1.1. 1.2. 1.3. 1.4. 1.5. 1.6. II. 2.1 2.2 2.3 III. 3.1 3.1.1 3.1.2 3.1.3 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.2.7 3.2.8 3.2.9 3.3 3.3.1 3.3.2 3.3.3 3.4 3.4.1 3.5 3.5.1 3.6 3.6.1 3.6.2 3.6.3 3.7 3.7.1 3.7.2 3.7.3 IV. OBJETIVOS. ...................................................................................................................................... 5 ALCANCES ....................................................................................................................................... 6 LIMITACIONES.................................................................................................................................. 6 SUPOSICIONES Y DEPENDENCIAS ..................................................................................................... 7 A QUIEN ESTA DIRIGIDO ESTE DOCUMENTO...................................................................................... 7 ORGANIZACIN DEL DOCUMENTO. .................................................................................................. 8 ANTECEDENTES ............................................................................................................................... 9 MOTORES DE PERSISTENCIA Y EL FRAMEWORK .NET.................................................................... 11 EL PORQUE DE LA CREACIN DE UN MOTOR DE PERSISTENCIA PARA .NET. .................................... 12 FUNDAMENTOS TEORICOS ...................................................................................................... 13 PROGRAMACIN ORIENTADA A OBJETOS ....................................................................................... 13 Historia y Evolucin................................................................................................................. 13 Ventajas de la OO..................................................................................................................... 14 Caractersticas de los Objetos.................................................................................................. 15 PATRONES DE DISEO .................................................................................................................... 21 Historia..................................................................................................................................... 22 Conceptos Clave ....................................................................................................................... 23 Tipos de Patrones ..................................................................................................................... 23 Patrones de Acceso a Datos ..................................................................................................... 25 El patrn Singleton................................................................................................................... 27 El Patrn Factory..................................................................................................................... 28 El Patrn Abstract Factory ...................................................................................................... 32 El Patron Data Accessors......................................................................................................... 34 Patron DAO (Data Access Object)........................................................................................... 34 BASES DE DATOS ORIENTADAS A OBJETOS .................................................................................... 38 El Concepto de Orientacin a Objetos ..................................................................................... 40 El Modelo de Datos Orientado a Objetos ................................................................................ 41 El modelo Estndar ODMG ..................................................................................................... 46 SISTEMAS OBJETOS-RELACIONALES .............................................................................................. 49 Diferencia entre los tres sistemas (RDBMS, ODBMS, ORDBMS) ........................................... 50 MOTORES DE PERSISTENCIA........................................................................................................... 53 Opciones para motores de persistencia.................................................................................... 55 PROCESO DE DISEO Y DESARROLLO DE UN PROYECTO DE SOFTWARE ........................................ 56 CMM......................................................................................................................................... 56 El RUP y el Proceso Unificado ................................................................................................ 65 Microsoft Solution Framework................................................................................................. 67 MICROSOFT .NET FRAMEWORK ..................................................................................................... 69 Caractersticas ......................................................................................................................... 71 Arquitectura.............................................................................................................................. 75 ADO .Net 2.0 ............................................................................................................................ 83
JUSTIFICACIN DEL TEMA............................................................................................................. 9
SOLUCIN PROPUESTA ............................................................................................................. 90
4.1 MODELADO DE LA SOLUCIN ........................................................................................................ 90 4.1.1 Consideraciones Iniciales......................................................................................................... 90 4.1.2 Namespaces y Assemblies......................................................................................................... 92 4.2 SINCRONIZACIN ESTRUCTURA ER Y MODELO DE DOMINIO ........................................................ 93 4.2.1 Planteamiento del Requerimiento............................................................................................. 93 4.2.2 Diseo de la Solucin ............................................................................................................... 93
Pgina 2 de 159
4.2.3 4.3 4.3.1 4.3.2 4.3.3 4.4 4.4.1 4.4.2 4.4.3 4.5 4.5.1 4.5.2 4.5.3 4.6 4.6.1 4.6.2 4.6.3 V. 5.1 5.2 5.3 5.3.1 5.3.2 5.3.3 5.4 5.4.1 5.4.2 5.5 5.5.1 5.5.2 5.5.3 5.6 VI.
Construccin de la Solucin..................................................................................................... 98 GENERACIN DE OPERACIONES TRANSACCIONALES ...................................................................... 99 Planteamiento del Requerimiento............................................................................................. 99 Diseo de la Solucin ............................................................................................................... 99 Construccin de la Solucin................................................................................................... 103 CONSTRUCCIN Y CARGAS DE LOS OBJETOS ............................................................................... 108 Planteamiento del Requerimiento........................................................................................... 108 Diseo de la Solucin ............................................................................................................. 108 Construccin de la Solucin................................................................................................... 109 ACCESO INDEPENDIENTE DEL SISTEMA RDBMS ......................................................................... 112 Planteamiento del Requerimiento........................................................................................... 112 Diseo de la Solucin ............................................................................................................. 113 Construccin de la Solucin................................................................................................... 115 CONFIGURACIN Y PARAMETRIZACIN ....................................................................................... 117 Planteamiento del Requerimiento........................................................................................... 117 Diseo de la Solucin ............................................................................................................. 118 Construccin de la Solucin................................................................................................... 118 OBJETIVO DE LAS PRUEBAS.......................................................................................................... 120 DEFINICIN DEL REQUERIMIENTO................................................................................................ 120 MODELADO Y DISEO DE LA SOLUCIN ...................................................................................... 121 Modelo de Dominio. ............................................................................................................... 121 Modelo de Acceso a Datos ..................................................................................................... 125 Modelo de Reglas del Negocio. .............................................................................................. 126 CONSTRUCCIN DE LA APLICACIN ............................................................................................. 128 Creacin de la Estructura de Datos. ...................................................................................... 128 Creacin del Proyecto Visual C# Win32 ................................................................................ 129 EJECUCIN Y RESULTADOS .......................................................................................................... 138 Operacin de Adicin............................................................................................................. 139 Operacin de Actualizacin: .................................................................................................. 140 Operacin de Eliminacin...................................................................................................... 141 CONCLUSIONES SOBRE LAS PRUEBAS........................................................................................... 141
RESULTADOS Y VERIFICACION EXPERIMENTAL ............................................................... 120
CONCLUSIONES Y FUTURAS LINEAS DE INVESTIGACION .......................................... 142
6.1 CONCLUSIONES GENERALES ........................................................................................................ 142 6.2 FUTURAS LNEAS DE INVESTIGACIN........................................................................................... 143 6.2.1 Manejo de Herencia y Composicin....................................................................................... 143 6.2.2 Eficiencia y Rendimiento. ....................................................................................................... 144 6.2.3 Ejecucin sobre plataformas no Windows.............................................................................. 144 VII. VIII. BIBLIOGRAFA Y REFERENCIAS ESTUDIADAS................................................................ 145 ANEXO A: CDIGO FUENTE DEL MOTOR DE PERSISTENCIA .................................... 147
Pgina 3 de 159
I. Introduccin
A medida que evoluciona la tecnologa y los procesos de negocios de las empresas privadas y gubernamentales se vuelven mas dependientes de las ciencias de la informacin, se demanda a su vez, una mayor calidad en los procesos de desarrollo de software con el fin de obtener productos de una mayor calidad, es decir con una mejor estabilidad, eficiencia robustez y reusabilidad de los dichos elementos. Esto significa que lo productos de software no deben ser diseados y creados nicamente para solucionar un requerimiento especifico de usuario como un caso de uso, un user story o un escenario, sino deben de ser diseados de tal forma que estn totalmente documentados, que su arquitectura sea robusta y permita la reutilizacin de sus componentes, que sea sencillo el cambio o extensin de una funcionalidad o comportamiento, que su ejecucin sea estable, etc. Estos requerimientos son totalmente soportados por la orientacin a objetos la cual con la ayuda de algunos metodologas de desarrollo y herramientas de software logran cumplir los requerimientos antes mencionados. En el ciclo de desarrollo de los proyectos de software, las etapas de conceptualizacin y diseo de sistemas requieren abstraer los comportamientos de los elementos que se desean mecanizar, de tal forma que sean imitados tanto en sus propiedades como en su comportamiento, esto nos lleva a la definicin de tipos de datos o clases los cuales sern la implementacin de los elementos surgidos de la etapa de conceptualizacin, estos tipos de datos con estado y comportamiento, darn vida a lo que denominaremos ya en la ejecucin de sistema objetos. Dado que la tecnologas favoritas actuales de persistencia de datos aun son las bases de relacionales, existe un divorcio entre los modelos de clases que forman la conceptualizacin del sistema con sus propias caractersticas OO (Object Oriented) como la herencia, la encapsulacin y el polimorfismo y los modelos relacionales los cuales siguen otro conjunto de reglas como las reglas de normalizacin. Este problema es solventado por los motores de persistencia, quienes se encargan de convertir objetos a registros en un sistema relacional y viceversa.
Pgina 4 de 159
Los motores de persistencia vienen entonces a ser el enlace entre ambas tecnologas permitiendo al diseador llegar a abstraer completamente un sistema en un modelo de clases con sus caractersticas innatas OO, sin tener que preocuparse por como sern persistidos los datos en la base relacional. Este documento muestra como utilizando recursos sin costo alguno puede ser construido un motor de persistencia para la plataforma .Net de Microsoft que implemente las caractersticas principales de esta tecnologa de persistencia de un modelo conceptual completamente Object Oriented o modelo de dominio en una base de datos relacional
1.1.
Objetivos.
Fomentar el diseo orientado a objetos utilizando la plataforma .Net, al facilitar una herramienta que implemente la funcionalidad necesaria para persistir objetos que a su ves sean capaces de conceptualizar los distintos elementos que componen un sistema de informacin como objetos que modelen la realidad del sistema y posean responsabilidades nicas. Disear y desarrollar una librera que implemente la funcionalidad para realizar un mapeo automtico entre un modelo de clases o modelo de Dominio y un modelo ER. Disear una librera que implemente la funcionalidad necesaria para crear de forma automtica las operaciones transaccionales contra un sistemas RDBMS. Aplicar conceptos avanzados de Ingeniera de Software, como el uso de patrones de diseo, para garantizar la reusabilidad del cdigo desarrollado, as como su confiabilidad y robustez. Fomentar el uso de tcnicas de ingeniera de software avanzadas en los programas educativos de las universidades, al utilizar este documento como una referencia de trabajo y ejemplo de la aplicacin de patrones de diseo y otras temas relacionados.
Pgina 5 de 159
1.2.
Alcances
Se desarrollar un prototipo que implementar la funcionalidad principal del motor de persistencia, es decir maneje automticamente las operaciones de Object / Relational Mapping O/R M. La arquitectura del producto es un diseo 100% creado por el grupo de trabajo y no se ha copiado, basado o inspirado en la arquitectura de productos existentes por lo que no existe un elemento de investigacin de las arquitecturas de los motores actuales, sino solamente sobre su funcionalidad. El proyecto esta orientado a la plataforma .Net de Microsoft, especficamente al Framework 2.0. Todas las herramientas a emplear en el desarrollo del proyecto a excepcin de la herramienta CASE 1de diseo y modelado son de libre distribucin, por lo que no se estiman costos para la adquisicin de software. El producto ser desarrollado utilizando el lenguaje C# de Microsoft y la herramienta de desarrollo Visual C# 2005 Express edition. Para realizar las operaciones de mapeo O/RM, ya que esto se har de forma automtica y transparente para el desarrollador, el producto se basar en un modelo de clases el cual debe de coincidir perfectamente con un modelo relacional por lo que ser altamente recomendable la utilizacin de una Herramienta Case que mantenga la sincrona entre el modelo de clases y el ER.
1.3.
Limitaciones.
La limitacin principal que afecta el proyecto en si, es el tiempo asignado y ya que de las 10 semanas totales se utilizaron ms de dos en la formulacin del proyecto, algunas limitaciones especificas son las siguientes: Para el prototipo a implementar, no se contempla el soporte para la Composicin y la herencia.
Se deja a criterio del lector el uso de la herramienta CASE de su preferencia. Para este proyecto se utiliza PowerDesigner 12
Pgina 6 de 159
Se construir el prototipo con libreras de acceso a datos o dialectos que permitan conectarse a los sistemas Oracle, Mysql y Microsoft SQL Server 2000/2005. Estas podrn ser extendidos posteriormente gracias a la utilizacin de los patrones de diseo como el Abstract Factory. Se han utilizado patrones de diseo fundamentales como el Singleton y el Abstract Factory y otros especficos de acceso a datos como DAO, Data Accesors, etc. Sin embargo es posible que alguna de la funcionalidad creada en este prototipo pudiera haber sido implementada tambin utilizando otros patrones que por el corto tiempo no pudieron ser considerados. Se enfoco el esfuerzo del grupo de trabajo en la eficacia de la funcionalidad a implementar, esto debido a la limitante de tiempo. Se propone entonces un estudio aparte a este proyecto donde se plantee la implemente la funcionalidad propuesta de una forma mas eficiente.
1.4.
Suposiciones y Dependencias
Se supone que el lector tiene conocimientos medios en la utilizacin del lenguaje C# y de las tcnicas de orientacin a objetos. Se supone que el lector tiene claro las ventajas de la utilizacin de un enfoque orientado a objetos sobre uno tradicional. Se supone que el lector tiene conocimientos bsicos de los patrones de diseo y de las ventajas que estos representan en la construccin de software. Se supone que el diseador modelador posee conocimientos sobre modelado UML y uso de la herramienta CASE.
1.5.
A quien esta dirigido este documento.
Este documento en general esta dirigido a todo aquel desarrollador que desee ampliar sus conocimientos en el uso de la tecnologa de motores de persistencia u O/R Mapping, aplicadas a la plataforma Microsoft .Net. El documento sin embargo ha sido elaborado para que pueda ser utilizado como una gua a educadores del rea de desarrollo de nivel intermedio que puedan al implementar la
Pgina 7 de 159
propuesta aqu planteada, repasar
una serie de conocimientos, tcnicas y principios
relacionados a la Ingeniera del Software. Sin embargo debe de recordarse que no esta orientada a desarrolladores principiantes, sino con un conocimiento intermedio de programacin orientada a objetos y desarrollo bajo e framework .Net.
1.6.
Organizacin del Documento.
El documento ha sido organizado de la siguiente manera: En el primer capitulo Introduccin encontrar todo lo referente a la definicin del proyecto, sus objetivos, alcances y limitantes, as como las suposiciones sobre las que se trabajo dicho proyecto y la descripcin de a quien esta dirigido este documento. El segundo capitulo Justificacin del Tema, describe la importancia del tema de motores de persistencia en el contexto de un mejor ciclo de vida de proyectos de desarrollo de software y del beneficio acadmico que supone este proyecto El tercer capitulo Fundamentos Tericos contiene una referencia documental rapida de distintas, tecnologas, disciplinas y estndares relacionados con el tema principal, con el fin de que sirvan de gua o refuerzo si desconoce algn tema en particular. El cuarto capitulo Solucin Propuesta, se describe el ciclo completo de construccin de la solucin, desde la definicin de sus requerimientos, el diseo de cada funcionalidad requerida y su implementacin con el lenguaje C El quinto capitulo Resultados y Verificacin Experimental, documenta los resultados de las pruebas realizadas luego de construida la solucin, demostrando que el producto es operable de acuerdo a los alcances definidos. El capitulo sexto Conclusiones y Futuras Lineas de Investigacin presenta las conclusiones generales despus de construir el producto, as como se propone una serie de temas que por motivos de tiempo no se han incluido en este documento, pero que se estiman pueden ser desarrollados extendiendo la funcionalidad del prototipo planteado. El capitulo sptimo Bibliografa y Referencias Estudiadas, lista la bibliografa utilizada como fuente para este proyecto.
Pgina 8 de 159
II. Justificacin del Tema

2.1 Antecedentes
Los procesos de desarrollo de software, han evolucionado en los ltimos aos. Esto debido en gran medida a la cantidad alarmante de proyectos de este tipo que no se desarrollan de acuerdo a lo planeado, o, finalizan en fracasos. Una muestra de esto se puede apreciar en la siguiente grfica la cual es resultado de una investigacin del Standish Group en los estados unidos, donde se recolecto informacin de mas de 30,000 proyectos de pequea, mediana y grandes empresas.
Failed
2000
Challenged
49%
Succeeded
28%
23%
1998
28%
46%
26%
1995
40%
33%
27%
1994
31%
53%
16%
Se puede observar en la grfica que se presentan para los aos 1994, 1995, 1998 y 2000 los porcentajes de proyectos los cuales han sido clasificados de la siguiente manera: Failed: Estos son proyectos que fueron abortados, suspendidos o finalizaron en un fracaso de acuerdo a los objetivos planteados. Challenged: Estos son proyectos que si bien finalizaron , consumieron mas de los recursos planeados originalmente , excediendose principalmente en tiempo o presupuesto. Succeeded: Estos son los proyectos que finalizaron existomente utilizando los recursos planeados originalmente.
Pgina 9 de 159
Esta situacin origino el estudio, documentacin, estandarizacin
y difusin de las
conocidas buenas practicas para el desarrollo de software. Tomando como base las investigaciones realizadas por el Instituto de Ingeniera del Software SIE solicitado por el Departamento de Defensa de los Estados Unidos que dieron origen al modelo de capacidad de madures CMM2 y sus sucesores SW-CMM y el actual CMMI que sirve como base a metodologas de desarrollo como el Rational Unified Process y el Microsoft Solution Framework. Estas nuevas metodologas al igual que el CMMI sugieren llevar en el proceso de desarrollo de software una administracin de requerimientos, control de cambios y otras caractersticas que garantizan un estricto control del proyecto para llevarlo a ser exitoso. El RUP y el MSF son las metodologas disponibles en nuestro medio y que lentamente son adoptadas por las instituciones y empresas, ambas sugieren la creacin de una serie de roles con responsabilidades bien definidas, en estos se aprecia que el rol del desarrollador sin bien y obviamente es necesario no tiene tanta importancia como los roles de Arquitectos de la solucin, ingenieros de requerimientos o Diseadores, ya que son ellos los que conciben la solucin la conceptualizan y modelan, dejando al final prcticamente un completo manual de que es lo que se debe de construir, donde se han evaluado ya los aspectos de arquitectura, seguridad etc. Entonces el desarrollador viene solo a seguir las indicaciones de que lo que se construir y como se har .(Debe de tenerse en cuenta que en proyectos pequeos o con pocos recursos, ambos roles diseador y desarrollador los podra ejecutar la misma persona). Dadas las necesidades de robustez, reusabilidad, etc. al momento de disear y construir la solucin se utiliza un enfoque orientado a objetos aunque este posteriormente pueda evolucionar a una orientacin a Aspectos o Servicios. El diseador o arquitecto de la solucin, podra entonces concebir un modelo de la solucin completamente orientado a objetos, utilizando herencias, polimorfismos, encapsulamiento, etc. Sin embargo al intentar persistir dichos objetos para hacerlo de forma transparente se requerira la utilizacin de una Base de Datos Orientada a Objetos, lo cual es poco usual ya
Para mayor informacin sobre CMM remitirse a la seccin 3.5.1

Pgina 10 de 159
que la tecnologa de almacenamiento mas utilizada son las bases relacionales como Oracle, SQL Server, Sybase, MySQl, etc. As que con un diseo orientada a objetos al momento realizar la persistencia el Desarrollador deber ver como se las arregla para realizar el mapeo entre clases y tablas y generar las operaciones transaccionales necesarias. Naturalmente esta operacin le consumir una considerable cantidad de tiempo. Los motores de persistencia o tambin denominados O/R Mapping implementan una capa que realiza las transformaciones entre clases y tablas de forma tal que los desarrolladores ya no deben de invertir tanto tiempo en estas actividades, siendo al final una valiosa herramienta a utilizar cuando se tiene un diseo orientado a objeto y se desea persistir en una base de datos relacional.
2.2
Motores de Persistencia y el Framework .Net
Los motores de persistencia han sido utilizados ampliamente en la plataforma Java, donde productos como Hibernate, TopLink, CocoBase, JRelay son algunos representantes de estos productos, de hecho Java tiene el estndar JDO que pretende normalizar las operaciones de persistencia bajo esta plataforma. En el caso de la plataforma Microsoft, es mas reciente la utilizacin de este tipo de tecnologas, sin embargo existen en el mercado opciones comerciales como ORM, Gentle .Net, etc. Adems existe ahora una versin del motor de persistencia de cdigo abierto mas difundido en el mundo Java Hibrnate, que en su versin para el framework .Net es denominado NHibernate. Antes de la aparicin del Framework 2.0 se hablaba tambin del producto ObjectSpaces el cual es un motor de persistencia desarrollado por Microsoft para trabajar nicamente sobre SQL Server, sin embargo se planeaba que fuera liberado junto con la nueva versin del framework. A la fecha el framework ya fue liberado pero no se tiene informacin sobre ObjectSpaces.
Pgina 11 de 159
2.3
El porque de la creacin de un motor de persistencia para .Net.
Cuando las necesidades de un motor de persistencia son inminentes, las dos opciones son o construirlo o comprar u adquirir un producto existente. El uso de un producto existente naturalmente conlleva adaptarse a la forma de trabajo planteada por dicho producto. Por otro lado la construccin de un motor de este tipo, requiere la inversin de tiempo, el conocimiento avanzado de tcnicas de orientacin a objetos, aplicacin de patrones de diseo, etc. Dado que bajo la plataforma .Net el uso de este tipo de aplicativos no es muy difundida, siendo sus beneficios muy amplios. La creacin y puesta a disposicin de una herramienta de este tipo se espera potencie su uso y promueva el diseo de sistemas completamente orientados a objetos, adems el hecho de dejar documentado el proceso de diseo y construccin en este documento, se espera pueda servir como un ejercicio acadmico que pueda ser utilizado por educadores y desarrolladores para profundizar en el tema y elevar su nivel. Finalmente la sola utilizacin de la herramienta construida por la comunidad de desarrolladores .Net, se espera tengo un impacto positivo permitiendo la reduccin de los tiempos de desarrollo, la abstraccin de modelos de dominio y de acceso a datos independientes del tipo de base de datos utilizado y en si todas las caractersticas que conlleva el uso de este tipo de herramientas.
Pgina 12 de 159
III. FUNDAMENTOS TEORICOS

Los fundamentos tericos plasmados en esta seccin describen aquellas tcnicas y disciplinas que estn estrechamente relacionadas al tema de los Motores de Persistencia, iniciando desde la programacin orientada a objetos y los patrones de diseo, pasando al tema de Bases de Datos Orientadas a Objetos, generalidades sobre los motores de persistencia e introduciendo al tema de Metodologas Iterativas de Desarrollo de Software donde se habla del CMMI, el RUP y el MSF. Finalmente se termina el capitulo describiendo algunas caractersticas de la plataforma sobre la cuales se implementan los conceptos antes descritos, es decir la plataforma del Microsoft .Net Framework. Esta informacin esta documentada en este capitulo de tal forma que pueda servir como base al lector para ampliar sobre algunos fundamentos sobre los cuales se ha desarrollado el presente proyecto.
3.1
Programacin Orientada a Objetos
3.1.1 Historia y Evolucin.

El modelo orientado a objetos es el modelo terico que usan la mayora de los programas actuales. La programacin orientada a objetos comienza en los aos sesenta (en los que aparecieron los primeros lenguajes de este tipo, llamados Simula I y Simula 67, desarrollados en el Centro Noruego de Computacin, en Oslo). En los primeros 70, aparece Smalltalk, un lenguaje fundamental en la historia de la orientacin a objetos. Sin embargo, es hasta la segunda mitad de los aos 80 que la orientacin de objetos se generaliza, convirtindose en el estndar predominante en los aos 90, con lenguajes tales como C++ y Java. Su xito ha sido impulsado por la difusin de otras tecnologas (como la interfaz grfica o las arquitecturas distribuidas) que son ms fciles de implementar mediante este tipo de desarrollo que mediante una programacin tradicional. En la actualidad, la prctica totalidad de los lenguajes de programacin que surgen son orientados a objetos y esta tecnologa se ha convertido en el estndar actual de
Pgina 13 de 159
programacin que, a su vez, est generando nuevos desarrollos muy prometedores para el futuro como, por ejemplo, la programacin orientada a aspectos. La idea de la orientacin a objetos es modelar los programas de una forma parecida a cmo percibimos la realidad. Para la mente humana, el universo est compuesto por una serie de objetos (en el sentido ms amplio de la palabra, incluyendo seres vivos, ideas, etc.). Cada objeto tiene unas caractersticas que lo diferencian de los dems y, con cada objeto, se pueden realizar unas acciones que son propias y especficas del mismo. As, por ejemplo, un determinado auto tiene unas caractersticas (color rojo, caja de cambios automtica, diesel, etc.) y puede realizar unas determinadas acciones (acelerar, frenar, etc.). La programacin orientada a objetos intenta modelar estos objetos reales con estructuras de programa, llamadas objetos de software o, simplemente, objetos. Cada uno de estos objetos de software, est compuesto por una serie de caractersticas (llamadas atributos) y una serie de acciones (llamadas mtodos), al igual que un objeto de la vida real. La OO aporta un enfoque nuevo, convirtiendo la estructura de datos en el centro sobre el que pivotan las operaciones. De esta forma, cualquier modificacin de la estructura de datos tiene efecto inmediato sobre las acciones a realizar sobre ella, siendo esta una de las diferencias radicales respecto a la programacin estructurada. En esta forma de diseo se descomponen los requerimientos del programa paso a paso, hasta llegar a un nivel que permite expresarlos mediante procedimientos y funciones. La OO estructura los datos en objetos que pueden almacenar, manipular y combinar informacin.
3.1.2 Ventajas de la OO
La OO proporciona las siguientes ventajas sobre otros lenguajes de programacin Uniformidad. Ya que la representacin de los objetos lleva implica tanto el anlisis como el diseo y la codificacin de los mismos.
Pgina 14 de 159
Comprensin. Tanto los datos que componen los objetos, como los procedimientos que los manipulan, estn agrupados en clases, que se corresponden con las estructuras de informacin que el programa trata. Flexibilidad. Al tener relacionados los procedimientos que manipulan los datos con los datos a tratar, cualquier cambio que se realice sobre ellos quedar reflejado automticamente en cualquier lugar donde estos datos aparezcan. Estabilidad. Dado que permite un tratamiento diferenciado de aquellos objetos que permanecen constantes en el tiempo sobre aquellos que cambian con frecuencia permite aislar las partes del programa que permanecen inalterables en el tiempo. Reusabilidad. La nocin de objeto permite que programas que traten las mismas estructuras de informacin reutilicen las definiciones de objetos empleadas en otros programas e incluso los procedimientos que los manipulan. De esta forma, el desarrollo de un programa puede llegar a ser una simple combinacin de objetos ya definidos donde estos estn relacionados de una manera particular.
Uno de los puntos clave a remarcar es que la programacin orientada a objetos no sustituye a ninguna metodologa ni lenguaje de programacin anterior. Todos los programas que se realizan segn OOD se pueden realizar igualmente mediante programacin estructurada. Su uso en la actualidad se justifica porque el desarrollo de todas las nuevas herramientas basadas en un interfase de usuario grfico como Windows, OS/2, x-Windows, etc. Es mucho ms sencillo
3.1.3 Caractersticas de los Objetos

3.1.3.1 Identidad del Objeto
La identidad expresa que aunque dos objetos sean exactamente iguales en sus atributos, son distintos entre s. De esta forma incluso una serie de Objetos vehiculo, recin fabricados son distintos los unos de los otros. La afirmacin anterior, aunque parece obvia, tiene importancia cuando descendemos al nivel de programacin. En este mbito cada uno de los objetos tiene un controlador pro el
Pgina 15 de 159
cual se identifica. Este puede ser una variable, una estructura de datos, una cadena de caracteres, etc. El controlador ser distinto para cada uno de los objetos, aunque las referencias a stos sean uniformes e independientes del contenido, permitiendo crear agrupaciones de objetos con el mismo tratamiento. 3.1.3.2 Abstraccin
Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cmo se implementan estas caractersticas. Los procesos, las funciones o los mtodos pueden tambin ser abstrados y cuando lo estn, una variedad de tcnicas son requeridas para ampliar una abstraccin
3.1.3.3 Clasificacin Con la clasificacin comienza la verdadera programacin orientada a objetos. Ellos nos obliga a una abstraccin del concepto de objeto denominada clase. Las clases permiten la agrupacin de objetos que comparten las mismas propiedades y comportamiento. El esfuerzo del programador ante una aplicacin orientada a objetos se centra en la identificacin de las clases, sus atributos y operaciones asociadas y que son estas realmente las que modelan la realidad de la aplicacin a construir. Las propiedades de cada clase deben cumplir una serie de premisas Las propiedades deber ser significativas dentro del entorno de la aplicacin es decir, deben servir para identificar claramente y de una manera nica (y univoca) a cada uno de los objetos El nmero de propiedades de un objeto debe ser el mnimo para realizar todas las operaciones que requiera la aplicacin.
Pgina 16 de 159
3.1.3.4
Encapsulacin y ocultacin de datos
La capacidad de presentacin de informacin dentro de un objeto se divide en dos partes bien diferenciadas: Interna: La informacin que necesita el objeto para operar y que es innecesaria para los dems objetos de la aplicacin. Estos atributos se denominada privados y tienen como marco de aplicacin nicamente a las operaciones asociadas al objeto. Externa La que necesitan el resto de los objetos para interactuar con el objeto que definimos . Estas propiedades se denominan pblicas y corresponde a la informacin que necesitan conocer los restantes objetos de la aplicacin respecto del objeto definido para poder operar. Podemos imaginarla encapsulacin como introducir el objeto dentro de una caja negra donde existen dos ranuras denominadas entrada y salida. Si introducimos datos por la entrada automticamente obtendr un resultado en la salida. No necesita conocer ningn detalle del funcionamiento interno de la caja. El trmino encapsulacin indica la capacidad que tienen los objetos de construir una cpsula a su alrededor, ocultando la informacin que contienen (aqulla que es necesaria para su funcionamiento interno, pero innecesaria para los dems objetos) a las otras clases que componen la aplicacin. Aunque a primera vista la encapsulacin puede parecer superflua, tengamos en cuenta que existen muchas variables utilizadas de forma temporal: contadores y variables que contienen resultados intermedios, etc. De no ser por la encapsulacin estas variables ocuparan memoria y podran interferir en el funcionamiento del resto de los objetos. La encapsulacin no es exclusiva de los lenguajes de programacin orientados a objetos. Aparece en los lenguajes basados en procedimientos (PASCAL, C, COBOL, ETC) como una forma de proteger los datos que se manipulan dentro de las funciones.
Pgina 17 de 159
Los lenguajes OOP incorporan la posibilidad de encapsular tambin las estructuras de datos que sirven como base a las funciones. Aportan por tanto un nivel superior en cuanto a proteccin de informacin. La encapsulacin nos permite el uso de libreras de objetos para el desarrollo de nuestros programas. Recordemos que las libreras son definiciones de objetos de propsito general que se incorporan a los programas. Al ser el objeto parcialmente independiente en su funcionamiento del programa en donde est definido, ya que contiene y define todo lo que necesita para poder funcionar, es fcil utilizarlo en los mas variados tipos de aplicaciones. Si aseguramos , depurando las propiedades y las operaciones dentro de la clase que el objeto funcin bien dentro de una aplicacin, con una correcta encapsulacin el objeto podr funcionar en cualquier otra. Otra de las ventajas de la encapsulacin, es que al definir el objeto como una caja negra con entradas y salida asociadas, en cualquier momento podemos cambiar el contenido de las operaciones del objeto, de manera que no afecte al funcionamiento general del programa. La encapsulacin est en el ncleo de dos grandes pilares de la construccin de sistemas; mantenibilidad y reusabilidad
3.1.3.5
Mantenibilidad
Cualidad que indica que un programa o sistema debe ser fcilmente modificable. Es decir que los cambios en las condiciones externas (como la definicin de una nueva variable) implicarn modificaciones pequeas en el programa / sistema. El concepto de mantenibilidad implica que un programa, al igual que un ser vivo debe ser capaz de adaptarse a un medio ambiente siempre cambiante.
Pgina 18 de 159
3.1.3.6
Reusabilidad
Cualidad que nos indica que partes del programa ( en este caso objetos) pueden ser reutilizados en la confeccin de otros programas. Ello implica que los objetos definidos en un programa pueden ser extrados del mismo e implantados en otro sin tener que realizar modificaciones importantes en el cdigo del objeto.
3.1.3.7
Poliformismo
El polimorfismo es una nueva caracterstica aportada por la OOP. Esta propiedad indica la posibilidad de definir varias operaciones con el mismo nombre, diferencindolas nicamente en los parmetros de entrada. Dependiendo del objeto que se introduzca como parmetro de entrada, se elegir automticamente cual de las operaciones se va a realizar. Ya est habituado al operador <<suma>> que est presente en todos los lenguajes de programacin. Sin embargo, los operadores <<suma de fracciones>> y <<suma de nmeros complejos>> no existen en casi ningn lenguaje de programacin. Los lenguajes OOP permiten definir un operador <<suma>> tal que reconozca que tipo de objeto se le est aplicando, a travs de operaciones de objetos. Previamente deber definir la fraccin y el nmero complejo como una clase y la operacin suma como una operacin de una clase. Definiendo adecuadamente las operaciones suma de fracciones y suma de nmeros imaginarios, el operador suma devolver, en el caso que los operandos sean fracciones, una fraccin y , en el caso de los nmeros imaginarios, otros nmero imaginario. Es posible extender el concepto e incluso definir operaciones como suma de bases de datos
3.1.3.8
Herencia
Pgina 19 de 159
La herencia es la ltima de las propiedades relativas a la OOP, Consiste en la propagacin de los atributos y las operaciones a travs de distintas sub-clases definidas a partir de una clase comn. Introduce, por tanto, una posibilidad de refinamiento sucesivo del concepto de clase. Nos permite definir una clase principal y , a travs de sucesivas aproximaciones, cualquier caracterstica de los objetos. A partir de ahora definiremos como sub-clases todas aquellas clases obtenidas mediante refinamiento de una (o varias) clases principales. La herencia nos permite crear estructuras jerrquicas de clases donde es posible la creacin de sub-clases que incluyan nuevas propiedades y atributos. Estas sub-clases admiten la definicin de nuevos atributos, as como crear, modificar o inhabilitar propiedades. Posibles modelos. Adems, es posible que una sub-clase herede atributos y propiedades de ms de una clase. Este proceso se denomina herencia mltiple La herencia es, sin duda alguna, una de las propiedades ms importantes de la OOP, ya que permite, a travs de la definicin de una clase bsica, ir aadiendo propiedades a medida que sean necesarias y, adems, en el sub-conjunto de objetos que sea preciso. La herencia permite que los objetos puedan compartir datos y comportamientos a travs de las diferentes sub-clases, sin incurrir en redundancia. Ms importante que el ahorro de cdigo, es la claridad que aporta al identificar que las distintas operaciones sobre los objetos son en realidad una misma cosa. 3.1.3.9 Conclusin.
Identidad, clasificacin, polimorfismo y herencia caracterizan a los lenguajes orientados a objetos. Cada uno de estos conceptos puede utilizarse aisladamente, incluso aparecen en otras metodologas de programacin, pero juntos se complementan en una relacin sinrgica. Los beneficios de la programacin orientada a objetos son ms que los que pueden verse a simple vista. El nfasis en las propiedades esenciales de un objeto, fuerza al
Pgina 20 de 159
desarrollador a pensar cuidadosamente que es un objeto y que es lo que hace con el resultado de que el sistema es normalmente ms preciso, general y robusto que si pusiramos el nfasis en los procedimientos y los datos por separado.
3.2
Patrones de Diseo
Un patrn de diseo es una solucin a un problema de diseo no trivial que es efectiva (ya se resolvi el problema satisfactoriamente en ocasiones anteriores) y reusable (se puede aplicar a diferentes problemas de diseo en distintas circunstancias). Los patrones son soluciones de sentido comn que deberan formar parte del conocimiento de un diseador experto. Adems facilitan la comunicacin entre diseadores, pues establecen un marco de referencia (terminologa, justificacin). Los patrones son una manera de resolver problemas del desarrollo del software, fruto de la experiencia acumulada de muchos desarrolladores. Esto garantiza que el patrn no es simplemente una abstraccin terica, sino que realmente soluciona el problema planteado y ha sido probado miles y miles de veces por lo que es altamente fiable y estable para la solucin del problema especifico. En la programacin orientada a objetos resulta complicado descomponer el sistema en objetos (encapsulacin, granularidad, dependencias, flexibilidad, reusabilidad, etc.), los patrones de diseo nos permitirn identificar a los objetos apropiados de una manera mucho ms sencilla. Tambin nos permitirn determinar la granularidad de los objetos.
Los patrones permiten Ante un problema reiterado ofrece una solucin contrastada que lo resuelve. Describe el problema en forma sencilla. Describe el contexto en que ocurre. Describe los pasos a seguir.
Pgina 21 de 159
Describe los puntos fuertes y dbiles de la solucin. Describe otros patrones asociados
En general un patrn tiene cuatro elementos fundamentales: El Nombre del Patrn, describe la forma en que podemos manejar un problema sus soluciones y consecuencias descritas en una o dos palabras El problema describe cuando aplicar dicho patrn. Explica el problema y su contexto. Puede exponer problemas especficos de diseo tales como representar algoritmos como objetos. En algunas ocasiones se incluyen tambin listas de condiciones que deben de ser conocidas antes de decidir aplicar este diseo La solucin, describe los elementos que componen el diseo, sus relaciones, responsabilidades y colaboracin. La solucin no describe un diseo concreto particular o su implementacin, esto es debido a que un patrn es mas como una plantilla que puede ser aplicada en muchas situaciones. En ves de eso, el patrn provee una descripcin abstracta del diseo de un problema Las consecuencias, estas son el resultado de la aplicacin del patrn. Las consecuencias, son elementos crticos al momento de evaluar las alternativas de diseo
3.2.1 Historia
El reciente inters del mundo del software por los patrones tiene su origen, a partir de 1995, tras la aparicin y el xito del libro "Design Patterns: Elements of Reusable ObjectOriented Software" de la banda de los cuatro. Ellos, Erich Gamma, Richar Helm, Ralph Johnson y John Vlissides, se dedicaron a recopilar una serie de patrones (23) aplicados habitualmente por expertos diseadores de software orientado a objetos, y al hacerlos pblicos. Podemos mencionar otros autores que han contribuido a este tema como Craig Larman, quien ha definido de los patrones GRASP (patrones generales de software para asignar responsabilidades
Pgina 22 de 159
3.2.2 Conceptos Clave

Resulta difcil hablar de patrones de diseo, sin retomar dos trminos que son un objetivo permanente del diseo orientado a objetos, como son la cohesin y el acoplamiento. Podramos definir la cohesin de una clase (o de un paquete, etc.) como la relacin entre los distintos elementos de la clase, normalmente sus mtodos. Es decir, que todos los elementos de una clase tienen que trabajar en la misma direccin, es decir, hacia un mismo fin. Por ejemplo, una clase "Coche" debera ocuparse de cosas relacionadas con el coche en si, como acelerar y frenar, pero no de cosas ajenas a l como manipular informacin referente a su seguro. La cohesin es una medida relativa, en el sentido de que depende de lo que cada uno piense que es la funcin de la clase, pero lo importante es mantener una cohesin lo mas alta posible. Existen diferentes tipos de cohesin (funcional, secuencial, etc.), Respecto al acoplamiento, podemos decir que es la interdependencia existente entre dos clases, paquetes, etc. Esto ocurre normalmente cuando una clase (o paquete) necesita saber demasiados detalles internos de otra para su funcionamiento, es decir, rompe el encapsulamiento del que tanto se habla en la programacin orientada a objetos. Tambin existen diversos tipos de acoplamiento (funcional, de datos, etc.), lo que nos lleva a la conclusin que para tener un diseo correcto, fcil de mantener y modular, cuanto ms bajo acoplamiento haya entre las clases (o paquetes), pues mejor.
3.2.3 Tipos de Patrones

La banda de los cuatro (GoF) defini tres tipos distintos de patrones fundamentales:

patrones de creacin. patrones estructurales. patrones de comportamiento
Pgina 23 de 159
3.2.3.1
Patrones Creacionales
Los patrones de creacin son las soluciones aceptadas como "buenas" a los problemas de creacin de instancias de objetos. Los programas orientados a objetos crean decenas, cientos o incluso miles de instancias de objetos, es por ello, que esta no es una tarea que se puede realizar a la ligera. Nuestros programas no deben depender de la forma en que se crean y organizan los objetos. Por supuesto que podemos utilizar el operador new cada vez que necesitemos, pero en ocasiones eso puede hacer nuestro software realmente difcil de mantener. Adems, en muchos casos, puede ocurrir que el objeto concreto que necesitemos en un momento concreto dependa del estado de nuestra aplicacin en tiempo de ejecucin. Por ejemplo, puede ocurrir que en un momento tengamos que dibujar un crculo o un cuadrado, pero no por ello tenemos que llenar nuestro software de sentencias if. El crear clases especiales que abstraen el proceso de creacin de instancias hace que nuestro software sea ms flexible y general. Ejemplos de estos patrones son:

Patrn Factora Patrn Factora Abstracta Patrn Singleton (Instancia nica) Patrn Prototipo Patrones Estructurales
3.2.3.2
Los patrones estructurales se ocupan de la combinacin de objetos para crear estructuras complejas. Esto no es del todo exacto, ya que hay patrones estructurales que se encargan de las relaciones entre clases (mayoritariamente el uso de la herencia), mientras que otros se encargan de los objetos, las instancias de las clases (normalmente composicin). Destacan entre este tipo de patrones, el patrn adaptador (adapter pattern, GoF), el patrn fachada (facade pattern, GoF), el patrn proxy (proxy pattern, GoF) y el patrn puente (bridge pattern, GoF).
Pgina 24 de 159
3.2.3.3
Patrones de Comportamiento
Los patrones de comportamiento estudian las relaciones entre llamadas entre los diferentes objetos, normalmente ligados con la dimensin temporal Entre este tipo de patrones, tenemos: Patrn Cadena de Responsabilidad Patrn Comando Patrn Intrprete Patrn Iterador Patrn Mediador Patrn Recuerdo (Memento) Patrn Observador Patrn Estado Patrn Estrategia Patrn Plantilla Patrn Visitante
3.2.4 Patrones de Acceso a Datos

Asi como los patrones de diseo, implementan soluciones a problemas comunes, los patrones de acceso a datos tienen un rol similar en el campo del acceso a datos. Estos patrones, describen una abstraccin comn a problemas a soluciones que pueden ser aplicadas directamente a problemas relacionados con la obtencin y persistencia de la informacin. Algunos de estos patrones son aplicados o utilizados ampliamente en una variedad de productos comerciales como en los casos de los patrones Resource pool y Object/Relational Map. Otros de estos patrones, son menos utilizados o conocidos, de igual forma ofrecen una amplia gama de soluciones a problemas relacionados con los datos. Muchos de estos patrones, son adaptaciones de los patrones fundamentales a problemas especficos del rea de acceso a datos. De este tipo de patrones tambin existe una categorizacin la cual se muestra a continuacin:
Pgina 25 de 159
Decoupling Patterns: describen estrategias para separar el acceso a datos de otras responsabilidades de la aplicacin. Esta accin de separacin brinda flexibilidad cuando se selecciona un modelo subyacente de datos o cuando se realizan cambios a la estrategia completa de acceso a datos. Algunos de estos patrones son: o Data Accesor o Active Domain Object o Object/Relational Map o Layer Resource Patterns: describen estrategias para administrar los objetos envueltos en relaciones de acceso a datos. Entre estos patrones tenemos: o Resource Decorador o Resource Pool o Resource Timer o Resource Descriptor o Retraer Input/output patterns: Describen patrones que simplifican las operaciones de entrada y salida, usando una tranlacin consistente en informacin relacional y la representacin de los Domain objects. Entre estos patrones tenemos: o Selection Factory o Domain Object Factory o Update Factory o Domain Object Assembler o Paging Iterator Cache Patterns: brindan soluciones que reducen la frecuencia de las operaciones de acceso a datos, almacenado informacion comun en cache. Estos patrones generalmente almacenan Domain object mas que informacin relacional. Entre estos patrones tenemos: o Cache Accessor o Demand Cache o Primed Cache
Pgina 26 de 159
o Cache Search Sequence o Cache Collector o Cache Replicator o Cache Statistics Concurrency Patterns: ofrecen soluciones para el acceso multiple o concurrente a informacin comun en una base datos. La mayoria de base de datos ofrecen operaciones de locking para permitir y ayudar con este problema, sin embargo la utilizacin de cdigo que maneje este problema desde la aplicacin, puede ser tuneado para necesidades especificas. Algunos patrones representantivos de este grupo son: o Transaction o Optimistic Lock o Pessimistic Lock o Compensating
3.2.5 El patrn Singleton

Este patrn asegura que slo una instancia de la clase es creada. Todos los objetos que usan una instancia de esa clase, usan la misma instancia. Algunas clases deben tener exactamente una instancia. Estas clases usualmente involucran la administracin centralizada de algn recurso. Por ejemplo, si se necesita escribir una clase que un applet pueda usar para asegurar que no ms de un clip de audio sea ejecutado al mismo tiempo. Para evitar que dos clips de audio sean ejecutados al mismo tiempo, la clase que usted escribe debe dejar de ejecutar un clip de audio antes de empezar a ejecutar el siguiente. Una forma de lograr esto, es asegurar que solamente exista una instancia de la clase, compartida por todos los objetos que usan la clase. La siguiente figura muestra el diagrama de clases.
Pgina 27 de 159
Se debe de recordar que "+" significa que la caracterstica es pblica, y "-" significa que la caracterstica es privada. Una caracterstica subrayada indica que es esttica. El constructor de la clase es privado. Esto previene que otras clases creen directamente una instancia de la clase. En lugar de eso, para acceder a una instancia de la clase deben usar el mtodo getInstance. Este mtodo es esttico, y siempre regresa la misma instancia de la clase. La siguiente figura muestra el diagrama de clases general de este patrn.
3.2.6 El Patrn Factory

Si consideramos el problema de crear un framework para el desarrollo de aplicaciones para PC (tipo MSOffice). Estas aplicaciones estn generalmente organizadas de una forma "centradas en documentos" (o "centradas en archivos"). Las operaciones usualmente empiezan con un comando para crear o editar un documento (del procesador de texto, la planilla electrnica, etc.). En el caso de un editor de texto, adems el editor puede reconocer diferentes tipos de archivos. Un framework que apoye este tipo de aplicaciones
Pgina 28 de 159
debe incluir operaciones comunes de alto nivel, como crear, abrir o guardar documentos. Supongamos que queremos crear los mtodos de la clase Application. La mayora de los mtodos de esta clase varan segn el tipo de documento. Debido a esto, la clase Application usualmente delega la mayora de los comandos a algn tipo de objeto documento. Adems, la lgica de las operaciones del objeto documento puede variar segn el tipo de documento. Sin embargo, hay operaciones, como por ejemplo desplegar el string con el ttulo del documento o desplegar una imagen .gif, que son comunes para todos los objetos documento. Esto sugiere una organizacin que incluya una clase abstracta Document independiente de la aplicacin, para especificar los tipos de documentos. Esta organizacin es mostrada en la siguiente figura.
Lo que no queda claro aun, es cmo un objeto Application puede crear instancias de clases de documentos especficos para esa aplicacin, sin ser ella misma una aplicacin especfica. Para lograr esto, se puede encapsular la lgica e instanciar subclases de la clase Document especficas a la aplicacin en una interfaz. La siguiente figura muestra esta nueva organizacin.
Pgina 29 de 159
Usando la organizacin de la figura anterior, un objeto Application llama al mtodo createDocument de un objeto que implementa la interfaz DocumentFactoryIF. ste le pasa un string al mtodo createDocument que le dice al mtodo cul subclase de la clase Document debe instanciar. El patrn Fctory provee un objeto independiente de la aplicacin con un objeto especfico a la aplicacin, al cual delega la creacin de otros objetos especficos a la aplicacin. La siguiente figura muestra el diagrama general de este patrn.
Pgina 30 de 159
Los roles que las clases e interfaz de la figura anterior juegan son los siguientes: Product. Una clase en este rol es la superclase abstracta de objetos producidos por el patrn Factory. Concrete Product. Cualquier clase concreta instanciada por los objetos que participan en este patrn. Creation Requestor. El objeto que requiere la creacin, es una clase independiente de la aplicacin que necesita crear clases especficas a la aplicacin. Esto lo hace indirectamente a travs de una instancia de la clase Factory. Factory IF. Es una interfaz independiente de la aplicacin. Los objetos que crean productos usando CreationRequestor deben implementar esta interfaz. Las interfaces de este tipo declaran un mtodo que es llamado por un objeto CreationRequestor para crear productos concretos. Factory Class. Es una clase especfica a la aplicacin que implementa la interfaz de fbrica adecuada, y tiene un mtodo para crear productos concretos.
Pgina 31 de 159
3.2.7 El Patrn Abstract Factory

Este patrn es tambin conocido como Kit o Toolkit. Dado un conjunto de clases relacionadas, el patrn Fbrica Abstracta provee una forma de crear instancias de estas clases desde un conjunto acoplado de subclases concretas. Supongamos que tenemos que construir un framework para crear interfaces de usuario, que trabajen sobre mltiples plataformas grficas (MS-Windows, Motif, MacOS, etc.). Cada plataforma tiene una forma nativa de desplegar cada componente (look and feel). Para construir el framework, se puede crear una clase abstracta para cada tipo de objeto (texto, botones, listas, etc.) y luego reescribir una subclase concreta de cada clase de objeto para cada plataforma. Para hacerlo robusto, hay que asegurarse adems que todos los objetos creados son de la plataforma deseada. En esta situacin, una clase fbrica abstracta define mtodos para crear una instancia de cada clase abstracta que representa un objeto de la interfaz de usuario. Fbricas concretas son subclases concretas de una fbrica abstracta que implementa sus mtodos para crear instancias de clases de objetos concretos para una misma plataforma. En un contexto ms general, una clase de fbrica abstracta y sus subclases concretas, organizan conjuntos de clases concretas que trabajan con productos diferentes, pero relacionados entre s. La siguiente figura muestra el diagrama general de este patrn.
Pgina 32 de 159
Los roles del la imagen anterior son los siguientes: Client. Las clases en el rol del cliente (Client) usan varias clases de objetos (widgets) para solicitar servicios del producto con el que el cliente est trabajando. Las clases cliente solamente conocen las clases de objetos (widgets) abstractos, y no necesitan conocer las clases concretas. AbstractFactory. Las clases AbstractFactory definen mtodos abstractos para crear instancias de clases de objetos concretas. Tienen un mtodo esttico getFactory el cual es llamado por los objetos Client para tener una instancia de una fbrica concreta, apropiada para crear widgets que trabajan con un producto particular. ConcreteFactory1, ConcreteFactory2. Estas clases implementan los mtodos definidos por la superclase de la fbrica abstracta, para crear instancias de widgets concretos. Las clases cliente que llaman estos mtodos no necesitan tener conocimiento directo de estas clases de fbrica concretas. En lugar de esto, accesan instancias de estas clases como instancias de la superclase fbrica abstracta.
Pgina 33 de 159
WidgetA, WidgetB. Son clases abstractas que corresponden a caractersticas de un producto con el que trabaja la subclase concreta. Se conocen como widgets abstractos. Product1WidgetA, Product2WidgetA. Son clases concretas que corresponden a caractersticas de un producto con el que trabajan. Se conocen como widgets concretos
3.2.8 El Patron Data Accessors

El patrn Data Accessor encapsula los detalles del acceso fsico a datos en una componente simple, exponiendo nicamente las operaciones lgicas vitales. El cdigo de la aplicacin debe mantener el conocimiento del modelo de datos pero, es separado a traves del uso de este patron, de cualquier responsabilidad de acceso a datos. La estructura esttica de este patrn, es mostrada en la siguiente figura:
3.2.9 Patron DAO (Data Access Object)

3.2.9.1 Origenes de DAO
Este patrn ha sido tomado de las especificaciones J2EE de la plataforma Java, su utilidad y beneficios son altos por lo que ser aplicado en la construccin de nuestro prototipo.
Pgina 34 de 159
3.2.9.2
Contexto y Aplicacin.
Muchas aplicaciones en el mundo real necesitan utilizar datos persistentes en algn momento. Para muchas de ellas, este almacenamiento persistente se implementa utilizando diferentes mecanismos, y hay marcadas diferencias en los APIS utilizados para acceder a esos mecanismos de almacenamiento diferentes. Otras aplicaciones podran necesitar acceder a datos que residen en sistemas diferentes. Por ejemplo, los datos podran residir en sitemas mainframe, repositorios LDAP, etc. Otro ejemplo es donde los datos los proporcionan servicios a travs de sistemas externos como los sistemas de integracin negocio-a-negocio (B2B), servicios de tarjetas de crdito, etc. Normalmente, las aplicaciones utilizan componentes distribuidos y compartidos como los beans de entidad para representar los datos persistentes en la plataforma Java. Se considera que una aplicacin emplea consistencia manejada por el bean (BMP) cuando sus beans de entidad acceden explcitamente al almacenamiento persistente -- el bean de entidad incluye cdigo para hacer esto. Una aplicacin con requerimientos sencillos podra por lo tanto utilizar beans de entidad en lugar de beans de sesin o servlets para acceder al almacenamiento persistente y recuperar o modificar los datos. O, la aplicacin podra usar beans de entidad con persistencia manejada por el contenedor, y as dejar que el contenedor maneje los detalles de las transacciones y de la persistencia. Utilizar un Data Access Object (DAO) para abstraer y encapsular todos los accesos a la fuente de datos. El DAO maneja la conexin con la fuente de datos para obtener y almacenar datos. El DAO implementa el mecanismo de acceso requerido para trabajar con la fuente de datos. Esta fuente de datos puede ser un almacenamiento persistente como una RDMBS, un servicio externo como un intercambio B2B, un repositorio LDAP, o un servicio de negocios al que se accede mediante CORBA Internet Inter-ORB Protocol (IIOP) o sockets de bajo nivel. Los componentes de negocio que tratan con el DAO utilizan un interface simple expuesto por el DAO para sus clientes. El DAO oculta completamente los detalles de implementacin de la fuente de datos a sus clientes.
Pgina 35 de 159
Como el interface expuesto por el DAO no cambia cuando cambia la implementacin de la fuente de datos subyacente, este patrn permite al DAO adaptarse a diferentes esquemas de almacenamiento sin que esto afecte a sus clientes o componentes de engocio. Esencialmente, el DAO acta como un adaptador entre el componente y la fuente de datos. La siguiente figura muestra el diagrama de clases que representa las relaciones para el patrn DAO:
La siguiente figura muestra el diagrama de secuencia de la interaccin entre los distintos participantes en este patrn:
Pgina 36 de 159
BusinessObject :Representa los datos del cliente. Es el objeto que requiere el acceso a la fuente de datos para obtener y almacenar datos. Podramos implementar un businessObject como un bean de sesin, un bean de entidad o cualquier otro objeto Java, adems de como un Servlet o como un bean de apoyo. DataAccessObject: es el objeto principal de este patrn. DataAccessObject abstrae la implementacin del acceso a datos subyacente al BusinessObject para permitirle un acceso transparente a la fuente de datos. El BusinessObject tambin delega las operaciones de carga y almacenamiento en el DataAccessObject. DataSource: Representa la implementacin de la fuente de datos. Una fuente de datos podra ser una base de datos como un RDBMS, un OODBMS, un repositorio XML, un fichero plano, etc. Tambin lo pueden ser otros sitemas (mainframes/legales), servicios (servicio B2B u oficina de tarjetas de crdito), o algn tipo de repositorio (LDAP).
3.2.9.3
Generacin Automtica de DAO
Como cada BusinessObject corresponde a un DAO especfico, es posible establecer relaciones entre el BusinessObject, el DAO, y las implementaciones subyacentes (como en las tablas de una RDBMS). Una vez que se han establecido las relaciones, es posible escribir una utilidad de generacin-de-cdigo-especfica-de-aplicacin que genere el cdigo para todos los DAOs que necesita la aplicacin. Los meta datos para generar el DAO pueden venir de un fichero descriptor definido por el desarrollador. Como alternativa, el generador de cdigo puede inspeccionar la base de datos y proporcionar los DAOs necesarios para acceder a ella. Si los requerimientos de los DAOs son lo suficientemente complejos, debemos considerar la utilizacin de herramientas de terceras partes que proporcionan un mapeo de objeto-arelacional para bases de datos RDBMS. Estas herramientas normalmente incluyen utilidades GUI para mapear los objetos de negocio a objetos de almacenamiento persistente y adems definir los DAOs intermedios. Estas herramientas generan el cdigo automticamente una vez que se termina el mapeo, y podran proporcionar otras caractersticas valiosas como el cach de resultados y de consultas, integracin con servidores de aplicaciones, integracin con otros productos de terceras partes, etc.
Pgina 37 de 159
3.2.9.4
Ventajas de DAO
Algunas ventajas en la utilizacin de DAO son las siguientes: Permite la Transpariencia Los objetos de negocio puede utilizar la fuente de datos sin conocer los detalles especficos de su implementacin. El acceso es transparente porque los detalles de la implementacin se ocultan dentro del DAO. Permite una Migracin ms Fcil :Una capa de DAOs hace ms fcil que una aplicacin pueda migrar a una implementacin de base de datos diferente. Los objetos de negocio no conocen la implementacin de datos subyacente, la migracin implica cambios slo en la capa DAO. Adems, si se emplea la estrategia de factoras, es posible proporcionar una implementacin de factoras concretas por cada implementacin del almacenamiento subyacente. En este caso, la migracin a un almacenamiento diferente significa proporcionar a la aplicacin una nueva implementacin de la factora. Reduce la Complejidad del Cdigo de los Objetos de Negocio : Como los DAOs manejan todas las complejidades del acceso a los datos, se simplifica el cdigo de los objetos de negocio y de otros clientes que utilizan los DAOs. Todo el cdigo relacionado con la implementacin (como las sentencias SQL) estn dentro del DAO y no en el objeto de negocio. Esto mejora la lectura del cdigo y la productividad del desarrollo. Centraliza Todos los Accesos a Datos en un Capa Independiente :Como todas las operaciones de acceso a los datos se ha delegado en los DAOs, esto se puede ver como una capa que asla el resto de la aplicacin de la implementacin de acceso a los datos. Esta centralizacin hace que la aplicacin sea ms sencilla de mantener y de manejar.
3.3
Bases de Datos Orientadas a Objetos
Los modelos de bases de datos tradicionales (relacional, red y jerrquico) han sido capaces de satisfacer con xito las necesidades, en cuanto a bases de datos, de las aplicaciones de gestin tradicionales. Sin embargo, presentan algunas deficiencias cuando se trata de aplicaciones ms complejas o sofisticadas como, por ejemplo, el diseo y fabricacin en ingeniera (CAD/CAM, CIM), los experimentos cientficos, los sistemas de informacin
Pgina 38 de 159
geogrfica o los sistemas multimedia. Los requerimientos y las caractersticas de estas nuevas aplicaciones difieren en gran medida de las tpicas aplicaciones de gestin la estructura de los objetos es ms compleja, las transacciones son de larga duracin, se necesitan nuevos tipos de datos para almacenar imgenes y textos, y hace falta definir operaciones no estndar, especficas para cada aplicacin. Las bases de datos orientadas a objetos se crearon para tratar de satisfacer las necesidades de estas nuevas aplicaciones. La orientacin a objetos ofrece flexibilidad para manejar algunos de estos requisitos y no est limitada por los tipos de datos y los lenguajes de consulta de los sistemas de bases de datos tradicionales. Una caracterstica clave de las bases de datos orientadas a objetos es la potencia que proporcionan al diseador al permitirle especificar tanto la estructura de objetos complejos, como las operaciones que se pueden aplicar sobre dichos objetos. Otro motivo para la creacin de las bases de datos orientadas a objetos es el creciente uso de los lenguajes orientados a objetos para desarrollar aplicaciones. Las bases de datos se han convertido en piezas fundamentales de muchos sistemas de informacin y las bases de datos tradicionales son difciles de utilizar cuando las aplicaciones que acceden a ellas est escritas en un lenguaje de programacin orientado a objetos como C++, Smalltalk o Java. Las bases de datos orientadas a objetos se han diseado para que se puedan integrar directamente con aplicaciones desarrolladas con lenguajes orientados a objetos, habiendo adoptado muchos de los conceptos de estos lenguajes. Los fabricantes de los Sistemas gestores de Base de Datos (SGBD) relacionales tambin se han dado cuenta de las nuevas necesidades en el modelado de datos, por lo que las nuevas versiones de sus sistemas incorporan muchos de los rasgos propuestos para las bases de datos orientadas a objetos, como ha ocurrido con Informix y Oracle. Esto ha dado lugar al modelo relacional extendido y a los sistemas que lo implementan se les denomina sistemas objetorelacionales. La nueva versin de SQL, SQL:19993, incluye algunas de las caractersticas de la orientacin a objetos.
3 Este es el nombre que recibe el estndar. En ocasiones se cita como SQL3 porque as se llamaba el proyecto que lo desarroll. Tambin se cita como SQL99, por ser un nombre similar al de la versin anterior, Pgina 39 de 159
Durante los ltimos aos se han creado muchos prototipos experimentales de sistemas de bases de datos orientadas a objetos y tambin muchos sistemas comerciales. Conforme stos fueron apareciendo, surgi la necesidad de establecer un modelo estndar y un lenguaje. Para ello, los fabricantes de los SGBD orientadas a objetos formaron un grupo denominado ODMG (Object Database Management Group), que propuso el estndar ODMG93 y que ha ido evolucionando hasta el ODMG 3.0, su ltima versin. El uso de estndares proporciona portabilidad, permitiendo que una aplicacin se pueda ejecutar sobre sistemas distintos con mnimas modificaciones. Los estndares tambin proporcionan interoperabilidad, permitiendo que una aplicacin pueda acceder a varios sistemas diferentes. Y una tercera ventaja de los estndares es que permiten que los usuarios puedan comparar entre distintos sistemas comerciales, dependiendo de qu partes del estndar proporcionan.
3.3.1 El Concepto de Orientacin a Objetos

El desarrollo del paradigma orientado a objetos aporta un gran cambio en el modo en que se ven los datos y los procedimientos que actan sobre ellos. Tradicionalmente, los datos y los procedimientos se han almacenado separadamente: los datos y sus relaciones en la base de datos y los procedimientos en los programas de aplicacin. La orientacin a objetos, sin embargo, combina los procedimientos de una entidad con sus datos. Esta combinacin se considera como un paso adelante en la gestin de datos. Las entidades son unidades auto contenidas que se pueden reutilizar con relativa facilidad. En lugar de ligar el comportamiento de una entidad a un programa de aplicacin, el comportamiento es parte de la entidad en s, por lo en cualquier lugar en el que se utilice la entidad, se comporta de un modo predecible y conocido.
SQL92; sin embargo, este ltimo nombre no se ha utilizado en esta ocasin porque se quiere evitar el efecto 2000 en el nombre de futuras versiones.
Pgina 40 de 159
El modelo orientado a objetos tambin soporta relaciones de muchos a muchos, siendo el primer modelo que lo permite. An as se debe ser muy cuidadoso cuando se disean estas relaciones para evitar prdidas de informacin. Por otra parte, las bases de datos orientadas a objetos son navegacionales: el acceso a los datos es a travs de las relaciones, que se almacenan con los mismos datos. Esto se considera un paso atrs. Las bases de datos orientadas a objetos no son apropiadas para realizar consultas ad hoc, al contrario que las bases de datos relacionales, aunque normalmente las soportan. La naturaleza navegacional de las bases de datos orientadas a objetos implica que las consultas deben seguir relaciones predefinidas y que no pueden insertarse nuevas relaciones al vuelo. No parece que las bases de datos orientadas a objetos vayan a reemplazar a las bases de datos relacionales en todas las aplicaciones del mismo modo en que stas reemplazaron a sus predecesoras. Los objetos han entrado en el mundo de las bases de datos de formas: SGBD orientados a objetos puros: son SGBD basados completamente en el modelo orientado a objetos. SGBD hbridos u objetorelacionales: son SGBD relacionales que permiten almacenar objetos en sus relaciones (tablas).
3.3.2 El Modelo de Datos Orientado a Objetos

El modelo de datos orientado a objetos es una extensin del paradigma de programacin orientado a objetos. Los objetos entidad que se utilizan en los programas orientados a objetos son anlogos a las entidades que se utilizan en las bases de datos orientadas a objetos puros, pero con una gran diferencia: los objetos del programa desaparecen cuando el programa termina su ejecucin, mientras que los objetos de la base de datos permanecen. A esto se le denomina persistencia.
Pgina 41 de 159
En una base de datos orientada a objetos, cualquier cosa es un objeto y se manipula como tal. Un objeto es una instancia que responde a mensajes activando un mtodo. Los objetos soportan una serie de caractersticas de los mismos : Se agrupan en tipos denominados clases Contienen datos internos que definen su estado actual Soportan ocultacin de datos Pueden heredar propiedades de otros objetos Pueden comunicarse con otros objetos enviando o pasando mensajes Tienen mtodos que definen su comportamiento
3.3.2.1
Relaciones
Las bases de datos relacionales representan las relaciones mediante las claves ajenas. No tienen estructuras de datos que formen parte de la base de datos y que representen estos enlaces entre tablas. Las relaciones se utilizan para hacer concatenaciones (join) de tablas. Por el contrario, las bases de datos orientadas a objetos implementan sus relaciones incluyendo en cada objeto los identificadores de los objetos con los que se relaciona. Un identificador de objeto es un atributo interno que posee cada objeto. Ni los programadores, ni los usuarios que realizan consultas de forma interactiva, ven o manipulan estos identificadores directamente. Los identificadores de los objetos los asigna el SGBD y es l el nico que los utiliza. El identificador puede ser un valor arbitrario o puede incluir la informacin necesaria para localizar el objeto en el fichero donde se almacena la base de datos. Por ejemplo, el identificador puede contener el nmero de la pgina del fichero donde se encuentra almacenado el objeto, junto con el desplazamiento desde el principio de la pgina. Hay dos aspectos importantes a destacar sobre este mtodo de representar las relaciones entre datos:
Pgina 42 de 159
Para que el mecanismo funcione, el identificador del objeto no debe cambiar mientras este forme parte de la base de datos. Las nicas relaciones que se pueden utilizar para consultar la base de datos son aquellas que se han predefinido almacenando en atributos los identificadores de los objetos relacionados. Por lo tanto, una base de datos orientada a objetos pura es navegacional, como los modelos prerrelacinales (el modelo jerrquico y el modelo de red). De este modo se limita la flexibilidad del programador/usuario a aquellas relaciones predefinidas, pero los accesos que siguen estas relaciones presentan mejores prestaciones que en las bases de datos relacionales porque es ms rpido seguir los identificadores de los objetos que hacer operaciones de concatenacin (join).
El modelo orientado a objetos permite los atributos multivaluados, agregaciones a las que se denomina conjuntos (sets) o bolsas (bags). Para crear una relacin de uno a muchos, se define un atributo en la parte del uno que ser de la clase del objeto con el que se relaciona. Este atributo contendr el identificador de objeto del padre. La clase del objeto padre contendr un atributo que almacenar un conjunto de valores: los identificadores de los objetos hijo con los que se relaciona. Cuando el SGBD ve que un atributo tiene como tipo de datos una clase, ya sabe que el atributo contendr un identificador de objeto. Las relaciones de muchos a muchos se pueden representar directamente en las bases de datos orientadas a objetos, sin necesidad de crear entidades intermedias. Para representar la relacin, cada clase que participa en ella define un atributo que contendr un conjunto de valores de la otra clase con la que se relacionar. Aunque el hecho de poder representar relaciones de muchos a muchos parece aportar muchas ventajas, hay que tener mucho cuidado cuando se utilizan. En primer lugar, si la relacin tiene datos, ser necesario crear una entidad intermedia que contenga estos datos. Por ejemplo, en la relacin de los artculos con los proveedores, en donde cada proveedor puede tener un precio distinto para un mismo artculo. En este caso, la relacin de muchos a muchos se sustituye por dos relaciones de uno a muchos, como se hara en una base de datos relacional. En segundo lugar, se puede disear una base de datos que contiene relaciones de muchos a muchos en
Pgina 43 de 159
donde o bien se pierde informacin, o bien se hace imposible determinar las relaciones con precisin. Tambin en estos casos la solucin es incluir una entidad intermedia que represente la relacin. Ya que el paradigma orientado a objetos soporta la herencia, una base de datos orientada a objetos tambin puede utilizar la relacin es un entre objetos. Por ejemplo, en una base de datos para un departamento de recursos humanos habr una clase genrica Empleado con diversos atributos: nombre, direccin, nmero de la seguridad social, fecha de contrato y departamento en el que trabaja. Sin embargo, para registrar el modo de pago de cada empleado hay un dilema. No a todos los empleados se les paga del mismo modo: a algunos se les paga por horas, mientras que otros tienen un salario mensual. La clase de los empleados que trabajan por horas necesita unos atributos distintos que la clase de los otros empleados. En una base de datos orientada a objetos se deben crear las dos subclases de empleados. Aunque el SGBD nunca crear objetos de la clase Empleado, su presencia en el diseo clarifica el diseo lgico de la base de datos y ayuda a los programadores de aplicaciones permitindoles escribir slo una vez los mtodos que tienen en comn las dos subclases (sern los mtodos que se sitan en la clase Empleado). En teora, una base de datos orientada a objetos debe soportar dos tipos de herencia: la relacin es un y la relacin extiende. La relacin es un, que tambin se conoce como generalizacinespecializacin, crea una jerarqua donde las subclases son tipos especficos de las sperclases. Con la relacin extiende, sin embargo, una clase expande su sperclase en lugar de estrecharla en un tipo ms especfico. Por ejemplo, en la jerarqua de la clase Empleado, al igual que son necesarias clases para los empleados que realizan cada trabajo especfico, hace falta guardar informacin adicional sobre los directores, que son empleados pero que tambin tienen unas caractersticas especficas. La base de datos incluir una clase Director con un atributo para los empleados a los que dirige. En este sentido un director no es un empleado ms especfico sino un empleado con informacin adicional.
Pgina 44 de 159
Una de las cosas que es difcil de manejar en las bases de datos relacionales es la idea de las partes de un todo, como en una base de datos de fabricacin, en la que hace falta saber qu piezas y qu componentes se utilizan para fabricar un determinado producto. Sin embargo, una base de datos orientada a objetos puede aprovechar la relacin denominada todo parte en la que los objetos de una clase se relacionan con objetos de otras clases que forman parte de l. En el caso de la base de datos de fabricacin, la clase Producto se relacionar con las clases Pieza y Componente utilizando una relacin todoparte. Este tipo de relacin es una relacin de muchos a muchos con un significado especial. Un producto puede estar hecho de muchas piezas y muchos componentes. Adems, una misma pieza o un mismo componente se puede utilizar para fabricar distintos productos. El identificar esta relacin como todoparte permite que el diseo sea ms fcil de entender. 3.3.2.2 Integridad de las Relaciones
Para que las relaciones funcionen en una base de datos orientada a objetos pura, los identificadores de los objetos deben corresponderse en ambos extremos de la relacin. Por ejemplo, si los aparejadores de una empresa de control de calidad se deben relacionar con las obras de construccin que supervisan, debe haber algn modo de garantizar que, cuando un identificador de un objeto Obra se incluye en un objeto Aparejador, el identificador de este mismo objeto Aparejador se debe incluir en el objeto Obra anterior. Este tipo de integridad de relaciones, que es de algn modo anlogo a la integridad referencial en las bases de datos relacionales, se gestiona especificando relaciones inversas. La clase Aparejador tiene un atributo de tipo conjunto llamado supervisa. Del mismo modo, la clase Obra tiene un atributo llamado es_supervisada. Para garantizar la integridad de esta relacin, un SGBD orientado a objetos puro deber permitir que el diseador de la base de datos pueda especificar dnde debe aparecer el identificador del objeto inverso, como por ejemplo: relationship set<Obra> supervisa inverse Obra::es supervisada
Pgina 45 de 159
en la clase Aparejador y: relationship Aparejador es supervisada inverse Aparejador::supervisa en la clase Obra. Siempre que un usuario o un programa de aplicacin inserta o elimina un identificador de objeto de la relacin supervisa en un objeto Aparejador, el SGBD actualizar automticamente la relacin es_supervisada en el objeto Obra relacionado. Cuando se hace una modificacin en el objeto Obra, el SGBD lo propagar automticamente al objeto Aparejador. Del mismo modo que en las bases de datos relacionales es el diseador de la base de datos el que debe especificar las reglas de integridad referencial, en las bases de datos orientadas a objetos es tambin el diseador el que debe especificar las relaciones inversas cuando crea el esquema de la base de datos.
3.3.3 El modelo Estndar ODMG

Un grupo de representantes de la industria de las bases de datos formaron el ODMG (Object Database Management Group) con el propsito de definir estndares para los SGBD orientados a objetos. Este grupo propuso un modelo estndar para la semntica de los objetos de una base de datos. Los principales componentes de la arquitectura ODMG para un SGBD orientado a objetos son los siguientes: Modelo de objetos. Lenguaje de definicin de objetos (ODL). Lenguaje de consulta de objetos (OQL). Conexin con los lenguajes C++, Smalltalk y Java.
Pgina 46 de 159
3.3.3.1
Modelo de Objetos
El modelo de objetos ODMG permite que tanto los diseos, como las implementaciones, sean portables entre los sistemas que lo soportan. Dispone de las siguientes primitivas de modelado: Los componentes bsicos de una base de datos orientada a objetos son los objetos y los literales. Un objeto es una instancia auto contenida de una entidad de inters del mundo real. Los objetos tienen algn tipo de identificador nico. Un literal es un valor especfico, como Amparo o 36. Los literales no tienen identificadores. Un literal no tiene que ser necesariamente un solo valor, puede ser una estructura o un conjunto de valores relacionados que se guardan bajo un solo nombre. Los objetos y los literales se categorizan en tipos. Cada tipo tiene un dominio especfico compartido por todos los objetos y literales de ese tipo. Los tipos tambin pueden tener comportamientos. Cuando un tipo tiene comportamientos, todos los objetos de ese tipo comparten los mismos comportamientos. En el sentido prctico, un tipo puede ser una clase de la que se crea un objeto, una interfase o un tipo de datos para un literal (por ejemplo, integer). Un objeto se puede pensar como una instancia de un tipo. Lo que un objeto sabe hacer son sus operaciones. Cada operacin puede requerir datos de entrada (parmetros de entrada) y puede devolver algn valor de un tipo conocido. Los objetos tienen propiedades, que incluyen sus atributos y las relaciones que tienen con otros objetos. El estado actual de un objeto viene dado por los valores actuales de sus propiedades. Una base de datos es un conjunto de objetos almacenados que se gestionan de modo que puedan ser accedidos por mltiples usuarios y aplicaciones.
Pgina 47 de 159
La definicin de una base de datos est contenida en un esquema que se ha creado mediante el lenguaje de definicin de objetos ODL (Object Definition Language) que es el lenguaje de manejo de datos que se ha definido como parte del estndar propuesto para las bases de datos orientadas a objetos
Lenguaje de Definicin de Objetos ODL es un lenguaje de especificacin para definir tipos de objetos para sistemas compatibles con ODMG. ODL es el equivalente del DDL (lenguaje de definicin de datos) de los SGBD tradicionales. Define los atributos y las relaciones entre tipos, y especifica la signatura de las operaciones. La sintaxis de ODL extiende el lenguaje de definicin de interfaces (IDL) de la arquitectura CORBA (Common Object Request Broker Architecture). Lenguaje de Consulta de Objetos. OQL es un lenguaje declarativo del tipo de SQL que permite realizar consultas de modo eficiente sobre bases de datos orientadas a objetos, incluyendo primitivas de alto nivel para conjuntos de objetos y estructuras. Est basado en SQL-92, proporcionando un sper conjunto de la sintaxis de la sentencia SELECT. OQL no posee primitivas para modificar el estado de los objetos ya que las modificaciones se pueden realizar mediante los mtodos que estos poseen. La sintaxis bsica de OQL es una estructura SELECT...FROM...WHERE..., como en SQL. Por ejemplo, la siguiente expresin obtiene los nombres de los departamentos de la escuela de Ingeniera: SELECT d.nombre FROM d in departamentos WHERE d.escuela = `Ingeniera'; En las consultas se necesita un punto de entrada, que suele ser el nombre de un objeto persistente. Para muchas consultas, el punto de entrada es la extensin de una clase. En el ejemplo anterior, el punto de entrada es la extensin departamentos, que es un objeto
Pgina 48 de 159
coleccin de tipo set<Departamento>. Cuando se utiliza una extensin como punto de entrada es necesario utilizar una variable iteradora que vaya tomando valores en los objetos de la coleccin. Para cada objeto de la coleccin (slo la forman objetos persistentes) que cumple la condicin (que es de la escuela de Ingeniera), se muestra el valor del atributo nombre. El resultado es de tipo bag<string>. Cuando se utiliza resultado es de tipo set ya que se eliminan los duplicados. OQL tiene adems otras caractersticas que no se van a presentar aqu: Especificacin de vistas dando nombres a consultas. Obtencin como resultado de un solo elemento (hasta ahora hemos visto que se devuelven colecciones: set, bag, list). Uso de operadores de colecciones: funciones de agregados (max, min, count, sum, avg) y cuantificadores (for all, exists). Uso de group by. SELECT DISTINCT el
3.4
Sistemas Objetos-Relacionales
El modo en que los objetos han entrado en el mundo de las bases de datos relacionales es en forma de dominios, actuando como el tipo de datos de una columna. Hay dos implicaciones muy importantes por el hecho de utilizar una clase como un dominio: Es posible almacenar mltiples valores en una columna de una misma fila ya que un objeto suele contener mltiples valores. Sin embargo, si se utiliza una clase como dominio de una columna, en cada fila esa columna slo puede contener un objeto de la clase (se sigue manteniendo la restriccin del modelo relacional de contener valores atmicos en la interseccin de cada fila con cada columna). Es posible almacenar procedimientos en las relaciones porque un objeto est enlazado con el cdigo de los procesos que sabe realizar (los mtodos de su clase).
Pgina 49 de 159
Otro modo de incorporar objetos en las bases de datos relacionales es construyendo tablas de objetos, donde cada fila es un objeto. Ya que un sistema objetorelacional es un sistema relacional que permite almacenar objetos en sus tablas, la base de datos sigue sujeta a las restricciones que se aplican a todas las bases de datos relacionales y conserva la capacidad de utilizar operaciones de concatenacin (join) para implementar las relaciones al vuelo. Toda la informacin de la base de datos esta guardado en los tablas pero algunas operaciones tabulares pueden tener una estructura de datos abstract data types(ADTs). Las extensiones son necesarias porque los ORBDMSs debe de soportar ADT's. El ORDBMS tiene un modelo relacionado porque los datos estn guardados en forma de tablas con renglones y columnas. SQL es usado como el lenguaje de bsqueda de informacin. Pero el modelo relacionado tiene que ser modificado para soportar las caractersticas clsicas de programacin orientada a objeto. Las caractersticas de ORDBMSs son:

extensin, de base de datos Soporte de objetos complejos, Herencia, y Reglas del Sistema.
Los ORDBMSs permiten que los usuarios puedan definir los tipos de datos, funciones y operadores. Como resultado, los ORDBMSs tiene ms funcionalidad y un mejor desempeo
3.4.1 Diferencia entre los tres sistemas (RDBMS, ODBMS, ORDBMS)

Tabla 1: Una comparacin de sistemas de Administracin de Base de Datos
Criterio Standard para definir Apoyo caractersticas de
RDBMS SQL2 difcil mapear un
ODBMS ODMG-2.0
ORDBMS SQL3 (in proceso) apoyo limitado; con mayormente
No lo apoya; Es apoyo extensivo
Pgina 50 de 159
orientadas-objetos
programa entre el objeto y la base de datos
datatypes
Uso
Fcil de usar
Bueno programadores; Algn finales acceso
para Fcil de usar excepto por de extensiones algunas
SQL para usuarios

Apoyo para relaciones complejas
No apoya datatypes Apoya abstractos variedad datatypes
una e
gran Apoya de abstractos
datatypes y
inter- relaciones complejas
relaciones de datos complejos

Desempeo
Buen desempeo
Relativamente menor Se espera que el desempeo desempeo mejor sea
Madurez del producto
Relativamente viejo Este concepto tiene Todava est en el y muy maduro un par de aos y es proceso relativamente maduro desarrollo de
El uso de SQL
Apoyo extensivo de OQL es similar a SQL3 est siendo SQL SQL, pero con desarrollado caractersticas como incorporadas con OO caractersticas adicionales caractersticas orientadas a objetos Objetos complejos y
Ventajas
Su dependencia de Puede manejar todo Habilidad SQL, consultas y su tipo de aplicaciones consultas de complejas, puede aplicaciones complejas y es reutilizar el cdigo optimizacin
de para la
Pgina 51 de 159
relativamente sencilla
Desventajas
habilidad a manejar aplicaciones grandes y complejas de Desempeo de complejas, inhabilidad gran escala pobre Desempeo pobre en consultas la de
Inhabilidad complejas
manejar aplicaciones por la optimizacin aplicaciones web.
soportar sistemas de
Tiene apoyo de los
Tiene
un
extenso En el presente, falta Tiene de vendedores de RDBMS
un
buen
vendedores
mercado y muchos apoyo vendedores
los futuro. Parece que por el todo los vendedores este producto
tamao del mercado de RDBMS quieren
En el artculo "Object-Relational DBMS: The Next Wave," del Dr. Michael Stonebraker, gerente de Tecnologa de la Informix Software, ha clasificado cuatro tipos de aplicaciones de DBMS: Tabla 2: Categoras de DBMSs File Systems Datos queries simples RDBMSs sin Datos queries simples OODBMSs ORDBMSs
con Datos complejos sin Datos complejos con queries queries
Esos cuatro tipos describen sistemas de archivos, DBMS relacionales, DBMS orientados a objetos, y DBMS objeto-relacional. Universal Server, creado por Informix pertenece a la cuarta categora. Los otros ORDBMS incluyen Oracle8 y superiores, de Oracle Corporation y Universal DB (UDB) de IBM. Tambin, Stonebraker predice que muy pronto todas las aplicaciones de DBMSs (datos sencillos con queries) relacionales van a imitar los DBMS objeto-relacional (datos complejos con query).
Pgina 52 de 159
Las cinco opciones de arquitectura por Dr. Stonebraker, estn enlistadas en orden de practicidad y desempeo:

Proveen plug-in code para hacer llamadas funcionales a otras aplicaciones. Proveen API's esperando subsistemas del servidor para apoyar la funcionalidad de objeto Simulan funcionalidad relacional-objeto en una capa de middleware Un motor de base de datos completamente rediseado. Provee una nueva capa orientada a objetos para soportar tipos de datos enriquecidos.
La ventaja principal del ORDBMSs es la gran escalabilidad que tienen, estn diseados para manejar una gran cantidad de informacin. Pero aunque tengan muchas ventajas, los ORDBMSs tambin tienen desventajas. La arquitectura de un modelo objeto relacionado no es el mejor modelo para aplicaciones de alta velocidad en el web. Sin embargo, los ORDBMS hacen la promesa de conquistar el mercado del mundo porque tienen ventajas como la capacidad de guardar cantidades grandes de informacin y acceso de alta velocidad. Tambin tienen el apoyo de los vendedores principales.
3.5
Motores de Persistencia
Las opciones que se basan en imponer un nico modelo terico (un nico formato de datos) a toda la aplicacin padecen de graves inconvenientes. En el caso de que toda la aplicacin siga el modelo relacional, se pierden las ventajas de la orientacin a objetos. En el caso de que toda la aplicacin siga el modelo orientado a objetos, las bases de datos estn inmaduras y tienen un bajo nivel de estandarizacin. Otra opcin es aquella en la que el programa sea orientado a objetos y la base de datos sea relacional, lo que, en principio, constituye la opcin ms natural. Sin embargo, plantea el problema de hacer que dos componentes con formatos de datos muy diferentes puedan comunicarse y trabajar conjuntamente.
Pgina 53 de 159
Se debe encontrar un traductor que sepa traducir de cada idioma al otro. Este traductor no es ms que un componente de software (concretamente, una capa de programacin), al que se le dan los nombres de capa de persistencia, capa de datos, correspondencia O/R (OR mapping) o motor de persistencia. El motor de persistencia traduce entre los dos formatos de datos: de registros a objetos y de objetos a registros. La situacin se ejemplifica en la figura 9. Cuando el programa quiere grabar un objeto llama al motor de persistencia, que traduce el objeto a registros y llama a la base de datos para que guarde estos registros. De la misma manera, cuando el programa quiere recuperar un objeto, la base de datos recupera los registros correspondientes, los cuales son traducidos en formato de objeto por el motor de persistencia.
El programa sabe que puede guardar y recuperar objetos, como si estuviera programado para una base de datos orientada a objetos. La base de datos sabe que guarda y recupera registros, como si el programa estuviera dirigindose a ella de forma relacional. Es decir, cada uno de los dos componentes trabaja con el formato de datos (el idioma) que le resulta ms natural y es el motor de persistencia el que acta de traductor entre los dos modelos, permitiendo que los dos componentes se comuniquen y trabajen conjuntamente. Esta solucin goza de las mejores ventajas de los dos modelos.
Por una parte, es posible programar con orientacin a objetos, aprovechando las ventajas de flexibilidad, mantenimiento y reusabilidad.
Pgina 54 de 159
Por otra parte, se puede para ella.
usar una base de datos relacional, aprovechando su
madurez y su estandarizacin as como las herramientas relacionales que existen
Un motor de persistencia puede reducir el cdigo de una aplicacin en un cuarenta por ciento, hacindola menos costosa de desarrollar. Adems, el cdigo es ms limpio y sencillo y, por lo tanto, ms fcil de mantener y ms robusto, de tal manera que el motor de persistencia no slo simplifica la programacin, sino que permite hacer ciertas optimizaciones de rendimiento que seran difciles de programar de otra manera. En conclusin, sta es la mejor opcin en la actualidad para implementar una aplicacin de software.
3.5.1 Opciones para motores de persistencia

El motor de persistencia tiene la ventaja de que es el mismo para todas las aplicaciones. De esta forma slo debe programarse una vez y puede usarse para todas las dems aplicaciones que se desarrollen en una empresa. Sin embargo, un motor de persistencia es difcil de programar y de mantener, por lo que necesita un gran esfuerzo en costo y tiempo de desarrollo. Es por ello que hay dos opciones a la hora de usar un motor de persistencia:
Programarlo, lo cual no es lo ms recomendable, por la complejidad y costo que introduce esta opcin. Utilizar un motor que ya est programado, comprndolo a un vendedor o bien usando un motor gratuito de cdigo abierto.
La segunda opcin es la ms recomendada, debido a que es la menos costosa y la menos propensa a fallos. Se debe escoger un motor de persistencia de los que estn programados, estudiarlo y aplicarlo a todas las aplicaciones de una misma empresa. En cuanto a la plataforma Java, los servidores de aplicaciones basados en la especificacin EJB (Enterprise JavaBeans), incorporan un motor de persistencia a travs del mecanismo conocido como entity beans. Sin embargo, los entity beans no son un mecanismo de
Pgina 55 de 159
persistencia
totalmente
recomendable,
pues
no
permiten
implementar
algunas
caractersticas de la programacin orientada a objetos (por ejemplo, herencia) y adems, obligan a una forma de programar diferente a los objetos normales de Java (o POJOs, por Plain Old Java Objects). Hay motores de persistencia ms completos que no tienen este tipo de inconvenientes, entre los de cdigo abierto podemos destacar: Hibernate, Castor, Torque, OJB y Cayenne. Entre los comerciales, podemos destacar TopLink, Cocobase y FastObjects. En los ltimos aos se ha creado una especificacin llamada JDO, para estandarizar la forma de programar en Java con esos motores de persistencia. Ejemplos de motores de persistencia que cumplen el estndar JDO son Kodo, JDO Genie, LiDo, Exadel JDO, IntelliBO, JRelay JDO (todos ellos comerciales), TJDO y XORM (de cdigo abierto). La plataforma .NET, por su relativa novedad, est ms inmadura que la plataforma Java. Adems, al ser una plataforma propietaria, cuesta ms encontrar proyectos de cdigo abierto para ella. Por esto no existe tanta variedad de motores de persistencia en esta plataforma. Microsoft anunci un motor de persistencia llamado Objectspaces para .NET 2004, sin embargo a la fecha y con el lanzamiento de .NET 2005, el producto no ha sido liberado. Mientras tanto, se puede usar ORM.NET, que es un motor de persistencia comercial para .NET.
3.6
Proceso de Diseo y Desarrollo de un Proyecto de Software
3.6.1 CMM
El Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un modelo de evaluacin de los procesos de una organizacin. Fue desarrollado inicialmente para los procesos relativos al software por la Universidad Carnegie-Mellon para el SEI (Software Engineering Institute). El SEI es un centro de investigacin y desarrollo patrocinado por el Departamento de Defensa de los Estados Unidos de Amrica y gestionado por la Universidad CarnegieMellon. "CMM" es una marca registrada del SEI
Pgina 56 de 159
A partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de los Estados Unidos de Amrica, desarroll una primera definicin de un modelo de madurez de procesos en el desarrollo de software, que se public en septiembre de 1987. Este trabajo evolucion al modelo CMM o SW-CMM (CMM for Software), cuya ltima versin (v1.1) se public en febrero de 1993. Este modelo establece un conjunto de prcticas o procesos clave agrupados en reas Clave de Proceso (KPA - Key Process Area). Para cada rea de proceso define un conjunto de buenas prcticas que habrn de ser: Definidas en un procedimiento documentado Provistas (la organizacin) de los medios y formacin necesarios Ejecutadas de un modo sistemtico, universal y uniforme (institucionalizadas) Medidas Verificadas A su vez estas reas de Proceso se agrupan en cinco "niveles de madurez", de modo que una organizacin que tenga institucionalizadas todas las prcticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez. Los niveles son: 1. Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para el desarrollo y mantenimiento de software. Aunque se utilicen tcnicas correctas de ingeniera, los esfuerzos se ven minados por falta de planificacin. El xito de los proyectos se basa la mayora de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos y altos costos. El resultado de los proyectos es impredecible. 2. Repetible. En este nivel las organizaciones disponen de unas prcticas institucionalizadas de gestin de proyectos, existen unas mtricas bsicas y un razonable seguimiento de la calidad. La relacin con subcontratistas y clientes est gestionada sistemticamente.
Pgina 57 de 159
Definido. Adems de una buena gestin de proyectos, a este nivel las organizaciones disponen de correctos procedimientos de coordinacin entre grupos, formacin del personal, tcnicas de ingeniera ms detalladas y un nivel ms avanzado de mtricas en los procesos. Se implementan tcnicas de revisin por pares (peer reviews).
Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de mtricas significativas de calidad y productividad, que se usan de modo sistemtico para la toma de decisiones y la gestin de riesgos. El software resultante es de alta calidad.
Optimizado. La organizacin completa est volcada en la mejora continua de los procesos. Se hace uso intensivo de las mtricas y se gestiona el proceso de innovacin.
As es como el modelo CMM establece una medida del progreso conforme avanza, en niveles de madurez. Cada nivel a su vez cuenta con un nmero de reas de proceso que deben lograrse. El alcanzar estas reas o estadios se detecta mediante la satisfaccin o insatisfaccin de varias metas claras y cuantificables. Con la excepcin del primer Nivel, cada uno de los restantes Niveles de Madurez est compuesto por un cierto nmero de reas Claves de Proceso, conocidas a travs de la documentacin del CMM por su sigla inglesa: KPA. Cada KPA identifica un conjunto de actividades y prcticas interrelacionadas, las cuales cuando son realizadas en forma colectiva permiten alcanzar las metas fundamentales del proceso. Las KPAs pueden clasificarse en 3 tipos de proceso: Gestin, Organizacional e Ingeniera. Las prcticas que deben ser realizadas por cada Area Clave de Proceso estn organizadas en 5 Caractersticas Comunes, las cuales constituyen propiedades que indican si la implementatcin y la institucionalizacin de un proceso clave es efectivo, repetible y duradero. Estas 5 caractersticas son: i)Compromiso de la realizacin, ii) La capacidad de realizacin, iii) Las actividades realizadas, iv) Las mediciones y el anlisis, v) La verificacin de la implementacin.
Pgina 58 de 159
Las organizaciones que utilizan CMM para mejorar sus procesos disponen de una gua til para orientar sus esfuerzos. Adems, el SEI proporciona formacin a evaluadores certificados (Lead Assesors) capacitados para evaluar y certificar el nivel CMM en el que se encuentra una organizacin. Esta certificacin es requerida por el Departamento de Defensa de los Estados Unidos, pero tambin es utilizada por multitud de organizaciones de todo el mundo para valorar a sus subcontratistas de software. Se considera tpico que una organizacin dedique unos 18 meses para progresar un nivel, aunque algunas consiguen mejorarlo. En cualquier caso requiere un amplio esfuerzo y un compromiso intenso de la direccin. Como consecuencia, muchas organizaciones que realizan funciones de factora de software o, en general, outsourcing de procesos de software, adoptan el modelo CMM y se certifican en alguno de sus niveles. Esto explica que uno de los pases en el que ms organizaciones certificadas exista sea India, donde han florecido las factoras de software que trabajan para clientes estadounidenses y europeos. A partir de 2001, en que se present el modelo CMMI, el SEI ha dejado de desarrollar el SW-CMM, cesando la formacin de los evaluadores en diciembre de 2003, quienes dispondrn hasta fin de 2005 para reciclarse al CMMI. Las organizaciones que sigan el modelo SW-CMM podrn continuar hacindolo, pero ya no podrn ser certificadas a partir de fin de 2005.
3.6.1.1
SW-CMM Vs CMMI
El objetivo de esta seccin es presentar un panorama general y un comparativo sobre los dos modelos de madurez del SEI (Software Engineering Institute) que han tenido ms aceptacin para las organizaciones y reas que se dedican al desarrollo del software y que ltimamente han generado gran controversia en la comunidad mundial: SW-CMM y
Pgina 59 de 159
CMMI. Esto con la finalidad de que el lector se forme una idea de la razn de ser de los mismos, la audiencia hacia la cual estn enfocados y los aspectos que cubren. Antes de iniciar con nuestra revisin es importante mencionar que la aplicabilidad de los modelos para la mejora de procesos depende de la situacin y del tipo de objetivos del negocio que tenga cada organizacin. SW-CMM (Software Capability Maturity Model) Es el modelo ms utilizado en la industria de software, no slo en los Estados Unidos (EE.UU.), sino en el mundo entero, por lo que representa el estndar de facto de la industria de software. Mide la capacidad de proceso para desarrollar software con calidad, incrementando la predectibilidad para terminar los proyectos en costo, tiempo y con la calidad que el cliente espera. El modelo fue creado a solicitud de la DoD (Department of Defense) de EE.UU. y rpidamente fue adoptado por la industria para evaluar a los proveedores de software de manera estndar y objetiva. Actualmente el SW-CMM, en su versin 1.1, est organizado en 5 niveles de madurez, con 18 reas clave (KPAs), con 52 metas que requieren de 316 prcticas comunes (tales como habilidades a desarrollar, compromisos de la gerencia, mtricas y revisiones para verificar la implantacin de las actividades requeridas). Su enfoque est orientado en generar, implantar y mejorar las prcticas de ingeniera de software, considerando al desarrollo de software como producto principal. El SW-CMM ha demostrado ser un diferenciador importante de nivel comercial, pues adems de permitir mejorar internamente los procesos de las organizaciones, representa una manera estndar e internacional de comparar (hacer benchmarking) objetivamente a diferentes proveedores. De hecho, el Departamento de Defensa de EE.UU. requiere que todos sus proveedores de software sean nivel 3 o superior. Este requerimiento se ha extendido en la mayora de las grandes empresas de EE.UU. que subcontratan empresas para el desarrollo de sus sistemas de software y por lo mismo la industria de desarrollo de cada organizacin, ya que los programas de mejora deben estar basados en la misin y los
Pgina 60 de 159
software en la India ha tenido un gran auge. Si bien es un modelo general, debido a que nos presenta un marco de referencia para generar nuevas capacidades de desarrollar software, su fortaleza radica en la flexibilidad que proporciona para que las organizaciones adapten el modelo a su forma de trabajo, sin forzarlos a utilizar determinadas herramientas o metodologas. Es un modelo totalmente orientado a la industria de software, lo cual implica que puede ser aplicado tanto a empresas que se dediquen exclusivamente al desarrollo de sistemas de software, o a aquellas que necesitan hacer integracin de hardware y software. Las industrias que son usuarias del modelo SW-CMM, numricamente, tienen el siguiente perfil: 689 de 1018 empresas evaluadas formalmente por el SEI son industrias comerciales (67.7%), mientras que slo 329 (32.3%) pertenecen a la industria militar, o son contratistas de los mismos. De las primeras, el 40% de las empresas tienen 100 o menos empleados y el 60% tienen 200 empleados o menos, lo cual indica que la mayora de las empresas usuarias del modelo son empresas medianas o pequeas. En una entrevista al Dr. Pankaj Jalote, Ex-Vicepresidente de Calidad de Infosys, una de las pocas empresas que han obtenido el nivel 5 de SW-CMM, coment textualmente, que la razn por la cual en la India se haba adoptado el SW-CMM, era muy sencilla y lgica ya que la industria de software de la India ha estado y est orientada a la exportacin de software a diversos pases, principalmente a EE.UU. y Europa, pases que han determinado el desarrollo de software bajo estndares internacionales. Debido a que sus principales compradores estn esparcidos por todo el mundo, la industria de desarrollo de software de la India necesitaba seguir un marco de referencia globalmente aceptado y alineado a los estndares internacionalmente reconocidos. Esto gener la necesidad de adoptar (C) modelos como ISO 9000 y SW-CMM. El Dr. Jalote se remont a la historia de la industria de la India y nos coment que al inicio, sus principales clientes eran empresas europeas y por lo tanto el primer estndar que adoptaron fue ISO 9000, ya que era el requerimiento del mercado para poder adquirir el software desarrollado por la India. De esta manera, las empresas exportadoras de software de la India, entre 1993 y 1996, se certificaron en ISO 9000. Ms adelante tuvieron que evolucionar a un nuevo estndar ya que el mercado y sus principales compradores, en este caso EE.UU., cambiaron el requerimiento hacia SWCMM, y por lo tanto las empresas de la India para seguir en el negocio de desarrollo y exportacin de software, dejaron atrs la certificacin ISO 9000 y cambiaron al modelo de SW-CMM. Actualmente existen 64 empresas que estn en nivel 5 y 51 de stas son
Pgina 61 de 159
empresas de la India. Resumiendo lo anterior y citando las palabras Dr. Jalote la razn principal es " market-driven", o como dice un conocido refrn mexicano Dale al cliente lo que pida. CMMI (Capability Maturity Model Integrated) Es un nuevo modelo del SEI que fue creado a solicitud del DoD para las organizaciones con iniciativas de ingeniera de software, ingeniera de sistemas o industrias que requieran integracin (software + hardware). La intencin de este nuevo modelo es consolidar y agrupar una familia de modelos que ya estaban siendo utilizados y reconciliar estos modelos con los estndares y metodologas (como ISO/IEC/TR 15504). La base del CMMI est constituida por los modelos SW-CMM, SA-CMM (Software Acquisition Capability Maturity Model), IPD-CMM (Integrated Product Development Capability Maturity Model) y SE-CMM(Systems Engineering Capability Maturity Model). El CMMI es un modelo nuevo y aunque se han liberado varias versiones, todava no son estables debido a las modificaciones y sugerencias de cambio que se estn realizando sobre la versin aprobada. La ltima versin liberada es la 1.02, y est en vas de liberacin la 1.1. Existen dos versiones de este modelo, la escalonada (staged) y la continua (continuos). Aunque los expertos y algunos opositores a este modelo opinan que no existe una clara diferencia entre el modelo escalonado y el continuo, ya que el escalonado es ms continuo de lo que aparenta. La versin escalonada del modelo tiene 5 niveles, como el SW-CMM versin 1.1, que contienen 24 reas de proceso (PAs), con 78 metas que se alcanzan al implantar las 618 prcticas comunes. Para la versin continua del modelo existen 6 niveles de madurez, que contienen 24 reas de proceso (PAs), con 174 metas que se deben alcanzar y 455 prcticas comunes. El modelo del CMMI tiene el propsito de proporcionar una gua unificada para la mejora de mltiples disciplinas tales como ingeniera de sistemas, ingeniera de software, etc. Sin embargo, mucho se ha escrito y discutido sobre el tema de que las empresas que en realidad
Pgina 62 de 159
necesitan una gua de este tipo, son las grandes organizaciones (proveedores del Departamento de Defensa, principalmente) cuyos proyectos involucran mltiples disciplinas; mientras que la gran mayora de los usuarios actuales del modelo SW-CMM son pequeas organizaciones y/o reas de desarrollo de software, que no utilizan o no necesitan otras disciplinas mas que la de ingeniera de software y sta es el foco principal del SW-CMM. La situacin actual del CMMI en el mercado norteamericano, es incierta ya que a pesar de tener la presin del Departamento de Defensa por adaptar este nuevo modelo, muchas empresas han comentado que el CMMI no se adapta a sus necesidades, debido a que hay muchos elementos que resultan sobrados para empresas pequeas-medianas cuyo negocio principal es el desarrollo de software, y no la integracin de tecnologa o hardware, que es el enfoque principal del nuevo modelo. Adicionalmente al esfuerzo requerido para la implantacin de las nuevas prcticas del CMMI, es necesario considerar el esfuerzo necesario para la capacitacin y para la evaluacin formal. El mtodo de evaluacin para el nuevo modelo se denomina SCAMPI (Standard CMMI Assessment Method for Process Improvement) y para realizar una evaluacin se requieren considerar varios meses debido a la visin global que refleja el modelo. La percepcin en la industria internacional, es que este modelo se adapta ms a empresas grandes, que requieren de diversas disciplinas. La transicin del SW-CMM al CMMI requiere una inversin fuerte, incluso para las organizaciones que son maduras en el modelo SW-CMM (niveles 3, 4), ya que se requiere realizar un esfuerzo extra para cubrir las nuevas reas de proceso (en niveles inferiores y superiores), lograr un nuevo cambio de cultura y capacitar a la organizacin en el nuevo modelo de referencia. En la conferencia del SEPG que se realiz el pasado febrero en Phoenix, se presentaron diversas conferencias y paneles de discusin sobre este tema y principalmente nos interes una conferencia que present el tema "CMMI not for the little guy?", impartida por Margaret Kulpa de Agile Dim Inc. El tema de la conferencia se enfoc al cuestionamiento de si el modelo CMMI se adapta a las organizaciones pequeas, dnde el trmino pequeas se utilizaba en el contexto de 20 o menos empleados, con 2 o 3 empleados por
Pgina 63 de 159
proyecto, donde el personal asignado al proyecto desempea varios roles y los proyectos tienen una duracin de 3 a 6 semanas. A continuacin se resumen algunos puntos de esta presentacin con la finalidad de formar al lector con ideas ms concretas de las implicaciones de este modelo en empresas pequeas, como es el caso de muchas empresas mexicanas. El modelo del CMMI no provee guas de ajuste para adaptar el modelo a las organizaciones pequeas. Esta gua es necesaria, debido a que la estructura del modelo (diseada para muchos recursos asignados a proyectos, con muchos roles, proyectos muy largos que pueden durar aos aeronutica. CMMI es demasiado grande para que pueda ser manejado en organizaciones pequeas. El CMM ha sido criticado por tener muchas reas clave, pero CMMI tiene muchas mas. Esto implica que la documentacin de procesos que cubra las prcticas del modelo puede ser agobiante para las organizaciones pequeas, y por lo tanto, el tiempo, costo y recursos para la documentacin pueden crecer exponencialmente. El retorno de inversin (ROI) del CMMI no ha sido validado (especialmente en organizaciones pequeas). El retorno de inversin, suele ser uno de los principales justificaciones para invertir en programas de mejora. Este punto es especialmente importante para las organizaciones pequeas donde, la mayora de las veces no se cuenta con un gran presupuesto e indudablemente el pago de la nmina cada dos semanas es una preocupacin mayor. Actualmente no se tienen estudios que ayuden a calcular el ROI para el CMMI. Las organizaciones pequeas se administran de manera diferente a las grandes y enfrentan retos diferentes. El principal mvil de negocio para las empresas pequeas es el tiempo de salida al mercado (time-to-market) de sus productos, por lo que la entrega rpida de productos es muy importante para stas, y para el CMMI ese "time-to-market" no parece ser una fuerza impulsora. CMMI fue escrito para organizaciones maduras. El material introductorio de las primeras versiones del modelo escalonado (CMMI staged), deca que las organizaciones evaluadas
Pgina 64 de 159
y cuestan millones de dlares). CMMI se basa en prcticas de
organizaciones grandes, y est enfocado para organizaciones del departamento de defensa o
en niveles superiores del SW-CMM deberan utilizar el CMMI. La mayora de este tipo de organizaciones son grandes, y por lo general ya han trabajado en programas de mejora o han alcanzado un buen entendimiento de lo que significa la mejora de procesos. El requerimiento de CMMI para el programa de mtricas es complicado y sofisticado desde el nivel 2, y aunque la definicin de mtricas es importante para cualquier programa de mejora esto puede ser difcil de implantar en una organizacin principiante. Podramos seguir listando una serie de elementos que han sido criticados en el nuevo modelo de CMMI y las inquietudes que existen, incluso en la industria estadounidense y en el propio SEI, en cuanto a la aceptacin por el modelo. Esto nos hace reflexionar sobre la dificultad que representa para las empresas mexicanas la adopcin de este nuevo modelo. Sobre todo para aquellas que no tienen experiencia anterior con un programa de mejora basado en el SW-CMM. Actualmente no hay muchas organizaciones que hayan adoptado o estn haciendo la transicin hacia el nuevo modelo. Incluso los grandes corporativos norteamericanos tienen que realizar una fuerte inversin para hacer la transicin. Lo que la comunidad internacional est pidiendo es que se mantengan los dos modelos, se libere la versin 2 del SW-CMM que actualmente est en versin borrador y permitir que el mercado decida cual de los dos modelos debe utilizar con base en sus necesidades y objetivos de negocio (SW-CMM vs. CMMI). Finalmente, nos gustara comentar que el xito del proyecto no est en la seleccin de un modelo en particular, sino en establecer un programa de mejora que establezca nuevas prcticas y disciplinas de trabajo para el desarrollo de software utilizando un modelo como un marco de referencia que ayude a las organizaciones a lograr sus objetivos de negocio. Lo recomendable es que ste sea reconocido mundialmente con el objetivo de ser comparable con otros proveedores en mercados internacionales.
3.6.2 El RUP y el Proceso Unificado

Los orgenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken Hartman, uno de los contribuidores claves de RUP colabor con Boehm en la investigacin. En 1995 Rational Software es comprada por una compaia sueca llamada
Pgina 65 de 159
Objectory AB. El Rational Unified Process fue el resultado de una convergencia de Rational Approach y Objectory, proceso desarrollado por el fundador de Objectory Ivan Jacobson. El primer resultado de esta fusin fue el Rational Objectory Process, la primera versin de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en jefe Philippe Kruchten. El Proceso Racional Unificado o RUP (Rational Unified Process), es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos. RUP es en realidad un refinamiento realizado por Rational Software del ms genrico Proceso Unificado. Sus principales caractersticas son: Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo) Pretende implementar las mejores prcticas en Ingeniera de Software Desarrollo interactivo Administracin de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificacin de la calidad del software
El RUP es un producto de Rational (IBM). Se caracteriza por ser interactivo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el cdigo fuente, etc.) y roles (papel que desempea una persona en un determinado momento, una persona puede desempear distintos roles a lo largo del proceso).
Pgina 66 de 159
3.6.2.1
Fases del RUP
El RUP divide el proceso de desarrollo en ciclos, teniendo un producto final al final de cada ciclo, cada ciclo se divide en fases que finalizan con un hito donde se debe tomar una decisin importante: 1. Inicio (Inception): se hace un plan de fases, se identifican los principales casos de uso y se identifican los riesgos 2. Elaboracin (Elaboration): se hace un plan de proyecto, se completan los casos de uso y se eliminan los riesgos 3. Construccin (Construction): se concentra en la elaboracin de un producto totalmente operativo y eficiente y el manual de usuario 4. Transicin (Transition): se implementa el producto en el cliente y se entrena a los usuarios. Como consecuencia de esto suelen surgir nuevos requisitos a ser analizados. 3.6.2.2 El RUP y la orientacin a Objetos.
Aunque RUP es un proceso de desarrollo de software genrico, se concibi en gran medida para el desarrollo de sistemas basados en P.O.O. Por ejemplo se suele emplear RUP en proyectos de programacin en Lenguajes como Java o .NET, etc. Al ser genrico, tiene muchas aplicaciones y se pueden realizar las adecuaciones necesarias al proceso, segn la naturaleza del proyecto que se desea afrontar.
3.6.3 Microsoft Solution Framework

Microsoft Solutions Framework (MSF) es un proceso de desarrollo de software altamente customizable, escalable e integrado. Actualmente junto al producto Visual Studio 2005 Team system ofrece una serie de herramientas con las cuales puede ser aplicado a proyectos pequeos denominados MSF for Agile Software Development y a proyectos de gran envergadura denominado MSF for CMMI Process Improvement
Pgina 67 de 159
Microsoft Solutions Framework (MSF) es una flexible e interrelacionada serie de conceptos, modelos y prcticas de uso que controlan la planificacin, el desarrollo y la gestin de proyectos tecnolgicos. MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnolgicas. Originalmente creado en 1994 para conseguir resolver los problemas a los que se enfrentaban las empresas en sus respectivos proyectos, se ha convertido posteriormente en un modelo prctico que facilita el xito de los proyectos tecnolgico MSF se compone de varios modelos encargados de planificar las diferentes partes implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto, Modelo de Equipo, Modelo de Proceso, Modelo de Gestin del Riesgo, Modelo de Diseo de Proceso y finalmente el modelo de Aplicacin. Modelo de Equipo: Este modelo ha sido diseado para mejorar el rendimiento del equipo de desarrollo. Proporciona una estructura flexible para organizar los equipos de un proyecto. Puede ser escalado dependiendo del tamao del proyecto y del equipo de personas disponibles. Para obtener ms informacin puedes consultar el Documento del Modelo de Equipo
Modelo de Proceso: Diseado para mejorar el control del proyecto, minimizando el riesgo, y aumentar la calidad acortando el tiempo de entrega. Proporciona una estructura de pautas a seguir en el ciclo de vida del proyecto, describiendo las fases, las actividades, la liberacin de versiones y explicando su relacin con el Modelo de equipo. Puedes encontrar su descripcin en el Documento del Modelo de Proceso
Disciplina de Gestin de Riesgos: Diseada para ayudar al equipo a identificar las prioridades, tomar las decisiones estratgicas correctas y controlar las emergencias que puedan surgir. Este modelo proporciona un entorno estructurado para la toma de decisiones y acciones valorando los riesgos que puedan provocar. Consulta la base del modelo en el Documento de la Disciplina de Gestin de Riesgos
Pgina 68 de 159
Disciplina de Gestin de Proyectos: Es una disciplina que describe el rol de la gestin del proyecto dentro del modelo de equipo de MSF, y como permite mayor escalabilidad, desde proyectos pequeos a proyectos largos y complejos. Puedes encontrar la descripcin de esta disciplina el el Documento de la Disciplina de Gestin de Proyectos
Disciplina de Gestin de la Preparacin (Readiness): Esta disciplina describe aquellos conocimientos, aptitudes y habilidades que son necesarias para planificar, desarrollar y gestionar soluciones satisfactorias. Se puede consultar en el Documento de la Disciplina de Gestin de la Preparacin
Para una mayor informacin sobre el MSF puede visitar la pgina http://www.microsoft.com/msf
3.7
Microsoft .Net Framework
Microsoft .NET es una plataforma de desarrollo y ejecucin de aplicaciones. que brinda las herramientas y servicios que se necesitan para desarrollar modernas aplicaciones empresariales y de misin crtica, y que tambin provee mecanismos robustos, seguros y eficientes para asegurar que la ejecucin de las mismas sea ptima. Los componentes principales de la plataforma .NET son: Un entorno de ejecucin de aplicaciones, tambin llamado Runtime, que es un componente de software cuya funcin es la de ejecutar las aplicaciones .NET e interactuar con el sistema operativo ofreciendo sus servicios y recursos. Un conjunto de bibliotecas de funcionalidades y controles reutilizables, con una enorme cantidad de componentes ya programados listos para ser consumidos por otras aplicaciones.
Pgina 69 de 159
Un conjunto de lenguajes de programacin de alto nivel, junto con sus compiladores y linkers, que permitirn el desarrollo de aplicaciones sobre la plataforma .NET.
Un conjunto de utilitarios y herramientas de desarrollo para simplificar las tareas ms comunes del proceso de desarrollo de aplicaciones.
Documentacin y guas de arquitectura, que describen las mejores prcticas de diseo, organizacin, desarrollo, prueba e instalacin de aplicaciones .NET
Por otra parte, .NET representa la evolucin COM (Component Object Model), la plataforma de desarrollo de Microsoft anterior a .NET y sobre la cual se basaba el desarrollo de aplicaciones Visual Basic 6. Entre los factores que motivaron el desarrollo e introduccin al mercado de la plataforma Microsoft .NET. se pueden mencionar: La amplia disponibilidad de conexiones a Internet de alta velocidad, e incluso inalmbricas La proliferacin de nuevos tipos de dispositivos de hardware que son usados en la vida diaria (telfonos inteligentes, Pocket PCs, HandHelds, Media Centers, etc.) El creciente poder de cmputo de las computadoras personales y servidores basados en arquitecturas x86. El surgimiento de estndares de Internet para permitir la comunicacin e integracin entre diversas plataformas de software
.NET no es un sistema operativo, como lo es Microsoft Windows en sus distintas versiones. .NET no es un Lenguaje de Programacin: si bien la plataforma Microsoft .NET incluye lenguajes de programacin de aplicaciones, su concepto es ms amplio y va ms all de stos.
Pgina 70 de 159
.NET no es un Entorno de Desarrollo: si bien la plataforma Microsoft .NET incluye entornos de desarrollo integrados (IDEs), su concepto es ms amplio y va ms all de stos. .NET no es un servidor de aplicaciones (Application Server) .NET no es un producto empaquetado que se pueda comprar como tal, sino que es una plataforma que engloba distintas aplicaciones, servicios y conceptos y que en conjunto permiten el desarrollo y la ejecucin de aplicaciones.
3.7.1 Caractersticas
Algunas de las caractersticas principales de la plataforma Microsoft .NET son: Se dice que es una plataforma de ejecucin intermedia, ya que las aplicaciones .NET no son ejecutadas directamente por el sistema operativo, como ocurre en el modelo tradicional de desarrollo. En su lugar, las aplicaciones .NET estn diseadas para ser ejecutadas contra un componente de software llamado Entorno de Ejecucin (muchas veces tambin conocido como Runtime, o , Mquina Virtual). Este componente es el encargado de manejar el ciclo de vida de cualquier aplicacin .NET, inicindola, detenindola, interactuando con el Sistema Operativo y proveyndole servicios y recursos en tiempo de ejecucin. La plataforma Microsoft .NET est completamente basada en el paradigma de Orientacin a Objetos. .NET es multi-lenguaje: esto quiere decir que para poder codificar aplicaciones sobre esta plataforma no es necesario aprender un nico lenguaje especfico de programacin de alto nivel, sino que se puede elegir de varias opciones. .NET es una plataforma que permite el desarrollo de aplicaciones empresariales de misin crtica, entendindose por esto que permite la creacin y ejecucin de aplicaciones de porte corporativo que sean crticas para la operacin de tipos variados de organizaciones. Puede soportar aplicaciones grandes y complejas. .Net fue diseado de manera tal de poder proveer un nico modelo de programacin, uniforme y consistente, para todo tipo de aplicaciones (ya sean de formularios Windows, de consola, aplicaciones Web, aplicaciones mviles, etc.) y
Pgina 71 de 159
para cualquier dispositivo de hardware (PCs, Pocket PCs, Telfonos Celulares Inteligentes, tambin llamados SmartPhones, Tablet PCs, etc.). Esto representa un gran cambio con respecto a las plataformas anteriores a .NET, las cuales tenan modelos de programacin, bibliotecas, lenguajes y herramientas distintas segn el tipo de aplicacin y el dispositivo de hardware. Uno de los objetivos de diseo de .NET fue que tenga la posibilidad de interactuar e integrarse fcilmente con aplicaciones desarrolladas en plataformas anteriores, particularmente en COM, ya que an hoy existen una gran cantidad de aplicaciones desarrolladas sobre esa base. .NET no slo se integra fcilmente con aplicaciones desarrolladas en otras plataformas Microsoft, sino tambin con aquellas desarrolladas en otras plataformas de software, sistemas operativos o lenguajes de programacin. Para esto hace un uso extensivo de numerosos estndares globales que son de uso extensivo en la industria, algunos ejemplos de estos estndares son XML, HTTP, SOAP, WSDL y UDDI.
El .NET Framework es el componente fundamental de la plataforma Microsoft .NET, necesario tanto para poder desarrollar aplicaciones como para poder ejecutarlas luego en entornos de prueba o produccin. El .NET framework tiene tres variantes principales, todas descargables gratuitamente desde Internet .NET Framework Redistributable Package: mnimo componente de la plataforma .NET que se necesita para poder ejecutar aplicaciones. Normalmente sta es la variante que se instala en los entornos productivos, una vez que el desarrollo y las pruebas de la aplicacin han finalizado. Est compuesto por: El entorno de ejecucin de la plataforma .NET Las bibliotecas de funcionalidad reutilizable
.NET Framework SDK: esta versin contiene herramientas de desarrollo de lnea de comandos (compiladores, depuradores, etc.), documentacin de referencia, ejemplos
Pgina 72 de 159
y manuales para desarrolladores de aplicaciones. Normalmente sta variante se instala en los entornos de desarrollo de aplicaciones, y es ms til a los programadores que a los usuarios finales. Para poder instalar la versin SDK (Software Development Kit) es necesario instalar previamente el Redistributable Package. NET Compact Framework: esta es una versin reducida del .NET Framework Redistributable, especialmente pensada para ser instalada en dispositivos mviles como Pocket PCs y SmartPhones. El .NET Framework puede ser instalado en cualquier sistema operativo de la familia Windows superior a Windows 98, actualmente, Windows 2003 Server y Windows XP SP2 traen el .NET Framework preinstalado. El .NET Framework debe estar instalado en cualquier dispositivo de hardware para que la ejecucin de una aplicacin .NET sea posible. En el caso de las aplicaciones de escritorio (tambin llamadas De Formularios Windows) y las aplicaciones de consola (aplicaciones cuya interfaz de usuario es una consola de comandos), el Framework debe estar presente del lado del cliente (computadora donde se ejecuta la parte de la aplicacin que interacta con el usuario), y en el servidor slo en caso de que la aplicacin sea distribuida y tenga parte de su funcionalidad centralizada en una nica computadora. En el caso de las aplicaciones Web, el nico requisito del lado del cliente es tener un navegador y una conexin de red al servidor, el cual debe tener instalado el .NET Framework. Para las aplicaciones mviles, que se ejecutan sobre Windows Mobile en algn dispositivo tipo Pocket PC o SmartPhone, es necesario tener instalado el .NET Compact Framework en el dispositivo.
Pgina 73 de 159
Dnde instalar el .NET Framework?
Cliente
Aplicacin de Escritorio Aplicacin Web
Servidor
Aplicacin de Consola Aplicacin Mvil
*
.NET Compact Framework
* Slo si la aplicacin es distribuida
Actualmente hay 3 versiones de la plataforma Microsoft .NET: La versin 1.0: fue liberada a principios del ao 2002, e inclua la versin 1.0 del .NET Framework, la versin 2002 de Visual Studio y varios lenguajes de programacin nuevos compatibles con la plataforma (como C#.NET y Visual Basic.NET) La versin 1.1: fue liberada en 2003, aproximadamente un ao despus que su predecesora. Esta versin introdujo el .NET Framework 1.1 junto con Visual Studio .NET 2003, la primer versin del .NET Compact Framework y un nuevo lenguaje de programacin llamado J#.NET. La versin 2.0: fue liberada a finales del ao 2005, esta versin trajo consigo las versiones 2.0 del .NET Framework y el .NET Compact Framework, as como tambin una nueva versin de Visual Studio. La prxima generacin de la plataforma .NET, tendr por nombre cdigo Orcas.
Pgina 74 de 159
Cronologa de .NET
Visual Studio 6.0 Visual Basic VBA Visual FoxPro VBScript C++ J++ JScript ASP
Visual Studio .NET 2003 .NET Framework 1.1 .NET Compact Framework J#
Visual Studio Orcas .NET Framework Orcas .NET Compact Framework Orcas
2000
2001
2002
2003
2004
2005
2006 y ms
Visual Studio .NET 2002 .NET Framework 1.0 Visual Basic .NET C#
Visual Studio 2005 (Whidbey) .NET Framework 2.0 (Whidbey) .NET Compact Framework 2.0 (Whidbey)
3.7.2 Arquitectura
Arquitectura del .NET Framework
VB
C++
C#
J#
.NET Framework Class Library
Common Language Specification

.NET Framework SDK .NET Framework Redistributable
ASP.NET ADO.NET y XML Base Class Library
Windows Forms
Common Language Runtime Windows COM+ Services
Pgina 75 de 159
En la figura se pueden apreciar las distintas partes que componen al .NET Framework, incluidas el entorno de ejecucin de aplicaciones (CLR, en verde), el conjunto de bibliotecas de funcionalidad reutilizable (.NET Framework Class Library, en azul) y los compiladores y herramientas de desarrollo para los lenguajes .NET (en rojo). Todos estos componentes se motan por encima de la familia de sistemas operativos Windows. Dentro del conjunto de la .NET Framework Class Library se distinguen 4 sub-componentes principales: La Base Class Library (BCL - Biblioteca de Clases Base), que contiene la funcionalidad ms comnmente utilizada para el desarrollo de todo tipo de aplicaciones. Algunos ejemplos de la funcionalidad provista por la BCL son el manejo de colecciones, cadenas de texto, entrada/salida, threading, operaciones matemticas y dibujos 2D. ADO.NET, que contiene un conjunto de clases que permiten interactuar con bases de datos relacionales y documentos XML como repositorios de informacin persistente. ASP.NET, que constituye la tecnologa dentro del .NET Framework para construir aplicaciones con interfaz de usuario Web (es decir, aplicaciones cuya lgica se encuentra centralizada en uno o varios servidores y que los clientes pueden acceder usando un browser o navegador mediante una serie de protocolos y estndares como HTTP y HTML). Windows Forms (o simplemente WinForms), que constituye la tecnologa dentro del .NET Framewok que permite crear aplicaciones con interfaz de usuario basada en formularios y ventanas Windows que se ejecutan directamente en los clientes.
El modelo de ejecucin que propone la plataforma .NET se suele definir como virtual, o de mquina virtual, ya que las aplicaciones no son desarrolladas directamente contra las APIs de programacin expuestas por el sistema operativo, ni es ste el que se encarga de su ejecucin y ciclo de vida, sino que .NET provee un entorno de ejecucin (el CLR) que corre por sobre el sistema operativo y que es el encargado de ejecutar las aplicaciones y proveerles servicios en tiempo de ejecucin. A los componentes de software que se
Pgina 76 de 159
ejecutan de esta manera se los conoce comnmente como componentes manejados, ya que su ejecucin es controlada por un entorno intermedio. Una de las principales ventajas de contar con una plataforma virtual es que no estn atadas de ninguna forma con el sistema operativo y la plataforma de hardware subyacente. Es sabido que una aplicacin compilada para que utilice directamente las APIs y servicios expuestos por un sistema operativo x muy difcilmente pueda ser ejecutada en otro sistema operativo distinto sin ser recompilada. Las aplicaciones manejadas, en cambio, descansan la tarea de su compilacin a un cdigo de mquina especfico en el entorno de ejecucin. De esta manera, si existen distintos entornos de ejecucin intermedia para diferentes Sistemas Operativos, la misma aplicacin puede ejecutarse en todos ellos si necesidad de recompilarse. El desarrollo de una aplicacin .NET comienza con la escritura de su cdigo fuente en alguno de los lenguajes de alto nivel soportados por la plataforma. El mismo luego es compilado obtenindose un ejecutable (que en Windows normalmente llevan la extensin .exe) o una biblioteca (que en Windows normalmente llevan la extensin .dll). A estos componentes .NET resultantes del proceso de compilacin se los denomina genricamente Assemblies, o Ensamblados. Ahora bien, en lugar de contener cdigo de mquina especfico para el sistema operativo y el hardware en el cual fueron compilados (nativo), los assemblies contienen un cdigo denominado MSIL (Microsoft Intermediate Language). EL MSIL es un set de instrucciones independientes de cualquier CPU existente y que puede ser convertido a cdigo nativo muy eficientemente. MSIL incluye instrucciones para cargar, almacenar, inicializar e interactuar con objetos y sus atributos y mtodos, as como tambin instrucciones aritmticas y lgicas, control de flujo, acceso directo a memoria, manejador de errores y otras operaciones. Antes de que el cdigo MSIL pueda ser ejecutado debe convertirse a cdigo nativo especfico para un CPU y Sistema Operativo, tarea a cargo de los compiladores JIT incluidos en el CLR. Un Assembly es la menor unidad de ejecucin y distribucin de una aplicacin .NET.
Pgina 77 de 159
Los assemblies son reutilizables, versionables y autodescriptivos, ya que no slo contienen el cdigo MSIL que representa la lgica de la aplicacin, sino que tambin incluyen informacin sobre si mismos y sobre todos los recursos externos de los que dependen para funcionar correctamente. A esta informacin se la denomina Meta data y forma una parte integral de un assembly junto con el cdigo MSIL ya que ambos no pueden estar separados. La Meta data se ubica en una seccin especial del Assembly denominada Manifest, o Manifiesto, y es utilizada por el CLR a la hora de cargar y ejecutar el Assembly. La herramienta ildasm.exe (Intermediate Languaje Dissasembler, incluida en el .NET Framework SDK) puede utilizarse para inspeccionar la meta data de un assembly. Una aplicacin .NET se compone, entonces, de uno o ms assemblies. Otra de las caractersticas de los Assemblies es que no necesitan estar registrados en la Registry de Windows, como sus predecesores COM. De esta forma, instalar una aplicacin .NET puede ser tan simple como copiar todos los assemblies necesarios a la computadora de destino, y basta con borrarlos a todos para tener una desinstalacin limpia y completa. Dado que .NET no depende de la Registry, y que cada assembly contiene informacin acerca de su versin y las versiones de los componentes de que depende, mltiples versiones de assemblies pueden coexistir sin ningn problema en la misma computadora. Existen dos formas de que una aplicacin pueda encontrar en tiempo de ejecucin los assemblies de los que depende: 1) Ubicarlos en el mismo directorio. Esta es la opcin preferida si esos assemblies slo sern utilizados por esa nica aplicacin. 2) Ubicarlos en un repositorio centralizado de assemblies denominado Global Assembly Cache, en el cual se instalan todos los assemblies que sern utilizados por mltiples aplicaciones en la misma computadora. Para registrar un assembly en el GAC es necesario utilizar otra herramienta incluida en el SDK llamada gacutil.exe.
Pgina 78 de 159
Uno de los objetivos de diseo de la plataforma .NET fue el ser independiente del lenguaje de programacin elegido para el desarrollo de aplicaciones. Para lograr esto es que se cre la Especificacin de Lenguaje Comn (o CLS, por sus siglas en ingls), que define y estandariza un subconjunto de todas las caractersticas soportadas por el CLR y que son necesarias en la mayora de las aplicaciones. Todos los componentes desarrollados y compilados de acuerdo con la especificacin CLS pueden interactuar entre si, independientemente del lenguaje de programacin de alto nivel en el que fueron escritos. Junto con el .NET Framework, Microsoft provee implementaciones de 4 lenguajes compatibles con CLS, junto con sus compiladores: Microsoft Visual Basic .NET Microsoft Visual C# .NET Microsoft Visual J#.NET Microsoft Visual C++.NET
Esto quiere decir que una aplicacin escrita, por ejemplo, en Visual Basic.NET, puede incorporar sin problemas nuevas partes escritas en C# o C++ .NET. La infraestructura de lenguaje comn (Common Language Infrastructure, CLI) es una especificacin estandarizada que describe un entorno virtual para la ejecucin de aplicaciones, cuya principal caracterstica es la de permitir que aplicaciones escritas en distintos lenguajes de alto nivel puedan luego ejecutarse en mltiples plataformas tanto de hardware como de software sin necesidad de reescribir o recompilar su cdigo fuente. Si bien el CLI tuvo sus orgenes en Microsoft (en principio se pensaba desarrollar un entorno de ejecucin compartido para COM con el nombre de Common Object Runtime, que luego de extendi y generaliz para dar lugar a CLI), sus especificaciones fueron llevadas ante ECMA (European Computer Manufacturers Association), una organizacin europea de estndares, para su estandarizacin en el ao 2000. Luego de un ao de trabajo conjunto entre ECMA, Microsoft y otras empresas que copatrocinaron el proceso (Intel, HP, IBM y Fujitsu entre otras), el estndar ECMA-335 que
Pgina 79 de 159
define el entorno CLI finalmente vio la luz en diciembre de 2001. En abril del ao 2003 ISO ratific este estndar con el denominacin ISO/IEC 23271:2003 . Para comprender mejor la inclusin de cada una de las partes principales de la arquitectura de CLI es interesante analizar los objetivos de diseo que se plantearon desde su concepcin. Segn su especificacin, la arquitectura de CLI debe: Permitir escribir componentes nter operables independientemente de la plataforma subyacente y del lenguaje de programacin utilizado. Exponer todas las entidades programticas a travs de un nico sistema unificado de tipos (en la especificacin, este sistema es conocido como CTS, o Common Type System). Empaquetar todos los tipos en unidades completamente auto descriptivas y portables. Cargar los tipos de forma tal que se encuentren aislados unos de otros en tiempo de ejecucin, pero que puedan a su vez compartir recursos. Resolver dependencias entre tipos en tiempo de ejecucin usando una poltica flexible que pueda tener en cuenta la versin, atributos de localizacin y polticas administrativas. Ejecutar aplicaciones bajo la supervisin de un entorno privilegiado que permita controlar y hacer cumplir polticas en tiempo de ejecucin. Disear toda la infraestructura y servicios basndose en meta datos extensibles, de manera tal que toda la arquitectura pueda acomodarse con poco impacto a nuevas incorporaciones y cambios. Poder realizar tareas de bajo nivel, como carga de tipos en memoria, linkeo con libreras y compilacin a cdigo nativo slo cuando sea necesario (este enfoque se conoce tpicamente como on demand, o just in time). Proveer una serie de funcionalidades comunes mediante un grupo de libreras de programacin que los desarrolladores puedan utilizar para construir sus aplicaciones.
Pgina 80 de 159
Microsoft .NET de hecho es un sper conjunto de esta especificacin, es decir, provee todo lo necesario para cumplir con la misma y adems agrega una serie de herramientas, libreras y funcionalidades no contempladas por ella originalmente y que proveen una enorme utilidad y flexibilidad a los desarrolladores (por ejemplo, libreras para la creacin de aplicaciones y servicios web, acceso a motores de bases de datos, controles grficos, herramientas para desensamblar assemblies, debuggers, etc.). Si bien es gratuito, su cdigo fuente no es abierto, y es distribuido por Microsoft en versiones para sistemas operativos Windows 98 y sus sucesores nicamente.
Sub-Especificaciones de CLI
Lenguajes de Alto Nivel

se ajustan a las reglas de la
CLS (Common Language Specification)

y utilizan las clases de la
BCL (Base Class Library)

cuyos tipos bsicos forman el
CTS (Common Type System)

y se ejecutan bajo el control de y usan los servicios del
CLR (Common Language Runtime)

que est acoplado al y utiliza los servicios del
Sistema Operativo
Pgina 81 de 159
Modelo de Ejecucin del CLR
Cdigo Fuente
VB.NET Compilador VB.NET
C# Compilador C#
C++.NET Compilador C++ .NET Componente No Manejado
Cdigo Manejado
Assembly Cdigo MSIL
Assembly Cdigo MSIL
Assembly Cdigo MSIL
Common Language Runtime

Compilador JIT
Cdigo Nativo
Sistema Operativo (Windows)
La figura representa el modelo de compilacin y ejecucin de aplicaciones .NET, al cual muchas veces se denomina de compilacin diferida, o de compilacin en dos etapas. Esto es asi ya que el primer paso para poder ejecutar una aplicacin dentro del CLR es compilar su cdigo fuente para obtener un assembly con cdigo MSIL. Este paso es realizado por cada uno de los compiladores de los distintos lenguajes de alto nivel soportados por .NET. Luego, el CLR se encarga de compilar el cdigo MSIL a cdigo nativo que hace uso especfico de los servicios del sistema operativo y la plataforma de hardware subyacente. Todos los compiladores de los nuevos lenguajes .NET de Microsoft siguen este modelo de ejecucin, con excepcin de C++ .NET, que es el nico lenguaje al que se le ha dejado la capacidad de emitir tambin cdigo no manejado. Esto se debe a que ciertas aplicaciones, como los drivers de dispositivos, necesitan tener acceso a los recursos del sistema operativo a muy bajo nivel para lograr un rendimiento ptimo y mayor performance.
Pgina 82 de 159
3.7.3 ADO .Net 2.0

ADO.NET es un subconjunto de la .NET Framework Class Library, que contiene todas las funcionalidades necesarias para conectarse e interactuar con dos tipos de repositorios permamentes de informacin: 1) Bases de Datos, como Microsoft SQL Server (clases del namespace System.Data, que se encuentran compiladas en System.data.dll) 2) Archivos XML (clases del namespace System.XML, que se encuentran compiladas en System.Xml.dll) La siguiente figura muestra el subconjunto.
Acceso a Datos: ADO.NET
System.Data Common OracleClient Odbc SqlClient OleDb SqlTypes
System.Xml XSLT XPath Serialization Schema
La arquitectura de ADO.NET est basada en el concepto de proveedores de acceso a datos, siendo un proveedor un conjunto de clases que permiten conectarse a una base de datos,
Pgina 83 de 159
ejecutar un comando sobre ella y tener acceso a los resultados de su ejecucin, tanto de forma conectada como desconectada. Los proveedores de acceso a datos ADO.NET (conocidos como Managed Data Providers) representan conjuntos especficos de clases que permiten conectarse e interactuar con una base de datos, cada uno utilizando un protocolo particular. El .NET Framework incluye cuatro proveedores de acceso a datos, que en conjunto le permiten conectarse e interactuar virtualmente con cualquier base de datos existente en la actualidad: Data Provider For SQL Server: es el proveedor de acceso nativo a servidores de bases de datos Microsoft SQL Server 7.0 o superior, y Microsoft Access. Al conectarse va protocolos nativos de bajo nivel, provee la alternativa ms performante para conexiones contra estos motores de bases de datos. Sus clases se encuentran en el namespace System.Data.SqlClient. Data Provider For OLE DB: es el proveedor de acceso a datos que permite interactuar va el protocolo estndar OLE DB con cualquier repositorio de datos que lo soporte. Sus clases se encuentran en el namespace System.Data.OleDb. Data Provider For ODBC: es el proveedor de acceso a datos que permite interactuar va el protocolo estndar ODBC con cualquier repositorio de datos que lo soporte. Sus clases se encuentran en el namespace System.Data.Odbc. Data Porvider For Oracle: es el proveedor de acceso nativo a bases de datos Oracle, desarrollado por Microsoft utilizando las herramientas de conectividad de Oracle. De esta forma puede lograrse un acceso ms performante a bases de datos Oracle desde aplicaciones .NET que utilizando ODBC u OLE DB. Sus clases se encuentran en el namespace System.Data.OracleClient, y estn compiladas en un assembly diferente al resto: System.Data.OracleClient.dll.
Pgina 84 de 159
ADO.NET- Clases ms comunes
Base de Datos
Maneja la coneccin a una base de datos Ejecuta comandos contra una base de datos
XxxConnection XxxCommand Intercambia datos entre un dataset y una base de datos Copia local de datos relacionales XxxDataAdapter DataSet XxxDataReader Provee acceso a datos read-only, Forward-only
En la figura se pueden apreciar las clases ms comunes que componen a todos los proveedores de acceso a datos de ADO.NET. Ntese que algunos nombres empiezan con las letras Xxx: esto se debe a que los nombres de esas clases varan segn el proveedor especfico que se est utilizando. Por ejemplo, la clase que representa una conexin con la base de datos usando el Data Provider For Sql Server es SqlConnection, mientras que si usamos el Data Provider For Oracle podemos obtener la misma funcionalidad de la clase OracleConnection. XxxConnection: representa una conexin. Almacena, entre otras cosas, el string de conexin (connection string), y permite conectarse y desconectarse con una base de datos. XxxCommand: permite almacenar y ejecutar una instruccin SQL contra una base de datos, enviando parmetros de entrada y recibiendo parmetros de salida. Estas dos clases se utilizan tanto en escenarios conectados como desconectados.
Pgina 85 de 159
XxxDataReader: permite acceder a los resultados de la ejecucin de un comando contra la base de datos de manera read-only (slo lectura), forward-only (slo hacia adelante). Esta clase se utiliza en escenarios conectados, ya que no es posible operar sobre los registros de un DataReader estando desconectado de la fuente de datos. XxxDataAdapter y DataSet: en conjunto, estas clases constituyen el corazn del soporte a escenarios desconectados de ADO.NET. El DataSet es una representacin en memoria de una base de datos relacional, que permite almacenar un conjunto de datos obtenidos mediante un DataAdapter. El DataAdapter acta como intermediario entre la base de datos y el DataSet local desconectado. Una vez que el DataSet se encuentra lleno con los datos que se necesitan para trabajar, la conexin con la base de datos puede cerrarse sin problemas y los datos pueden ser modificados localmente. Por ltimo, el DataAdapter provee un mecanismo para sincronizar los cambios locales contra el servidor de base de datos. Ntese que la clase System.Data.DataSet no tiene el prefijo Xxx, ya que es independiente del proveedor de acceso a datos utilizado. ADO.NET provee una arquitectura extensible, posibilitando que terceras partes creen sus propios proveedores de acceso nativo para aplicaciones .NET. Algunos ejemplos de esto son: Data Provider For DB2, desarrollado por IBM Oracle Data Provider For .NET, desarrollado por Oracle Providers de acceso nativo a bases de datos OpenSource, como MySQL y PostgreSQL
Pgina 86 de 159
ADO.NET vs. ADO
ADO.NET es el sucesor de ADO (ActiveX Data Objects), la biblioteca de acceso a datos de la plataforma COM. Si bien ADO soporta slo escenarios conectados, puede resultar til hacer una analoga de las clases ms comunes utilizadas en ADO con respecto a sus nuevas versiones en ADO.NET: La clase Connection de ADO tiene su paralelo en las clases XxxConnection de los distintos proveedores de ADO.NET La clase Command de ADO tiene su paralelo en las clases XxxCommand de los distintos proveedores de ADO.NET La clase Recordset de ADO dej de existir como tal en ADO.NET. En su lugar existen en ADO.NET las clases XxxDataReader (es lo ms parecido a un Recordset read-only forward-only de ADO), y las nuevas clases DataSet y XxxDataAdapter para escenarios desconectados.
Pgina 87 de 159
ADO.NET - Soporte a XML
<X M L >
DocumentNavigator
XmlTextWriter XmlDocument
XmlReader
XmlTextReader
XmlValidatingReader
XmlNodeReader
La figura ilustra una parte del soporte a XML provisto por el .NET Framework, que va desde la simple lectura de un documento XML a su navegacin, bsqueda y transformaciones complejas. XmlReader clase abstracta cuyo propsito es proveer un mecanismo de lectura forward-only de un documento XML. Tiene tres clases derivadas: XmlTextReader utilizada para leer datos de un documento XML o un stream. Se utiliza normalmente cuando la performance de lectura es un factor clave y todo el sobreprocesamiento de DOM debe evitarse. XmlValidatingReader similar a XmlTextReader, pero pensada para validaciones DOM. XmlNodeReader permite leer datos de un nodo XML.
XmlTextWriter permite que datos XML puedan ser escritos a un archivo XML o a un stream, y puede adems proveer mecanismos de validacin para asegurar que slo datos XML vlidos y bien formados sean escritos.
Pgina 88 de 159
XmlDocument esta es una clase compleja que acta como un contenedor de datos XML, representando en un modelo de objetos en memoria toda la estructura de un documento XML. Esto permite tener facilidades de navegacin y edicin, pero a un cierto costo de performance y consumo de recursos.
DocumentNavigator permite navegar libremente la estructura de un documento XML una vez que ha sido cargado dentro de una instancia de la clase XmlDocument.
Pgina 89 de 159
IV. Solucin Propuesta

El presente capitulo, describe la conceptualizacin, elaboracin y construccin de la solucin propuesta. De esta forma que se detallan los requerimientos base con los que se inicio la conceptualizacin y diseo de la solucin, los criterios y estimaciones de diseo y finalmente se muestra la implementacin del diseo utilizando cdigo C#. La propuesta se plantea, presentando inicialmente el modelado general de la solucin describiendo elementos de arquitectura considerados y las caractersticas generales propuestas. Posteriormente se presenta la funcionalidad bsica que debe de implementar aislando en secciones cada funcionalidad con sus requerimientos, sus criterios de diseo y su implementacin, con el fin de que sea mas sencillo detallar la construccin de cada seccin especifica de la solucin propuesta.
4.1 Modelado de la solucin

4.1.1 Consideraciones Iniciales
Dado que nuestra solucin pretende reforzar y promover el uso de un diseo y construccin completamente orientado a objetos, esto requiere la utilizacin de una arquitectura multicapas como las mostrada en el siguiente diagrama.
Presentacin
<<Usa>>
Negocio
<<Usa>>
Acceso a Datos
<<Usa>>
<<Crea>> Dominio
Para el diseo del core del sistema se construir un modelo de dominio basados en el patrn Domain Value Object, donde en ves de disear tablas o un modelo ER, se disearan clases
Pgina 90 de 159
que encapsulen datos y comportamiento siguiendo las caractersticas de la orientacin a objetos. El motor de persistencia a construir implementar funcionalidad de la capa de Acceso a Datos, por lo que es en este nivel donde definir el ambiente, estndares y caractersticas bajo los cuales trabajara la propuesta. Debido que existen una serie de patrones de diseo disponibles para el Acceso a Datos, se ha decido tomar el patrn utilizado en la plataforma J2EE denominado DAO (Data Access Object)4. Este patrn proporcionara los siguientes beneficios a nuestro diseo. DAO define una relacin uno a uno entre clases de dominio y de acceso a datos Cada clase de dominio tendr asociada una clase de DAO de acceso a datos lo que permitir no mezclar operaciones entre clases e identificar rpidamente la clase responsable de cada entidad. El uso de DAO proporciona una alta cohesin ya que todos los mtodos transaccionales de una clase estn relacionados a una sola clase de dominio y el acoplamiento entre clases DAO es bastante bajo.5 El uso de DAO permitir una alta reusabilidad de las clases implementadas.
DAOMaster
Dado que por cada clase de dominio tendremos una clase de acceso a datos, podemos considerar el diseo de una clase maestra que contenga la funcionalidad genrica del
<<Crea>> <<Crea>> DAOCliente DAOFactura
DAOItem
DAOProducto
motor de persistencia y sea heredado a cada una de las clases DAO de la aplicacin. Esto se muestra en el diagrama adjunto.
<<Crea>> <<Crea>>
Cliente
Factura
Item
Producto
4 5
Para mas informacin sobre el patrn DAO consultar la seccin 3.2.9 Para mas informacin sobre Acoplamiento y Cohesin remitirse a la seccin 3.2.2
Pgina 91 de 159
4.1.2 Namespaces y Assemblies.

La funcionalidad principal del motor de persistencia ser encapsulada en una clase a la que se denominar DAOMaster la cual deber ser heredada, por lo que se definir de tipo abstracta. Adicionalmente esta clase depender de los servicios de otras clases encargadas de crear conexiones y otros tipos de objetos. Toda esta funcionalidad se definir y agrupar dentro de un solo namespace el cual ser denominado DAOMasterLibrary con el fin de que solo sea incorporado en la lgica de las capa de acceso datos de las aplicaciones que utilicen esta herramienta. As a la hora de disear la arquitectura de una aplicacin la lgica de acceso a datos ser heredada de este namespace, esto como se muestra en el siguiente diagrama:
DAOMasterLibrary
Negocio <<Usa>>
Acceso a Datos
<<Usa>>
<<Crea>> Dominio
Finalmente la implementacin del motor de persistencia, estar contenida en un solo Assembly o librera de clases DLL la cual ser denominada DAOMasterLibrary.dll . Este podr ser incorporado en cualquier proyecto de desarrollo, simplemente al agregar una referencia a esta librera y seguir el esquema propuesto. Finalmente el motor de persistencia debe de implementar ciertas caractersticas como la Sincronizacin de la Estructura del Modelo de Dominio con el modelo ER donde se persistirn los datos, generacin automtica de las sentencias de insercin, actualizacin y
Pgina 92 de 159
eliminacin, carga de objetos, implementar las caractersticas anteriores independientes del sistema RDBMS o contenedor usado, parametrizacin, etc. Todas estas caractersticos son explicadas en la secciones siguientes del presente capitulo.
4.2 Sincronizacin Estructura ER y Modelo de Dominio

4.2.1 Planteamiento del Requerimiento
Dado que la persistencia de datos es una caracterstica que debemos de implementar sobre el modelo de dominio, es necesario que la funcionalidad del motor de persistencia a crear contenga un mecanismo a travs del cual se mantenga una relacin bien sincronizada entre el modelo de dominio y su respectivo equivalente en el RDBMS. Esta sincronizacin debe de garantizar que cada instancia de una clase del Dominio pueda ser persistida como una o varias filas en una o varias tablas especificas, de la misma forma se debe de garantizar que la filas de las tablas puedan ser cargadas dentro de objetos en tiempo de ejecucin. Las operaciones antes mencionadas requieren que exista una forma de indicar al Motor una relacin uno a uno entre tablas y clases as como tambin relaciones uno a uno entre columnas de una tabla y las propiedades de una clase. Se debe de considerar como parte del requerimiento que esta operacin de mapeo requiera el menor tiempo posible al desarrollador, de tal forma que no le rastrase o le obligue a realizar complejos o detallados mapeos entre cada propiedad de una tabla y las propiedades de una clase.
4.2.2 Diseo de la Solucin

Motores de persistencia como Hibernate o NHIbernate utilizan un archivo XML para definir el mapeo entre clases y tablas. Para nuestro caso se ha considerado automatizar totalmente dicho mapeo, sin embargo esta funcionalidad supone que el desarrollador utilizar una herramienta CASE que le permita modelar un sistema en un diagrama de clases, es decir construir un modelo de dominio y su respectivo cdigo C# y a partir de este generar el DDL para ser ejecutado en el RDBMS y construir de esa forma el ER a partir del diagrama de clases. Este mecanismo solucionara el problema de mantener sincronizado ambos modelos, asignando dicha responsabilidad a la herramienta CASE.
Pgina 93 de 159
4.2.2.1
Diseando la Clase de Dominio
Por ejemplo para el modelamiento de los usuarios de un sistema, se disea la siguiente clase:
Usuario + + + + + + + + + + + + + + + <<Property>> <<Property>> <<Property>> <<Property>> <<Property>> <<Property>> <<Property>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> usuarioID usuarioNombres usuarioApellidos usuarioEmail usuarioCelular usuarioPassword fechaActualizacion _usuarioID _usuarioNombres _usuarioApellidos _usuarioEmail _usuarioCelular _usuarioPassword _fechaActualizacion : : : : : : : : : : : : : : string string string string string string Datetime string string string string string string Datetime : : : : : : : : : : : : : : : : : : void int bool int void string void string void string void string void string void string void Datetime
<<Setter>> <<Getter>> <<Setter>> <<Getter>> <<Setter>> <<Getter>> <<Setter>> <<Getter>> <<Setter>> <<Getter>> <<Setter>> <<Getter>> <<Setter>> <<Getter>>
Usuario (string sUsuarioCuenta, string sUsuarioNombre, string sUsuarioPassword) encriptarClave () validarClave (string sPassword) cambiarPassword (string sPasswordAnterior, string sNuevoPassword) set_usuarioID (string value) get_usuarioID () set_usuarioNombres (string value) get_usuarioNombres () set_usuarioApellidos (string value) get_usuarioApellidos () set_usuarioEmail (string value) get_usuarioEmail () set_usuarioCelular (string value) get_usuarioCelular () set_usuarioPassword (string value) get_usuarioPassword () set_fechaActualizacion (Datetime value) get_fechaActualizacion ()
Se puede notar de esta clase que tiene 7 propiedades las cuales son privadas, es decir no pueden ser acezadas directamente, sino solamente a travs de la propiedades (getter y setter) las cuales son mtodos con el mismo nombre que los atributos de la clase, esta es la implementacin del Data Hidding y de la Encapsulacin de objeto. Adicionalmente se han agregado las siguientes reglas de negocio a este modelo: No es posible crear una nueva instancia de un objeto Usuario si no se cuenta con los datos obligatorios UsuarioID, UsuarioNombre y UsuarioClave. Estos son parmetros obligatorios del Constructor de la Clase.
Pgina 94 de 159
No es posible cambiar las propiedades UsuarioID, UsuarioNombre e UsuacioClave esta ultima solo puede ser cambiada a travs del mtodo cambiarPassword. Debido a esto los Setter de la propiedades UsuarioID, UsuarioNombre y UsuarioClave, si bien existen son privados por lo que no pueden ser invocados externamente. La clase cuenta con un mtodo privado encriptarClave el cual se encarga de codificar la clave del usuario de tal forma que este encriptada al momento que el usuario sea persistido La clase Usuario cuenta con el mtodo validarClave la cual recibe una cadena de texto y devuelve un valor verdadero si es la clave asignada al usuario o falso si no es as
Estas propiedades y mtodos que mantienen un alto grado de cohesin permitirn dar a esta clase la responsabilidad nica de representar a los usuarios manteniendo un bajo grado de acoplamiento de tal forma que el objeto pueda ser reutilizable. El cdigo generado por el case para esta clase, es el siguiente:
public class Usuario { private string _usuarioID; private string _usuarioNombres; private string _usuarioApellidos; private string _usuarioEmail; private string _usuarioCelular; private string _usuarioPassword; private Datetime _fechaActualizacion;
public
sealed
void {
Usuario(string
sUsuarioCuenta,
string
sUsuarioNombre,
string
sUsuarioPassword)
// TODO: implement }
public sealed int encriptarClave() // TODO: implement return 0; }
public sealed bool validarClave(ref string sPassword) // TODO: implement return false; }
Pgina 95 de 159
public
sealed {
int
cambiarPassword(ref
string
sPasswordAnterior,
ref
string
sNuevoPassword)
// TODO: implement return 0; } {
private string usuarioID get {
return _usuarioID; } Set {
if (this._usuarioID != value) this._usuarioID = value; } }
private string usuarioNombres get {
return _usuarioNombres; } Set { if (this._usuarioNombres != value) this._usuarioNombres = value; } }
private string usuarioApellidos get {
return _usuarioApellidos; } Set {
if (this._usuarioApellidos != value) this._usuarioApellidos = value; } } private string usuarioEmail get { {
return _usuarioEmail; } Set {
if (this._usuarioEmail != value) this._usuarioEmail = value; } } private string usuarioCelular get { {
return _usuarioCelular; } Set {
if (this._usuarioCelular != value)
Pgina 96 de 159
this._usuarioCelular = value; } }
private string usuarioPassword get {
return _usuarioPassword; } Set { if (this._usuarioPassword != value) this._usuarioPassword = value; } } Private Datetime fechaActualizacion Get { {
return _fechaActualizacion; } Set { if (this._fechaActualizacion != value) this._fechaActualizacion = value; } } }
4.2.2.2
Diseando el Modelo Fsico en el RDBMS
Habiendo finalizado el modelo de dominio, podemos utilizar el CASE para que nos genere el modelo Fsico orientado a un sistema RDBMS especifico, para nuestro caso, generamos el modelo fsico especificando Microsoft SQL Server como RDBMS y el CASE nos genero la siguiente tabla
Usuario usuari oID usuari oNom bres usuari oApelli dos usuari oEm ail usuari oCelular usuari oPassword fechaActualizaci on varchar(50) <pk> varchar(100) varchar(100) varchar(100n) varchar(8) varchar(100) Datetim e
El DDL de dicha clase es el siguiente

create table Usuario ( usuarioID varchar(50) not null, usuarioNombres varchar(100) not null, usuarioApellidos varchar(100) null, usuarioEmail varchar(100n) null, usuarioCelular varchar(8) null, usuarioPassword varchar(100) not null, fechaActualizacion Datetime not null, constraint PK_USUARIO primary key (usuarioID) )
Este puede ya ser ejecutado contra la base de datos para definir el ER de nuestro sistema.
Pgina 97 de 159
4.2.3 Construccin de la Solucin.

Los siguientes, son mas que construcciones dentro del prototipo, son bien lineamientos que debern seguirse al construir la aplicacin particular para garantizar que el motor de persistencia identifique la relacin entre clases y tablas. Se deber construir un namespace denominado Dominio dentro del cual debern de declararse todas las clases de dominio que formen el aplicativo. Entonces el cdigo generado por el case quedara de la siguiente manera:
Namespace Dominio { public class Usuario { private string _usuarioID; private string _usuarioNombres; private string _usuarioApellidos; private string _usuarioEmail; private string _usuarioCelular; private string _usuarioPassword; private Datetime _fechaActualizacion; } }
Para cada clase de dominio se deber crear una clase DAO en cuyo constructor se declare a travs de la ejecucin del mtodo setDoName el nombre de la tabla del ER al cual esta mapeada dicha clase. Por nomenclatura el nombre de la clase deber ser la cadena DAO mas el nombre de la clase de dominio. Estas clases DAO debern ser definidas dentro de un namespace denominado AccedoDatos y cada clase deber ser heredada de la clase DAOMaster. Para la clase de Dominio Usuario, la clase de acceso a datos quedara de la siguiente forma:
using System;
using System.Data; using DAOMasterLibrary; using Dominio; namespace AccesoDatos {
Pgina 98 de 159
class DAOUsuario : DAOMaster { public DAOUsuario() { this.setDOName("usuario"); } } }
4.3 Generacin de operaciones transaccionales

El sistema a implementar debe de generar las operaciones de insercin, actualizacin y eliminacin de forma automtica, recibiendo como insumo nicamente una instancia del objeto a procesar. Dado que el motor de persistencia trabaja en la capa de acceso a datos, ser a este nivel donde debern de estar disponibles mtodos para adicionar, actualizar y eliminar objetos. Los cuales recibirn una instancia y generarn las operaciones pertinentes de la forma mas eficiente posible. Esto significa para el caso de la actualizacin por ejemplo solo actualizar las propiedades que hayan cambiado y no toda la fila.

Dado el requerimiento anterior, se han diseado tres mtodos concretos los cuales se describen a continuacin:
Mtodo Parmetros Descripcin
1 2 3
add Update Delete
Domain Object Domain Object Domain Object
Adiciona el objeto Actualiza las propiedades del objeto que han cambiado Elimina el Objeto
4.3.2.1
Mtodo para la insercin de registros.
El mtodo Add que ser implementado en la Capa de acceso a Datos para ser usado en la capa de negocios, tendr la responsabilidad de recibir una instancia de un Domain Object y convertirlo a un registro de la correspondiente tabla mapeada, generando la correspondiente
Pgina 99 de 159
sentencia insert. Para desarrollar esta tarea dicho mtodo, se auxiliara de una serie de mtodos privados siguiendo la secuencia que se muestra en el siguiente diagrama:
add
setdoName
getSchema
getPropierties
saveDS
getID
RDBMS
Setear Nombre Objeto
Solicitar Esquema Devuelve Esquema Tabla Crear Row a paritr de esquema Envio de objeto y DataRow vaco DataRow poblado con propiedades de objeto
Adicionar Datarow a Dataset Envio DataSet envio de sentencia Insert generada
Exito o Exepcin Solicitar Pk de registro insertado PK insertado
Resultado Exito o Exepcin
Los mtodos utilizados en la secuencia anterior se describen a continuacin:

Mtodo Descripcin
Mtodo Setter que establece el nombre de la clase a procesar SetdoName Obtiene el esquema de la tabla identificada por el nombre del objeto getSchema getPropierties Recibe la instancia del objeto a persistir y un Datarow vaci con la estructura de la tabla, barre la instancia y asigna los valores de cada propiedad a su respeciva columna en el datarow, devolviendo el datarow poblado Toma un Dataset y genera una sentencia insert para el datarow contenido saveDS 4.3.2.2 Mtodo para la actualizacin de registros.
El mtodo update a implementar en la Capa de Acceso a Datos. Recibir la referencia del objeto de dominio a actualizar y tendr la responsabilidad de generar la sentencia update
Pgina 100 de 159
basado en los primary keys del registro actualizando nicamente las columnas que han cambiado. Para realizar esta actividad el mtodo update, se Valera de la ayuda de una serie de mtodos privados, siguiendo la secuencia del diagrama siguiente:
update
setDoName
getSchema
getPropierties
saveDS
getStrWhere
RDBMS2
Generar Where para registro a partir de primaries Keys Sentencia Where ejecutar select con el where construido DataRow poblado
Solicitar Esquema Devuelve Esquema Tabla
Crear DataSet a paritr de esquema
Asignar Datarow poblado a DataSet Creado Envio de objeto y DataRow vaco DataRow poblado con propiedades de objeto
Asignar nuevo valores a existentes en DataRow Envio DataSet envio de sentencia update generada Resultado Exito o Exepcin
Exito o Exepcin
Mtodo
Descripcin
Mtodo Setter que establece el nombre de la clase a procesar SetdoName Obtiene el esquema de la tabla identificada por el nombre del objeto getSchema getPropierties Recibe la instancia del objeto a persistir y un Datarow vaci con la estructura de la tabla, barre la instancia y asigna los valores de cada
Pgina 101 de 159
saveDS getWhere
propiedad a su respectiva columna en el datarow, devolviendo el datarow poblado Toma un Dataset y genera una sentencia update para el datarow contenido Genera un string que servir como filtro where para un Quero, esta sentencia esta formada por las columnas definidas como Primary Keys para la tabla mapeada as como el valor respectivo que hace nico al registro
4.3.2.3
Mtodo para la eliminacin de registros
El mtodo delete que implementara el motor de persistencia, recibir un objeto de dominio y partir de esto deber de generar la sentencia delete respectiva filtrada por las columnas que forman la primary Key y sus valores respectivos. Al igual que los casos de adicin y actualizacin el mtodo se auxiliara de mtodos privados, siguiendo la secuencia mostrada en el siguiente diagrama:
delete
setdoName
getStrWhere
execSQL
RDBMS
Contruir Where con Primary keys String para where Envio de sentencia delete con where creado Ejecutar Delete Exito o Exepcion
Exito o Exepcion
Mtodo
Descripcin
Mtodo Setter que establece el nombre de la clase a procesar SetdoName getStrWhere Genera un string que servir como filtro where para un Quero, esta sentencia esta formada por las columnas definidas como Primary Keys para la tabla mapeada as como el valor respectivo que hace nico al registro Ejecuta una sentencia SQL execSQL
Pgina 102 de 159
4.3.3 Construccin de la Solucin

En esta seccin se muestra el cdigo de los mtodos implementados para soportar las operaciones de adicin, actualizacin y eliminacin siguiendo la lgica y secuencias planteados en el diseo de los mismos.
4.3.3.1
Mtodo Add
Este mtodo pblico recibe un Domain Object e intenta persistirlo en Data Source especificado. El cdigo de dicho mtodo es el siguiente:
// Salva el Domain Object en el Datasource
public long add(object aDO) { try { setDOName(aDO.GetType().Name.ToString()); DataSet oDS = new DataSet() ; oDS.ReadXmlSchema(getSchema()); DataRow oRow = oDS.Tables[0].NewRow(); getPropiedades(oRow,aDO); oDS.Tables[0].Rows.Add(oRow); saveDS(oDS); } catch (Exception ex) { throw new Exception("Error Insertando objeto " + ex.Message); } return getID(); }
this._doName + " / " +
Puede observarse que debido a que el parmetro es un objeto de tipo Domain Object que puede ser en si cualquier objeto, es necesario la utilizacin de Late Binding al momento de definir el tipo de dato del argumento recibido. El mtodo ADD utiliza se vale de una serie de modos como se mostr en la secuencia del diseo, el cdigo de estos mtodos es mostrado a continuacin:
// Devuelve el Schema en formato XML StrinReader de la estructura de persistencia del Domain Object actual private System.IO.StringReader getSchema() { string sXML = this.getDsSchema().GetXmlSchema(); return new System.IO.StringReader(sXML); } //Funcin privada que ejecuta y devuelve el Schema del Objeto mapeado private DataSet getDsSchema(){ if (dsSchema != null) return dsSchema; else {
Pgina 103 de 159
DataSet ds; DbCommand oCommand; DbDataAdapter oAdapter; string SqlString = "select * from " + this._doName; try { if (setConnection()) { ds = new DataSet(); oCommand = _oCon.CreateCommand(); oAdapter = dbFactory.CreateDataAdapter(); oCommand.Connection = _oCon; oCommand.CommandType = CommandType.Text; oCommand.CommandText = SqlString; oAdapter.SelectCommand = oCommand; oAdapter.FillSchema(ds, SchemaType.Mapped); dsSchema = ds; } else { return null; } } catch (Exception ex) { throw ex; } return ds; } } // Obtiene las propiedades de un Domain Object asignandolas a un DataRow a traves de invocaciones dinamicas a los Getter private void getPropiedades(DataRow aRow, object aDO){ PropertyInfo[] oProperties; string sPropertyName=""; MethodInfo oMetodo; try { oProperties = aDO.GetType().GetProperties(BindingFlags.NonPublic|BindingFlags.Instance|BindingF lags.Static|BindingFlags.Public); foreach(PropertyInfo oProperty in oProperties) { sPropertyName = oProperty.Name.ToString(); oMetodo = oProperty.GetGetMethod(true); switch (oMetodo.ReturnType.ToString()) { case "System.String": aRow[sPropertyName] = (string)oMetodo.Invoke(aDO, null); break; case "System.DateTime": aRow[sPropertyName] = (DateTime)oMetodo.Invoke(aDO, null); break; case "System.Int16": aRow[sPropertyName] = (Int16)oMetodo.Invoke(aDO, null); break; case "System.Int32": aRow[sPropertyName] = (Int32)oMetodo.Invoke(aDO, null); break; case "System.Int64": aRow[sPropertyName] = (Int64)oMetodo.Invoke(aDO, null); break; case "System.Decimal": aRow[sPropertyName] = (Decimal)oMetodo.Invoke(aDO, null); break; case "System.Double":
Pgina 104 de 159
aRow[sPropertyName] = (Double)oMetodo.Invoke(aDO, null); break; case "System.Boolean": aRow[sPropertyName] = (Boolean)oMetodo.Invoke(aDO, null); break; case "System.Char": aRow[sPropertyName] = (Char)oMetodo.Invoke(aDO, null); break; } } } catch(Exception ex) { throw new Exception("Error accesando la propiedad " + sPropertyName + " / " + ex.Message); } }
// Objetivo: Actualizar el Dataset en el DataSource private int saveDS(DataSet ds) { string sSQL = "select * from " + this._doName; DbDataAdapter oAdapter; DbCommandBuilder oCBuilder; int iResult = 0; if (setConnection()) { try { oAdapter = dbFactory.CreateDataAdapter(); oAdapter.SelectCommand.CommandText = sSQL; oAdapter.SelectCommand.Connection = this._oCon; oCBuilder = dbFactory.CreateCommandBuilder(); oCBuilder.DataAdapter = oAdapter; iResult = oAdapter.Update(ds); oAdapter.Dispose(); oAdapter = null; } catch (Exception ex) { throw new Exception("Error actualizando objeto " + this._doName + " / " + ex.Message); } } return iResult; }
4.3.3.2
Mtodo Update.
Este mtodo pblico recibe un Domain Object e intenta actualizarlo en el Data Source especificado. El cdigo de dicho mtodo es el siguiente:
Pgina 105 de 159
//Actualizar el Domain Object en el Datasource public bool update(object aDO) { this.setDOName(aDO.GetType().Name.ToString()); try { string sSQL = "select * from " + this._doName + " " + this.getWhere(aDO); DataSet oDS, fDS; fDS = new DataSet(); fDS.ReadXmlSchema(getSchema()); oDS = getDS(sSQL); DataRow oRow = oDS.Tables[0].Rows[0]; DataRow fRow = fDS.Tables[0].NewRow(); foreach(DataColumn oColumn in oDS.Tables[0].Columns) { fRow[oColumn.ColumnName.ToString()] = oRow[oColumn.ColumnName.ToString()]; } fDS.Tables[0].Rows.Add(fRow); fDS.AcceptChanges(); getPropiedades(fRow, aDO); saveDS(fDS,true,aDO); } catch(Exception ex) { throw new Exception("Error actualizando objeto " + this._doName + " / " + ex.Message); } return true; }
El mtodo actualizar se vale de los mismos mtodos que Add, es decir los mtodos getSchema(), readXMLSchema(),getPropiedades() y saveDS() incorpora adems el mtodo getDS() y getWhere() de los cuales se muestra el cdigo a continuacin:
//Funcin protected que ejecuta y devuelve un DataSet protected DataSet getDS(string SqlString){ DataSet ds; DbCommand oCommand = _oCon.CreateCommand(); DbDataAdapter oAdapter = dbFactory.CreateDataAdapter(); try { if(setConnection()) { ds = new DataSet() ; oCommand.Connection = _oCon; oCommand.CommandType = CommandType.Text; oCommand.CommandText = SqlString; oAdapter.SelectCommand = oCommand; oAdapter.Fill(ds); } else { return null; } } catch(Exception ex) { throw ex; } return ds; } // Generar la Sentencia where correspondiente usando los primary key y sus valores private string getWhere(object aDO) { DataColumn[] colArr; string sWhere = "", sColumn, sAND, sType; DataSet ds; DataRow fila;
Pgina 106 de 159
int ikeys; try { ds = getDsSchema(); fila = ds.Tables[0].NewRow(); getPropiedades(fila,aDO); colArr = ds.Tables[0].PrimaryKey; ikeys = colArr.Length; sColumn = ""; sWhere = " where "; if (ikeys == 0) throw new Exception("Objeto " + _doName + " no tiene definido Primary Key en el ER, imposible continuar"); for (int i = 1; i < ikeys; i++) { sAND = (i>0)? " AND ":""; sColumn = colArr[i].ColumnName; sType = colArr[i].DataType.Name.ToString(); if(sType.CompareTo("String")==0||sType.CompareTo("Char")==0) { sWhere += sAND + sColumn + " = '" + fila[sColumn] + "'"; } else { sWhere += sAND + sColumn + " = " + Convert.ToString(fila[sColumn]) + " "; } } } catch (Exception ex) { throw new Exception("Error obteniendo Primary Keys / " + ex.Message); } return sWhere; }
4.3.3.3
Mtodo Delete
Este mtodo pblico recibe un Domain Object e intenta eliminarlo del Data Source especificado. El cdigo de dicho mtodo es el siguiente:
// Elimina el DVO en el Datasource public bool delete(object aDO) { try { setDOName(aDO.GetType().Name.ToString()); string sSQL = "delete from " + this._doName + " " + getWhere(aDO); execSQL(sSQL); } catch(Exception ex) { throw new Exception("Error eliminando objeto " + this._doName + " / " + ex.Message); } return true; }
Este mtodo utiliza el mismo mtodo getWhere utilizado en el Update, incorpora adems un nuevo mtodo de tipo protected denominado execSQL. El cdigo de este mtodo se muestra a continuacin:
Pgina 107 de 159
// Ejecutar un SQL protected bool execSQL(string sSQL) { DbCommand oCommand; if(setConnection()) { oCommand = dbFactory.CreateCommand(); try { oCommand.CommandText = sSQL; oCommand.Connection = this._oCon ; oCommand.ExecuteNonQuery(); } catch(Exception ex) { throw ex; }finally { oCommand.Dispose(); oCommand = null; } } else return false; return true; }
4.4
Construccin y Cargas de los Objetos

El motor de persistencia, debe de ser capas de recuperar un objeto indicando nicamente el ID del objeto a recuperar.

Dado el requerimiento anterior, se han diseado dos mtodos para realizar la carga de un objeto a travs de su ID
Mtodo
Parmetros
Descripcin
1 2
cargar cargar
ID de tipo numrico ID de tipo string
Devuelve la instancia de la clase llena con las propiedades identificados por el ID numrico dado Devuelve la instancia de la clase llena con las propiedades identificados por el ID string dado
El mtodo cargar hace uso de los servicios proporcionados por otros mtodos de la misma clase, esto se muestra en la siguiente secuencia:
Pgina 108 de 159
cargar
getObject
getWhereID
getDS
setPropiedades
RDBMS
Contruir Where con ID enviado String para where Enviar SQL y Solicitar Objeto
Envio de sentencia sql con filtro por ID Exito o Exepcion Identificacin de Tipo de Objeto
Solicitar Registro Exito o Exepcion
Creacin de instancia de Tipo de Objeto Envio de Registro y Domain Object Domain Object Poblado Instancia Domain Object Poblado

El cdigo C# del mtodo sobrecargado cargar tanto en su versin para id numrico como string, se muestra a continuacin:
// Metodo cargar para menejo de ID numericos
public object cargar(long id) { string sSQL; object aDO; try { sSQL = "select * from " + this._doName + getWhereID(id); aDO = getObject(sSQL); } catch (Exception ex) { throw ex; } return aDO; }
// Metodo cargar para menejo de ID string

public object cargar(string id) { string sSQL; object aDO; try {
Pgina 109 de 159
sSQL = "select * from " + this._doName + getWhereID(id); aDO = getObject(sSQL); } catch (Exception ex) { throw ex; } return aDO; }
El mtodo cargar una ves construido el SQL con filtro Where, delega la responsabilidad de creacin y poblado de los datos al mtodo getObjet, el cdigo de este mtodo, se muestra a continuacin:
//Metodo privado que devuelve la instancia cargada del objeto a partir de un registro
private object getObject(string sSQL) { DataSet miDs; object aDO; try { string spaceName = this.GetType().AssemblyQualifiedName; string objectDAOName = this.GetType().Namespace + "." + this.GetType().Name; string objectName = "Dominio." + this._doName ; spaceName = spaceName.Replace(objectDAOName, objectName); Type tTipo = Type.GetType(spaceName,true,true); aDO = Activator.CreateInstance(tTipo); miDs = this.getDS(sSQL); if (miDs.Tables[0].Rows.Count > 0) setPropiedades(miDs.Tables[0].Rows[0], aDO); else throw new Exception("Problemas con el objeto " + this._doName ); } catch (Exception ex) { throw new Exception("Error en objeto " + this.GetType().Name + " / " + ex.Message); } finally { miDs = null; } return aDO; }
El mtodo cargar utiliza en su secuencia de ejecucin los mtodos getWhereID que devuelve un string con el filtro Where compuesto por el ID del objeto, por su lado el metodo getobject utiliza el mtodo setPropiedades el cual puebla las propiedades de un objeto con los datos de un DataRow utilizando la Reflexin. El cdigo de ambos mtodos, se detalla a continuacin:
//Metodo que devuelve una cadena con la construccion del Where con los primarykeys del objeto private string getWhereID(string id){ DataColumn[] colArr; string sColumn; int ikeys; try { DataSet ds = getDsSchema();
Pgina 110 de 159
colArr = ds.Tables[0].PrimaryKey; ikeys = colArr.Length; sColumn = " where " ; if(ikeys==0) throw new Exception("Objeto " + _doName + " no tiene definido Primary Key en el ER, imposible continuar"); for(int i = 1; i<ikeys;i++) sColumn += colArr[i].ColumnName + " = '" + id + "'"; } catch(Exception ex) { throw new Exception("Error obteniendo Primary Keys / " + ex.Message ); } return sColumn; }
// Llenar el Domain Object a partir del DataRow invocando dinamicamente los Setter de cada propiedad private void setPropiedades(DataRow aRow, object aDO) { PropertyInfo[] oProperties; string sPropertyName=""; MethodInfo oMetodo; try { oProperties = aDO.GetType().GetProperties(BindingFlags.NonPublic|BindingFlags.Instance|BindingF lags.Static|BindingFlags.Public); foreach(PropertyInfo oProperty in oProperties) { sPropertyName = oProperty.Name.ToString(); if(aRow.IsNull(sPropertyName)) { oProperty.SetValue(aDO,null,null); } else { oMetodo = oProperty.GetGetMethod(true); switch (oProperty.GetSetMethod(true).ReturnType.Name.ToString()) { case "System.String": oProperty.SetValue(aDO, (string)aRow[sPropertyName], null); break; case "System.DateTime": oProperty.SetValue(aDO, (DateTime)aRow[sPropertyName], null); break; case "System.Int16": oProperty.SetValue(aDO, (Int16)aRow[sPropertyName], null); break; case "System.Int32": oProperty.SetValue(aDO, (Int32)aRow[sPropertyName], null); break; case "System.Int64": oProperty.SetValue(aDO, (Int64)aRow[sPropertyName], null); break; case "System.Decimal": oProperty.SetValue(aDO, (Decimal)aRow[sPropertyName], null); break; case "System.Double": oProperty.SetValue(aDO, (Double)aRow[sPropertyName], null); break; case "System.Boolean": Boolean bValor; if(aRow[sPropertyName].GetType().ToString().CompareTo("System.SByte")==0) { SByte sbValor = (SByte)aRow[sPropertyName]; bValor = (sbValor.ToString().Equals("1"))?true:false; } else if(aRow[sPropertyName].GetType().ToString().CompareTo("System.Byte")==0) { Byte sbValor = (Byte)aRow[sPropertyName]; bValor = (sbValor.ToString().Equals("1"))?true:false; } else {
Pgina 111 de 159
bValor = (Boolean)aRow[sPropertyName]; } oProperty.SetValue(aDO,bValor,null); break; case "System.Char": oProperty.SetValue(aDO, (string)aRow[sPropertyName], null); break; } } } } catch(Exception ex) { throw new Exception("Error seteando la propiedad " + sPropertyName + " / " + ex.Message); } }
4.5
Acceso Independiente del sistema RDBMS

La funcionalidad a construir ya que implementar la Capa de Acceso a Datos, debe de ser capas de manejar eficientemente el acceso a distintos sistema de bases de datos relacionales de forma transparente y parametrizada para el desarrollador. Esto supone que el desarrollador solo deber indicar dentro de la configuracin del aplicativo que motor de base de datos utilizar y el motor de persistencia debe de hacer el resto. Sin embargo esto supone los siguientes problemas Aunque ADO .Net 2.0 contiene una serie de objetos genricos agrupados en el namespace System.Data, entre otros el DataSet, DataTable, DataView, DataColumn, DataRow, etc., al momento de interactuar con distintas bases de datos como SQL Server u Oracle, hace uso de controles especficos para cada RDBMS. De esta forma existe una clase SqlConenction para Microsoft SQL y una clase OraConnection para Oracle, as como MySqlConnections para Mysql y OleConnection para acceso via OleDB. El uso de estas clases especificas por proveedor es necesaria ya que garantiza la eficiencia en las operaciones en contra de cada contenedor. Si bien esta considerado el uso de acceso va OleDB a cualquier base con este tipo de acceso, esto ocasiona una perdida de rendimiento por lo que es conveniente utilizar los namespaces ofrecidos por Microsoft o construidos por cada proveedor.
Pgina 112 de 159
La funcionalidad a construir requiere de la utilizacin de objetos especficos para cada RDBMS tales como: Clase Connection DataAdapter Descripcin Clase Conexin especifica para cada proveedor Adaptador de datos especifico para cada proveedor, permite incorporar un contenido de datos dentro de un DataSet. Clase Coomand, la que ejecuta un sql en una conexin especifica para cada proveedor Clase para acceso conectado especifica para cada proveedor (implementa un cursor Forward Only)
Microsoft SQL SqlConnection
Oracle
OraConnection
OleDB
OleConnection
SqlDataAdapter
OraDataAdapter
OleDataAdapter
Command
SqlCommand
OraCommand
OleCommand
DataReader
SqlDataReader
OraDataReader
OleDataReader

Conociendo el requerimiento establecido. Donde se plantea la necesidad de crear familias de objetos en tiempo de ejecucin, el patrn idneo para modelar una solucin de este tipo es el patrn Abstract Factory 6. El framework .Net 2.0 posee dentro de ADO .Net 2.0 una implementacin de este patrn, el cual esta disponible en el namespace System.Data.Common, esta solucin permite la creacin de objetos especficos para cada proveedor. Sin embargo a la fecha de este estudio, nicamente existen Factoras concretas para SQL , Oracle y OLE DB, las cuales son proporcionadas por Microsoft a travs del mismo framework. Proveedores como Mysql, Sybase, PostGress y el mismo Oracle ofrecen conectores especficos para ADO .Net, pero
Ver numeral 3.4.7 para mayor informacin sobre el patrn Abstract Factory
Pgina 113 de 159
estos no son heredados de la clase System.Data.Comon por lo que no pueden ser utilizados para implementar el patrn Abstract Factory. Dado esto para el caso de Proveedores distintos a SQL y Oracle se utilizar el mtodo de Acceso OLE DB, esperando que en pronto tiempo el resto de proveedores liberen conectores que si puedan ser utilizados dentro de este esquema. Un esquema de la solucin propuesta a travs del patrn Abstract Factory implementado en .Net, se muestra a continuacin:
DAOMasterlibrary <<Usa>> <<Usa>>
<<Usa>> DbConnection {abstract} {abstract}
DbProviderFactory
+ + + + + +
getFactory (string Provider) createCommand () createConnection () createParameter () createDataAdapter () createTransaction ()
: : : : : :
DbProviderFactory DbCommand DbConnection DbParameter DbDataAdapter DbTransaction
SQLConnection
OraConnection
DbCommand <<Crea>> SQLProviderFactory {abstract}
OraProviderFactory <<Crea>> OraCommand SqlCommand
+ + + + +
createCommand () createConnection () createParameter () createDataAdapter () createTransaction ()
: : : : :
SQLCommand SQLConnection SQLParameter SQLDataAdapter SQLTransaction
+ + + + +
createCommand () createConnection () createParameter () createDataAdapter () createTransaction ()
: : : : :
OraCommand OraConnection OraParameter OraDataAdapter OraTransaction
<<Crea>>
<<Crea>>
ADO .Net provee la clase Abstracta DbProviderFactory la cual es capas de crear instancias de clases xxConnections, xxCommand, xxDataAdapter, etc. Estos son referenciados a travs de productos abstractos DbConnection, DbCommand, DbDataAdapter que en realidad contienen objetos concretos de tipo SqlConnection, SqlCommand, SqlDataAdapter u OraConnection, OraCommand, OraDataAdapter para el caso de Oracle.
Pgina 114 de 159
Dado que dentro de la funcionalidad a crear se deber manejar mecanismos de crear la DBFactory adecuada, as como crear las cadenas de conexin correctas, etc. Se deber disear una clase separada para implementar estos mecanismos la cual proporcionara sus servicios a la clase principal que implementara el patrn DAO. Dado que la clase DAOMaster implementara los mtodos de persistencia, la responsabilidad de crear el DBFactory correcta, as como el de crear conexiones a la base de datos caer sobre una nueva clase denominada DataFactory cuyos servicios sern usados por la clase principal DAOMaster. Esta relacin se muestra en el siguiente diagrama.
DAOMaster 0..1
<<Usa>>
dataFactory DAOMasterLibrary DataFactory - dataFactory : DataFactory - dbFactory : DbProviderFactory - dbCon : DbConnection + + + DbFactory () : getInstancia () : getFactory () : getConnection () : setDB () : = new DataFactory() 1..1 DBProviderFactory <<Crea>>
void DataFactory DbProviderFactory DbConnection void

El procedimiento de utilizacin de la Factory consiste en los siguientes pasos: 1. Definicin de la Factory Para realizar esta tarea bastara con definir una instancia de tipo DbProvider Factory de la siguiente manera:
Pgina 115 de 159
DbProviderFactory DbFactoria;
2. Instanciamiento de la Factory de acuerdo al Proveedor Teniendo la definicin del tipo de dato, pasaremos al proceso de creacin de la instancia a travs del mtodo getFactory() el cual devuelve una instancia concreta de acuerdo al argumento enviado el cual debe de indicar el namespace del proveedor a utilizar, as:
DbFactoria = DbProviderFactory.GetFactory(System.Data.SqlClient);
Crea una instancia de una factory para SQL Server. 3. Definicin de productos abstractos Para utilizar objetos de tipo Connection, Command , TableAdapter o DataAdapter dentro del cdigo del motor de persistencia se hace referencia a objetos de tipo DB como se muestra en las siguientes definiciones
DbConnection conn; DbCommand command; DbTableAdapter tableAdapter; DbDataAdapter dataAdapter;
4.
Creacin de Productos concretos.
Para la instanciacin de objetos concretos se har referencia a la clase DbFactoria como se muestra a continuacin.
Conn = DbFactoria.createConnection() ; Command = DbFactoria.createCommand(); tableAdapter = DbFactoria.createTableAdapter(); dataAdapter = DbFactoria.createDataAdapter();
El cdigo C# de la clase DataFactory se muestra a continuacin:

using System; using System.Data.Common; namespace DAOMasterLibrary { class DataFactory
Pgina 116 de 159
{ static DataFactory dataFactory = new DataFactory(); DbProviderFactory dbFactory; DbConnection dbCon; private void DbFactory() { } static public DataFactory getInstancia() { return dataFactory; } public DbProviderFactory getFactory() { if (dbFactory == null) setDB(); return dbFactory; } public DbConnection getConnection() { try { if (dbCon == null) { setDB(); dbCon = dbFactory.CreateConnection(); dbCon.ConnectionString = ""; dbCon.Open(); } } catch (Exception ex) { throw new Exception("Imposible Crear Conexin a RDBMS / " + ex.Message); } return dbCon; } private void setDB() { dbFactory = DbProviderFactories.GetFactory("System.Data.SqlClient"); } } }
4.6 Configuracin y Parametrizacin

Para que el motor de persistencia sea reutilizable en cualquier aplicacin, debe de permitir su parametrizacin, es decir el desarrollador al utilizar esta funcionalidad debe poder indicar el tipo de dialecto o contenedor a utilizar, indicar parmetros de servidor, usuario, password y bases de datos, etc.
Pgina 117 de 159

Para definir los parmetros como datos de la conexin, dialectos, etc. Se ha considerado la creacin de un archivo XML el cual ser denominado DAOConfig.ini, este contendr entre otros los siguientes parmetros. Dialecto: Es el nombre del sistema RDBMS a utiliza, podr tomar los valores SqlClient, Oracle, MySql, OleDB. DataSource: Es el nombre del servidor o la ip address del datasource. Usuario: El nombre del usuario con el cual se crearn las conexiones hacia el datasource Password: El password del usuario a conectarse. DataBase: El nombre de la base de datos a la cual se deber conectar la aplicacin.

El archivo DAOConfig deber ser ubicado en el mismo directorio donde se ubique la librera DAOMasterLibrary.dll, como generalmente se agregar como referencia a un proyecto .Net. El directorio por defecto ser el directorio bin el cual ya esta protegido para no descargar informacin desde dicha ruta. Un ejemplo del archivo de configuracin, se muestra a continuacin:
<DAOConfig> <Parametros> <Dialecto>SqlClient</dialecto> <DataSource>Localhost<DataSource> <Usuario>sa<Usuario> <Password>daoMasterSA<Password> <DataBase>Northwind<DataBase> </Parametros> </DAOConfig>
Pgina 118 de 159
Dado que la responsabilidad de crear y manejar las conexiones es de la clase DataFactory, esta que es implementada a travs del patrn Singleton, tendr una serie de propiedades asociadas a los parmetros ingresados en el archivo XML
namespace DAOMasterLibrary { class DataFactory { private string _dialecto; private string _datasource; private string _database; private string _usuario; private string _password;
De igual forma esta clase posee el mtodo loadParameters() el cual se encarga de leer el archivo XML cargando los parmetros a las propiedades de la clase. La implementacin de este mtodo, se muestra a continuacin:
private void loadParameters() { XPathDocument doc; XPathNavigator nav; try { StreamReader stFile = new StreamReader("DAOConfig.xml"); string xml = stFile.ReadToEnd(); stFile.Close(); doc = new XPathDocument(new StringReader(xml)); nav = doc.CreateNavigator(); _dialecto = nav.SelectSingleNode("/*/Parametros/Dialecto").InnerXml; _datasource = nav.SelectSingleNode("/*/Parametros/DataSource").InnerXml; _database = nav.SelectSingleNode("/*/Parametros/DataBase").InnerXml; _usuario = nav.SelectSingleNode("/*/Parametros/Usuario").InnerXml; _password = nav.SelectSingleNode("/*/Parametros/Password").InnerXml; }catch (Exception ex) { throw new Exception("Problemas cargando parametros de conexion al datasource / " + ex.Message ); } }
Pgina 119 de 159
V. RESULTADOS Y VERIFICACION EXPERIMENTAL

Este capitulo documenta procedimiento empleado para verificar la funcionalidad del producto creado, as como los resultados obtenidos a partir de dichas pruebas. Para la pruebas del motor de persistencia, se construyo un mantenimiento de usuarios, este es en si, una interfase Win32 construida con C# .
5.1
Objetivo de las Pruebas

Verificar que el motor de persistencia creado, ejecuta automticamente las conversiones entre operaciones con objetos a sentencias SQL y viceversa. Demostrar que la utilizacin del motor de persistencia reduce el tiempo necesario para el desarrollo de un aplicativo. Demostrar que la utilizacin del motor de persistencia permite abstraer el diseo y construccin del sistema de forma tal que es independiente la base de datos empleada.
5.2
Definicin del Requerimiento
Para realizar las pruebas de prototipo desarrollado, se deber construir un aplicativo que de mantenimiento a usuarios, ya que esta es una funcionalidad comn en muchas aplicaciones. El aplicativo deber de contener. Herramienta de carga y bsqueda de usuarios Herramienta de Adicin de Usuarios Herramienta de actualizacin de los datos de un usuario Herramienta de Eliminacin de Usuarios. Del usuario nos interesan los siguientes datos: o Cuenta asociada al usuario o Password del Usuario
Pgina 120 de 159
o Nombres del Usuario o Apellidos del Usuario o Email del Usuario o Si el usuario esta activo o no o Fecha de Creacin o Fecha de Actualizacin de los datos del usuario Se deben de considerar las siguientes consideraciones. Por razones de seguridad el password debe de persistirse de forma encriptada Se debe de considerar mtodos de cambio de password No pueden existir dos usuarios con el mismo nombre de cuenta Los datos obligatorio para crear un usuario es el nombre de cuenta, su password y su nombre. Para la implementacin, se utilizar el RDBMS. SQL Server 2005 para manejar la base de datos
5.3
Modelado y Diseo de la Solucin
A continuacin se disean los distintos modelos que componen el sistema
5.3.1 Modelo de Dominio.

Dado que nuestro requerimiento solo establece un concepto, es decir el Usuario al momento de modelar solo tendremos esta entidad la cual quedara modelada de la siguiente forma:
Usuario cuenta password nombres apellidos email activo fechaCreacion fechaActualizacin : : : : : : : : string string string string string bool DateTime DateTime
La clase anterior cuenta nicamente con los atributos definidos para la entidad usuario. Estas posteriormente al aplicarles el encapsulamiento y Data Hide son convertidos en propiedades quedando de la siguiente forma:
Pgina 121 de 159
Usuario + + + + + + + + + + + + <<Property>> <<Property>> <<Property>> <<Property>> <<Property>> <<Property>> <<Property>> <<Property>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> <<Setter>> <<Getter>> <<Setter>> <<Getter>> <<Setter>> <<Getter>> <<Setter>> <<Getter>> <<Setter>> <<Getter>> <<Setter>> <<Getter>> <<Setter>> <<Getter>> <<Setter>> <<Getter>> cuenta password nombres apellidos email activo fechaCreacion fechaActualizacin _cuenta _password _nombres _apellidos _email _activo _fechaCreacion _fechaActualizacin : : : : : : : : : : : : : : : : string string string string string bool DateTime DateTime string string string string string bool DateTime DateTime : : : : : : : : : : : : : : : : void string void string void string void string void string void bool void DateTime void DateTime
set_Cuenta (string value) get_Cuenta () set_Password (string value) get_Password () set_Nombres (string value) get_Nombres () set_Apellidos (string value) get_Apellidos () set_Email (string value) get_Email () set_Activo (bool value) get_Activo () set_FechaCreacion (DateTime value) get_FechaCreacion () set_FechaActualizacion (DateTime value) get_FechaActualizacion ()
Finalmente, se agregan mtodos para soportar las operaciones de validar password, cambiar password y encriptar el password ingresado. Adems se adiciona un constructor que no dejara se cree una instancia a menos que se ingrese la cuenta, password y nombre del usuario, los correspondientes Setters de estas propiedades son declarados privados, para que no puedan ser invocados externamente y las propiedades seteadas nicamente a travs del constructor. La clase queda de la siguiente forma
Pgina 122 de 159
Usuario + + + + + + + + + + + + + + + <<Property>> <<Property>> <<Property>> <<Property>> <<Property>> <<Property>> <<Property>> <<Property>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> <<Setter>> <<Getter>> <<Setter>> <<Getter>> <<Setter>> <<Getter>> <<Setter>> <<Getter>> <<Setter>> <<Getter>> <<Setter>> <<Getter>> <<Setter>> <<Getter>> <<Setter>> <<Getter>> cuenta password nombres apellidos email activo fechaCreacion fechaActualizacin _cuenta _password _nombres _apellidos _email _activo _fechaCreacion _fechaActualizacin : : : : : : : : : : : : : : : : string string string string string bool DateTime DateTime string string string string string bool DateTime DateTime : : : : : : : : : : : : : : : : : : : : void void string void string void string void string void string void bool void DateTime void DateTime void bool bool
Usuario (string sCuenta, string sPassword, string sNombre) set_Cuenta (string value) get_Cuenta () set_Password (string value) get_Password () set_Nombres (string value) get_Nombres () set_Apellidos (string value) get_Apellidos () set_Email (string value) get_Email () set_Activo (bool value) get_Activo () set_FechaCreacion (DateTime value) get_FechaCreacion () set_FechaActualizacion (DateTime value) get_FechaActualizacion () encryptPassword (string sCadena) passwordIsValid (string sPassword) cambiarPassword (string sPasswordAnterior, string sNuevoPassword)
El cdigo de la clase es el siguiente:

using System; public sealed class Usuario { private string _Cuenta; private string _Password; private string _Nombres; private string _Apellidos; private string _Email; private bool _Activo; private DateTime _FechaCreacion; private DateTime _FechaActualizacion; public sealed void Usuario(string sCuenta, string sPassword, string sNombre) { // TODO: implement } private string Cuenta get { return _Cuenta; {
Pgina 123 de 159
} set
{ if (this._Cuenta != value) this._Cuenta = value;
} } private string Password { get { return _Password; } set { if (this._Password != value) this._Password = value; } } private string Nombres { get { return _Nombres; } set { if (this._Nombres != value) this._Nombres = value; } } private string Apellidos { get { return _Apellidos; } set { if (this._Apellidos != value) this._Apellidos = value; } } private string Email { get { return _Email; } set { if (this._Email != value) this._Email = value; } } private bool Activo { get { return _Activo; } set { if (this._Activo != value) this._Activo = value; } } private DateTime FechaCreacion { get { return _FechaCreacion; } set { if (this._FechaCreacion != value) this._FechaCreacion = value;
Pgina 124 de 159
} } private DateTime FechaActualizacion { get { return _FechaActualizacion; } set { if (this._FechaActualizacion != value) this._FechaActualizacion = value; } } public sealed bool PasswordIsValid(string sPassword) { // TODO: implement return false; } public sealed bool CambiarPassword(string sPasswordAnterior, string sNuevoPassword) { // TODO: implement return false; } private sealed string EncryptPassword(string sCadena) { // TODO: implement return ""; } }
5.3.2 Modelo de Acceso a Datos

Para el modelado de la Capa de Acceso a Datos, tenemos como directivas la utilizacin del patrn DAO y la incorporacin de la funcionalidad del motor de persistencia creado a travs de la Herencia en nuestra clase DAO. El modelado de esta capa se muestra en la siguiente figura:
DAOMaster
DAOUsuario
+ DAOUsuario () : void
Pgina 125 de 159
Ya que solo utilizaremos una entidad, tambin en la capa de acceso a datos solo tendremos una sola clase denominada DAOUsuario. Gracias a la utilizacin del motor de persistencia la funcionalidad se heredara por lo que no ser necesario escribir mucho cdigo, el nico mtodo que deber de implementarse es el constructor de la clase, en este se invocara el mtodo de setteo del nombre del objeto de dominio a procesar. El cdigo generado a nivel de diseo es el siguiente:
public class DAOUsuario : DAOMaster { public void DAOUsuario() { // TODO: implement } }
5.3.3 Modelo de Reglas del Negocio.

Para la capa de negocio se modela una clase que se denominar NgcUsuario la cual brindara los servicios a la capa de presentacin, esta clase contendr los mtodos de adicin, actualizacin, eliminacin y carga de una entidad. Sin embargo es importante recalcar que la interfase de los mtodos de esta clase recibirn valores primitivos, es decir enteros, Strings, fechas, etc e internamente se manipularan como objetos. La siguiente figura muestra el modelado de dicha clase:
NgcUsuario
+ + + + +
adicionarUsuario (string sCuenta, string sPassword, string sNombre, string sApellido, string sEmail) : int actualizarUsuario (string sCuenta, string sNombre, string sApellido, string sEmail) : int eliminarUsuario (string sCuenta) : int cambiarPassword (string sCuenta, string sPassword, string sNuevoPassword) : int obtenerUsuario (string sCuenta) : Usuario
El cdigo generado para la clase es el siguiente:

public sealed class NgcUsuario {
Pgina 126 de 159
public sealed int AdicionarUsuario(string sCuenta, string sPassword, string sNombre, string sApellido, string sEmail) { // TODO: implement return 0; } public sealed int ActualizarUsuario(string sCuenta, string sNombre, string sApellido, string sEmail) { // TODO: implement return 0; } public int EliminarUsuario(string sCuenta) { // TODO: implement return 0; } public int CambiarPassword(string sCuenta, string sPassword, string sNuevoPassword) { // TODO: implement return 0; } public Usuario ObtenerUsuario(string sCuenta) { // TODO: implement return null; } }
El modelado final de todas las clases que interactan es el siguiente:
Pgina 127 de 159
DAOMaster
NgcUsuario DAOUsuario + + + + + adicionarUsuario (string sCuenta, string sPassword, string sNombre, string sApellido, string sEmail) : int actualizarUsuario (string sCuenta, string sNombre, string sApellido, string sEmail) : int eliminarUsuario (string sCuenta) : int cambiarPassword (string sCuenta, string sPassword, string sNuevoPassword) : int obtenerUsuario (string sCuenta) : Usuario <<Usa>> + DAOUsuario () : void
<<Crea>>
Usuario <<Property>> <<Property>> <<Property>> <<Property>> <<Property>> <<Property>> <<Property>> <<Property>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> <<PropertyImplementation>> cuenta password nombres apellidos email activo fechaCreacion fechaActualizacin _cuenta _password _nombres _apellidos _email _activo _fechaCreacion _fechaActualizacin : : : : : : : : : : : : : : : : string string string string string bool DateTime DateTime string string string string string bool DateTime DateTime
<<Usa>>
+ Usuario (string sCuenta, string sPassword, string sNombre) - <<Setter>> set_Cuenta (string value)
5.4
Construccin de la Aplicacin
5.4.1 Creacin de la Estructura de Datos.

Dado que el motor de persistencia creado requiere una total sincrona entre el modelo de dominio y el las estructuras de persistencia, la mejor forma de garantizar esto como ya se explico antes, es utilizar un CASE que pueda manejar ambos modelos es decir objetos y datos o DDL . Para nuestro caso utilizamos el producto PowerDesigner 12.0 de la empresa Sybase. Sin embargo se puede utilizar el producto que mas le convenga o parezca al desarrollador. Como solo tenemos una entidad en el modelo de dominio, igual al transformar este modelo en un ER obtendremos una sola entidad como muestra la siguiente figura:
Pgina 128 de 159
Usuario <<Property>> <<Property>> <<Property>> <<Property>> <<Property>> <<Property>> <<Property>> <<Property>> cuenta password nombres apellidos email activo fechaCreacion fechaActualizacin varchar(30) varchar(50) varchar(50) varchar(50) varchar(75) bit datetime datetime
El cdigo DDL para esta entidad y generado por el CASE PowerDesigner, es el siguiente:
/*==============================================================*/ /* Table: Usuario */ /*==============================================================*/ create table Usuario ( Cuenta varchar(30) not null, Password varchar(100) not null, Nombres varchar(50) not null, Apellidos varchar(50) null, Email varchar(75) null, Activo bit null, FechaCreacion datetime not null, FechaActualizacion datetime not null, constraint PK_USUARIO primary key (Cuenta) ) Go
Este Script se ejecutara sobre una instancia de SQL Server 2005 con las siguientes caractersticas de conexin: Servidor: Localhost Base de Datos: Maestria Usuario: MaestriaUFG Password: Maestria$UFG$2006
5.4.2 Creacin del Proyecto Visual C# Win32

Ya con el diseo de la solucin y la base de datos creada, procedemos a abrir el Visual C# 2005 Express Edition y creamos un nuevo proyecto de tipo Win32 Application, como se muestra en la siguiente imagen:
Pgina 129 de 159
Se puede notar que en el Solution Explorer se agregaron automticamente las referencias a las libreras necesarias para manejar la parte visual del proyecto. Procederemos a agregar una referencia a nuestro motor de persistencia el cual reside dentro del Assembly DAOMasterLibrary.dll, para esto deberemos copiar dicho dll a una ruta fsica en la maquina de desarrollo y agregar la referencia a dicha ruta como se muestra a continuacin:
Pgina 130 de 159
Se deber observar la referencia agregada en el proyecto como se muestra en la siguiente imagen:
Posteriormente procederemos a incorporar el cdigo generado a partir del modelamiento y diseo, para organizar mejor dicho cdigo se ha creado un Flder al que nombramos Clases y bajo este subfolders Dominio, AccesoDatos y Negocio donde crearemos las clases respectivamente, esto se muestra en la siguiente imagen.
Pgina 131 de 159
El cdigo final de cada una de las clases es el siguiente: ***************************** ****** Clase Usuario ********** *****************************
using System;
namespace Dominio { public sealed class Usuario { private string _Cuenta; private string _Password; private string _Nombres; private string _Apellidos; private string _Email; private bool _Activo; private DateTime _FechaCreacion; private DateTime _FechaActualizacion; public Usuario(string sCuenta, string sPassword, string sNombre) { _Cuenta = sCuenta; _Password = this.EncryptPassword(sPassword); _Nombres = sNombre; } private string Cuenta { get { return _Cuenta; } set { if (this._Cuenta != value) this._Cuenta = value; } } private string Password { get { return _Password; } set { if (this._Password != value) this._Password = value; } } public string Nombres { get { return _Nombres; } set
Pgina 132 de 159
{ if (this._Nombres != value) this._Nombres = value; } } public string Apellidos { get { return _Apellidos; } set { if (this._Apellidos != value) this._Apellidos = value; } } public string Email { get { return _Email; } set { if (this._Email != value) this._Email = value; } } public bool Activo { get { return _Activo; } set { if (this._Activo != value) this._Activo = value; } } public DateTime FechaCreacion { get { return _FechaCreacion; } set { if (this._FechaCreacion != value) this._FechaCreacion = value; } } public DateTime FechaActualizacion { get { return _FechaActualizacion; }
Pgina 133 de 159
set { if (this._FechaActualizacion != value) this._FechaActualizacion = value; } } //Devuelve verdadero si el password enviado coincide con el almacenado en la instancia public bool PasswordIsValid(string sPassword) { return _Password.Equals(this.EncryptPassword(sPassword)); } //Realiza cambio de password en instancia si el password actual enviado coincide con el almacenado en la instancia public bool CambiarPassword(string sPasswordActual, string sNuevoPassword) { if (PasswordIsValid(sPasswordAnterior)) _Password = EncryptPassword(sNuevoPassword); else throw new Exception("Password Invalido"); return true; } //Devuelve Cadena Encriptada con algoritmo Hash SHA private string EncryptPassword(string sCadena) { return Utils.Encrypt.encryptSHA(sCadena); } } }
***************************** ****** Clase DAOUsuario ****** *****************************

using using using using System; System.Data; DAOMasterLibrary; Dominio;
namespace AccesoDatos { class DAOUsuario : DAOMaster { public DAOUsuario() { this.setDOName("usuario"); } } }
Pgina 134 de 159
***************************** ****** Clase NgcUsuario ******* *****************************

using using using using System; System.Data; Dominio; AccesoDatos;
namespace Negocio { class NgcUsuario { public int AdicionarUsuario(string sCuenta, string sPassword, string sNombre, string sApellido, string sEmail) { DAOUsuario daoUsuario = new DAOUsuario();; Usuario usuario; try { usuario = new Usuario(sCuenta, sPassword, sNombre); if (!daoUsuario.existe(usuario)) { usuario.Apellidos = sApellido; usuario.Activo = true; usuario.FechaCreacion = DateTime.Now; usuario.FechaActualizacion = DateTime.Now; daoUsuario.add(usuario); } else throw new Exception("Cuenta de usuario ya existe..."); } catch (Exception ex) { throw new Exception("Error al intentar adicionar Usuario / " + ex.Message); } finally { if (daoUsuario != null) daoUsuario.release(); } return 1; } public int ActualizarUsuario(string sCuenta, string sNombre, string sApellido, string sEmail) { DAOUsuario daoUsuario = new DAOUsuario(); ; Usuario usuario; try { usuario = (Usuario)daoUsuario.cargar(sCuenta); usuario.Nombres = sNombre; usuario.Apellidos = sApellido; usuario.Email = sEmail; usuario.FechaActualizacion = DateTime.Now; daoUsuario.update(usuario); } catch (Exception ex) {
Pgina 135 de 159
throw new Exception("Error al intentar actualizar Usuario / " + ex.Message); } finally { if (daoUsuario != null) daoUsuario.release(); } return 1; } public int EliminarUsuario(string sCuenta) { DAOUsuario daoUsuario = new DAOUsuario(); ; try { daoUsuario.delete(sCuenta); } catch (Exception ex) { throw new Exception("Error al intentar eliminar Usuario / " + ex.Message); } finally { if (daoUsuario != null) daoUsuario.release(); } } public int CambiarPassword(string sCuenta, string sPassword, string sNuevoPassword) { DAOUsuario daoUsuario = new DAOUsuario(); ; Usuario usuario; try { usuario = (Usuario)daoUsuario.cargar(sCuenta); usuario.CambiarPassword(sPassword, sNuevoPassword); daoUsuario.update(usuario); } catch (Exception ex) { throw new Exception("Error al intentar actualizar Password de Usuario / " + ex.Message); } finally { if (daoUsuario != null) daoUsuario.release(); } } public Usuario ObtenerUsuario(string sCuenta) { DAOUsuario daoUsuario = new DAOUsuario(); ; Usuario usuario; try { usuario = (Usuario)daoUsuario.cargar(sCuenta); } catch (Exception ex) { throw new Exception("Error al intentar actualizar Usuario / " + ex.Message);
Pgina 136 de 159
} finally { if (daoUsuario != null) daoUsuario.release(); } return usuario; } } }
***************************** ****** Clase Visual Form1 ***** *****************************

using using using using using using using using using System; System.Collections.Generic; System.ComponentModel; System.Data; System.Drawing; System.Text; System.Windows.Forms; Negocio; Dominio;
namespace pruebaPersistencia { public partial class Form1 : Form { public Form1() { InitializeComponent(); } private void cbtAdd_Click(object sender, EventArgs e) { try { new NgcUsuario().AdicionarUsuario(txtCuenta.Text, txtPassword.Text, txtNombre.Text, txtApellido.Text, txtEmail.Text); } catch (Exception ex) { MessageBox.Show(ex.Message, "Error"); } } private void cbtUpdate_Click(object sender, EventArgs e) { try { new NgcUsuario().ActualizarUsuario(txtCuenta.Text, txtNombre.Text, txtApellido.Text, txtEmail.Text); } catch (Exception ex) { MessageBox.Show(ex.Message, "Error"); } }
Pgina 137 de 159
private void cbtDelete_Click(object sender, EventArgs e) { try { new NgcUsuario().EliminarUsuario(txtCuenta.Text); } catch (Exception ex) { MessageBox.Show(ex.Message, "Error"); } } private void cbtLoad_Click(object sender, EventArgs e) { try { Usuario usuario = new NgcUsuario().ObtenerUsuario(txtCuenta.Text); txtNombre.Text = usuario.Nombres; txtApellido.Text = usuario.Apellidos; txtEmail.Text = usuario.Email; usuario = null; } catch (Exception ex) { MessageBox.Show(ex.Message, "Error"); } } private void button5_Click(object sender, EventArgs e) { this.Close(); }
} }
5.5
Ejecucin y Resultados
Construida la interfase que invoca los servicios de la capa de negocios. Al momento de ejecutarla se obtiene la siguiente interfase:
Pgina 138 de 159
Al ejecutar la funcionalidad de la interfase que invoca los mtodos de la capa de negocios, se obtienen los siguientes resultados. Ya que se esta utilizando SQL como RDBMS se utilizar el SQL Server Profiler para verificar las sentencias enviadas por el aplicativo al motor de base de datos.
5.5.1 Operacin de Adicin.

Al momento de ejecutar el mtodo de negocio adicionarUsuario, el cual crea una instancia de la clase de acceso a datos que hereda la funcionalidad creada y se invoca el mtodo Add especficamente la instruccin:
daoUsuario.add(usuario);
El motor de persistencia genera la siguiente instruccin SQL:

exec sp_executesql N'INSERT INTO [Usuario] ([Cuenta], [Password], [Nombres], [Apellidos], [Email], [Activo], [FechaCreacion], [FechaActualizacion]) VALUES (@p1, @p2, @p3, @p4, @p5, @p6, @p7, @p8)',N'@p1 varchar(11),@p2 varchar(44),@p3 varchar(7),@p4 varchar(8),@p5 varchar(19),@p6 bit,@p7 datetime,@p8 datetime',@p1='ufgMaestria',@p2='Vr5RWMG2az/rADYZLrrvwB3QwFB1ZmdNYWVzdHJpYQ==',@p 3='Usuario',@p4='Maestra',@p5='maestria@ufg.edu.sv',@p6=1,@p7=''2006-12-22 16:17:48:423'',@p8=''2006-12-22 16:17:48:423''
Pgina 139 de 159
5.5.2 Operacin de Actualizacin:

Al momento de ejecutar el mtodo de negocio actualizaUsuario, el cual crea una instancia de la clase de acceso a datos que hereda la funcionalidad creada y se invoca el mtodo cargar especficamente la instruccin:
usuario = (Usuario)daoUsuario.cargar(sCuenta);

select * from usuario where Cuenta = 'ufgMaestria'
Posteriormente cuando se ejecuta la instruccin de acceso a datos:

daoUsuario.update(usuario);

exec sp_executesql N'UPDATE [Usuario] SET [Nombres] = @p1, [FechaActualizacion] = @p2 WHERE (([Cuenta] = @p3) AND ([Password] = @p4) AND ([Nombres] = @p5) AND ((@p6 = 1 AND [Apellidos] IS NULL) OR ([Apellidos] = @p7)) AND ((@p8 = 1 AND [Email] IS NULL) OR ([Email] = @p9)) AND ((@p10 = 1 AND [Activo] IS NULL) OR ([Activo] = @p11)) AND ([FechaCreacion] = @p12) AND ([FechaActualizacion] = @p13))',N'@p1 varchar(18),@p2 datetime,@p3 varchar(11),@p4 varchar(44),@p5 varchar(7),@p6 int,@p7 varchar(8),@p8 int,@p9 varchar(19),@p10 int,@p11 bit,@p12 datetime,@p13 datetime',@p1='Usuario Acualizado',@p2=''2006-12-22 16:20:03:923'',@p3='ufgMaestria',@p4='Vr5RWMG2az/rADYZLrrvwB3QwFB1ZmdNYWVzdHJpYQ= =',@p5='Usuario',@p6=0,@p7='Maestra',@p8=0,@p9='maestria@ufg.edu.sv',@p10=0,@p11 =1,@p12=''2006-12-22 16:17:48:423'',@p13=''2006-12-22 16:17:48:423''
Pgina 140 de 159
5.5.3 Operacin de Eliminacin.

Al momento de ejecutar el mtodo de negocio eliminaUsuario, el cual crea una instancia de la clase de acceso a datos que hereda la funcionalidad creada y se invoca el mtodo cargar especficamente la instruccin:
usuario = (Usuario)daoUsuario.cargar(sCuenta);

select * from usuario where Cuenta = 'ufgMaestria'
Posteriormente cuando se ejecuta la instruccin de acceso a datos:

daoUsuario.delete(usuario);

exec sp_executesql N'DELETE DROM [Usuario] WHERE (([Cuenta] = @p1))',N'@p1 varchar(18), ,@p1='ufgMaestria'
5.6
Conclusiones sobre las Pruebas.
Al finalizar estas pruebas despus de analizar el cdigo construido podemos concluir. La funcionalidad del motor de persistencia heredada en las clases DAO genera correctamente las operaciones SQL de insercin, actualizacin, eliminacin y carga de objetos. Estas construccin es automtica y transparente para el desarrollador y el usuario. El motor de persistencia utiliza adecuadamente los campos que funcionan como primary key para generar los filtros y condiciones where. Las operaciones de Update se realizan eficientemente nicamente sobre los campos modificados.
Pgina 141 de 159
VI. CONCLUSIONES Y FUTURAS LINEAS DE INVESTIGACION
6.1
Conclusiones Generales
En el desarrollo de este proyecto se muestra las ventajas del desarrollo de aplicaciones siguiendo un modelo de desarrollo completamente orientado a objetos, donde el acceso a datos es abstrado y separado a una capa especifica de la aplicacin, donde debe de manejarse la relacin entre objetos, las tablas y registros donde sern persistidos. Si bien como objetivo general se ha demostrado la funcionalidad del prototipo creado al aplicarlo a esta la capa de acceso a datos, existen una serie de puntos y conclusiones ms especficos donde resaltan los siguientes: Sobre la operabilidad del prototipo, podemos concluir, que es sencilla ya que solo requiere la incorporacin en el proyecto .Net del Assembly DAOMasterLibrary.dll y seguir los linimientos de uso. Dado las caractersticas de la plataforma .Net el proyecto puede ser de cualquier tipo que requiera acceso a un RDBMS y es independiente del lenguaje a utilizar. El motor de persistencia construido es parametrizable a travs del archivo XML de configuracin DAOConfig.xml. Cambiando por ejemplo el dialecto en este archivo, nuestro prototipo puede trabajar perfectamente con otra base de datos, sin ningn problema. El motor de persistencia construido permite fcilmente trabajar o interactuar con distintos sistemas RDBMS, evitando que el desarrollador se preocupe de estas actividades. El motor de persistencia oculta esta complejidad al desarrollador teniendo este nada ms que efectuare la parametrizacin y especificacin dialecto a utilizar. El uso de un motor de persistencia, evita que el usuario se preocupe por las operaciones transaccionales de Acceso a Datos. El desarrollador nada mas se del
Pgina 142 de 159
preocupara por ejecutar mtodos Add, cargar, Update o Delete sobre los objetos de dominio, el motor se encargar del resto. El modelo distribuido propuesto facilita la reusabilidad de cdigo, por ejemplo las clases DAO construidas pueden ser reutilizadas por otras aplicaciones. La abstraccin de la capa de Acceso a Datos permite hacer operaciones a nivel de negocios sobre objetos y no sobre registros. El modelado de las clases de dominio permite que los objetos imiten de la realidad modelada y como en el caso construido no solo contengan datos, sino ejecuten mtodos propios o internos a sus datos, cosa que no es natural para un registro. El uso de patrones de diseo, permite que el cdigo generado sea muy flexible y potencia grandemente la reusabilidad. El uso de este material por educadores ser de beneficios para estudiantes que puedan utilizar estos ejemplo como base para construir o mejorar el cdigo o como simple aplicacin de diversos conceptos relacionados a la ingeniera de software.
6.2
Futuras Lneas de investigacin.
Dado que el prototipo desarrollado en este documento, esta limitado en su diseo y funcionalidad principalmente por factores de tiempo, existen ciertos aspectos no considerados en este documento que podran ser desarrollados como futuras lneas de investigacin. Entre esas posibles lneas de investigacin se proponen las siguientes:
6.2.1 Manejo de Herencia y Composicin.

El objetivo de este tema, es el de extender la funcionalidad actual del motor con el fin de dar soporte a la herencia y la composicin. Investigando la forma mas eficiente de definir este tipo de relaciones y manejarlas al momento de ser persistidas.
Pgina 143 de 159
Se propone este tema, debido a que la herencia es una de las principales propiedades de la Orientacin a Objetos, es una de las caractersticas que ms denotan la diferencia al construir un modelo orientado a objetos contra uno relacional u orientado a datos. El soporte de esta funcionalidad al igual que el caso de la composicin en el motor de persistencia como ya lo hacen productos como Hibernate, mejorara en gran medida la utilidad de esta herramienta.
6.2.2 Eficiencia y Rendimiento.

El desarrollo de este tema, abarca un proceso de revisin completo al aplicativo de tal forma de buscar los mecanismos y tcnicas mas eficientes para la construccin de los mtodos, documentando los resultados y exponiendo el porque de dichas mejoras y como impactan el rendimiento de la funcionalidad construida en un ambiente de mltiples usuarios o con cargas considerables de datos. Se propone tratar temas como manejo de pools y cache de objetos y conexiones, etc. Se propone este tema dado que los ejemplos planteados en este documento han sido orientados ms que todo a la funcionalidad en si del producto y no a un uso masivo o con grandes cargas de estrs. Lo que permitira la utilizacin de este modelo en aplicaciones de tipo Enterprise o de alto rendimiento.
6.2.3 Ejecucin sobre plataformas no Windows.

Este tema esta orientado a la ejecucin del motor sobre una plataforma no Windows, esto debido a las limitantes de la plataforma .Net y a que actualmente existen ya proyectos muy avanzados de ejecucin del framework sobre otras plataformas, como el proyecto Mono (http://www.mono-project.com) , esto brindara la oportunidad de ejecutar dicho aplicativo sobre plataformas Linux, Unix, Mac, etc.
Pgina 144 de 159
VII. Bibliografa y Referencias Estudiadas.
Design Patterns: Elements of Reusable Object-Oriented Software (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides) 1995 Paulk, Paul C. et al. The Capability Maturity Model, Guidelines for improving the software process, CMU/SEI, Addison-Wesley, 1995. CBA Lead Assessor Training. Participants Guide. December, 2001. Version 1.2. Software Engineering Institute. Carnegie Mellon University. Kitson David. CMMI: Current status & standardization aspects. SPIN meeting at LA, October 2000. Kulpa, Margaret. CMM not for the little guy? SEPG Conference, February 2002. Servello, Kasse Tim. Et al. Panel. The loyal opposition versus the CMMI champions: A frank discussion of CMMI models. Setting the stage. SEPG Conference, February 2002.
Diseo de Sistemas de Bases de Datos Merche Marqus. 12 de abril de 2002 Cattell, R.G. The Object Database Standard: ODMG-93 (Release 1.2). Morgan Kauffman Publishers. San Francisco, 1995.
Codd, E.F. A Relational Model of Data for Large Shared Data Banks. CACM 13(6): 377-387. 1970.
Elmasri, R. & Navathe, S.B. Fundamentals of Database Systems 3e. Addison Wesley, 2000.
McClure, S. IDC Bulletin #14821E. August, 1997. Nahouraii, E. & Petry, F. Object-Oriented Databases. IEEE, 1991.
Rao, B.R. Object-Oriented Databases: Technology, Applications, and Products McGraw-Hill. New York, 1994.
Stonebraker, M. Architectural Options for Object-Relational DBMSs. Informix Software, CA. Feb, 1997.
Pgina 145 de 159
Stonebraker, M. Object-Relational DBMS: The Next Wave. Informix Software, CA. Stonebraker, M., Brown, P., and Moore, D. Object-Relational DBMSs: Tracking the Next Great Wave 2e. Morgan-Kauffman Publishers. San Francisco, 1999.
Pgina 146 de 159
VIII. ANEXO A: Cdigo Fuente del Motor de Persistencia

******************************************************************************** **** **** Clase: DataFactoy Descripcin: Clase encargada del manejo de los factories y conexiones
********************************************************************************
using using using using using using
System; System.Data; System.Data.Common; System.Xml; System.Xml.XPath; System.IO;
namespace DAOMasterLibrary { class DataFactory { static DataFactory dataFactory = new DataFactory(); DbProviderFactory dbFactory; DbConnection dbCon; private string _dialecto; private string _datasource; private string _database; private string _usuario; private string _password;
private void DbFactory() { } static public DataFactory getInstancia() { return dataFactory; } public DbProviderFactory getFactory() { if (dbFactory == null) setDB(); return dbFactory; } public DbConnection getConnection() { try { if (dbCon == null) { setDB(); dbCon = dbFactory.CreateConnection(); dbCon.ConnectionString = getStrCon(); dbCon.Open(); } if (dbCon.State == ConnectionState.Closed || dbCon.State == ConnectionState.Broken) { dbCon.ConnectionString = getStrCon(); dbCon.Open(); } } catch (Exception ex) { throw new Exception("Imposible Crear Conexin a RDBMS / " + ex.Message); } return dbCon; }
Pgina 147 de 159
private void setDB() { loadParameters(); switch (_dialecto.ToUpper()) { case "SQLCLIENT": dbFactory = DbProviderFactories.GetFactory("System.Data.SqlClient"); break; case "ORACLE": dbFactory = DbProviderFactories.GetFactory("System.Data.OraClient"); break; case "MYSQL": dbFactory = DbProviderFactories.GetFactory("System.Data.Odbc"); break; case "OLEDB": dbFactory = DbProviderFactories.GetFactory("System.Data.OleDb"); break; case "ODBC": dbFactory = DbProviderFactories.GetFactory("System.Data.Odbc"); break; } } private string getStrCon() { string strCon=""; switch (_dialecto.ToUpper()) { case "SQLCLIENT": strCon = "Server=" + _datasource + ";Database=" + _database + ";User ID=" + _usuario + ";Password=" + _password + ";Trusted_Connection=False"; break; case "ORACLE": strCon = "Data Source=" + _datasource + ";User Id=" + _usuario + ";Password=" + _password + ";Integrated Security=no;"; break; case "MYSQL": strCon = "Driver={MySQL ODBC 3.51 Driver};Server=" + _datasource + ";Database=" + _database + ";User=" + _usuario + ";Password=" + _password + ";Option=3"; break; } return strCon; } private void loadParameters() { XPathDocument doc; XPathNavigator nav; try { StreamReader stFile = new StreamReader("DAOConfig.xml"); string xml = stFile.ReadToEnd(); stFile.Close(); doc = new XPathDocument(new StringReader(xml)); nav = doc.CreateNavigator(); _dialecto = nav.SelectSingleNode("/*/Parametros/Dialecto").InnerXml; _datasource = nav.SelectSingleNode("/*/Parametros/DataSource").InnerXml; _database = nav.SelectSingleNode("/*/Parametros/DataBase").InnerXml; _usuario = nav.SelectSingleNode("/*/Parametros/Usuario").InnerXml; _password = nav.SelectSingleNode("/*/Parametros/Password").InnerXml; } catch (Exception ex) { throw new Exception("Problemas cargando parametros de conexion al datasource / " + ex.Message ); } } } }
Pgina 148 de 159
******************************************************************************** **** **** Clase: DaoMaster Descripcin: Clase encargada de implementar la funcionalidad del motor
********************************************************************************
using using using using using
System; System.Data; System.Data.Common; System.Reflection; System.Collections;
namespace DAOMasterLibrary { public abstract class DAOMaster : IDisposable { private DbConnection _oCon; private string _doName; private DbProviderFactory dbFactory; private DataSet dsSchema; protected bool disposed; //Constructor public DAOMaster() { dbFactory = DataFactory.getInstancia().getFactory(); } //Getter y Setter de la Propieda Conexin private DbConnection Conn { get { return _oCon; } set { if (this._oCon != value) this._oCon = value; } } //Getter y Setter de la Propieda Nombre del Domain Object private string doName { get { return _doName; } set { if (this._doName != value) this._doName = value; } }
//Setter del Domain Object Name protected void setDOName(string sName) { if (dbFactory == null) dbFactory = DataFactory.getInstancia().getFactory(); this._doName = sName; } //Metodo Privado que obtiene uan conexion asignandola a la instancia actual private bool setConnection() { try { if (_oCon == null) _oCon = DataFactory.getInstancia().getConnection();
Pgina 149 de 159
if (_oCon.State == ConnectionState.Closed || _oCon.State == ConnectionState.Broken) _oCon = DataFactory.getInstancia().getConnection(); } catch(Exception ex) { throw new Exception("Error intentando obtener conexin / " + ex.Message ); } return true; }
//Funcin protected que ejecuta y devuelve un DataSet protected DataSet getDS(string SqlString){ DataSet ds; DbCommand oCommand; DbDataAdapter oAdapter; try { if(setConnection()) { ds = new DataSet() ; oCommand = _oCon.CreateCommand(); oAdapter = dbFactory.CreateDataAdapter(); oCommand.Connection = _oCon; oCommand.CommandType = CommandType.Text; oCommand.CommandText = SqlString; oAdapter.SelectCommand = oCommand; oAdapter.Fill(ds); } else { return null; } } catch(Exception ex) { throw ex; } return ds; } //Funcin privada que ejecuta y devuelve el Schema del Objeto mapeado private DataSet getDsSchema(){ if (dsSchema != null) return dsSchema; else { DataSet ds; DbCommand oCommand; DbDataAdapter oAdapter; string SqlString = "select * from " + this._doName; try { if (setConnection()) { ds = new DataSet(); oCommand = _oCon.CreateCommand(); oAdapter = dbFactory.CreateDataAdapter(); oCommand.Connection = _oCon; oCommand.CommandType = CommandType.Text; oCommand.CommandText = SqlString; oAdapter.SelectCommand = oCommand; oAdapter.FillSchema(ds, SchemaType.Mapped); dsSchema = ds; } else { return null; } } catch (Exception ex) { throw ex; } return ds; } } //Metodo getWhereId para ID de tipo Numero private string getWhereID(long id) { DataColumn[] colArr; string sColumn; int ikeys;
Pgina 150 de 159
try { DataSet ds = getDsSchema(); colArr = ds.Tables[0].PrimaryKey; ikeys = colArr.Length; sColumn = " where "; if (ikeys == 0) throw new Exception("Objeto " + _doName + " no tiene definido Primary Key en el ER, imposible continuar"); for (int i = 0; i < ikeys; i++) sColumn += colArr[i].ColumnName + " = " + id + " "; } catch (Exception ex) { throw new Exception("Error obteniendo Primary Keys / " + ex.Message); } return sColumn; } //Metodo que devuelve una cadena con la construccion del Where con los primarykeys del objeto private string getWhereID(string id){ DataColumn[] colArr; string sColumn; int ikeys; try { DataSet ds = getDsSchema(); colArr = ds.Tables[0].PrimaryKey; ikeys = colArr.Length; sColumn = " where " ; if(ikeys==0) throw new Exception("Objeto " + _doName + " no tiene definido Primary Key en el ER, imposible continuar"); for(int i = 0; i<ikeys;i++) sColumn += colArr[i].ColumnName + " = '" + id + "'"; } catch(Exception ex) { throw new Exception("Error obteniendo Primary Keys / " + ex.Message ); } return sColumn; } // Devuelve el Schema en formato XML StrinReader del DVO actual private System.IO.StringReader getSchema() { string sXML = this.getDsSchema().GetXmlSchema(); return new System.IO.StringReader(sXML); }
// Generar la Sentencia where correspondiente usando los primary key y sus valores private string getWhere(object aDO) { DataColumn[] colArr; string sWhere = "", sColumn, sAND, sType; DataSet ds; DataRow fila; int ikeys; try { ds = getDsSchema(); fila = ds.Tables[0].NewRow(); getPropiedades(fila,aDO,false); colArr = ds.Tables[0].PrimaryKey; ikeys = colArr.Length; sColumn = ""; sWhere = " where "; if (ikeys == 0) throw new Exception("Objeto " + _doName + " no tiene definido Primary Key en el ER, imposible continuar"); for (int i = 0; i < ikeys; i++) { sAND = (i>0)? " AND ":""; sColumn = colArr[i].ColumnName; sType = colArr[i].DataType.Name.ToString(); if(sType.CompareTo("String")==0||sType.CompareTo("Char")==0) { sWhere += sAND + sColumn + " = '" + fila[sColumn] + "'"; } else {
Pgina 151 de 159
sWhere += + " "; } }
sAND + sColumn + " = " + Convert.ToString(fila[sColumn])
} catch (Exception ex) { throw new Exception("Error obteniendo Primary Keys / " + ex.Message); } return sWhere; } // Objetivo: Actualizar el Dataset en el DataSource private int saveDS(DataSet ds) { string sSQL = "select * from " + this._doName; DbDataAdapter oAdapter; DbCommandBuilder oCBuilder; DbCommand oCommand; int iResult = 0; if (setConnection()) { try { oAdapter = dbFactory.CreateDataAdapter(); oCommand = _oCon.CreateCommand(); oCommand.CommandText = sSQL; oAdapter.SelectCommand = oCommand; oCBuilder = dbFactory.CreateCommandBuilder(); oCBuilder.DataAdapter = oAdapter; iResult = oAdapter.Update(ds); oAdapter.Dispose(); oAdapter = null; } catch (Exception ex) { throw new Exception("Error actualizando objeto " + this._doName + " / " + ex.Message); } } return iResult; }
// Actualizar el Dataset en el DataSource utilizando filtro where por primary Key(Metodo Sobrecargado) private int saveDS( DataSet ds, bool useWhere, object aDO) { string sSQL = "select * from " + this._doName; DbDataAdapter oAdapter; DbCommandBuilder oCBuilder; DbCommand oCommand; int iResult = 0; sSQL = (useWhere)? sSQL + " " + this.getWhere(aDO):sSQL; if (setConnection()) { try { oAdapter = dbFactory.CreateDataAdapter(); oCommand = _oCon.CreateCommand(); oCommand.CommandText = sSQL; oAdapter.SelectCommand = oCommand; oCBuilder = dbFactory.CreateCommandBuilder(); oCBuilder.DataAdapter = oAdapter; iResult = oAdapter.Update(ds); oAdapter.Dispose(); oAdapter = null; } catch (Exception ex) { throw new Exception("Error actualizando objeto " + this._doName + " / " + ex.Message); }
Pgina 152 de 159
} return iResult; } // Obtiene las propiedades de un Domain Object asignandolas a un DataRow a traves de invocaciones dinamicas a los Getter private void getPropiedades(DataRow aRow, object aDO, bool actualizar){ PropertyInfo[] oProperties; string sPropertyName=""; MethodInfo oMetodo; try { oProperties = aDO.GetType().GetProperties(BindingFlags.NonPublic|BindingFlags.Instance|BindingFlags.Static |BindingFlags.Public); foreach(PropertyInfo oProperty in oProperties) { sPropertyName = oProperty.Name.ToString(); oMetodo = oProperty.GetGetMethod(true); if (!(actualizar&&aRow.Table.Columns[sPropertyName].ReadOnly)) { switch (oMetodo.ReturnType.ToString()) { case "System.String": aRow[sPropertyName] = (string)oMetodo.Invoke(aDO, null); break; case "System.DateTime": aRow[sPropertyName] = (DateTime)oMetodo.Invoke(aDO, null); break; case "System.Int16": aRow[sPropertyName] = (Int16)oMetodo.Invoke(aDO, null); break; case "System.Int32": aRow[sPropertyName] = (Int32)oMetodo.Invoke(aDO, null); break; case "System.Int64": aRow[sPropertyName] = (Int64)oMetodo.Invoke(aDO, null); break; case "System.Decimal": aRow[sPropertyName] = (Decimal)oMetodo.Invoke(aDO, null); break; case "System.Double": aRow[sPropertyName] = (Double)oMetodo.Invoke(aDO, null); break; case "System.Boolean": aRow[sPropertyName] = (Boolean)oMetodo.Invoke(aDO, null); break; case "System.Char": aRow[sPropertyName] = (Char)oMetodo.Invoke(aDO, null); break; } } } } catch(Exception ex) { throw new Exception("Error accesando la propiedad " + sPropertyName + " / " + ex.Message); } } // Llenar el Domain Object a partir del DataRow invocando dinamicamente los Setter de cada propiedad private void setPropiedades(DataRow aRow, object aDO) { PropertyInfo[] oProperties; string sPropertyName=""; try { oProperties = aDO.GetType().GetProperties(BindingFlags.NonPublic|BindingFlags.Instance|BindingFlags.Static |BindingFlags.Public); foreach(PropertyInfo oProperty in oProperties) { sPropertyName = oProperty.Name.ToString(); if(aRow.IsNull(sPropertyName)) { oProperty.SetValue(aDO,null,null); } else {
Pgina 153 de 159
switch (oProperty.GetGetMethod(true).ReturnType.ToString()) { case "System.String": oProperty.SetValue(aDO, (string)aRow[sPropertyName], null); break; case "System.DateTime": oProperty.SetValue(aDO, (DateTime)aRow[sPropertyName], null); break; case "System.Int16": oProperty.SetValue(aDO, (Int16)aRow[sPropertyName], null); break; case "System.Int32": oProperty.SetValue(aDO, (Int32)aRow[sPropertyName], null); break; case "System.Int64": oProperty.SetValue(aDO, (Int64)aRow[sPropertyName], null); break; case "System.Decimal": oProperty.SetValue(aDO, (Decimal)aRow[sPropertyName], null); break; case "System.Double": oProperty.SetValue(aDO, (Double)aRow[sPropertyName], null); break; case "System.Boolean": Boolean bValor; if(aRow[sPropertyName].GetType().ToString().CompareTo("System.SByte")==0) { SByte sbValor = (SByte)aRow[sPropertyName]; bValor = (sbValor.ToString().Equals("1"))?true:false; } else if(aRow[sPropertyName].GetType().ToString().CompareTo("System.Byte")==0) { Byte sbValor = (Byte)aRow[sPropertyName]; bValor = (sbValor.ToString().Equals("1"))?true:false; } else if(aRow[sPropertyName].GetType().ToString().CompareTo("System.Int16")==0) { Int16 sbValor = (Int16)aRow[sPropertyName]; bValor = (sbValor.ToString().Equals("1"))?true:false; } else { bValor = (Boolean)aRow[sPropertyName]; } oProperty.SetValue(aDO,bValor,null); break; case "System.Char": oProperty.SetValue(aDO, (string)aRow[sPropertyName], null); break; } } } } catch(Exception ex) { throw new Exception("Error seteando la propiedad " + sPropertyName + " / " + ex.Message); } }
// Metodo cargar para manejo de ID numericos public object cargar(long id) { string sSQL; object aDO; try { sSQL = "select * from " + this._doName + getWhereID(id); aDO = getObject(sSQL); } catch (Exception ex) { throw ex; }
Pgina 154 de 159
return aDO; } // Metodo cargar para manejo de ID string public object cargar(string id) { string sSQL; object aDO; try { sSQL = "select * from " + this._doName + getWhereID(id); aDO = getObject(sSQL); } catch (Exception ex) { throw ex; } return aDO; }
//Metodo privado que devuelve la instancia cargada del objeto a partir de un registro private object getObject(string sSQL) { DataSet miDs; object aDO; try { string spaceName = this.GetType().AssemblyQualifiedName; string objectDAOName = this.GetType().Namespace + "." + this.GetType().Name; string objectName = "Dominio." + this._doName ; spaceName = spaceName.Replace(objectDAOName, objectName); Type tTipo = Type.GetType(spaceName,true,true); aDO = Activator.CreateInstance(tTipo); miDs = this.getDS(sSQL); if (miDs.Tables[0].Rows.Count > 0) setPropiedades(miDs.Tables[0].Rows[0], aDO); else throw new Exception("Problemas con el objeto " + this._doName ); } catch (Exception ex) { throw new Exception("Error en objeto " + this.GetType().Name + " / " + ex.Message); } finally { miDs = null; } return aDO; }
//Metodo que verifica si una instancia de una clase ya ha sido persistida public Boolean existe(object aDO) { long iResult = 0; string sSQL; try { sSQL = "select count(*) from " + _doName + " " + getWhere(aDO); iResult = getVal(sSQL); } catch (Exception ex) { throw ex; } return (iResult > 0) ? true : false; }
Pgina 155 de 159
// Ejecutar un SQL protected bool execSQL(string sSQL) { DbCommand oCommand; if(setConnection()) { oCommand = dbFactory.CreateCommand(); try { oCommand.CommandText = sSQL; oCommand.Connection = this._oCon ; oCommand.ExecuteNonQuery(); } catch(Exception ex) { throw ex; }finally { oCommand.Dispose(); oCommand = null; } } else return false; return true; }
// Obtener un valor numerico escalar protected long getVal(string sSQL) { DbCommand oCommand; long iresult = 0; if(setConnection()) { oCommand = dbFactory.CreateCommand(); try { oCommand.CommandText = sSQL; oCommand.Connection = this._oCon ; iresult = Convert.ToInt64(oCommand.ExecuteScalar()); } catch(Exception ex) { throw ex; }finally { oCommand.Dispose(); oCommand = null; } } ; return iresult; } // Obtener un valor String escalar protected string getStrVal(string sSQL) { DbCommand oCommand; string sResult ; if (setConnection()) { oCommand = dbFactory.CreateCommand(); try { oCommand.CommandText = sSQL; oCommand.Connection = this._oCon; sResult = Convert.ToString(oCommand.ExecuteScalar()); } catch (Exception ex) { throw ex; } finally { oCommand.Dispose(); oCommand = null; } } else return null; return sResult; } // Obtener un valor decimal protected decimal getDecimalVal(string sSQL) { DbCommand oCommand;
Pgina 156 de 159
decimal dResult = new decimal(); if (setConnection()) { oCommand = dbFactory.CreateCommand(); try { oCommand.CommandText = sSQL; oCommand.Connection = this._oCon; dResult = Convert.ToDecimal(oCommand.ExecuteScalar()); } catch (Exception ex) { throw ex; } finally { oCommand.Dispose(); oCommand = null; } } return dResult; } // Obtener un valor de tipo DateTime protected DateTime getDatetimeVal(string sSQL) { DbCommand oCommand; DateTime dResult = new DateTime(); if (setConnection()) { oCommand = dbFactory.CreateCommand(); try { oCommand.CommandText = sSQL; oCommand.Connection = this._oCon; dResult = Convert.ToDateTime(oCommand.ExecuteScalar()); } catch (Exception ex) { throw ex; } finally { oCommand.Dispose(); oCommand = null; } } return dResult; } // Metodo publico encargado de salvar el Domain Object en el Datasource public long add(object aDO) { try { DataSet oDS = new DataSet() ; oDS.ReadXmlSchema(getSchema()); DataRow oRow = oDS.Tables[0].NewRow(); getPropiedades(oRow,aDO,false); oDS.Tables[0].Rows.Add(oRow); saveDS(oDS); } catch (Exception ex) { throw new Exception("Error Insertando objeto " + ex.Message); } return getID(); } public virtual long getID() { return 0; }
this._doName + " / " +
Pgina 157 de 159
//Metodo publico encargado de actualizar el Domain Object en el Datasource public bool update(object aDO) { try { string sSQL = "select * from " + this._doName + " " + this.getWhere(aDO); DataSet oDS, fDS; fDS = new DataSet(); fDS.ReadXmlSchema(getSchema()); oDS = getDS(sSQL); DataRow oRow = oDS.Tables[0].Rows[0]; DataRow fRow = fDS.Tables[0].NewRow(); foreach(DataColumn oColumn in oDS.Tables[0].Columns) { fRow[oColumn.ColumnName.ToString()] = oRow[oColumn.ColumnName.ToString()]; } fDS.Tables[0].Rows.Add(fRow); fDS.AcceptChanges(); getPropiedades(fRow, aDO,true); saveDS(fDS,true,aDO); } catch(Exception ex) { throw new Exception("Error actualizando objeto " + this._doName + " / " + ex.Message); } return true; } // Metodo publico encargado de eliminar el objeto en el Datasource public bool delete(object aDO) { try { string sSQL = "delete from " + this._doName + " " + getWhere(aDO); execSQL(sSQL); } catch(Exception ex) { throw new Exception("Error eliminando objeto " + this._doName + " / " + ex.Message); } return true; } // Metodo publico encargado de eliminar el objeto en el Datasource a partir de un Id string public bool deleteById(string id ) { try { string sSQL = "delete from " + this._doName + " " + getWhereID(id); execSQL(sSQL); } catch (Exception ex) { throw new Exception("Error eliminando objeto " + this._doName + " / " + ex.Message); } return true; } // Metodo publico encargado de eliminar el objeto a partir de un Id numerico public bool deleteById(long id) { try { string sSQL = "delete from " + this._doName + " " + getWhereID(id); execSQL(sSQL); } catch (Exception ex) { throw new Exception("Error eliminando objeto " + this._doName + " / " + ex.Message); } return true; }
Pgina 158 de 159
//Metodo publico que devuelve un Dataset con todos los registros de una tabla filtrados por el Where enviado public DataSet getDSWhere(string sWhere) { try { if(setConnection()) return getDS("select * from " + this._doName + " where " + sWhere); return null; } catch (Exception ex) { throw new Exception("Imposible Obtener Datos de Objeto " + this._doName + " filtrando por" + sWhere + " / " + ex.Message); } } //Devuelve un Dataset con todos los registros de una tabla public DataSet getDSAllRecords() { try { if (setConnection()) return getDS("select * from " + this._doName ); return null; } catch (Exception ex) { throw new Exception("Imposible Obtener Datos de Objeto " + this._doName " / " + ex.Message); } }
//Metodo Privado que libera la conexion private bool releaseConnection() { try { if (_oCon != null) _oCon.Close(); } catch (Exception ex) { throw new Exception("Error intentando liberar conexin / " + ex.Message); } return true; } //Metodo publico para liberar recursos y es invocado por el usuario public void Dispose() { Dispose(true); GC.SuppressFinalize(this); } //Metodo protegido que implementa el dispose de los recursos protected virtual void Dispose(bool disposing) { if (!disposed) { if (disposing) { releaseConnection(); } disposed = true; } } //Destructor del objeto que sera llamado por el Garbage Colector e invocara el metodo Dispose ~DAOMaster() { Dispose(false); } } }
Pgina 159 de 159

Tesis Persistencia Maestria

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Tesis Persistencia Maestria

Diunggah oleh

Hak Cipta:

Format Tersedia

UNIVERSIDAD FRANCISCO GAVIDIA

Desarrollo de un Motor de Persistencia para la Plataforma Microsoft .Net

MASTER EN INFORMATICA APLICADA A REDES

DICIEMBRE 2006 SAN SALVADOR EL SALVADOR CENTROAMERICA

Maestra en Informtica Aplicada a Redes

JUSTIFICACIN DEL TEMA............................................................................................................. 9

SOLUCIN PROPUESTA ............................................................................................................. 90

Maestra en Informtica Aplicada a Redes

RESULTADOS Y VERIFICACION EXPERIMENTAL ............................................................... 120

CONCLUSIONES Y FUTURAS LINEAS DE INVESTIGACION .......................................... 142

Maestra en Informtica Aplicada a Redes

Maestra en Informtica Aplicada a Redes

Maestra en Informtica Aplicada a Redes

Maestra en Informtica Aplicada a Redes

A quien esta dirigido este documento.

Maestra en Informtica Aplicada a Redes

propuesta aqu planteada, repasar

una serie de conocimientos, tcnicas y principios

Organizacin del Documento.

Maestra en Informtica Aplicada a Redes

II. Justificacin del Tema

Maestra en Informtica Aplicada a Redes

Esta situacin origino el estudio, documentacin, estandarizacin

Para mayor informacin sobre CMM remitirse a la seccin 3.5.1

Maestra en Informtica Aplicada a Redes

Motores de Persistencia y el Framework .Net

Maestra en Informtica Aplicada a Redes

El porque de la creacin de un motor de persistencia para .Net.

Maestra en Informtica Aplicada a Redes

III. FUNDAMENTOS TEORICOS

Programacin Orientada a Objetos

3.1.1 Historia y Evolucin.

Maestra en Informtica Aplicada a Redes

Maestra en Informtica Aplicada a Redes

3.1.3 Caractersticas de los Objetos

Maestra en Informtica Aplicada a Redes

Maestra en Informtica Aplicada a Redes

Encapsulacin y ocultacin de datos

Maestra en Informtica Aplicada a Redes

Maestra en Informtica Aplicada a Redes

Maestra en Informtica Aplicada a Redes

Maestra en Informtica Aplicada a Redes

Maestra en Informtica Aplicada a Redes

Maestra en Informtica Aplicada a Redes

3.2.2 Conceptos Clave

3.2.3 Tipos de Patrones

patrones de creacin. patrones estructurales. patrones de comportamiento

Maestra en Informtica Aplicada a Redes

Maestra en Informtica Aplicada a Redes

3.2.4 Patrones de Acceso a Datos

Maestra en Informtica Aplicada a Redes

Maestra en Informtica Aplicada a Redes

3.2.5 El patrn Singleton

Maestra en Informtica Aplicada a Redes

3.2.6 El Patrn Factory

Maestra en Informtica Aplicada a Redes

Maestra en Informtica Aplicada a Redes

Maestra en Informtica Aplicada a Redes

Maestra en Informtica Aplicada a Redes

3.2.7 El Patrn Abstract Factory

Maestra en Informtica Aplicada a Redes

Maestra en Informtica Aplicada a Redes

3.2.8 El Patron Data Accessors