Maestría en Informática Aplicada a Redes
Página 15 de 190
III. FUNDAMENTOS TEORICOS
Los fundamentos teóricos plasmados en ...
Maestría en Informática Aplicada a Redes
Página 16 de 190
fáciles de implementar mediante este tipo de desarrollo que medi...
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 ventaja...
Maestría en Informática Aplicada a Redes
Página 18 de 190
de todas las nuevas herramientas basadas en un interfase de usua...
Maestría en Informática Aplicada a Redes
Página 19 de 190
Las clases permiten la agrupación de objetos que comparten las m...
Maestría en Informática Aplicada a Redes
Página 20 de 190
Podemos imaginarla encapsulación como introducir el objeto dentr...
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 de...
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...
Maestría en Informática Aplicada a Redes
Página 23 de 190
Introduce, por tanto, una posibilidad de refinamiento sucesivo d...
Maestría en Informática Aplicada a Redes
Página 24 de 190
las propiedades esenciales de un objeto, fuerza al desarrollador...
Maestría en Informática Aplicada a Redes
Página 25 de 190
• Describe el contexto en que ocurre.
• Describe los pasos a seg...
Maestría en Informática Aplicada a Redes
Página 26 de 190
Podemos mencionar otros autores que han contribuido a este tema ...
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ó tre...
Maestría en Informática Aplicada a Redes
Página 28 de 190
3.2.3.2 Patrones Estructurales
Los patrones estructurales se ocu...
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...
Maestría en Informática Aplicada a Redes
Página 30 de 190
o Resource Descriptor
o Retraer
• Input/output patterns: Describ...
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...
Maestría en Informática Aplicada a Redes
Página 32 de 190
regresa la misma instancia de la clase. La siguiente figura mues...
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 c...
Maestría en Informática Aplicada a Redes
Página 34 de 190
createDocument de un objeto que implementa la interfaz DocumentF...
Maestría en Informática Aplicada a Redes
Página 35 de 190
aplicación. Esto lo hace indirectamente a través de una instanci...
Maestría en Informática Aplicada a Redes
Página 36 de 190
diferentes, pero relacionados entre sí. La siguiente figura mues...
Maestría en Informática Aplicada a Redes
Página 37 de 190
conocimiento directo de estas clases de fábrica concretas. En lu...
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
Es...
Maestría en Informática Aplicada a Redes
Página 39 de 190
Utilizar un Data Access Object (DAO) para abstraer y encapsular ...
Maestría en Informática Aplicada a Redes
Página 40 de 190
La siguiente figura muestra el diagrama de secuencia de la inter...
Maestría en Informática Aplicada a Redes
Página 41 de 190
(mainframes/legales), servicios (servicio B2B u oficina de tarje...
Maestría en Informática Aplicada a Redes
Página 42 de 190
objetos de negocio no conocen la implementación de datos subyace...
Maestría en Informática Aplicada a Redes
Página 43 de 190
Las bases de datos orientadas a objetos se crearon para tratar d...
Maestría en Informática Aplicada a Redes
Página 44 de 190
Durante los últimos años se han creado muchos prototipos experim...
Maestría en Informática Aplicada a Redes
Página 45 de 190
El modelo orientado a objetos también soporta relaciones de much...
Maestría en Informática Aplicada a Redes
Página 46 de 190
del programa desaparecen cuando el programa termina su ejecución...
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 ...
Maestría en Informática Aplicada a Redes
Página 48 de 190
Las relaciones de muchos a muchos se pueden representar directam...
Maestría en Informática Aplicada a Redes
Página 49 de 190
aplicaciones permitiéndoles escribir sólo una vez los métodos qu...
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 fun...
Maestría en Informática Aplicada a Redes
Página 51 de 190
actualizará automáticamente la relación es_supervisada en el obj...
Maestría en Informática Aplicada a Redes
Página 52 de 190
identificador único. Un literal es un valor específico, como “Am...
Maestría en Informática Aplicada a Redes
Página 53 de 190
ODL es un lenguaje de especificación para definir tipos de objet...
Maestría en Informática Aplicada a Redes
Página 54 de 190
iteradora que vaya tomando valores en los objetos de la colecció...
Maestría en Informática Aplicada a Redes
Página 55 de 190
• Es posible almacenar procedimientos en las relaciones porque u...
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 d...
Maestría en Informática Aplicada a Redes
Página 57 de 190
adicionales como
Objetos complejos
y características
orientadas ...
Maestría en Informática Aplicada a Redes
Página 58 de 190
Stonebraker, gerente de Tecnología de la Informix Software, ha c...
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...
Maestría en Informática Aplicada a Redes
Página 60 de 190
El programa sabe que puede guardar y recuperar objetos, como si ...
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 imp...
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 esp...
Maestría en Informática Aplicada a Redes
Página 63 de 190
Este modelo establece un conjunto de prácticas o procesos clave ...
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écnica...
Maestría en Informática Aplicada a Redes
Página 65 de 190
Las organizaciones que utilizan CMM para mejorar sus procesos di...
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 s...
Maestría en Informática Aplicada a Redes
Página 67 de 190
EE.UU. que subcontratan empresas para el desarrollo de sus siste...
Maestría en Informática Aplicada a Redes
Página 68 de 190
De esta manera, las empresas exportadoras de software de la Indi...
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...
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 r...
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 (espe...
Maestría en Informática Aplicada a Redes
Página 72 de 190
Lo que la comunidad internacional está pidiendo es que se manten...
Maestría en Informática Aplicada a Redes
Página 73 de 190
• Forma disciplinada de asignar tareas y responsabilidades (quié...
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.
Upcoming SlideShare
Loading in …5
×

Programacion o.o.

614 views

Published on

Published in: Software
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
614
On SlideShare
0
From Embeds
0
Number of Embeds
37
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Programacion o.o.

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

×