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

ServidorServidorServidorServidor ClienteClienteClienteCliente

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

.NE

T F

ram

ewor

k R

edis

trib

utab

le

.NE

T F

ram

ew

ork

SD

K

.NE

T F

ramew

ork C

lass Library

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++++..NNEETT CC##

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

CCoommppiillaaddoorr CC##

CCoommppiillaaddoorr CC++++ ..NNEETT




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.