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

Dr. Juan José Aranda Aboy 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

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

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 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 Dr. Juan José Aranda Aboy

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

Dr. Juan José Aranda Aboy 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

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

Dr. Juan José Aranda Aboy 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

Funcionamiento de la persistencia Dr. Juan José Aranda Aboy

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

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

Dr. Juan José Aranda Aboy 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

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

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

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

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

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

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

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

Impacto sobre cada entidad Dr. Juan José Aranda Aboy

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

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

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

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

Dr. Juan José Aranda Aboy 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dr. Juan José Aranda Aboy 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

Dr. Juan José Aranda Aboy Responsabilidades fundamentales de un sistema de gestión de bases de datos orientado a objetos OODBMS Manifesto: Mandatory Features Object/Relational Access Layers: Covered by (1) Complex Objects Your programming language for business objects (like C++, Smalltalk, Java, ...), your RDBMS plus an access layer. (2) Object Identity See Object Identity Pattern (3) Encapsulation Your programming language (4) Types and Classes (5) Class or Type Hierarchies Your programming language plus patterns for Mapping Objects to Tables. (6) Overriding, overloading and late binding Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy Responsabilidades fundamentales de un sistema de gestión de bases de datos orientado a objetos (2) OODBMS Manifesto: Mandatory Features Object/Relational Access Layers: Covered by (7) Computational Completeness Your programming language (8) Extensibility Your programming language plus patterns for Mapping Objects to Tables. (9) Persistence Whole access layer plus relational database (RDBMS). (10) Secondary storage management RDBMS (11) Concurrency RDBMS plus patterns for transaction control and locking strategies. (12) Recovery (13) Ad Hoc Query Facility access layer on top of RDBMS Dr. Juan José Aranda Aboy

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

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

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

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

Referencias anteriores: Enlaces a herramientas Java Data Objects (JDO) Introduction to Java Data Objects (JDO) Enterprise Java Bean (EJB) JavaEE5 Tutorial - Part 3 Oracle TopLink BEA Kodo™ 4.1 SAP NetWeaver Application Server, Java EE 5 Edition Apache OpenJPA GlassFish Java Persistence API Reference Implementation, TopLink Essentials Hibernate: Relational Persistence for Java and .NET (JBoss) Descarga Dr. Juan José Aranda Aboy

Referencias anteriores: Enlaces a herramientas (2) Foundations of Object-Relational Mapping - ChiMu Corporation Mapping tools for .NET: SharpToolbox' Object-Relational Mapping category Mapping tools for Java: JavaToolbox' Object-Relational Mapping category Tools to handle persistence and data access layers for .NET: SharpToolbox' Persistence - Data-tier category General code generation tools for .NET SharpToolbox' Code Generation category Ways to see data from an application developer's perspective - Frans Bouma A First Look at ObjectSpaces in Visual Studio 2005 Introduction to ObjectSpaces Dr. Juan José Aranda Aboy

Referencias anteriores: Ejemplos de NetBeans 5.5 Using Hibernate With the NetBeans Visual Web Pack http://www.netbeans.org/kb/55/vwp-hibernate.html Creating a Simple Web Application in NetBeans IDE Using MySQL http://www.netbeans.org/kb/55/mysql-webapp.html Connecting to a MySQL Database in NetBeans IDE http://www.netbeans.org/kb/55/mysql.html EJB Technology and Java Persistence: Java Persistence Using Hibernate as the Persistence Manager for an Application EJB 3.0 Enterprise Beans CMP Mapping in J2EE 1.4 Applications Testing EJB 2.0 Enterprise Beans in NetBeans IDE Dr. Juan José Aranda Aboy