SlideShare a Scribd company logo
1 of 82
Download to read offline
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
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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:
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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:
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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).
Maestría en Informática Aplicada a Redes
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)
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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,
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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.
Maestría en Informática Aplicada a Redes
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:
Maestría en Informática Aplicada a Redes
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
Programacion o.o.
Programacion o.o.
Programacion o.o.
Programacion o.o.
Programacion o.o.
Programacion o.o.
Programacion o.o.
Programacion o.o.
Programacion o.o.
Programacion o.o.
Programacion o.o.
Programacion o.o.
Programacion o.o.
Programacion o.o.
Programacion o.o.
Programacion o.o.
Programacion o.o.
Programacion o.o.
Programacion o.o.
Programacion o.o.
Programacion o.o.
Programacion o.o.
Programacion o.o.

More Related Content

What's hot

Diseño Orientado a Objetos
Diseño Orientado a ObjetosDiseño Orientado a Objetos
Diseño Orientado a ObjetosMegaMono
 
Sistemas ii fundamentos y metodos de analisis de requerimientos
Sistemas ii   fundamentos y metodos de analisis de requerimientosSistemas ii   fundamentos y metodos de analisis de requerimientos
Sistemas ii fundamentos y metodos de analisis de requerimientosGalderIL057
 
Actividad 1 de programacion
Actividad 1 de programacionActividad 1 de programacion
Actividad 1 de programacionkevinlugo11
 
Too Tecnologia orientada a objetos
Too Tecnologia orientada a objetosToo Tecnologia orientada a objetos
Too Tecnologia orientada a objetosFrangelys Perez
 
Qué Es El AnáLisis Y DiseñO De Software Orientado A Objetos
Qué Es El AnáLisis Y DiseñO De Software Orientado A ObjetosQué Es El AnáLisis Y DiseñO De Software Orientado A Objetos
Qué Es El AnáLisis Y DiseñO De Software Orientado A Objetosmaria8003
 
Fundamentos del análisis orientado a objetos
Fundamentos del análisis orientado a objetosFundamentos del análisis orientado a objetos
Fundamentos del análisis orientado a objetosEduardo Galindo
 
TEMA 1: LENGUAJE DE PROGRAMACIÓN.
TEMA 1: LENGUAJE DE PROGRAMACIÓN. TEMA 1: LENGUAJE DE PROGRAMACIÓN.
TEMA 1: LENGUAJE DE PROGRAMACIÓN. ClaretCabello
 
Tipos de modelo y metodologias
Tipos de modelo y metodologiasTipos de modelo y metodologias
Tipos de modelo y metodologiasJosafat Mtz
 
Metodología orientada a objetos
Metodología orientada a objetosMetodología orientada a objetos
Metodología orientada a objetosalcrrsc
 
Estructura de datos presentacion y sesion 1
Estructura de datos presentacion y sesion 1Estructura de datos presentacion y sesion 1
Estructura de datos presentacion y sesion 1Jesús Gómez Ávila
 
Analisis y diseño orientado a odjetos
Analisis y diseño orientado a odjetosAnalisis y diseño orientado a odjetos
Analisis y diseño orientado a odjetosLex Marin
 
Diseno orientado a objetos
Diseno orientado a objetosDiseno orientado a objetos
Diseno orientado a objetosCecilia Lemus
 
Análisis orientado a objetos y uml
Análisis orientado a objetos y umlAnálisis orientado a objetos y uml
Análisis orientado a objetos y umlSena
 
Introduccion a la programacion orientada a objetos
Introduccion a la programacion orientada a objetosIntroduccion a la programacion orientada a objetos
Introduccion a la programacion orientada a objetosFabian Dorado
 
Fundamentos De ProgramacióN Unidad 1
Fundamentos De ProgramacióN Unidad 1Fundamentos De ProgramacióN Unidad 1
Fundamentos De ProgramacióN Unidad 1cesarmrl2
 
Análisis de los tipos de modelos y metodologías del modelado orientado a objetos
Análisis de los tipos de modelos y metodologías del modelado orientado a objetosAnálisis de los tipos de modelos y metodologías del modelado orientado a objetos
Análisis de los tipos de modelos y metodologías del modelado orientado a objetosJuan Guadarrama
 
Unidad 1 introducción a las estructuras de datos
Unidad 1 introducción a las estructuras de datosUnidad 1 introducción a las estructuras de datos
Unidad 1 introducción a las estructuras de datosUrban Skate House
 

What's hot (20)

Diseño Orientado a Objetos
Diseño Orientado a ObjetosDiseño Orientado a Objetos
Diseño Orientado a Objetos
 
Sistemas ii fundamentos y metodos de analisis de requerimientos
Sistemas ii   fundamentos y metodos de analisis de requerimientosSistemas ii   fundamentos y metodos de analisis de requerimientos
Sistemas ii fundamentos y metodos de analisis de requerimientos
 
Actividad 1 de programacion
Actividad 1 de programacionActividad 1 de programacion
Actividad 1 de programacion
 
Too Tecnologia orientada a objetos
Too Tecnologia orientada a objetosToo Tecnologia orientada a objetos
Too Tecnologia orientada a objetos
 
Qué Es El AnáLisis Y DiseñO De Software Orientado A Objetos
Qué Es El AnáLisis Y DiseñO De Software Orientado A ObjetosQué Es El AnáLisis Y DiseñO De Software Orientado A Objetos
Qué Es El AnáLisis Y DiseñO De Software Orientado A Objetos
 
Dominio
DominioDominio
Dominio
 
Fundamentos del análisis orientado a objetos
Fundamentos del análisis orientado a objetosFundamentos del análisis orientado a objetos
Fundamentos del análisis orientado a objetos
 
TEMA 1: LENGUAJE DE PROGRAMACIÓN.
TEMA 1: LENGUAJE DE PROGRAMACIÓN. TEMA 1: LENGUAJE DE PROGRAMACIÓN.
TEMA 1: LENGUAJE DE PROGRAMACIÓN.
 
Tipos de modelo y metodologias
Tipos de modelo y metodologiasTipos de modelo y metodologias
Tipos de modelo y metodologias
 
Tc2 301403 21
Tc2 301403 21Tc2 301403 21
Tc2 301403 21
 
Metodología orientada a objetos
Metodología orientada a objetosMetodología orientada a objetos
Metodología orientada a objetos
 
Estructura de datos presentacion y sesion 1
Estructura de datos presentacion y sesion 1Estructura de datos presentacion y sesion 1
Estructura de datos presentacion y sesion 1
 
Analisis y diseño orientado a odjetos
Analisis y diseño orientado a odjetosAnalisis y diseño orientado a odjetos
Analisis y diseño orientado a odjetos
 
Diseno orientado a objetos
Diseno orientado a objetosDiseno orientado a objetos
Diseno orientado a objetos
 
Análisis orientado a objetos y uml
Análisis orientado a objetos y umlAnálisis orientado a objetos y uml
Análisis orientado a objetos y uml
 
Introduccion a la programacion orientada a objetos
Introduccion a la programacion orientada a objetosIntroduccion a la programacion orientada a objetos
Introduccion a la programacion orientada a objetos
 
Fundamentos De ProgramacióN Unidad 1
Fundamentos De ProgramacióN Unidad 1Fundamentos De ProgramacióN Unidad 1
Fundamentos De ProgramacióN Unidad 1
 
Análisis de los tipos de modelos y metodologías del modelado orientado a objetos
Análisis de los tipos de modelos y metodologías del modelado orientado a objetosAnálisis de los tipos de modelos y metodologías del modelado orientado a objetos
Análisis de los tipos de modelos y metodologías del modelado orientado a objetos
 
Unidad 1 introducción a las estructuras de datos
Unidad 1 introducción a las estructuras de datosUnidad 1 introducción a las estructuras de datos
Unidad 1 introducción a las estructuras de datos
 
Estructura de Datos
Estructura de DatosEstructura de Datos
Estructura de Datos
 

Similar to Programacion o.o.

Programacion orientada a_objeto
Programacion orientada a_objetoProgramacion orientada a_objeto
Programacion orientada a_objetocesar
 
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon Koudsi
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon KoudsiFUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon Koudsi
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon KoudsiRaimonKoudsi
 
Tecnología Orientada A Objetos
Tecnología Orientada A ObjetosTecnología Orientada A Objetos
Tecnología Orientada A ObjetosAndrés
 
Slideshare 2do corte, luismortell
Slideshare 2do corte, luismortellSlideshare 2do corte, luismortell
Slideshare 2do corte, luismortellforwer1223
 
Programacin estructurada
Programacin estructuradaProgramacin estructurada
Programacin estructuradaKurt_williams
 
Programación estructurada
Programación estructuradaProgramación estructurada
Programación estructuradawinny_arias
 
Programación orientada a objetos
Programación orientada a objetosProgramación orientada a objetos
Programación orientada a objetosjaninaplaza
 
Fundamentos de POO
Fundamentos de POOFundamentos de POO
Fundamentos de POOgueritamala
 
Guia flash
Guia flashGuia flash
Guia flashnatalia
 
Comunidad emagister 63082_63082-convertido
Comunidad emagister 63082_63082-convertidoComunidad emagister 63082_63082-convertido
Comunidad emagister 63082_63082-convertidoJamil Cajamarca
 
Unidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del softwareUnidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del softwareAndhy H Palma
 

Similar to Programacion o.o. (20)

Compu 1
Compu 1Compu 1
Compu 1
 
Programacion orientada a_objeto
Programacion orientada a_objetoProgramacion orientada a_objeto
Programacion orientada a_objeto
 
Poovb
PoovbPoovb
Poovb
 
Programacion visual
Programacion visualProgramacion visual
Programacion visual
 
Diseño o.o
Diseño o.oDiseño o.o
Diseño o.o
 
Diseño o.o
Diseño o.oDiseño o.o
Diseño o.o
 
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon Koudsi
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon KoudsiFUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon Koudsi
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS Raimon Koudsi
 
Tecnología Orientada A Objetos
Tecnología Orientada A ObjetosTecnología Orientada A Objetos
Tecnología Orientada A Objetos
 
Slideshare 2do corte, luismortell
Slideshare 2do corte, luismortellSlideshare 2do corte, luismortell
Slideshare 2do corte, luismortell
 
Programacin estructurada
Programacin estructuradaProgramacin estructurada
Programacin estructurada
 
Programación estructurada
Programación estructuradaProgramación estructurada
Programación estructurada
 
Tema nº 1
Tema nº 1Tema nº 1
Tema nº 1
 
Tema nº 1
Tema nº 1Tema nº 1
Tema nº 1
 
Programación orientada a objetos
Programación orientada a objetosProgramación orientada a objetos
Programación orientada a objetos
 
Uml
UmlUml
Uml
 
Fundamentos de POO
Fundamentos de POOFundamentos de POO
Fundamentos de POO
 
Guia flash
Guia flashGuia flash
Guia flash
 
Comunidad emagister 63082_63082-convertido
Comunidad emagister 63082_63082-convertidoComunidad emagister 63082_63082-convertido
Comunidad emagister 63082_63082-convertido
 
Unidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del softwareUnidad 3 paradigmas de la ingeniería del software
Unidad 3 paradigmas de la ingeniería del software
 
Tare psitiva
Tare psitivaTare psitiva
Tare psitiva
 

More from johnny herrera

Presentación de johnny herrera
Presentación de johnny herreraPresentación de johnny herrera
Presentación de johnny herrerajohnny herrera
 
Introduccin a-programacin-orientada-a-objetos-oop-clases-y-objetos900
Introduccin a-programacin-orientada-a-objetos-oop-clases-y-objetos900Introduccin a-programacin-orientada-a-objetos-oop-clases-y-objetos900
Introduccin a-programacin-orientada-a-objetos-oop-clases-y-objetos900johnny herrera
 
Desarrollo de-software-poo-2-parte
Desarrollo de-software-poo-2-parteDesarrollo de-software-poo-2-parte
Desarrollo de-software-poo-2-partejohnny herrera
 
2983238 programacion-orientada-a-objetos
2983238 programacion-orientada-a-objetos2983238 programacion-orientada-a-objetos
2983238 programacion-orientada-a-objetosjohnny herrera
 
13 desarrollo-de-software-fundamentos-poo-1
13 desarrollo-de-software-fundamentos-poo-113 desarrollo-de-software-fundamentos-poo-1
13 desarrollo-de-software-fundamentos-poo-1johnny herrera
 
10. programacion orientada a objetos en visual basic .net
10.  programacion orientada a objetos en visual basic .net10.  programacion orientada a objetos en visual basic .net
10. programacion orientada a objetos en visual basic .netjohnny herrera
 
Mapas conceptual, evolucion de la Web 1.0 hasta la Web 5.0
Mapas conceptual, evolucion de la Web 1.0 hasta la Web 5.0Mapas conceptual, evolucion de la Web 1.0 hasta la Web 5.0
Mapas conceptual, evolucion de la Web 1.0 hasta la Web 5.0johnny herrera
 
Programacion Orientada a Objetos
Programacion Orientada a ObjetosProgramacion Orientada a Objetos
Programacion Orientada a Objetosjohnny herrera
 
Programacion Orientada a Objetos Luis Joyanes Aguilar
Programacion Orientada a Objetos Luis Joyanes AguilarProgramacion Orientada a Objetos Luis Joyanes Aguilar
Programacion Orientada a Objetos Luis Joyanes Aguilarjohnny herrera
 
Programacioncon Visual Basic 6
Programacioncon Visual Basic 6 Programacioncon Visual Basic 6
Programacioncon Visual Basic 6 johnny herrera
 
Practicas visualbasic60
Practicas visualbasic60Practicas visualbasic60
Practicas visualbasic60johnny herrera
 
Matematica universitaria
Matematica universitariaMatematica universitaria
Matematica universitariajohnny herrera
 
Problemas resueltos de c++
Problemas  resueltos de c++Problemas  resueltos de c++
Problemas resueltos de c++johnny herrera
 

More from johnny herrera (20)

Presentación de johnny herrera
Presentación de johnny herreraPresentación de johnny herrera
Presentación de johnny herrera
 
Tiristores
TiristoresTiristores
Tiristores
 
Introduccin a-programacin-orientada-a-objetos-oop-clases-y-objetos900
Introduccin a-programacin-orientada-a-objetos-oop-clases-y-objetos900Introduccin a-programacin-orientada-a-objetos-oop-clases-y-objetos900
Introduccin a-programacin-orientada-a-objetos-oop-clases-y-objetos900
 
Desarrollo de-software-poo-2-parte
Desarrollo de-software-poo-2-parteDesarrollo de-software-poo-2-parte
Desarrollo de-software-poo-2-parte
 
METODOS Y MODELOS POO
METODOS Y MODELOS POOMETODOS Y MODELOS POO
METODOS Y MODELOS POO
 
2983238 programacion-orientada-a-objetos
2983238 programacion-orientada-a-objetos2983238 programacion-orientada-a-objetos
2983238 programacion-orientada-a-objetos
 
13 desarrollo-de-software-fundamentos-poo-1
13 desarrollo-de-software-fundamentos-poo-113 desarrollo-de-software-fundamentos-poo-1
13 desarrollo-de-software-fundamentos-poo-1
 
10. programacion orientada a objetos en visual basic .net
10.  programacion orientada a objetos en visual basic .net10.  programacion orientada a objetos en visual basic .net
10. programacion orientada a objetos en visual basic .net
 
Mapas conceptual, evolucion de la Web 1.0 hasta la Web 5.0
Mapas conceptual, evolucion de la Web 1.0 hasta la Web 5.0Mapas conceptual, evolucion de la Web 1.0 hasta la Web 5.0
Mapas conceptual, evolucion de la Web 1.0 hasta la Web 5.0
 
Programacion Orientada a Objetos
Programacion Orientada a ObjetosProgramacion Orientada a Objetos
Programacion Orientada a Objetos
 
Programacion Orientada a Objetos Luis Joyanes Aguilar
Programacion Orientada a Objetos Luis Joyanes AguilarProgramacion Orientada a Objetos Luis Joyanes Aguilar
Programacion Orientada a Objetos Luis Joyanes Aguilar
 
Programacioncon Visual Basic 6
Programacioncon Visual Basic 6 Programacioncon Visual Basic 6
Programacioncon Visual Basic 6
 
Visual Basic 6.0
Visual Basic 6.0Visual Basic 6.0
Visual Basic 6.0
 
Tutorial de Visual
Tutorial de  VisualTutorial de  Visual
Tutorial de Visual
 
Practicas visualbasic60
Practicas visualbasic60Practicas visualbasic60
Practicas visualbasic60
 
Modulo Derivadas
Modulo DerivadasModulo Derivadas
Modulo Derivadas
 
Matematica 1 usb
Matematica 1 usbMatematica 1 usb
Matematica 1 usb
 
Matematica universitaria
Matematica universitariaMatematica universitaria
Matematica universitaria
 
Matematica1 usb
Matematica1 usbMatematica1 usb
Matematica1 usb
 
Problemas resueltos de c++
Problemas  resueltos de c++Problemas  resueltos de c++
Problemas resueltos de c++
 

Recently uploaded

Algoritmos Paralelos - Actividad 14 - UNIBE.pdf
Algoritmos Paralelos - Actividad 14 - UNIBE.pdfAlgoritmos Paralelos - Actividad 14 - UNIBE.pdf
Algoritmos Paralelos - Actividad 14 - UNIBE.pdfdarosario3d
 
Herramientas de Mantenimiento_Soporte Técnico_David Andrade.pdf
Herramientas de Mantenimiento_Soporte Técnico_David Andrade.pdfHerramientas de Mantenimiento_Soporte Técnico_David Andrade.pdf
Herramientas de Mantenimiento_Soporte Técnico_David Andrade.pdfdaa100407
 
Formato de práctica reflexiva ante una problemática social.docx.pdf
Formato de práctica reflexiva ante una problemática social.docx.pdfFormato de práctica reflexiva ante una problemática social.docx.pdf
Formato de práctica reflexiva ante una problemática social.docx.pdfjuanrubenc78
 
02 - RUP_Introduccion_Definicion.pdf
02 - RUP_Introduccion_Definicion.pdf02 - RUP_Introduccion_Definicion.pdf
02 - RUP_Introduccion_Definicion.pdfRodrigo Cerón
 
Simuladores de circuitos electrónicos.pdf
Simuladores de circuitos electrónicos.pdfSimuladores de circuitos electrónicos.pdf
Simuladores de circuitos electrónicos.pdfLeonardoOa4
 
Virus -Josue Cabascango _20240322_194349_0000.pdf
Virus -Josue Cabascango _20240322_194349_0000.pdfVirus -Josue Cabascango _20240322_194349_0000.pdf
Virus -Josue Cabascango _20240322_194349_0000.pdfMiSpotify
 
03 - RUP_Elaboracion_Construccion_1_2024.pdf
03 - RUP_Elaboracion_Construccion_1_2024.pdf03 - RUP_Elaboracion_Construccion_1_2024.pdf
03 - RUP_Elaboracion_Construccion_1_2024.pdfRodrigo Cerón
 
Los mejores simuladores electrónicos que se pueden utilizar
Los mejores simuladores electrónicos que se pueden utilizarLos mejores simuladores electrónicos que se pueden utilizar
Los mejores simuladores electrónicos que se pueden utilizarjosuesj13
 
Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...
Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...
Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...AlexaRamirez39
 

Recently uploaded (9)

Algoritmos Paralelos - Actividad 14 - UNIBE.pdf
Algoritmos Paralelos - Actividad 14 - UNIBE.pdfAlgoritmos Paralelos - Actividad 14 - UNIBE.pdf
Algoritmos Paralelos - Actividad 14 - UNIBE.pdf
 
Herramientas de Mantenimiento_Soporte Técnico_David Andrade.pdf
Herramientas de Mantenimiento_Soporte Técnico_David Andrade.pdfHerramientas de Mantenimiento_Soporte Técnico_David Andrade.pdf
Herramientas de Mantenimiento_Soporte Técnico_David Andrade.pdf
 
Formato de práctica reflexiva ante una problemática social.docx.pdf
Formato de práctica reflexiva ante una problemática social.docx.pdfFormato de práctica reflexiva ante una problemática social.docx.pdf
Formato de práctica reflexiva ante una problemática social.docx.pdf
 
02 - RUP_Introduccion_Definicion.pdf
02 - RUP_Introduccion_Definicion.pdf02 - RUP_Introduccion_Definicion.pdf
02 - RUP_Introduccion_Definicion.pdf
 
Simuladores de circuitos electrónicos.pdf
Simuladores de circuitos electrónicos.pdfSimuladores de circuitos electrónicos.pdf
Simuladores de circuitos electrónicos.pdf
 
Virus -Josue Cabascango _20240322_194349_0000.pdf
Virus -Josue Cabascango _20240322_194349_0000.pdfVirus -Josue Cabascango _20240322_194349_0000.pdf
Virus -Josue Cabascango _20240322_194349_0000.pdf
 
03 - RUP_Elaboracion_Construccion_1_2024.pdf
03 - RUP_Elaboracion_Construccion_1_2024.pdf03 - RUP_Elaboracion_Construccion_1_2024.pdf
03 - RUP_Elaboracion_Construccion_1_2024.pdf
 
Los mejores simuladores electrónicos que se pueden utilizar
Los mejores simuladores electrónicos que se pueden utilizarLos mejores simuladores electrónicos que se pueden utilizar
Los mejores simuladores electrónicos que se pueden utilizar
 
Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...
Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...
Diseño de Algoritmos Paralelos. Mejorando la eficiencia computacional aprovec...
 

Programacion o.o.

  • 1. 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
  • 2. Maestría en Informática Aplicada a Redes 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.
  • 3. Maestría en Informática Aplicada a Redes 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
  • 4. Maestría en Informática Aplicada a Redes 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.
  • 5. Maestría en Informática Aplicada a Redes 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.
  • 6. Maestría en Informática Aplicada a Redes 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
  • 7. Maestría en Informática Aplicada a Redes 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.
  • 8. Maestría en Informática Aplicada a Redes 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.
  • 9. Maestría en Informática Aplicada a Redes 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
  • 10. Maestría en Informática Aplicada a Redes 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.
  • 11. Maestría en Informática Aplicada a Redes 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.
  • 12. Maestría en Informática Aplicada a Redes 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.
  • 13. Maestría en Informática Aplicada a Redes 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
  • 14. Maestría en Informática Aplicada a Redes 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
  • 15. Maestría en Informática Aplicada a Redes 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
  • 16. Maestría en Informática Aplicada a Redes 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
  • 17. Maestría en Informática Aplicada a Redes 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
  • 18. Maestría en Informática Aplicada a Redes 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.
  • 19. Maestría en Informática Aplicada a Redes 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
  • 20. Maestría en Informática Aplicada a Redes 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
  • 21. Maestría en Informática Aplicada a Redes 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
  • 22. Maestría en Informática Aplicada a Redes 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
  • 23. Maestría en Informática Aplicada a Redes 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:
  • 24. Maestría en Informática Aplicada a Redes 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.
  • 25. Maestría en Informática Aplicada a Redes 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:
  • 26. Maestría en Informática Aplicada a Redes 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
  • 27. Maestría en Informática Aplicada a Redes 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
  • 28. Maestría en Informática Aplicada a Redes 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.
  • 29. Maestría en Informática Aplicada a Redes 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.
  • 30. Maestría en Informática Aplicada a Redes 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.
  • 31. Maestría en Informática Aplicada a Redes 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
  • 32. Maestría en Informática Aplicada a Redes 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
  • 33. Maestría en Informática Aplicada a Redes 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.
  • 34. Maestría en Informática Aplicada a Redes 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
  • 35. Maestría en Informática Aplicada a Redes 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.
  • 36. Maestría en Informática Aplicada a Redes 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
  • 37. Maestría en Informática Aplicada a Redes 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
  • 38. Maestría en Informática Aplicada a Redes 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
  • 39. Maestría en Informática Aplicada a Redes 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
  • 40. Maestría en Informática Aplicada a Redes 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).
  • 41. Maestría en Informática Aplicada a Redes 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)
  • 42. Maestría en Informática Aplicada a Redes 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
  • 43. Maestría en Informática Aplicada a Redes 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
  • 44. Maestría en Informática Aplicada a Redes 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
  • 45. Maestría en Informática Aplicada a Redes 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.
  • 46. Maestría en Informática Aplicada a Redes 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.
  • 47. Maestría en Informática Aplicada a Redes 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,
  • 48. Maestría en Informática Aplicada a Redes 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.
  • 49. Maestría en Informática Aplicada a Redes 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
  • 50. Maestría en Informática Aplicada a Redes 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.
  • 51. Maestría en Informática Aplicada a Redes 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
  • 52. Maestría en Informática Aplicada a Redes 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
  • 53. Maestría en Informática Aplicada a Redes 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.
  • 54. Maestría en Informática Aplicada a Redes 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.
  • 55. Maestría en Informática Aplicada a Redes 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
  • 56. Maestría en Informática Aplicada a Redes 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.
  • 57. Maestría en Informática Aplicada a Redes 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.
  • 58. Maestría en Informática Aplicada a Redes 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:
  • 59. Maestría en Informática Aplicada a Redes 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