Aspectos Avanzados de la Tecnología de Objetos

1. Aspectos Avanzados de laTecnología de Objetos 6. Objetos y componentes de software: Persistencia en el modelo de objetos. (2da parte) Dr. Juan José Aranda Aboy

2. Contenidos • Bases de datos orientadas a objetos. • Motores de persistencia. Opciones. • Estándares de objetos de datos: • Patrones utilizados para resolver el Modelo de Negocio y su Acceso • Patrones utilizados para resolver el Mapeo de la Persistencia • Patrones utilizados para resolver la Arquitectura de la Persistencia • Patrones utilizados para resolver el Comportamiento de la Persistencia Dr. Juan José Aranda Aboy

3. Objetivos específicos • Describir la correspondencia (mapping) objeto – relacional. • Conocer y aplicar apropiadamente los patrones utilizados. • Emplear apropiadamente los motores de persistencia. Dr. Juan José Aranda Aboy

4. Java Cryptography Architecture (JCA) Java Cryptography Extension (JCE) AWT 1.1 Swing JDO EJB Struts JSF (en SUN Microsystems) Junit jMaki AJAX RMI MFC COM+ .NET Seguridad de .NET Framework ADO NUnit ASP.NET AJAX CORBA ExpressWeb Framework (EWF) for Delphi 6 and 7 Control 4: Frameworks para analizar • Desarrollar: • Características generales del Framework. • Patrones de Diseño que utiliza. • Ejemplo de aplicación. • Referencia general adicional: Evolving Frameworks Dr. Juan José Aranda Aboy

5. Control 5: Sistema de votación • Diseñe el mapeo objeto relacional entre las clases definidas y las tablas de la base de datos del sistema de votación, para crear la persistencia. • Justifique la alternativa seleccionada. Dr. Juan José Aranda Aboy

6. Persistencia Concepto: • Habilidad del programador para lograr que sus datos sobrevivan a la ejecución de un proceso, para eventualmente reutilizarles en otros procesos. La Persistencia debe • Ser ortogonal: a cada objeto, independientemente de su tipo, de permitírsele convertirse en persistente como tal, sin una traducción explícita. • Además, debe estar implícita: el usuario no debe tener que explícitamente mover o copiar datos para convertirlos en persistentes. Dr. Juan José Aranda Aboy

7. Tres tipos diferentes de capas de acceso a la base de datos Dr. Juan José Aranda Aboy

8. Factores que conducen el diseño de capas de acceso objeto / relacionales • Funcionalidad versus costo. • Separación de problemas respecto a costos. • Rendimiento • Flexibilidad versus confiabilidad. • Sistemas del legado histórico. • Estilo de la aplicación. • Aplicaciones de diseño asistido por computador (CAD). • Herramientas CASE. Dr. Juan José Aranda Aboy

9. Funcionamiento de la persistencia Dr. Juan José Aranda Aboy

10. Framework para Persistencia ¿Qué es un Framework para Persistencia? • Un framework para persistencia mueve los datos del programa en su forma mas natural (objetos en memoria) hacia y desde un almacenamiento permanente de datos: la base de datos. • El framework para persistencia gestiona la base de datos y el mapeo entre dicha base de datos y los objetos, por lo que debe proporcionar funciones para: • Almacenar y recuperar los objetos en un mecanismo de almacenamiento persistente. • Confirmar (commit) y deshacer (rollback) las transacciones. • Su diseño debe ser extensible, para dar soporte a diferentes mecanismos de almacenamiento: bases de datos relacioneales, registros en archivos simples ó XML. Dr. Juan José Aranda Aboy

11. Ideas claves para desarrollar un framework de persistencia • Correspondencia • Identidad de objeto • Conversor (converter) de base de datos • Materialización y desmaterialización • Caché • Materialización perezosa • Proxies virtuales • Estado de transacción de los objetos • Operaciones de transacción Dr. Juan José Aranda Aboy

12. Correspondencia • Se debe establecer alguna correspondencia (mapeo – mapping) entre una clase y su almacenamiento persistente, y entre los atributos de los objetos y los campos (columnas) en un registro: Debe existir una correspondencia de esquemas entre los dos esquemas. Dr. Juan José Aranda Aboy

13. Representación de objetos como tablas • El patrón Representación de objetos como tablas propone la definición de una tabla en una base de datos relacional por cada clase de objeto persistente. • Los atributos de los objetos que contienen tipos de datos primitivos se corresponden con las columnas. Dr. Juan José Aranda Aboy

14. Roadmap para acceso a bases de datos relacionales Estos patrones son encontrados simplemente en las capas para el acceso objeto/relacional Dr. Juan José Aranda Aboy

15. Ejemplo del perfil (profile) de Modelado de Datos en UML Dr. Juan José Aranda Aboy

16. Modelo de datos Dr. Juan José Aranda Aboy

17. Mapeo de una jerarquía de clases Dr. Juan José Aranda Aboy

18. Atributos específicos de una entidad Ampliación de la jerarquía de clase Dr. Juan José Aranda Aboy

19. Cada clase concreta de la jerarquía se mapea contra una entidad Dr. Juan José Aranda Aboy

20. Impacto sobre cada entidad Dr. Juan José Aranda Aboy

21. Estrategias de mapeo Dr. Juan José Aranda Aboy

22. Comparación de las estrategias Dr. Juan José Aranda Aboy

23. Implementación de Asociaciones Dr. Juan José Aranda Aboy

24. Roadmap para mapeo de objetos a tablas Dr. Juan José Aranda Aboy

25. Identidad de objeto • Los registros y los objetos tienen un único identificador de objeto para relacionar fácilmente los registros con los objetos, y asegurar que no hay duplicados inapropiados: • El patrón Identificador de Objeto propone asignar un identificador de objeto (OID) a cada registro y objeto (ó proxy de un objeto). Dr. Juan José Aranda Aboy

26. Ejemplo de identidad de objeto Dr. Juan José Aranda Aboy

27. Fachada de persistencia • Se define una fachada para estos servicios: La FachadaDePersistencia delega las peticiones en objetos del subsistema. Dr. Juan José Aranda Aboy

28. Conversores de base de datos • Una Fabricación Pura conversor (mapper) de base de datos es responsable de la materialización y desmaterialización. Dr. Juan José Aranda Aboy

29. Correspondencia directa • El patrón Experto en Información sugiere que la propia clase del objeto persistente sea responsable de la materialización y desmaterialización, porque tiene algunos de los datos que se van a almacenar que necesita la responsabilidad. Si una clase de objetos persistentes define el código para almacenarse a si misma en una base de datos se denomina diseño de correspondencia directa. • Puede utilizarse si el código relacionado de la BD se genera y se inyecta en la clase mediante un compilador de post-procesamiento y el desarrollador nunca mantiene este código. • Problemas: • Fuerte acoplamiento de la clase de objetos persistentes y el conocimiento del almacenamiento persistente: violación de Bajo Acoplamiento. • Responsabilidades complejas en un área nueva no relacionada con las responsabilidades previas del objeto: violación de Alta Cohesión y del mantenimiento de la separación de intereses. Dr. Juan José Aranda Aboy

30. Patrón Conversor ó Intermediario • Enfoque clásico de correspondencia indirecta, que utiliza otros objetos para establecer la correspondencia con los objetos persistentes. • Se utiliza el patrón Intermediario (Broker) de Base de Datos, que propone crear una clase que sea responsable de materializar y desmaterializar un objeto almacenado. • También se le llama patrón Conversor (Mapper) de Base de Datos, puesto que describe su responsabilidad. • Se define una clase diferente que establece la correspondencia para cada clase de objetos persistentes. Dr. Juan José Aranda Aboy

31. Cada objeto persistente – clase propia que lleva a cabo la correspondencia Dr. Juan José Aranda Aboy

32. Método Plantilla para objetos conversores • La idea es crear un método (patrón GoF Método Plantilla) en una superclase que define el esqueleto de un algoritmo, con sus partes variables e invariables. • El Método Plantilla invoca otros métodos. Las subclases pueden redefinir algunos métodos que varían para añadir su propio comportamiento: Dr. Juan José Aranda Aboy

33. Redefinición del método de enganche Dr. Juan José Aranda Aboy

34. Materialización y desmaterialización • La materialización es el acto de transformar una representación de datos no orientada a objetos de un almacenamiento persistente en objetos. • La desmaterialización (passivation) es la actividad opuesta. • Los servicios persistentes almacenan en una caché los objetos materializados por razones de rendimiento. • Materialización perezosa: No todos los objetos se materializan de una vez; una instancia particular sólo se materializa bajo demanda, cuando se necesita. • Representantes (proxies) virtuales: La materialización perezosa puede implementarse utilizando una referencia inteligente que se conoce como representante (proxy) virtual. Dr. Juan José Aranda Aboy

35. Estado de transición de los objetos • Es útil conocer el estado de los objetos en función de sus relaciones con la transacción actual: conocer qué objetos han sido modificados (están sucios) de manera que sea posible determinar si es necesario que se guarden de nuevo en el almacenamiento persistente. • Diagrama de la máquina de estados para ObjetoPersistente: Dr. Juan José Aranda Aboy

36. Aplicación del patrón Estado • Contexto / Problema: El comportamiento de un objeto depende de su estado, y sus métodos contienen la lógica de casos que reflejan las acciones condicionales dependientes del estado. • Solución: Crear clases estado para cada estado, que implementan una interfaz común. En lugar de definir en el objeto de contexto las operaciones que dependen del estado, se delegan en su objeto del estado actual. Debe asegurarse que el objeto de contexto referencie siempre al objeto estado que refleja su estado actual. Dr. Juan José Aranda Aboy

37. Operaciones de transacción • Informalmente, una transacción es una unidad de trabajo - conjunto de tareas- que deben completarse con éxito ó no se debe realizar ninguna. • Una transacción es atómica: indivisible. • Comúnmente termina mediante las operaciones confirmar (commit) ó deshacer (rollback) • Las tareas de una transacción pueden incluir inserción, actualización, eliminación de objetos y combinaciones de estas operaciones, que pueden ser solicitadas en cualquier orden. • Esto conduce al patrón GoF Command: Defina una clase por cada tarea que implementa una interfaz común. Dr. Juan José Aranda Aboy

38. Clases Command para las operaciones de la base de datos Dr. Juan José Aranda Aboy

39. Jerarquía de clases del mecanismo de persistencia Dr. Juan José Aranda Aboy

40. Jerarquía de clases de las sentencias SQL Dr. Juan José Aranda Aboy

41. Boceto del diseño de una capa de persistencia Dr. Juan José Aranda Aboy

42. Enfoque arquitectónico para la carga de datos Dr. Juan José Aranda Aboy

43. Ejemplo de framework para persistencia Dr. Juan José Aranda Aboy

44. Cuestiones adicionales de interés en el diseño de un framework de persistencia • Desmaterialización de los objetos: • La desmaterialización de jerarquías de composición requiere la colaboración entre múltiples conversores y el mantenimiento de tablas asociativas. • Materialización y desmaterialización de las colecciones. • Consultas a grupos de objetos. • Gestión completa de transacciones • Gestión de los errores cuando falla una operación de la base de datos. • Acceso multiusuario y estrategias de bloqueo. • Seguridad - control de acceso a la base de datos. Dr. Juan José Aranda Aboy

45. Responsabilidades fundamentales de un sistema de gestión de bases de datos orientado a objetos Dr. Juan José Aranda Aboy

46. Responsabilidades fundamentales de un sistema de gestión de bases de datos orientado a objetos (2) Dr. Juan José Aranda Aboy

47. Referencias y otros enlaces de interés • The Design of a Persistence Framework • Accessing Data Through Persistence Frameworks • Automated Unit Testing Frameworks • An Introduction to Java Object Persistence with EJB • Evolving Frameworks • Introduction to Patterns and Frameworks • Patterns for Object / Relational Mapping and Access Layers • Aprenda UML: Esquema de persistencia • USIC Tutoriales: UML, JSP , JavaScript Dr. Juan José Aranda Aboy

48. Referencias anteriores: • Motores de Persistencia • Persistencia de Objetos Java Utilizando JDO • PRB: Modelo de persistencia de objetos COM de SQL Server • Connolly, T.M. & Begg, C.E. “Sistemas de Bases de Datos” 4ta ed. Pearson Addison Weasley, 2005, Caps. 25 al 30 pp 729-1034 • Larman, C. “UML y Patrones” 2da ed. Pearson Prentice Hall, 2004, Cap. 34 pp 501-527 • Deitel, H.M. & Deitel, P.J. “Java: Cómo Programar” 5ta ed. Pearson Educación, 2004, Caps. 23 al 25 pp 1073-1189 • Persistence Options for Object-Oriented Programs • Object/Relational Access Layer Patterns • Java Persistence API • Java Transaction API (JTA) • Java Transaction Service (JTS) Dr. Juan José Aranda Aboy

49. Referencias anteriores:Desacople de impedancia Objeto-Relacional • http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch Ejemplos de problemas de desacople: • http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx Microsoft recientemente anució soporte a entidades en ADO.NET 3.0 y que aceptó la Java Persistence API como sustituta tanto de los Beans EJB de Entidad y de JDO: • The ADO.NET Entity Framework Overview • ADO.NET team blog Dr. Juan José Aranda Aboy

50. Referencias anteriores: Mapeo Objeto-Relacional • Object-relational mapping • Object Relational Mapping • Techniques for Successful Evolutionary/Agile Database Development: • Mapping Objects to Relational Databases: O/R Mapping In Detail • The Object-Relational Impedance Mismatch • Object Relational Tool Comparison • Object Relational Tool Comparison in .NET • Core J2EE Design Pattern: Data Access Objects • Patterns for Object / Relational Mapping and Access Layers • (:-) Choosing an Object-Relational mapping tool • JDBCPersistence Fast ORM for Java • O/R Mapping Products Dr. Juan José Aranda Aboy