Programacion o.o.

Maestría en Informática Aplicada a Redes
Página 15 de 190
III. FUNDAMENTOS TEORICOS
Los fundamentos teóricos plasmados en esta sección describen aquellas técnicas y
disciplinas que están estrechamente relacionadas al tema de los Motores de
Persistencia, iniciando desde la programación orientada a objetos y los patrones de
diseño, pasando al tema de Bases de Datos Orientadas a Objetos, generalidades
sobre los motores de persistencia e introduciendo al tema de Metodologías Iterativas
de Desarrollo de Software donde se habla del CMMI, el RUP y el MSF. Finalmente
se termina el capitulo describiendo algunas características de la plataforma sobre la
cuales se implementan los conceptos antes descritos, es decir la plataforma del
Microsoft .Net Framework.
Esta información 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 Programación Orientada a Objetos
3.1.1 Historia y Evolución.
El modelo orientado a objetos es el modelo teórico que usan la mayoría de los
programas actuales. La programación orientada a objetos comienza en los años
sesenta (en los que aparecieron los primeros lenguajes de este tipo, llamados
“Simula I” y “Simula 67”, desarrollados en el Centro Noruego de Computación, en
Oslo). En los primeros 70, aparece “Smalltalk”, un lenguaje fundamental en la historia
de la orientación a objetos.
Sin embargo, es hasta la segunda mitad de los años 80 que la orientación de objetos
se generaliza, convirtiéndose en el estándar predominante en los años 90, con
lenguajes tales como C++ y Java. Su éxito ha sido impulsado por la difusión de otras
tecnologías (como la interfaz gráfica o las arquitecturas distribuidas) que son más

Página 16 de 190
fáciles de implementar mediante este tipo de desarrollo que mediante una
programación tradicional.
En la actualidad, la práctica totalidad de los lenguajes de programación que surgen
son orientados a objetos y esta tecnología se ha convertido en el estándar actual de
programación que, a su vez, está generando nuevos desarrollos muy prometedores
para el futuro como, por ejemplo, la programación orientada a aspectos.
La idea de la orientación a objetos es modelar los programas de una forma parecida
a cómo percibimos la realidad. Para la mente humana, el universo está compuesto
por una serie de “objetos” (en el sentido más amplio de la palabra, incluyendo seres
vivos, ideas, etc.). Cada objeto tiene unas características que lo diferencian de los
demás y, con cada objeto, se pueden realizar unas acciones que son propias y
específicas del mismo. Así, por ejemplo, un determinado auto tiene unas
características (color rojo, caja de cambios automática, diesel, etc.) y puede realizar
unas determinadas acciones (acelerar, frenar, etc.).
La programación 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
características (llamadas “atributos”) y una serie de acciones (llamadas “métodos”),
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 modificación 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 programación estructurada.
En esta forma de diseño 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 información.

Página 17 de 190
3.1.2 Ventajas de la OO
La OO proporciona las siguientes ventajas sobre otros lenguajes de programación
• Uniformidad. Ya que la representación de los objetos lleva implica tanto el
análisis como el diseño y la codificación de los mismos.
• Comprensión. Tanto los datos que componen los objetos, como los
procedimientos que los manipulan, están agrupados en clases, que se
corresponden con las estructuras de información 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 automáticamente 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 noción de objeto permite que programas que traten las
mismas estructuras de información 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 combinación de objetos ya definidos donde estos están
relacionados de una manera particular.
Uno de los puntos clave a remarcar es que la programación orientada a objetos no
sustituye a ninguna metodología ni lenguaje de programación anterior. Todos los
programas que se realizan según OOD se pueden realizar igualmente mediante
programación estructurada. Su uso en la actualidad se justifica porque el desarrollo

Página 18 de 190
de todas las nuevas herramientas basadas en un interfase de usuario gráfico como
Windows, OS/2, x-Windows, etc. Es mucho más sencillo
3.1.3 Características 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,
recién fabricados son distintos los unos de los otros.
La afirmación anterior, aunque parece obvia, tiene importancia cuando descendemos
al nivel de programación. 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 Abstracción
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 cómo se implementan estas características. Los procesos, las
funciones o los métodos pueden también ser abstraídos y cuando lo están, una
variedad de técnicas son requeridas para ampliar una abstracción
3.1.1.3 Clasificación
Con la clasificación comienza la verdadera programación orientada a objetos. Ellos
nos obliga a una abstracción del concepto de objeto denominada clase.

Página 19 de 190
Las clases permiten la agrupación de objetos que comparten las mismas
propiedades y comportamiento.
El esfuerzo del programador ante una aplicación orientada a objetos se centra en la
identificación de las clases, sus atributos y operaciones asociadas y que son estas
realmente las que modelan la realidad de la aplicación a construir.
Las propiedades de cada clase deben cumplir una serie de premisas
• Las propiedades deber ser significativas dentro del entorno de la aplicación es
decir, deben servir para identificar claramente y de una manera única (y
univoca) a cada uno de los objetos
• El número de propiedades de un objeto debe ser el mínimo para realizar todas
las operaciones que requiera la aplicación.
3.1.1.4 Encapsulación y ocultación de datos
La capacidad de presentación de información dentro de un objeto se divide en dos
partes bien diferenciadas:
• Interna: La información que necesita el objeto para operar y que es
innecesaria para los demás objetos de la aplicación. Estos atributos se
denominada privados y tienen como marco de aplicación ú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 públicas y corresponde a la
información que necesitan conocer los restantes objetos de la aplicación
respecto del objeto definido para poder operar.

Página 20 de 190
Podemos imaginarla encapsulación como introducir el objeto dentro de una caja
negra donde existen dos ranuras denominadas entrada y salida. Si introducimos
datos por la entrada automáticamente obtendrá un resultado en la salida. No
necesita conocer ningún detalle del funcionamiento interno de la caja.
El término encapsulación indica la capacidad que tienen los objetos de construir una
cápsula a su alrededor, ocultando la información que contienen (aquélla que es
necesaria para su funcionamiento interno, pero innecesaria para los demás objetos)
a las otras clases que componen la aplicación.
Aunque a primera vista la encapsulación 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 encapsulación
estas variables ocuparían memoria y podrían interferir en el funcionamiento del resto
de los objetos.
La encapsulación no es exclusiva de los lenguajes de programación 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 también las estructuras
de datos que sirven como base a las funciones. Aportan por tanto un nivel superior
en cuanto a protección de información.
La encapsulación nos permite el uso de librerías de objetos para el desarrollo de
nuestros programas. Recordemos que las librerías son definiciones de objetos de
propósito 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 fácil utilizarlo en los
mas variados tipos de aplicaciones. Si aseguramos , depurando las propiedades y

Página 21 de 190
las operaciones dentro de la clase que el objeto función bien dentro de una
aplicación, con una correcta encapsulación el objeto podrá funcionar en cualquier
otra.
Otra de las ventajas de la encapsulación, 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 encapsulación está en el núcleo de dos grandes pilares de la construcción de
sistemas; mantenibilidad y reusabilidad
3.1.1.5 Mantenibilidad
Cualidad que indica que un programa o sistema debe ser fácilmente modificable. Es
decir que los cambios en las condiciones externas (como la definición de una nueva
variable) implicarán modificaciones pequeñas 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 confección de otros programas. Ello implica que los objetos
definidos en un programa pueden ser extraídos del mismo e implantados en otro sin
tener que realizar modificaciones importantes en el código del objeto.

Página 22 de 190
3.1.1.7 Poliformismo
El polimorfismo es una nueva característica aportada por la OOP. Esta propiedad
indica la posibilidad de definir varias operaciones con el mismo nombre,
diferenciándolas únicamente en los parámetros de entrada. Dependiendo del objeto
que se introduzca como parámetro de entrada, se elegirá automáticamente cual de
las operaciones se va a realizar.
Ya está habituado al operador <<suma>> que está presente en todos los lenguajes
de programación. Sin embargo, los operadores <<suma de fracciones>> y <<suma
de números complejos>> no existen en casi ningún lenguaje de programación.
Los lenguajes OOP permiten definir un operador <<suma>> tal que reconozca que
tipo de objeto se le está aplicando, a través de operaciones de objetos. Previamente
deberá definir la fracción y el número complejo como una clase y la operación suma
como una operación de una clase.
Definiendo adecuadamente las operaciones suma de fracciones y suma de números
imaginarios, el operador suma devolverá, en el caso que los operandos sean
fracciones, una fracción y , en el caso de los números imaginarios, otros número
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
propagación de los atributos y las operaciones a través de distintas sub-clases
definidas a partir de una clase común.

Página 23 de 190
Introduce, por tanto, una posibilidad de refinamiento sucesivo del concepto de clase.
Nos permite definir una clase principal y , a través de sucesivas aproximaciones,
cualquier característica 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 jerárquicas de clases donde es posible la
creación de sub-clases que incluyan nuevas propiedades y atributos. Estas sub-
clases admiten la definición de nuevos atributos, así como crear, modificar o
inhabilitar propiedades.
Posibles modelos.
Además, es posible que una sub-clase herede atributos y propiedades de más de
una clase. Este proceso se denomina herencia múltiple
La herencia es, sin duda alguna, una de las propiedades más importantes de la
OOP, ya que permite, a través de la definición de una clase básica, ir añadiendo
propiedades a medida que sean necesarias y, además, en el sub-conjunto de objetos
que sea preciso.
La herencia permite que los objetos puedan compartir datos y comportamientos a
través de las diferentes sub-clases, sin incurrir en redundancia. Más importante que
el ahorro de código, es la claridad que aporta al identificar que las distintas
operaciones sobre los objetos son en realidad una misma cosa.
3.1.1.9 Conclusión.
Identidad, clasificación, polimorfismo y herencia caracterizan a los lenguajes
orientados a objetos. Cada uno de estos conceptos puede utilizarse aisladamente,
incluso aparecen en otras metodologías de programación, pero juntos se
complementan en una relación sinérgica. Los beneficios de la programación
orientada a objetos son más que los que pueden verse a simple vista. El énfasis en

Página 24 de 190
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 más preciso, general y robusto que si pusiéramos el énfasis
en los procedimientos y los datos por separado.
3.2 Patrones de Diseño
Un patrón de diseño es una solución a un problema de diseño no trivial que es
efectiva (ya se resolvió el problema satisfactoriamente en ocasiones anteriores) y
reusable (se puede aplicar a diferentes problemas de diseño en distintas
circunstancias).
Los patrones son soluciones de sentido común que deberían formar parte del
conocimiento de un diseñador experto. Además facilitan la comunicación entre
diseñadores, pues establecen un marco de referencia (terminología, justificación).
Los patrones son una manera de resolver problemas del desarrollo del software, fruto
de la experiencia acumulada de muchos desarrolladores. Esto garantiza que el
patrón no es simplemente una abstracción teórica, 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 solución del problema especifico.
En la programación orientada a objetos resulta complicado descomponer el sistema
en objetos (encapsulación, granularidad, dependencias, flexibilidad, reusabilidad,
etc.), los patrones de diseño nos permitirán identificar a los objetos apropiados de
una manera mucho más sencilla. También nos permitirán determinar la granularidad
de los objetos.
Los patrones permiten
• Ante un problema reiterado ofrece una solución contrastada que lo
resuelve.
• Describe el problema en forma sencilla.

Página 25 de 190
• Describe el contexto en que ocurre.
• Describe los pasos a seguir.
• Describe los puntos fuertes y débiles de la solución.
• Describe otros patrones asociados
En general un patrón tiene cuatro elementos fundamentales:
• El Nombre del Patrón, 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 patrón. Explica el problema y su
contexto. Puede exponer problemas específicos de diseño tales como
representar algoritmos como objetos. En algunas ocasiones se incluyen
también listas de condiciones que deben de ser conocidas antes de decidir
aplicar este diseño
• La solución, describe los elementos que componen el diseño, sus relaciones,
responsabilidades y colaboración. La solución no describe un diseño concreto
particular o su implementación, esto es debido a que un patrón es mas como
una plantilla que puede ser aplicada en muchas situaciones. En ves de eso, el
patrón provee una descripción abstracta del diseño de un problema
• Las consecuencias, estas son el resultado de la aplicación del patrón. Las
consecuencias, son elementos críticos al momento de evaluar las alternativas
de diseño
3.2.1 Historia
El reciente interés del mundo del software por los patrones tiene su origen, a partir de
1995, tras la aparición 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 diseñadores de software
orientado a objetos, y al hacerlos públicos.

Página 26 de 190
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 difícil hablar de patrones de diseño, sin retomar dos términos que son un
objetivo permanente del diseño orientado a objetos, como son la cohesión y el
acoplamiento.
Podríamos definir la cohesión de una clase (o de un paquete, etc.) como la relación
entre los distintos elementos de la clase, normalmente sus métodos. Es decir, que
todos los elementos de una clase tienen que trabajar en la misma dirección, es decir,
hacia un mismo fin. Por ejemplo, una clase "Coche" debería ocuparse de cosas
relacionadas con el coche en si, como acelerar y frenar, pero no de cosas ajenas a él
como manipular información referente a su seguro. La cohesión es una medida
relativa, en el sentido de que depende de lo que cada uno piense que es la función
de la clase, pero lo importante es mantener una cohesión lo mas alta posible. Existen
diferentes tipos de cohesión (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
programación orientada a objetos. También existen diversos tipos de acoplamiento
(funcional, de datos, etc.), lo que nos lleva a la conclusión que para tener un diseño
correcto, fácil de mantener y modular, cuanto más bajo acoplamiento haya entre las
clases (o paquetes), pues mejor.

Página 27 de 190
3.2.3 Tipos de Patrones
La banda de los cuatro (GoF) definió tres tipos distintos de patrones fundamentales:
• patrones de creación.
• patrones estructurales.
• patrones de comportamiento
3.2.3.1 Patrones Creacionales
Los patrones de creación son las soluciones aceptadas como "buenas" a los
problemas de creación 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 difícil
de mantener.
Además, en muchos casos, puede ocurrir que el objeto concreto que necesitemos en
un momento concreto dependa del estado de nuestra aplicación en tiempo de
ejecución. Por ejemplo, puede ocurrir que en un momento tengamos que dibujar un
círculo o un cuadrado, pero no por ello tenemos que llenar nuestro software de
sentencias if. El crear clases especiales que abstraen el proceso de creación de
instancias hace que nuestro software sea más flexible y general.
Ejemplos de estos patrones son:
• Patrón Factoría
• Patrón Factoría Abstracta
• Patrón Singleton (Instancia Única)
• Patrón Prototipo

Página 28 de 190
3.2.3.2 Patrones Estructurales
Los patrones estructurales se ocupan de la combinación 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 composición).
Destacan entre este tipo de patrones, el patrón adaptador (adapter pattern, GoF), el
patrón fachada (facade pattern, GoF), el patrón proxy (proxy pattern, GoF) y el patrón
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 dimensión temporal
Entre este tipo de patrones, tenemos:
• Patrón Cadena de Responsabilidad
• Patrón Comando
• Patrón Intérprete
• Patrón Iterador
• Patrón Mediador
• Patrón Recuerdo (Memento)
• Patrón Observador
• Patrón Estado
• Patrón Estrategia
• Patrón Plantilla
• Patrón Visitante

Página 29 de 190
3.2.4 Patrones de Acceso a Datos
Asi como los patrones de diseño, 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 abstracción común a problemas a soluciones que
pueden ser aplicadas directamente a problemas relacionados con la obtención y
persistencia de la información. 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 específicos del área de acceso a datos. De este tipo de patrones también
existe una categorización la cual se muestra a continuación:
• Decoupling Patterns: describen estrategias para separar el acceso a datos
de otras responsabilidades de la aplicación. Esta acción de separación 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

Página 30 de 190
o Resource Descriptor
o Retraer
• Input/output patterns: Describen patrones que simplifican las operaciones
de entrada y salida, usando una tranlación consistente en información
relacional y la representación 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 información
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 información 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 utilización de código que maneje este problema
desde la aplicación, puede ser tuneado para necesidades especificas. Algunos
patrones representantivos de este grupo son:
o Transaction
o Optimistic Lock

Página 31 de 190
o Pessimistic Lock
o Compensating
3.2.5 El patrón Singleton
Este patrón asegura que sólo 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 administración centralizada de algún recurso. Por ejemplo, si se
necesita escribir una clase que un applet pueda usar para asegurar que no más 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 característica es pública, y "-" significa
que la característica es privada. Una característica subrayada indica que es estática.
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 método getInstance. Este método es estático, y siempre

Página 32 de 190
regresa la misma instancia de la clase. La siguiente figura muestra el diagrama de
clases general de este patrón.
3.2.6 El Patrón Factory
Si consideramos el problema de crear un framework para el desarrollo de
aplicaciones para PC (tipo MSOffice). Estas aplicaciones están 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 electrónica, etc.). En el caso de un
editor de texto, además 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 métodos de la clase Application. La mayoría de los métodos de esta clase
varían según el tipo de documento. Debido a esto, la clase Application usualmente
delega la mayoría de los comandos a algún tipo de objeto documento. Además, la
lógica de las operaciones del objeto documento puede variar según el tipo de
documento. Sin embargo, hay operaciones, como por ejemplo desplegar el string con
el título del documento o desplegar una imagen .gif, que son comunes para todos los
objetos documento. Esto sugiere una organización que incluya una clase abstracta
Document independiente de la aplicación, para especificar los tipos de documentos.
Esta organización es mostrada en la siguiente figura.

Página 33 de 190
Lo que no queda claro aun, es cómo un objeto Application puede crear instancias de
clases de documentos específicos para esa aplicación, sin ser ella misma una
aplicación específica. Para lograr esto, se puede encapsular la lógica e instanciar
subclases de la clase Document específicas a la aplicación en una interfaz. La
siguiente figura muestra esta nueva organización.
Usando la organización de la figura anterior, un objeto Application llama al método

Página 34 de 190
createDocument de un objeto que implementa la interfaz DocumentFactoryIF. Éste le
pasa un string al método createDocument que le dice al método cuál subclase de la
clase Document debe instanciar.
El patrón Fáctory provee un objeto independiente de la aplicación con un objeto
específico a la aplicación, al cual delega la creación de otros objetos específicos a la
aplicación. La siguiente figura muestra el diagrama general de este patrón.
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 patrón Factory.
Concrete Product. Cualquier clase concreta instanciada por los objetos que
participan en este patrón.
Creation Requestor. El objeto que requiere la creación, es una clase
independiente de la aplicación que necesita crear clases específicas a la

Página 35 de 190
aplicación. Esto lo hace indirectamente a través de una instancia de la clase
Factory.
Factory IF. Es una interfaz independiente de la aplicación. Los objetos que
crean productos usando CreationRequestor deben implementar esta interfaz.
Las interfaces de este tipo declaran un método que es llamado por un objeto
CreationRequestor para crear productos concretos.
Factory Class. Es una clase específica a la aplicación que implementa la
interfaz de fábrica adecuada, y tiene un método para crear productos
concretos.
3.2.7 El Patrón Abstract Factory
Este patrón es también conocido como Kit o Toolkit. Dado un conjunto de clases
relacionadas, el patrón Fábrica 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 múltiples plataformas gráficas (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 además que todos los objetos creados son de la
plataforma deseada. En esta situación, una clase fábrica abstracta define métodos
para crear una instancia de cada clase abstracta que representa un objeto de la
interfaz de usuario. Fábricas concretas son subclases concretas de una fábrica
abstracta que implementa sus métodos para crear instancias de clases de objetos
concretos para una misma plataforma.
En un contexto más general, una clase de fábrica abstracta y sus subclases
concretas, organizan conjuntos de clases concretas que trabajan con productos

Página 36 de 190
diferentes, pero relacionados entre sí. La siguiente figura muestra el diagrama
general de este patrón.
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 métodos abstractos para crear
instancias de clases de objetos concretas. Tienen un método estático getFactory el
cual es llamado por los objetos Client para tener una instancia de una fábrica
concreta, apropiada para crear widgets que trabajan con un producto particular.
ConcreteFactory1, ConcreteFactory2. Estas clases implementan los métodos
definidos por la superclase de la fábrica abstracta, para crear instancias de widgets
concretos. Las clases cliente que llaman estos métodos no necesitan tener

Página 37 de 190
conocimiento directo de estas clases de fábrica concretas. En lugar de esto, accesan
instancias de estas clases como instancias de la superclase fábrica abstracta.
WidgetA, WidgetB. Son clases abstractas que corresponden a características de un
producto con el que trabaja la subclase concreta. Se conocen como widgets
abstractos.
Product1WidgetA, Product2WidgetA. Son clases concretas que corresponden a
características de un producto con el que trabajan. Se conocen como widgets
concretos
3.2.8 El Patron Data Accessors
El patrón Data Accessor encapsula los detalles del acceso físico a datos en una
componente simple, exponiendo únicamente las operaciones lógicas vitales. El
código de la aplicación 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 estática de este patrón, es mostrada en la siguiente figura:

Página 38 de 190
3.2.9 Patron DAO (Data Access Object)
3.2.9.1 Origenes de DAO
Este patrón ha sido tomado de las especificaciones J2EE de la plataforma Java, su
utilidad y beneficios son altos por lo que será aplicado en la construcción de
nuestro prototipo.
3.2.9.2 Contexto y Aplicación.
Muchas aplicaciones en el mundo real necesitan utilizar datos persistentes en algún
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
podrían necesitar acceder a datos que residen en sistemas diferentes. Por ejemplo,
los datos podrían residir en sitemas mainframe, repositorios LDAP, etc. Otro ejemplo
es donde los datos los proporcionan servicios a través de sistemas externos como
los sistemas de integración negocio-a-negocio (B2B), servicios de tarjetas de crédito,
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 aplicación emplea consistencia manejada por el bean (BMP)
cuando sus beans de entidad acceden explícitamente al almacenamiento persistente
-- el bean de entidad incluye código para hacer esto. Una aplicación con
requerimientos sencillos podría por lo tanto utilizar beans de entidad en lugar de
beans de sesión o servlets para acceder al almacenamiento persistente y recuperar o
modificar los datos. O, la aplicación podría 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.

Página 39 de 190
Utilizar un Data Access Object (DAO) para abstraer y encapsular todos los accesos a
la fuente de datos. El DAO maneja la conexión 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 implementación de la fuente de datos a sus clientes.
Como el interface expuesto por el DAO no cambia cuando cambia la implementación
de la fuente de datos subyacente, este patrón permite al DAO adaptarse a diferentes
esquemas de almacenamiento sin que esto afecte a sus clientes o componentes de
engocio. Esencialmente, el DAO actúa 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 patrón DAO:

Página 40 de 190
La siguiente figura muestra el diagrama de secuencia de la interacción entre los
distintos participantes en este patrón:
• BusinessObject :Representa los datos del cliente. Es el objeto que requiere el
acceso a la fuente de datos para obtener y almacenar datos. Podríamos
implementar un businessObject como un bean de sesión, un bean de entidad o
cualquier otro objeto Java, además de como un Servlet o como un bean de
apoyo.
• DataAccessObject: es el objeto principal de este patrón. DataAccessObject
abstrae la implementación del acceso a datos subyacente al BusinessObject para
permitirle un acceso transparente a la fuente de datos. El BusinessObject también
delega las operaciones de carga y almacenamiento en el DataAccessObject.
• DataSource: Representa la implementación de la fuente de datos. Una fuente de
datos podría ser una base de datos como un RDBMS, un OODBMS, un
repositorio XML, un fichero plano, etc. También lo pueden ser otros sitemas

Página 41 de 190
(mainframes/legales), servicios (servicio B2B u oficina de tarjetas de crédito), o
algún tipo de repositorio (LDAP).
3.2.9.3 Generación Automática de DAO
Como cada BusinessObject corresponde a un DAO específico, 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 generación-de-código-específica-de-aplicación que
genere el código para todos los DAOs que necesita la aplicación. Los meta datos
para generar el DAO pueden venir de un fichero descriptor definido por el
desarrollador. Como alternativa, el generador de código 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 utilización 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 además definir los DAOs intermedios. Estas
herramientas generan el código automáticamente una vez que se termina el mapeo,
y podrían proporcionar otras características valiosas como el caché de resultados y
de consultas, integración con servidores de aplicaciones, integración con otros
productos de terceras partes, etc.
3.2.9.4 Ventajas de DAO
Algunas ventajas en la utilización de DAO son las siguientes:
• Permite la Transpariencia Los objetos de negocio puede utilizar la fuente de
datos sin conocer los detalles específicos de su implementación. El acceso es
transparente porque los detalles de la implementación se ocultan dentro del
DAO.
• Permite una Migración más Fácil :Una capa de DAOs hace más fácil que una
aplicación pueda migrar a una implementación de base de datos diferente. Los

Página 42 de 190
objetos de negocio no conocen la implementación de datos subyacente, la
migración implica cambios sólo en la capa DAO. Además, si se emplea la
estrategia de factorías, es posible proporcionar una implementación de
factorías concretas por cada implementación del almacenamiento subyacente.
En este caso, la migración a un almacenamiento diferente significa
proporcionar a la aplicación una nueva implementación de la factoría.
• Reduce la Complejidad del Código de los Objetos de Negocio : Como los
DAOs manejan todas las complejidades del acceso a los datos, se simplifica el
código de los objetos de negocio y de otros clientes que utilizan los DAOs.
Todo el código relacionado con la implementación (como las sentencias SQL)
están dentro del DAO y no en el objeto de negocio. Esto mejora la lectura del
código 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 aísla el resto de la aplicación de la
implementación de acceso a los datos. Esta centralización hace que la
aplicación sea más sencilla de mantener y de manejar.
3.3 Bases de Datos Orientadas a Objetos
Los modelos de bases de datos tradicionales (relacional, red y jerárquico) han sido
capaces de satisfacer con éxito las necesidades, en cuanto a bases de datos, de las
aplicaciones de gestión tradicionales. Sin embargo, presentan algunas deficiencias
cuando se trata de aplicaciones más complejas o sofisticadas como, por ejemplo, el
diseño y fabricación en ingeniería (CAD/CAM, CIM), los experimentos científicos, los
sistemas de información geográfica o los sistemas multimedia. Los requerimientos y
las características de estas nuevas aplicaciones difieren en gran medida de las
típicas aplicaciones de gestión la estructura de los objetos es más compleja, las
transacciones son de larga duración, se necesitan nuevos tipos de datos para
almacenar imágenes y textos, y hace falta definir operaciones no estándar,
específicas para cada aplicación.

Página 43 de 190
Las bases de datos orientadas a objetos se crearon para tratar de satisfacer las
necesidades de estas nuevas aplicaciones. La orientación 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 característica clave de las bases de datos orientadas a objetos es la potencia
que proporcionan al diseñador al permitirle especificar tanto la estructura de objetos
complejos, como las operaciones que se pueden aplicar sobre dichos objetos.
Otro motivo para la creación 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
información y las bases de datos tradicionales son difíciles de utilizar cuando las
aplicaciones que acceden a ellas está escritas en un lenguaje de programación
orientado a objetos como C++, Smalltalk o Java. Las bases de datos orientadas a
objetos se han diseñado 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
también 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 objeto–relacionales. La nueva versión
de SQL, SQL:19993
, incluye algunas de las características de la orientación a
objetos.
3
Este es el nombre que recibe el estándar. En ocasiones se cita como SQL3 porque así se llamaba el
proyecto que lo desarrolló. También se cita como SQL99, por ser un nombre similar al de la versión anterior,
SQL92; sin embargo, este último nombre no se ha utilizado en esta ocasión porque se quiere evitar el efecto
2000 en el nombre de futuras versiones.

Página 44 de 190
Durante los últimos años se han creado muchos prototipos experimentales de
sistemas de bases de datos orientadas a objetos y también muchos sistemas
comerciales. Conforme éstos fueron apareciendo, surgió la necesidad de establecer
un modelo estándar 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 estándar
ODMG–93 y que ha ido evolucionando hasta el ODMG 3.0, su última versión. El uso
de estándares proporciona portabilidad, permitiendo que una aplicación se pueda
ejecutar sobre sistemas distintos con mínimas modificaciones. Los estándares
también proporcionan interoperabilidad, permitiendo que una aplicación pueda
acceder a varios sistemas diferentes. Y una tercera ventaja de los estándares es que
permiten que los usuarios puedan comparar entre distintos sistemas comerciales,
dependiendo de qué partes del estándar proporcionan.
3.3.1 El Concepto de Orientación 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 actúan 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 aplicación.
La orientación a objetos, sin embargo, combina los procedimientos de una entidad
con sus datos.
Esta combinación se considera como un paso adelante en la gestión 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
aplicación, 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.

Página 45 de 190
El modelo orientado a objetos también soporta relaciones de muchos a muchos,
siendo el primer modelo que lo permite. Aún así se debe ser muy cuidadoso cuando
se diseñan estas relaciones para evitar pérdidas de información.
Por otra parte, las bases de datos orientadas a objetos son navegacionales: el
acceso a los datos es a través de las relaciones, que se almacenan con los mismos
datos. Esto se considera un paso atrás. 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 híbridos u objeto–relacionales: 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 extensión del paradigma de
programación orientado a objetos. Los objetos entidad que se utilizan en los
programas orientados a objetos son análogos a las entidades que se utilizan en las
bases de datos orientadas a objetos puros, pero con una gran diferencia: los objetos

Página 46 de 190
del programa desaparecen cuando el programa termina su ejecución, 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
método. Los objetos soportan una serie de características de los mismos :
• Se agrupan en tipos denominados clases
• Contienen datos internos que definen su estado actual
• Soportan ocultación de datos
• Pueden heredar propiedades de otros objetos
• Pueden comunicarse con otros objetos enviando o pasando mensajes
• Tienen métodos 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 información necesaria
para localizar el objeto en el fichero donde se almacena la base de datos. Por

Página 47 de 190
ejemplo, el identificador puede contener el número de la página del fichero donde se
encuentra almacenado el objeto, junto con el desplazamiento desde el principio de la
página.
Hay dos aspectos importantes a destacar sobre este método 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 prerrelaciónales
(el modelo jerárquico 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 más rápido seguir los identificadores de los
objetos que hacer operaciones de concatenación (join).
El modelo orientado a objetos permite los atributos multivaluados, agregaciones a las
que se denomina conjuntos (sets) o bolsas (bags). Para crear una relación 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.

Página 48 de 190
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 relación, 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 relación tiene datos, será necesario crear una entidad intermedia que contenga
estos datos. Por ejemplo, en la relación de los artículos con los proveedores, en
donde cada proveedor puede tener un precio distinto para un mismo artículo. En este
caso, la relación de muchos a muchos se sustituye por dos relaciones de uno a
muchos, como se haría en una base de datos relacional. En segundo lugar, se puede
diseñar una base de datos que contiene relaciones de muchos a muchos en donde o
bien se pierde información, o bien se hace imposible determinar las relaciones con
precisión. También en estos casos la solución es incluir una entidad intermedia que
represente la relación.
Ya que el paradigma orientado a objetos soporta la herencia, una base de datos
orientada
a objetos también puede utilizar la relación “es un” entre objetos. Por ejemplo, en una
base de datos para un departamento de recursos humanos habrá una clase genérica
Empleado con diversos atributos: nombre, dirección, número 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
diseño clarifica el diseño lógico de la base de datos y ayuda a los programadores de

Página 49 de 190
aplicaciones permitiéndoles escribir sólo una vez los métodos que tienen en común
las dos subclases (serán los métodos que se sitúan en la clase Empleado).
En teoría, una base de datos orientada a objetos debe soportar dos tipos de
herencia: la relación “es un” y la relación “extiende”. La relación “es un”, que también
se conoce como generalización–especialización, crea una jerarquía donde las
subclases son tipos específicos de las súperclases. Con la relación “extiende”, sin
embargo, una clase expande su súperclase en lugar de estrecharla en un tipo más
específico. Por ejemplo, en la jerarquía de la clase Empleado, al igual que son
necesarias clases para los empleados que realizan cada trabajo específico, hace
falta guardar información adicional sobre los directores, que son empleados pero que
también tienen unas características específicas. 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 más específico sino un empleado con información
adicional.
Una de las cosas que es difícil de manejar en las bases de datos relacionales es la
idea de las partes de un todo, como en una base de datos de fabricación, 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 relación denominada “todo–parte” en la que los objetos de una clase
se relacionan con objetos de otras clases que forman parte de él. En el caso de la
base de datos de fabricación, la clase Producto se relacionará con las clases Pieza y
Componente utilizando una relación “todo–parte”. Este tipo de relación es una
relación de muchos a muchos con un significado especial. Un producto puede estar
hecho de muchas piezas y muchos componentes. Además, una misma pieza o un
mismo componente se puede utilizar para fabricar distintos productos. El identificar
esta relación como “todo–parte” permite que el diseño sea más fácil de entender.

Página 50 de 190
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
relación. Por ejemplo, si los aparejadores de una empresa de control de calidad se
deben relacionar con las obras de construcción que supervisan, debe haber algún
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 algún
modo análogo 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 relación, un SGBD orientado a objetos puro deberá
permitir que el diseñador de la base de datos pueda especificar dónde 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 aplicación inserta o elimina un
identificador de objeto de la relación supervisa en un objeto Aparejador, el SGBD

Página 51 de 190
actualizará automáticamente la relación es_supervisada en el objeto Obra
relacionado. Cuando se hace una modificación en el objeto Obra, el SGBD lo
propagará automáticamente al objeto Aparejador.
Del mismo modo que en las bases de datos relacionales es el diseñador de la base
de datos el que debe especificar las reglas de integridad referencial, en las bases de
datos orientadas a objetos es también el diseñador el que debe especificar las
relaciones inversas cuando crea el esquema de la base de datos.
3.3.3 El modelo Estándar ODMG
Un grupo de representantes de la industria de las bases de datos formaron el ODMG
(Object Database Management Group) con el propósito de definir estándares para
los SGBD orientados a objetos. Este grupo propuso un modelo estándar para la
semántica 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 definición de objetos (ODL).
• Lenguaje de consulta de objetos (OQL).
• Conexión con los lenguajes C++, Smalltalk y Java.
3.3.3.1 Modelo de Objetos
El modelo de objetos ODMG permite que tanto los diseños, como las
implementaciones, sean portables entre los sistemas que lo soportan. Dispone de las
siguientes primitivas de modelado:
• Los componentes básicos 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 interés del mundo real. Los objetos tienen algún tipo de

Página 52 de 190
identificador único. Un literal es un valor específico, 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
específico compartido por todos los objetos y literales de ese tipo. Los tipos
también pueden tener comportamientos. Cuando un tipo tiene
comportamientos, todos los objetos de ese tipo comparten los mismos
comportamientos. En el sentido práctico, 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 operación puede
requerir datos de entrada (parámetros de entrada) y puede devolver algún
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 múltiples usuarios y aplicaciones.
• La definición de una base de datos está contenida en un esquema que se ha
creado mediante el lenguaje de definición de objetos ODL (Object Definition
Language) que es el lenguaje de manejo de datos que se ha definido como
parte del estándar propuesto para las bases de datos orientadas a objetos
Lenguaje de Definición de Objetos

Página 53 de 190
ODL es un lenguaje de especificación para definir tipos de objetos para sistemas
compatibles con ODMG. ODL es el equivalente del DDL (lenguaje de definición 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 definición 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 súper 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 métodos que estos poseen.
La sintaxis básica de OQL es una estructura SELECT...FROM...WHERE..., como en
SQL.
Por ejemplo, la siguiente expresión obtiene los nombres de los departamentos de la
escuela de ‘Ingeniería’:
SELECT d.nombre
FROM d in departamentos
WHERE d.escuela = `Ingeniería';
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 extensión de
una clase. En el ejemplo anterior, el punto de entrada es la extensión
departamentos, que es un objeto colección de tipo set<Departamento>. Cuando se
utiliza una extensión como punto de entrada es necesario utilizar una variable

Página 54 de 190
iteradora que vaya tomando valores en los objetos de la colección. Para cada objeto
de la colección (sólo la forman objetos persistentes) que cumple la condición (que es
de la escuela de ‘Ingeniería’), 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 además otras características que no se van a presentar aquí:
• Especificación de vistas dando nombres a consultas.
• Obtención 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 múltiples valores en una columna de una misma fila ya
que un objeto suele contener múltiples valores. Sin embargo, si se utiliza una
clase como dominio de una columna, en cada fila esa columna sólo puede
contener un objeto de la clase (se sigue manteniendo la restricción del modelo
relacional de contener valores atómicos en la intersección de cada fila con
cada columna).

Página 55 de 190
• Es posible almacenar procedimientos en las relaciones porque un objeto está
enlazado con el código de los procesos que sabe realizar (los métodos 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 objeto–relacional 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 concatenación (join) para implementar las relaciones “al vuelo”.
Toda la información 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 están
guardados en forma de tablas con renglones y columnas. SQL es usado como el
lenguaje de búsqueda de información. Pero el modelo relacionado tiene que ser
modificado para soportar las características clásicas de programación orientada a
objeto. Las características de ORDBMSs son:
• extensión, 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 más funcionalidad y un
mejor desempeño
3.4.1 Diferencia entre los tres sistemas (RDBMS, ODBMS, ORDBMS)

Página 56 de 190
Tabla 1: Una comparación de sistemas de Administración de Base de Datos
Criterio RDBMS ODBMS ORDBMS
Standard para
definir
SQL2 ODMG-2.0 SQL3 (in proceso)
Apoyo de
características
orientadas-
objetos
No lo apoya; Es
difícil mapear un
programa entre el
objeto y la base de
datos
apoyo extensivo apoyo limitado;
mayormente con
datatypes
Uso Fácil de usar Bueno para
programadores;
Algún acceso de
SQL para usuarios
finales
Fácil de usar
excepto por
algunas
extensiones
Apoyo para
relaciones
complejas
No apoya
datatypes
abstractos
Apoya una gran
variedad de
datatypes e inter-
relaciones de
datos complejos
Apoya datatypes
abstractos y
relaciones
complejas
Desempeño Buen desempeño Relativamente
menor desempeño
Se espera que el
desempeño sea
mejor
Madurez del
producto
Relativamente
viejo y muy
maduro
Este concepto
tiene un par de
años y es
relativamente
maduro
Todavía está en el
proceso de
desarrollo
El uso de SQL Apoyo extensivo
de SQL
OQL es similar a
SQL, pero con
características
SQL3 está siendo
desarrollado con
características OO

Página 57 de 190
adicionales como
Objetos complejos
y características
orientadas a
objetos
incorporadas
Ventajas Su dependencia
de SQL, y su
optimización de
consultas es
relativamente
sencilla
Puede manejar
todo tipo de
aplicaciones
complejas, puede
reutilizar el código
Habilidad de
consultas para
aplicaciones
complejas y la
habilidad a
manejar
aplicaciones
grandes y
complejas
Desventajas Inhabilidad de
manejar
aplicaciones
complejas
Desempeño pobre
por la optimización
de consultas
complejas, la
inhabilidad de
soportar sistemas
de gran escala
Desempeño pobre
en aplicaciones
web.
Tiene apoyo de
los vendedores
Tiene un extenso
mercado y muchos
vendedores
En el presente,
falta apoyo de los
vendedores por el
tamaño del
mercado de
RDBMS
Tiene un buen
futuro. Parece que
todo los
vendedores de
RDBMS quieren
este producto
En el artículo "Object-Relational DBMS: The Next Wave," del Dr. Michael

Página 58 de 190
Stonebraker, gerente de Tecnología de la Informix Software, ha clasificado cuatro
tipos de aplicaciones de DBMS:
Tabla 2: Categorías de DBMSs
File Systems RDBMSs OODBMSs ORDBMSs
Datos simples sin
queries
Datos simples con
queries
Datos complejos sin
queries
Datos complejos
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 categoría. Los otros ORDBMS incluyen Oracle8 y superiores,
de Oracle Corporation y Universal DB (UDB) de IBM. También, 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, están enlistadas en orden de
practicidad y desempeño:
• 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 rediseñado.
• Provee una nueva capa orientada a objetos para soportar tipos de datos
enriquecidos.
La ventaja principal del ORDBMSs es la gran escalabilidad que tienen, están
diseñados para manejar una gran cantidad de información. Pero aunque tengan
muchas ventajas, los ORDBMSs también tienen desventajas. La arquitectura de
un modelo objeto relacionado no es el mejor modelo para aplicaciones de alta

Página 59 de 190
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 información y acceso de alta velocidad. También tienen el
apoyo de los vendedores principales.
3.5 Motores de Persistencia
Las opciones que se basan en imponer un único modelo teórico (un único formato de
datos) a toda la aplicación padecen de graves inconvenientes. En el caso de que
toda la aplicación siga el modelo relacional, se pierden las ventajas de la orientación
a objetos. En el caso de que toda la aplicación siga el modelo orientado a objetos, las
bases de datos están inmaduras y tienen un bajo nivel de estandarización.
Otra opción es aquella en la que el programa sea orientado a objetos y la base de
datos sea relacional, lo que, en principio, constituye la opción más 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 más que un componente de software (concretamente, una capa de
programación), 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 situación 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.

Página 60 de 190
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 dirigiéndose a ella de
forma relacional. Es decir, cada uno de los dos componentes trabaja con el formato
de datos (el “idioma”) que le resulta más natural y es el motor de persistencia el que
actúa de traductor entre los dos modelos, permitiendo que los dos componentes se
comuniquen y trabajen conjuntamente.
Esta solución goza de las mejores ventajas de los dos modelos.
• Por una parte, es posible programar con orientación 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 estandarización así como las herramientas relacionales que
existen para ella.
Un motor de persistencia puede reducir el código de una aplicación en un cuarenta
por ciento, haciéndola menos costosa de desarrollar. Además, el código es más
limpio y sencillo y, por lo tanto, más fácil de mantener y más robusto, de tal manera
que el motor de persistencia no sólo simplifica la programación, sino que permite
hacer ciertas optimizaciones de rendimiento que serían difíciles de programar de otra
manera.

Página 61 de 190
En conclusión, ésta es la mejor opción en la actualidad para implementar una
aplicación 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 sólo debe programarse una vez y puede usarse para
todas las demás aplicaciones que se desarrollen en una empresa. Sin embargo, un
motor de persistencia es difícil 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 más recomendable, por la complejidad y costo
que introduce esta opción.
• Utilizar un motor que ya esté programado, comprándolo a un vendedor o bien
usando un motor gratuito de código abierto.
La segunda opción es la más recomendada, debido a que es la menos costosa y la
menos propensa a fallos. Se debe escoger un motor de persistencia de los que están
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
especificación EJB (“Enterprise JavaBeans”), incorporan un motor de persistencia a
través del mecanismo conocido como “entity beans”. Sin embargo, los “entity beans”
no son un mecanismo de persistencia totalmente recomendable, pues no permiten
implementar algunas características de la programación orientada a objetos (por
ejemplo, herencia) y además, obligan a una forma de programar diferente a los
objetos normales de Java (o POJOs, por “Plain Old Java Objects”).
Hay motores de persistencia más completos que no tienen este tipo de
inconvenientes, entre los de código abierto podemos destacar: Hibernate, Castor,
Torque, OJB y Cayenne. Entre los comerciales, podemos destacar TopLink,

Página 62 de 190
Cocobase y FastObjects. En los últimos años se ha creado una especificación
llamada JDO, para estandarizar la forma de programar en Java con esos motores de
persistencia. Ejemplos de motores de persistencia que cumplen el estándar JDO son
Kodo, JDO Genie, LiDo, Exadel JDO, IntelliBO, JRelay JDO (todos ellos
comerciales), TJDO y XORM (de código abierto).
La plataforma .NET, por su relativa novedad, está más inmadura que la plataforma
Java. Además, al ser una plataforma propietaria, cuesta más encontrar proyectos de
código 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 Diseño 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 evaluación de los procesos de una organización. 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 investigación y desarrollo patrocinado por el Departamento de
Defensa de los Estados Unidos de América 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 América, desarrolló una primera definición 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 versión (v1.1) se publicó en febrero de 1993.

Página 63 de 190
Este modelo establece un conjunto de prácticas o procesos clave agrupados en
Áreas Clave de Proceso (KPA - Key Process Area). Para cada área de proceso
define un conjunto de buenas prácticas que habrán de ser:
• Definidas en un procedimiento documentado
• Provistas (la organización) de los medios y formación necesarios
• Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas)
• Medidas
• Verificadas
• A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez",
de modo que una organización que tenga institucionalizadas todas las
prácticas 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 técnicas
correctas de ingeniería, los esfuerzos se ven minados por falta de planificación. El
éxito de los proyectos se basa la mayoría 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 prácticas
institucionalizadas de gestión de proyectos, existen unas métricas básicas y un
razonable seguimiento de la calidad. La relación con subcontratistas y clientes
está gestionada sistemáticamente.
2 Definido. Además de una buena gestión de proyectos, a este nivel las
organizaciones disponen de correctos procedimientos de coordinación entre
grupos, formación del personal, técnicas de ingeniería más detalladas y un nivel

Página 64 de 190
más avanzado de métricas en los procesos. Se implementan técnicas de revisión
por pares (peer reviews).
3 Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto
de métricas significativas de calidad y productividad, que se usan de modo
sistemático para la toma de decisiones y la gestión de riesgos. El software
resultante es de alta calidad.
4 Optimizado. La organización completa está volcada en la mejora continua de los
procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de
innovación.
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 número de áreas de
proceso que deben lograrse. El alcanzar estas áreas o estadios se detecta mediante
la satisfacción o insatisfacción de varias metas claras y cuantificables. Con la
excepción del primer Nivel, cada uno de los restantes Niveles de Madurez está
compuesto por un cierto número de Áreas Claves de Proceso, conocidas a través de
la documentación del CMM por su sigla inglesa: KPA.
Cada KPA identifica un conjunto de actividades y prácticas 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:
Gestión, Organizacional e Ingeniería.
Las prácticas que deben ser realizadas por cada Area Clave de Proceso están
organizadas en 5 Características Comunes, las cuales constituyen propiedades que
indican si la implementatción y la institucionalización de un proceso clave es efectivo,
repetible y duradero.
Estas 5 características son: i)Compromiso de la realización, ii) La capacidad de
realización, iii) Las actividades realizadas, iv) Las mediciones y el análisis, v) La
verificación de la implementación.

Página 65 de 190
Las organizaciones que utilizan CMM para mejorar sus procesos disponen de una
guía útil para orientar sus esfuerzos. Además, el SEI proporciona formación a
evaluadores certificados (Lead Assesors) capacitados para evaluar y certificar el
nivel CMM en el que se encuentra una organización. Esta certificación es requerida
por el Departamento de Defensa de los Estados Unidos, pero también es utilizada
por multitud de organizaciones de todo el mundo para valorar a sus subcontratistas
de software.
Se considera típico que una organización 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 dirección.
Como consecuencia, muchas organizaciones que realizan funciones de factoría 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 países en
el que más organizaciones certificadas exista sea India, donde han florecido las
factorías 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 formación de los evaluadores en diciembre de
2003, quienes dispondrán hasta fin de 2005 para reciclarse al CMMI. Las
organizaciones que sigan el modelo SW-CMM podrán continuar haciéndolo, pero ya
no podrán ser certificadas a partir de fin de 2005.
3.6.1.1 SW-CMM Vs CMMI
El objetivo de esta sección es presentar un panorama general y un comparativo
sobre los dos modelos de madurez del SEI (Software Engineering Institute) que han
tenido más aceptación para las organizaciones y áreas que se dedican al desarrollo
del software y que últimamente han generado gran controversia en la comunidad

Página 66 de 190
mundial: SW-CMM y CMMI. Esto con la finalidad de que el lector se forme una idea
de la razón de ser de los mismos, la audiencia hacia la cual están enfocados y los
aspectos que cubren.
Antes de iniciar con nuestra revisión es importante mencionar que la aplicabilidad de
los modelos para la mejora de procesos depende de la situación y del tipo de cada
organización, ya que los programas de mejora deben estar basados en la misión y
los objetivos del negocio que tenga cada organización.
SW-CMM (Software Capability Maturity Model)
Es el modelo más utilizado en la industria de software, no sólo en los Estados Unidos
(EE.UU.), sino en el mundo entero, por lo que representa el estándar 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 rápidamente fue adoptado por la industria para evaluar a los
proveedores de software de manera estándar y objetiva.
Actualmente el SW-CMM, en su versión 1.1, está organizado en 5 niveles de
madurez, con 18 áreas clave (KPAs), con 52 metas que requieren de 316 prácticas
comunes (tales como habilidades a desarrollar, compromisos de la gerencia,
métricas y revisiones para verificar la implantación de las actividades requeridas). Su
enfoque está orientado en generar, implantar y mejorar las prácticas de ingeniería de
software, considerando al desarrollo de software como producto principal.
El SW-CMM ha demostrado ser un diferenciador importante de nivel comercial, pues
además de permitir mejorar internamente los procesos de las organizaciones,
representa una manera estándar 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 mayoría de las grandes empresas de

Página 67 de 190
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 metodologías. 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 integración de hardware y software.
Las industrias que son usuarias del modelo SW-CMM, numéricamente, tienen el
siguiente perfil: 689 de 1018 empresas evaluadas formalmente por el SEI son
industrias comerciales (67.7%), mientras que sólo 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 mayoría de las empresas usuarias del modelo son empresas
medianas o pequeñas.
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 razón por la cual en la India se había adoptado el SW-CMM, era
muy sencilla y lógica ya que la industria de software de la India ha estado y está
orientada a la exportación de software a diversos países, principalmente a EE.UU. y
Europa, países que han determinado el desarrollo de software bajo estándares
internacionales. Debido a que sus principales compradores están 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 estándares
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 estándar que adoptaron fue ISO 9000, ya que era el
requerimiento del mercado para poder adquirir el software desarrollado por la India.

Página 68 de 190
De esta manera, las empresas exportadoras de software de la India, entre 1993 y
1996, se certificaron en ISO 9000. Más adelante tuvieron que evolucionar a un nuevo
estándar 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 exportación de software, dejaron atrás la
certificación ISO 9000 y cambiaron al modelo de SW-CMM. Actualmente existen 64
empresas que están en nivel 5 y 51 de éstas son empresas de la India. Resumiendo
lo anterior y citando las palabras Dr. Jalote la razón principal es " market-driven", o
como dice un conocido refrán 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 ingeniería de software, ingeniería de sistemas o
industrias que requieran integración (software + hardware). La intención de este
nuevo modelo es consolidar y agrupar una familia de modelos que ya estaban siendo
utilizados y reconciliar estos modelos con los estándares y metodologías (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, todavía no
son estables debido a las modificaciones y sugerencias de cambio que se están
realizando sobre la versión aprobada. La última versión liberada es la 1.02, y está en
vías de liberación 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 más continuo de lo que aparenta.

Página 69 de 190
La versión escalonada del modelo tiene 5 niveles, como el SW-CMM versión 1.1, que
contienen 24 áreas de proceso (PAs), con 78 metas que se alcanzan al implantar las
618 prácticas comunes. Para la versión continua del modelo existen 6 niveles de
madurez, que contienen 24 áreas de proceso (PAs), con 174 metas que se deben
alcanzar y 455 prácticas comunes.
El modelo del CMMI tiene el propósito de proporcionar una guía unificada para la
mejora de múltiples disciplinas tales como ingeniería de sistemas, ingeniería de
software, etc. Sin embargo, mucho se ha escrito y discutido sobre el tema de que las
empresas que en realidad necesitan una guía de este tipo, son las grandes
organizaciones (proveedores del Departamento de Defensa, principalmente) cuyos
proyectos involucran múltiples disciplinas; mientras que la gran mayoría de los
usuarios actuales del modelo SW-CMM son pequeñas organizaciones y/o áreas de
desarrollo de software, que no utilizan o no necesitan otras disciplinas mas que la de
ingeniería de software y ésta es el foco principal del SW-CMM.
La situación actual del CMMI en el mercado norteamericano, es incierta ya que a
pesar de tener la presión 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 pequeñas-medianas cuyo negocio principal es el desarrollo de software, y
no la integración de tecnología o hardware, que es el enfoque principal del nuevo
modelo. Adicionalmente al esfuerzo requerido para la implantación de las nuevas
prácticas del CMMI, es necesario considerar el esfuerzo necesario para la
capacitación y para la evaluación formal. El método de evaluación para el nuevo
modelo se denomina SCAMPI (Standard CMMI Assessment Method for Process
Improvement) y para realizar una evaluación se requieren considerar varios meses
debido a la visión global que refleja el modelo.
La percepción en la industria internacional, es que este modelo se adapta más a
empresas grandes, que requieren de diversas disciplinas. La transición del SW-CMM
al CMMI requiere una inversión fuerte, incluso para las organizaciones que son

Página 70 de 190
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 organización 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 discusión 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
pequeñas, dónde el término “pequeñas” se utilizaba en el contexto de 20 o menos
empleados, con 2 o 3 empleados por proyecto, donde el personal asignado al
proyecto desempeña varios roles y los proyectos tienen una duración de 3 a 6
semanas. A continuación se resumen algunos puntos de esta
presentación con la finalidad de formar al lector con ideas más concretas de las
implicaciones de este modelo en empresas pequeñas, como es el caso de muchas
empresas mexicanas.
El modelo del CMMI no provee guías de ajuste para adaptar el modelo a las
organizaciones pequeñas. Esta guía es necesaria, debido a que la estructura del
modelo (diseñada para muchos recursos asignados a proyectos, con muchos roles,
proyectos muy largos que pueden durar años y cuestan millones de dólares). CMMI
se basa en prácticas de organizaciones grandes, y está enfocado para
organizaciones del departamento de defensa o
aeronáutica.
CMMI es demasiado grande para que pueda ser manejado en organizaciones
pequeñas. El CMM ha sido criticado por tener muchas áreas clave, pero CMMI tiene
muchas mas. Esto implica que la documentación de procesos que cubra las prácticas
del modelo puede ser agobiante para las organizaciones pequeñas, y por lo tanto, el
tiempo, costo y recursos para la documentación pueden crecer exponencialmente.

Página 71 de 190
El retorno de inversión (ROI) del CMMI no ha sido validado (especialmente en
organizaciones pequeñas). El retorno de inversión, suele ser uno de los principales
justificaciones para invertir en programas de mejora. Este punto es especialmente
importante para las organizaciones pequeñas donde, la mayoría de las veces no se
cuenta con un gran presupuesto e indudablemente el pago de la nómina cada dos
semanas es una preocupación mayor. Actualmente no se tienen estudios que
ayuden a calcular el ROI para el CMMI.
Las organizaciones pequeñas se administran de manera diferente a las grandes y
enfrentan retos diferentes. El principal móvil de negocio para las empresas
pequeñas es el tiempo de salida al mercado (time-to-market) de sus productos, por lo
que la entrega rápida 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), decía que las
organizaciones evaluadas en niveles superiores del SW-CMM deberían utilizar el
CMMI. La mayoría 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
métricas es complicado y sofisticado desde el nivel 2, y aunque la definición de
métricas es importante para cualquier programa de mejora esto puede ser difícil de
implantar en una organización principiante.
Podríamos 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 aceptación por el modelo. Esto nos
hace reflexionar sobre la dificultad que representa para las empresas mexicanas la
adopción 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 estén haciendo
la transición hacia el nuevo modelo. Incluso los grandes corporativos
norteamericanos tienen que realizar una fuerte inversión para hacer la transición.

Página 72 de 190
Lo que la comunidad internacional está pidiendo es que se mantengan los dos
modelos, se libere la versión 2 del SW-CMM que actualmente está en versión
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 gustaría comentar que el éxito del proyecto no está en la selección
de un modelo en particular, sino en establecer un programa de mejora que
establezca nuevas prácticas 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 orígenes 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
investigación. En 1995 Rational Software es comprada por una compañia 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 fusión fue el
Rational Objectory Process, la primera versión 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 metodología estándar más utilizada para el análisis, implementación y
documentación de sistemas orientados a objetos. RUP es en realidad un
refinamiento realizado por Rational Software del más genérico Proceso Unificado.
Sus principales características son:

Página 73 de 190
• Forma disciplinada de asignar tareas y responsabilidades (quién hace qué,
cuándo y cómo)
• Pretende implementar las mejores prácticas en Ingeniería de Software
• Desarrollo interactivo
• Administración de requisitos
• Uso de arquitectura basada en componentes
• Control de cambios
• Modelado visual del software
• Verificación 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 código fuente, etc.) y roles (papel que desempeña una persona
en un determinado momento, una persona puede desempeñar 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 decisión importante:
1. Inicio (Inception): se hace un plan de fases, se identifican los principales casos
de uso y se identifican los riesgos
2. Elaboración (Elaboration): se hace un plan de proyecto, se completan los casos
de uso y se eliminan los riesgos
3. Construcción (Construction): se concentra en la elaboración de un producto
totalmente operativo y eficiente y el manual de usuario

Página 74 de 190
4. Transición (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 orientación a Objetos.
Aunque RUP es un proceso de desarrollo de software genérico, se concibió en gran
medida para el desarrollo de sistemas basados en P.O.O. Por ejemplo se suele
emplear RUP en proyectos de programación en Lenguajes como Java o .NET, etc. Al
ser genérico, tiene muchas aplicaciones y se pueden realizar las adecuaciones
necesarias al proceso, según 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 pequeños 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 prácticas de uso que controlan la planificación, el desarrollo y
la gestión de proyectos tecnológicos. MSF se centra en los modelos de proceso y de
equipo dejando en un segundo plano las elecciones tecnológicas. 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 práctico que facilita el éxito de los proyectos tecnológico
MSF se compone de varios modelos encargados de planificar las diferentes partes
implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto,

Página 75 de 190
Modelo de Equipo, Modelo de Proceso, Modelo de Gestión del Riesgo, Modelo de
Diseño de Proceso y finalmente el modelo de Aplicación.
• Modelo de Equipo: Este modelo ha sido diseñado para mejorar el rendimiento
del equipo de desarrollo. Proporciona una estructura flexible para organizar los
equipos de un proyecto. Puede ser escalado dependiendo del tamaño del
proyecto y del equipo de personas disponibles. Para obtener más información
puedes consultar el Documento del Modelo de Equipo
• Modelo de Proceso: Diseñado 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 liberación de versiones y explicando
su relación con el Modelo de equipo. Puedes encontrar su descripción en el
Documento del Modelo de Proceso
• Disciplina de Gestión de Riesgos: Diseñada para ayudar al equipo a identificar
las prioridades, tomar las decisiones estratégicas 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 Gestión de Riesgos
• Disciplina de Gestión de Proyectos: Es una disciplina que describe el rol de la
gestión del proyecto dentro del modelo de equipo de MSF, y como permite
mayor escalabilidad, desde proyectos pequeños a proyectos largos y
complejos. Puedes encontrar la descripción de esta disciplina el el
Documento de la Disciplina de Gestión de Proyectos

Página 76 de 190
• Disciplina de Gestión de la Preparación (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 Gestión de la Preparación
Para una mayor información sobre el MSF puede visitar la página
http://www.microsoft.com/msf
3.7 Microsoft .Net Framework
Microsoft .NET es una plataforma de desarrollo y ejecución de aplicaciones. que
brinda las herramientas y servicios que se necesitan para desarrollar modernas
aplicaciones empresariales y de misión crítica, y que también provee mecanismos
robustos, seguros y eficientes para asegurar que la ejecución de las mismas sea
óptima. Los componentes principales de la plataforma .NET son:
• Un entorno de ejecución de aplicaciones, también llamado “Runtime”, que es
un componente de software cuya función 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 programación de alto nivel, junto con sus
compiladores y linkers, que permitirán el desarrollo de aplicaciones sobre la
plataforma .NET.
• Un conjunto de utilitarios y herramientas de desarrollo para simplificar las
tareas más comunes del proceso de desarrollo de aplicaciones.

Página 77 de 190
• Documentación y guías de arquitectura, que describen las mejores prácticas
de diseño, organización, desarrollo, prueba e instalación de aplicaciones .NET
Por otra parte, .NET representa la evolución 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 introducción al mercado de la
plataforma Microsoft .NET. se pueden mencionar:
- La amplia disponibilidad de conexiones a Internet de alta velocidad, e incluso
inalámbricas
- La proliferación de nuevos tipos de dispositivos de hardware que son usados
en la vida diaria (teléfonos inteligentes, Pocket PC’s, HandHelds, Media
Centers, etc.)
- El creciente poder de cómputo de las computadoras personales y servidores
basados en arquitecturas x86.
- El surgimiento de estándares de Internet para permitir la comunicación e
integración 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 Programación: si bien la plataforma Microsoft .NET
incluye lenguajes de programación de aplicaciones, su concepto es más amplio y
va más 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 más amplio y va más
allá de éstos.
.NET no es un servidor de aplicaciones (Application Server)

Página 78 de 190
.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 ejecución de aplicaciones.
3.7.1 Características
Algunas de las características principales de la plataforma Microsoft .NET son:
• Se dice que es una plataforma de ejecución 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 están diseñadas para ser ejecutadas contra un componente
de software llamado Entorno de Ejecución (muchas veces también conocido
como “Runtime”, o , “Máquina Virtual”). Este componente es el encargado de
manejar el ciclo de vida de cualquier aplicación .NET, iniciándola,
deteniéndola, interactuando con el Sistema Operativo y proveyéndole
servicios y recursos en tiempo de ejecución.
• La plataforma Microsoft .NET está completamente basada en el paradigma de
Orientación a Objetos.
• .NET es multi-lenguaje: esto quiere decir que para poder codificar aplicaciones
sobre esta plataforma no es necesario aprender un único lenguaje específico
de programación de alto nivel, sino que se puede elegir de varias opciones.
• .NET es una plataforma que permite el desarrollo de aplicaciones
empresariales de misión crítica, entendiéndose por esto que permite la
creación y ejecución de aplicaciones de porte corporativo que sean críticas
para la operación de tipos variados de organizaciones. Puede soportar
aplicaciones grandes y complejas.
• .Net fue diseñado de manera tal de poder proveer un único modelo de
programación, uniforme y consistente, para todo tipo de aplicaciones (ya sean
de formularios Windows, de consola, aplicaciones Web, aplicaciones móviles,

Página 79 de 190
etc.) y para cualquier dispositivo de hardware (PC’s, Pocket PC’s, Teléfonos
Celulares Inteligentes, también llamados “SmartPhones”, Tablet PC’s, etc.).
Esto representa un gran cambio con respecto a las plataformas anteriores a
.NET, las cuales tenían modelos de programación, bibliotecas, lenguajes y
herramientas distintas según el tipo de aplicación y el dispositivo de hardware.
• Uno de los objetivos de diseño de .NET fue que tenga la posibilidad de
interactuar e integrarse fácilmente con aplicaciones desarrolladas en
plataformas anteriores, particularmente en COM, ya que aún hoy existen una
gran cantidad de aplicaciones desarrolladas sobre esa base.
• .NET no sólo se integra fácilmente con aplicaciones desarrolladas en otras
plataformas Microsoft, sino también con aquellas desarrolladas en otras
plataformas de software, sistemas operativos o lenguajes de programación.
Para esto hace un uso extensivo de numerosos estándares globales que son
de uso extensivo en la industria, algunos ejemplos de estos estándares 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 producción.
El .NET framework tiene tres variantes principales, todas descargables gratuitamente
desde Internet
• .NET Framework Redistributable Package: mínimo 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 aplicación han finalizado.
Está compuesto por:
• El entorno de ejecución de la plataforma .NET
• Las bibliotecas de funcionalidad reutilizable
• .NET Framework SDK: esta versión contiene herramientas de desarrollo de
línea de comandos (compiladores, depuradores, etc.), documentación de

Página 80 de 190
referencia, ejemplos y manuales para desarrolladores de aplicaciones.
Normalmente ésta variante se instala en los entornos de desarrollo de
aplicaciones, y es más útil a los programadores que a los usuarios finales.
Para poder instalar la versión SDK (Software Development Kit) es necesario
instalar previamente el Redistributable Package.
• NET Compact Framework: esta es una versión reducida del .NET Framework
Redistributable, especialmente pensada para ser instalada en dispositivos
móviles como Pocket PC’s 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 ejecución de una aplicación .NET sea posible. En el caso de las aplicaciones
de escritorio (también 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 aplicación que interactúa con el usuario), y en el servidor sólo en caso
de que la aplicación 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 conexión de red al servidor, el cual debe tener instalado el .NET
Framework.
Para las aplicaciones móviles, que se ejecutan sobre Windows Mobile en algún
dispositivo tipo Pocket PC o SmartPhone, es necesario tener instalado el .NET
Compact Framework en el dispositivo.

Página 81 de 190
Actualmente hay 3 versiones de la plataforma Microsoft .NET:
• La versión 1.0: fue liberada a principios del año 2002, e incluía la versión 1.0
del .NET Framework, la versión 2002 de Visual Studio y varios lenguajes de
programación nuevos compatibles con la plataforma (como C#.NET y Visual
Basic.NET)
• La versión 1.1: fue liberada en 2003, aproximadamente un año después que
su predecesora. Esta versión introdujo el .NET Framework 1.1 junto con Visual
Studio .NET 2003, la primer versión del .NET Compact Framework y un nuevo
lenguaje de programación llamado J#.NET.
• La versión 2.0: fue liberada a finales del año 2005, esta versión trajo consigo
las versiones 2.0 del .NET Framework y el .NET Compact Framework, así
como también una nueva versión de Visual Studio.
La próxima generación de la plataforma .NET, tendrá por nombre código “Orcas”.
.NET Compact Framework
*
*
Aplicación
Móvil
Aplicación de
Consola
Aplicación Web
Aplicación de
Escritorio
¿¿DDóónnddee iinnssttaallaarr eell ..NNEETT FFrraammeewwoorrkk??
ServidorServidorServidorServidorClienteClienteClienteCliente
** SSóólloo ssii llaa aapplliiccaacciióónn eess ddiissttrriibbuuiiddaa

Página 82 de 190
3.7.2 Arquitectura
Windows COM+ Services
Common Language Runtime
Base Class Library
ADO.NET y XML
ASP.NET Windows
Forms
Common Language Specification
VB C++ C# J# …
AArrqquuiitteeccttuurraa ddeell ..NNEETT FFrraammeewwoorrkk
.NETFramework
Redistributable
.NETFrameworkSDK
.NETFramework
ClassLibrary
CCrroonnoollooggííaa ddee ..NNEETT
Visual Studio 6.0
Visual Basic
VBA
Visual FoxPro
VBScript
C++
J++
JScript
ASP
Visual Studio .NET 2003
.NET Framework 1.1
.NET Compact Framework
J#
Visual Studio “Orcas”
.NET Framework “Orcas”
.NET Compact Framework “Orcas”
2000 2001 2002 2003 2004 2005 2006 y más
Visual Studio 2005 (“Whidbey”)
.NET Framework 2.0 (“Whidbey”)
.NET Compact Framework 2.0 (“Whidbey”)
Visual Studio .NET 2002
.NET Framework 1.0
Visual Basic .NET
C#

Página 83 de 190
En la figura se pueden apreciar las distintas partes que componen al .NET
Framework, incluidas el entorno de ejecución 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 más comúnmente 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 matemáticas 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
información persistente.
• ASP.NET, que constituye la tecnología dentro del .NET Framework para
construir aplicaciones con interfaz de usuario Web (es decir, aplicaciones cuya
lógica 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 estándares como HTTP y HTML).
• Windows Forms (o simplemente WinForms), que constituye la tecnología
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 ejecución que propone la plataforma .NET se suele definir como
“virtual”, o “de máquina virtual”, ya que las aplicaciones no son desarrolladas
directamente contra las APIs de programación expuestas por el sistema operativo, ni

Página 84 de 190
es éste el que se encarga de su ejecución y ciclo de vida, sino que .NET provee un
entorno de ejecución (el CLR) que corre por sobre el sistema operativo y que es el
encargado de ejecutar las aplicaciones y proveerles servicios en tiempo de
ejecución. A los componentes de software que se ejecutan de esta manera se los
conoce comúnmente como “componentes manejados”, ya que su ejecución es
controlada por un entorno intermedio.
Una de las principales ventajas de contar con una plataforma virtual es que no están
“atadas” de ninguna forma con el sistema operativo y la plataforma de hardware
subyacente. Es sabido que una aplicación compilada para que utilice directamente
las APIs y servicios expuestos por un sistema operativo “x” muy difícilmente pueda
ser ejecutada en otro sistema operativo distinto sin ser recompilada. Las aplicaciones
manejadas, en cambio, descansan la tarea de su compilación a un código de
máquina específico en el entorno de ejecución. De esta manera, si existen distintos
entornos de ejecución intermedia para diferentes Sistemas Operativos, la misma
aplicación puede ejecutarse en todos ellos si necesidad de recompilarse.
El desarrollo de una aplicación .NET comienza con la escritura de su código fuente
en alguno de los lenguajes de alto nivel soportados por la plataforma. El mismo luego
es compilado obteniéndose un ejecutable (que en Windows normalmente llevan la
extensión .exe) o una biblioteca (que en Windows normalmente llevan la extensión
.dll). A estos componentes .NET resultantes del proceso de compilación se los
denomina genéricamente Assemblies, o Ensamblados.
Ahora bien, en lugar de contener código de máquina específico para el sistema
operativo y el hardware en el cual fueron compilados (nativo), los assemblies
contienen un código denominado MSIL (Microsoft Intermediate Language). EL MSIL
es un set de instrucciones independientes de cualquier CPU existente y que puede
ser convertido a código nativo muy eficientemente. MSIL incluye instrucciones para
cargar, almacenar, inicializar e interactuar con objetos y sus atributos y métodos, así
como también instrucciones aritméticas y lógicas, control de flujo, acceso directo a

Página 85 de 190
memoria, manejador de errores y otras operaciones. Antes de que el código MSIL
pueda ser ejecutado debe convertirse a código nativo específico para un CPU y
Sistema Operativo, tarea a cargo de los compiladores JIT incluidos en el CLR.
Un Assembly es la menor unidad de ejecución y distribución de una aplicación .NET.
Los assemblies son reutilizables, versionables y autodescriptivos, ya que no sólo
contienen el código MSIL que representa la lógica de la aplicación, sino que también
incluyen información sobre si mismos y sobre todos los recursos externos de los que
dependen para funcionar correctamente. A esta información se la denomina “Meta
data” y forma una parte integral de un assembly junto con el código MSIL ya que
ambos no pueden estar separados. La Meta data se ubica en una sección 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 aplicación .NET se compone, entonces, de uno o más assemblies. Otra de las
características de los Assemblies es que no necesitan estar registrados en la
Registry de Windows, como sus predecesores COM. De esta forma, instalar una
aplicación .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
desinstalación limpia y completa.
Dado que .NET no depende de la Registry, y que cada assembly contiene
información acerca de su versión y las versiones de los componentes de que
depende, múltiples versiones de assemblies pueden coexistir sin ningún problema en
la misma computadora.
Existen dos formas de que una aplicación pueda encontrar en tiempo de ejecución
los assemblies de los que depende:

Página 86 de 190
1) Ubicarlos en el mismo directorio. Esta es la opción preferida si esos
assemblies sólo serán utilizados por esa única aplicación.
2) Ubicarlos en un repositorio centralizado de assemblies denominado Global
Assembly Cache, en el cual se instalan todos los assemblies que serán
utilizados por múltiples 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 diseño de la plataforma .NET fue el ser independiente del
lenguaje de programación elegido para el desarrollo de aplicaciones. Para lograr esto
es que se creó la Especificación de Lenguaje Común (o CLS, por sus siglas en
inglés), que define y estandariza un subconjunto de todas las características
soportadas por el CLR y que son necesarias en la mayoría de las aplicaciones.
Todos los componentes desarrollados y compilados de acuerdo con la especificación
CLS pueden interactuar entre si, independientemente del lenguaje de programación
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 aplicación escrita, por ejemplo, en Visual Basic.NET,
puede incorporar sin problemas nuevas partes escritas en C# o C++ .NET.
La infraestructura de lenguaje común (Common Language Infrastructure, CLI) es una
especificación estandarizada que describe un entorno virtual para la ejecución de
aplicaciones, cuya principal característica es la de permitir que aplicaciones escritas
en distintos lenguajes de alto nivel puedan luego ejecutarse en múltiples plataformas

Página 87 de 190
tanto de hardware como de software sin necesidad de reescribir o recompilar su
código fuente.
Si bien el CLI tuvo sus orígenes en Microsoft (en principio se pensaba desarrollar un
entorno de ejecución 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 organización europea de estándares, para su estandarización en
el año 2000.
Luego de un año de trabajo conjunto entre ECMA, Microsoft y otras empresas que
co-patrocinaron el proceso (Intel, HP, IBM y Fujitsu entre otras), el estándar ECMA-
335 que define el entorno CLI finalmente vio la luz en diciembre de 2001. En abril del
año 2003 ISO ratificó este estándar con el denominación ISO/IEC 23271:2003 .
Para comprender mejor la inclusión de cada una de las partes principales de la
arquitectura de CLI es interesante analizar los objetivos de diseño que se plantearon
desde su concepción. Según su especificación, la arquitectura de CLI debe:
• Permitir escribir componentes ínter operables independientemente de la
plataforma subyacente y del lenguaje de programación utilizado.
• Exponer todas las entidades programáticas a través de un único sistema
unificado de tipos (en la especificación, 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 ejecución, pero que puedan a su vez compartir recursos.
• Resolver dependencias entre tipos en tiempo de ejecución usando una política
flexible que pueda tener en cuenta la versión, atributos de localización y
políticas administrativas.

Página 88 de 190
• Ejecutar aplicaciones bajo la supervisión de un entorno privilegiado que
permita controlar y hacer cumplir políticas en tiempo de ejecución.
• Diseñar toda la infraestructura y servicios basándose 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 librerías y compilación a código nativo sólo cuando sea necesario (este
enfoque se conoce típicamente como “on demand”, o “just in time”).
• Proveer una serie de funcionalidades comunes mediante un grupo de librerías
de programación que los desarrolladores puedan utilizar para construir sus
aplicaciones.
Microsoft .NET de hecho es un súper conjunto de esta especificación, es decir,
provee todo lo necesario para cumplir con la misma y además agrega una serie de
herramientas, librerías y funcionalidades no contempladas por ella originalmente y
que proveen una enorme utilidad y flexibilidad a los desarrolladores (por ejemplo,
librerías para la creación de aplicaciones y servicios web, acceso a motores de bases
de datos, controles gráficos, herramientas para desensamblar assemblies,
debuggers, etc.). Si bien es gratuito, su código fuente no es abierto, y es distribuido
por Microsoft en versiones para sistemas operativos Windows 98 y sus sucesores
únicamente.

Página 89 de 190
La figura representa el modelo de compilación y ejecución de aplicaciones .NET, al
cual muchas veces se denomina “de compilación diferida”, o “de compilación en dos
etapas”. Esto es asi ya que el primer paso para poder ejecutar una aplicación dentro
del CLR es compilar su código fuente para obtener un assembly con código 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 código MSIL a código nativo que hace uso
específico 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 ejecución, con excepción de C++ .NET, que es el único lenguaje al que se
le ha dejado la capacidad de emitir también código “no manejado”. Esto se debe a
que ciertas aplicaciones, como los drivers de dispositivos, necesitan tener acceso a
VVBB..NNEETT
CCóóddiiggoo
FFuueennttee
CCoommppiillaaddoorr
VVBB..NNEETT
CC++++..NNEETTCC##
AAsssseemmbbllyy
CCóóddiiggoo MMSSIILL
SSiisstteemmaa OOppeerraattiivvoo ((WWiinnddoowwss))
CCoommmmoonn LLaanngguuaaggee RRuunnttiimmee
CCoommppiillaaddoorr JJIITT
CCóóddiiggoo NNaattiivvoo
CCóóddiiggoo
MMaanneejjaaddoo
CCoommppoonneennttee
NNoo MMaanneejjaaddoo
MMooddeelloo ddee EEjjeeccuucciióónn ddeell CCLLRR
CC##
CC++++ ..NNEETT
AAsssseemmbbllyy
AAsssseemmbbllyy

Página 90 de 190
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 información:
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.
AAcccceessoo aa DDaattooss:: AADDOO..NNEETT
System.Data
OleDb
SqlClient
OracleClient
Common
Odbc SqlTypes
System.Xml
Serialization
XPath
XSLT
Schema

Página 91 de 190
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
ejecución, tanto de forma conectada como desconectada.
Los proveedores de acceso a datos ADO.NET (conocidos como “Managed Data
Providers”) representan conjuntos específicos 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 vía protocolos nativos de bajo nivel, provee la alternativa más
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 vía el protocolo estándar 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 vía el protocolo estándar 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

Página 92 de 190
de Oracle. De esta forma puede lograrse un acceso más 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 están
compiladas en un assembly diferente al resto: System.Data.OracleClient.dll.
En la figura se pueden apreciar las clases más comunes que componen a todos los
proveedores de acceso a datos de ADO.NET. Nótese que algunos nombres
empiezan con las letras “Xxx”: esto se debe a que los nombres de esas clases varían
según el proveedor específico que se esté utilizando. Por ejemplo, la clase que
representa una conexión 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”.
Base de Datos
XxxConnection
XxxCommand
DataSet XxxDataReader
XxxDataAdapter
Maneja la conección a una base de
datos
Ejecuta comandos contra una base
de datos
Copia local de datos relacionales
Provee acceso a datos
read-only, Forward-only
Intercambia datos entre un dataset
y una base de datos
AADDOO..NNEETT-- CCllaasseess mmááss ccoommuunneess

Página 93 de 190
● XxxConnection: representa una conexión. Almacena, entre otras cosas, el
string de conexión (connection string), y permite conectarse y desconectarse
con una base de datos.
● XxxCommand: permite almacenar y ejecutar una instrucción SQL contra una
base de datos, enviando parámetros de entrada y recibiendo parámetros de
salida.
Estas dos clases se utilizan tanto en escenarios conectados como desconectados.
● XxxDataReader: permite acceder a los resultados de la ejecución de un
comando contra la base de datos de manera read-only (sólo lectura), forward-
only (sólo 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 corazón
del soporte a escenarios desconectados de ADO.NET. El DataSet es una
representación en memoria de una base de datos relacional, que permite
almacenar un conjunto de datos obtenidos mediante un DataAdapter. El
DataAdapter actúa 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 conexión 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. Nótese 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:

Página 94 de 190
• 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 es el sucesor de ADO (ActiveX Data Objects), la biblioteca de acceso a
datos de la plataforma COM. Si bien ADO soporta sólo escenarios conectados,
puede resultar útil hacer una analogía de las clases más 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 más parecido a un
Recordset read-only forward-only de ADO), y las nuevas clases DataSet y
XxxDataAdapter para escenarios desconectados.
AADDOO..NNEETT vvss.. AADDOO

Página 95 de 190
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 navegación, búsqueda y
transformaciones complejas.
• XmlReader – clase abstracta cuyo propósito 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.
XXmmllTTeexxttWWrriitteerr
XXmmllTTeexxttRReeaaddeerr
<<XXMMLL
>>
XXmmllDDooccuummeenntt
DDooccuummeennttNNaavviiggaattoorr
XXmmllRReeaaddeerr
XXmmllVVaalliiddaattiinnggRReeaaddeerr XXmmllNNooddeeRReeaaddeerr
AADDOO..NNEETT -- SSooppoorrttee aa XXMMLL

Página 96 de 190
• XmlTextWriter – permite que datos XML puedan ser escritos a un archivo
XML o a un stream, y puede además proveer mecanismos de validación para
asegurar que sólo datos XML válidos y bien formados sean escritos.
• XmlDocument – esta es una clase compleja que actúa 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
navegación y edición, 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.

Programacion o.o.

Más contenido relacionado

La actualidad más candente

Similar a Programacion o.o.

Más de johnny herrera

Programacion o.o.