Está en la página 1de 82

Maestra en Informtica Aplicada a Redes

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

Pgina 15 de 190
Maestra en Informtica Aplicada a Redes

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

Pgina 16 de 190
Maestra en Informtica Aplicada a Redes

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

Pgina 17 de 190
Maestra en Informtica Aplicada a Redes

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.1.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 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.1.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.1.3 Clasificacin
Con la clasificacin comienza la verdadera programacin orientada a objetos. Ellos
nos obliga a una abstraccin del concepto de objeto denominada clase.

Pgina 18 de 190
Maestra en Informtica Aplicada a Redes

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.

3.1.1.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.

Pgina 19 de 190
Maestra en Informtica Aplicada a Redes

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.

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

Pgina 20 de 190
Maestra en Informtica Aplicada a Redes

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.1.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.

3.1.1.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.

Pgina 21 de 190
Maestra en Informtica Aplicada a Redes

3.1.1.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.1.8 Herencia

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.

Pgina 22 de 190
Maestra en Informtica Aplicada a Redes

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.1.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

Pgina 23 de 190
Maestra en Informtica Aplicada a Redes

las propiedades esenciales de un objeto, fuerza al 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.

Pgina 24 de 190
Maestra en Informtica Aplicada a Redes

Describe el contexto en que ocurre.


Describe los pasos a seguir.
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
Object-Oriented 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.

Pgina 25 de 190
Maestra en Informtica Aplicada a Redes

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

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.

Pgina 26 de 190
Maestra en Informtica Aplicada a Redes

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

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

Pgina 27 de 190
Maestra en Informtica Aplicada a Redes

3.2.3.2 Patrones Estructurales

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).

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

Pgina 28 de 190
Maestra en Informtica Aplicada a Redes

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:

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

Pgina 29 de 190
Maestra en Informtica Aplicada a Redes

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

Pgina 30 de 190
Maestra en Informtica Aplicada a Redes

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.

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

Pgina 31 de 190
Maestra en Informtica Aplicada a Redes

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

Pgina 32 de 190
Maestra en Informtica Aplicada a Redes

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.

Usando la organizacin de la figura anterior, un objeto Application llama al mtodo

Pgina 33 de 190
Maestra en Informtica Aplicada a Redes

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.

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

Pgina 34 de 190
Maestra en Informtica Aplicada a Redes

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.

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

Pgina 35 de 190
Maestra en Informtica Aplicada a Redes

diferentes, pero relacionados entre s. La siguiente figura muestra el diagrama


general de este patrn.

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

Pgina 36 de 190
Maestra en Informtica Aplicada a Redes

conocimiento directo de estas clases de fbrica concretas. En lugar de esto, accesan


instancias de estas clases como instancias de la superclase fbrica abstracta.
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:

Pgina 37 de 190
Maestra en Informtica Aplicada a Redes

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.

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.

Pgina 38 de 190
Maestra en Informtica Aplicada a Redes

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.

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:

Pgina 39 de 190
Maestra en Informtica Aplicada a Redes

La siguiente figura muestra el diagrama de secuencia de la interaccin entre los


distintos participantes en este patrn:

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

Pgina 40 de 190
Maestra en Informtica Aplicada a Redes

(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-a-relacional 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.

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

Pgina 41 de 190
Maestra en Informtica Aplicada a Redes

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

Pgina 42 de 190
Maestra en Informtica Aplicada a Redes

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,
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 43 de 190
Maestra en Informtica Aplicada a Redes

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.

Pgina 44 de 190
Maestra en Informtica Aplicada a Redes

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

Pgina 45 de 190
Maestra en Informtica Aplicada a Redes

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.

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

Pgina 46 de 190
Maestra en Informtica Aplicada a Redes

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:

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.

Pgina 47 de 190
Maestra en Informtica Aplicada a Redes

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

Pgina 48 de 190
Maestra en Informtica Aplicada a Redes

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.

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 todoparte 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.

Pgina 49 de 190
Maestra en Informtica Aplicada a Redes

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

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

Pgina 50 de 190
Maestra en Informtica Aplicada a Redes

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.

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

Pgina 51 de 190
Maestra en Informtica Aplicada a Redes

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.

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

Pgina 52 de 190
Maestra en Informtica Aplicada a Redes

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 coleccin de tipo set<Departamento>. Cuando se
utiliza una extensin como punto de entrada es necesario utilizar una variable

Pgina 53 de 190
Maestra en Informtica Aplicada a Redes

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 SELECT DISTINCT el
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.

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).

Pgina 54 de 190
Maestra en Informtica Aplicada a Redes

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).

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)

Pgina 55 de 190
Maestra en Informtica Aplicada a Redes

Tabla 1: Una comparacin de sistemas de Administracin de Base de Datos


Criterio RDBMS ODBMS ORDBMS
Standard para SQL2 ODMG-2.0 SQL3 (in proceso)
definir
Apoyo de No lo apoya; Es apoyo extensivo apoyo limitado;
caractersticas difcil mapear un mayormente con
orientadas- programa entre el datatypes
objetos objeto y la base de
datos
Uso Fcil de usar Bueno para Fcil de usar
programadores; excepto por
Algn acceso de algunas
SQL para usuarios extensiones
finales
Apoyo para No apoya Apoya una gran Apoya datatypes
relaciones datatypes variedad de abstractos y
complejas abstractos datatypes e inter- relaciones
relaciones de complejas
datos complejos
Desempeo Buen desempeo Relativamente Se espera que el
menor desempeo desempeo sea
mejor
Madurez del Relativamente Este concepto Todava est en el
producto viejo y muy tiene un par de proceso de
maduro aos y es desarrollo
relativamente
maduro
El uso de SQL Apoyo extensivo OQL es similar a SQL3 est siendo
de SQL SQL, pero con desarrollado con
caractersticas caractersticas OO

Pgina 56 de 190
Maestra en Informtica Aplicada a Redes

adicionales como incorporadas


Objetos complejos
y caractersticas
orientadas a
objetos
Ventajas Su dependencia Puede manejar Habilidad de
de SQL, y su todo tipo de consultas para
optimizacin de aplicaciones aplicaciones
consultas es complejas, puede complejas y la
relativamente reutilizar el cdigo habilidad a
sencilla manejar
aplicaciones
grandes y
complejas
Desventajas Inhabilidad de Desempeo pobre Desempeo pobre
manejar por la optimizacin en aplicaciones
aplicaciones de consultas web.
complejas complejas, la
inhabilidad de
soportar sistemas
de gran escala
Tiene apoyo de Tiene un extenso En el presente, Tiene un buen
los vendedores mercado y muchos falta apoyo de los futuro. Parece que
vendedores vendedores por el todo los
tamao del vendedores de
mercado de RDBMS quieren
RDBMS este producto

En el artculo "Object-Relational DBMS: The Next Wave," del Dr. Michael

Pgina 57 de 190
Maestra en Informtica Aplicada a Redes

Stonebraker, gerente de Tecnologa de la Informix Software, ha clasificado cuatro


tipos de aplicaciones de DBMS:

Tabla 2: Categoras de DBMSs

File Systems RDBMSs OODBMSs ORDBMSs

Datos simples sin Datos simples con Datos complejos sin Datos complejos
queries queries queries con 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).

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

Pgina 58 de 190
Maestra en Informtica Aplicada a Redes

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.

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.

Pgina 59 de 190
Maestra en Informtica Aplicada a Redes

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.
Por otra parte, se puede usar una base de datos relacional, aprovechando su
madurez y su estandarizacin as como las herramientas relacionales que
existen para ella.

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.

Pgina 60 de 190
Maestra en Informtica Aplicada a Redes

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 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,

Pgina 61 de 190
Maestra en Informtica Aplicada a Redes

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 Capability Maturity Model - 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
Carnegie-Mellon. "CMM" es una marca registrada del SEI

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.

Pgina 62 de 190
Maestra en Informtica Aplicada a Redes

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.
2 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

Pgina 63 de 190
Maestra en Informtica Aplicada a Redes

ms avanzado de mtricas en los procesos. Se implementan tcnicas de revisin


por pares (peer reviews).
3 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.
4 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 64 de 190
Maestra en Informtica Aplicada a Redes

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

Pgina 65 de 190
Maestra en Informtica Aplicada a Redes

mundial: SW-CMM y 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 cada
organizacin, ya que los programas de mejora deben estar basados en la misin y
los 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

Pgina 66 de 190
Maestra en Informtica Aplicada a Redes

EE.UU. que subcontratan empresas para el desarrollo de sus sistemas de software y


por lo mismo la industria de desarrollo de
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.

Pgina 67 de 190
Maestra en Informtica Aplicada a Redes

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 SW-CMM, 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 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.

Pgina 68 de 190
Maestra en Informtica Aplicada a Redes

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

Pgina 69 de 190
Maestra en Informtica Aplicada a Redes

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 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 y cuestan millones de dlares). CMMI
se basa en prcticas de organizaciones grandes, y est enfocado para
organizaciones del departamento de defensa o
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.

Pgina 70 de 190
Maestra en Informtica Aplicada a Redes

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

Pgina 71 de 190
Maestra en Informtica Aplicada a Redes

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

Pgina 72 de 190
Maestra en Informtica Aplicada a Redes

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).

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

Pgina 73 de 190
Maestra en Informtica Aplicada a Redes

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

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,

Pgina 74 de 190
Maestra en Informtica Aplicada a Redes

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

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

Pgina 75 de 190
Maestra en Informtica Aplicada a Redes

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.

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.

Pgina 76 de 190
Maestra en Informtica Aplicada a Redes

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.
.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)

Pgina 77 de 190
Maestra en Informtica Aplicada a Redes

.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,

Pgina 78 de 190
Maestra en Informtica Aplicada a Redes

etc.) y 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

Pgina 79 de 190
Maestra en Informtica Aplicada a Redes

referencia, ejemplos 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 80 de 190
Maestra en Informtica Aplicada a Redes

Dnde instalar el .NET Framework?

Cliente Servidor
Aplicacin de
Escritorio
 *
Aplicacin Web

Aplicacin de
Consola
 *
Aplicacin .NET Compact Framework
Mvil

* 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 81 de 190
Maestra en Informtica Aplicada a Redes

Cronologa de .NET

Visual Studio 6.0


Visual Basic
VBA
Visual FoxPro
VBScript Visual Studio .NET 2003 Visual Studio Orcas
C++ .NET Framework 1.1 .NET Framework Orcas
.NET Compact Framework .NET Compact Framework Orcas
J++
JScript J#
ASP

2000 2001 2002 2003 2004 2005 2006 y ms

Visual Studio .NET 2002 Visual Studio 2005 (Whidbey)


.NET Framework 1.0 .NET Framework 2.0 (Whidbey)
Visual Basic .NET .NET Compact Framework 2.0 (Whidbey)
C#

3.7.2 Arquitectura

Arquitectura del .NET Framework

VB C++ C# J#
Common Language Specification
Class Library
.NET Framework
.NET Framework
.NET Framework SDK

ASP.NET Windows
Redistributable

Forms
ADO.NET y XML
Base Class Library
Common Language Runtime

Windows COM+ Services

Pgina 82 de 190
Maestra en Informtica Aplicada a Redes

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

Pgina 83 de 190
Maestra en Informtica Aplicada a Redes

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

Pgina 84 de 190
Maestra en Informtica Aplicada a Redes

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.


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:

Pgina 85 de 190
Maestra en Informtica Aplicada a Redes

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.

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

Pgina 86 de 190
Maestra en Informtica Aplicada a Redes

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


co-patrocinaron el proceso (Intel, HP, IBM y Fujitsu entre otras), el estndar ECMA-
335 que 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.

Pgina 87 de 190
Maestra en Informtica Aplicada a Redes

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.

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.

Pgina 88 de 190
Maestra en Informtica Aplicada a Redes

Modelo de Ejecucin del CLR

Cdigo
Fuente VB.NET C# C++.NET

Compilador Compilador Compilador Componente


VB.NET C# C++ .NET No Manejado

Cdigo Assembly Assembly Assembly


Manejado Cdigo MSIL Cdigo MSIL 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

Pgina 89 de 190
Maestra en Informtica Aplicada a Redes

los recursos del sistema operativo a muy bajo nivel para lograr un rendimiento ptimo
y mayor performance.

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 SqlClient

OracleClient OleDb

Odbc SqlTypes

System.Xml
XSLT Serialization

XPath Schema

Pgina 90 de 190
Maestra en Informtica Aplicada a Redes

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, 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

Pgina 91 de 190
Maestra en Informtica Aplicada a Redes

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.

ADO.NET- Clases ms comunes

Maneja la coneccin a una base de


Base de Datos datos

Ejecuta comandos contra una base


de datos
XxxConnection
Intercambia datos entre un dataset
y una base de datos
XxxCommand
Copia local de datos relacionales

XxxDataAdapter Provee acceso a datos


read-only, Forward-only
DataSet XxxDataReader

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.

Pgina 92 de 190
Maestra en Informtica Aplicada a Redes

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.

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:

Pgina 93 de 190
Maestra en Informtica Aplicada a Redes

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

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 94 de 190
Maestra en Informtica Aplicada a Redes

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.

Pgina 95 de 190
Maestra en Informtica Aplicada a Redes

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.

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 96 de 190