Fundamentos de Ingeniería de Software

Fundamentos de Ingeniería de Software Marcello Visconti y Hernán Astudillo Departamento de Informática Universidad Técnica Federico Santa María {visconti,hernan} en inf.utfsm.cl Fundamentos de Ingeniería de SW 1 Objetivos: Definir el concepto de esquema (Framework) Aplicar patrones para el diseño de un modelo persistente Método de la Plantilla Instanciación de Objetos complejos Uso de Agentes virtuales Fundamentos de Ingeniería de SW 2 1

Introducción En los sistemas actuales es necesario guardar información en medios de almacenamiento persistente (Bases de Datos) Cómo guardar objetos en dichos medios? Se introducirá un esquema de persistencia para enfrentar esta problemática Objeto persistente: Objeto instanciado en memoria que debe ser almacenado en un medio no volátil por ej., EspecificacionDeProducto Objetivo: Diseñar un esquema que permita diseñar objetos que den servicios (métodos) a otros objetos para ser almacenados en un medio persistente Fundamentos de Ingeniería de SW 3 Mecanismos de Almacenamiento Mecanismos de Almacenamiento más comunes son: Bases de datos Orientadas a Objeto: Presentan la ventaja de no necesitar servicios específicos de persistencia. Bases de datos Relacionales: Son las más utilizadas hoy en día. No poseen métodos para almacenamiento de objetos. Se requieren de servicios especiales para almacenar objetos en las tablas. Fundamentos de Ingeniería de SW 4 2

Esquema (Framework) Esquema: subsistema expandible de un conjunto de servicios afines. Conjunto cohesivo de clases que prestan servicios a la parte fundamental e invariable de un sistema lógico. Contiene clases concretas y abstractas definiendo las interfaces e interacciones en que participarán. En general es necesario que el usuario defina subclases adaptando los servicios definidos en el esquema. Posee clases abstractas que pueden incluir métodos abstractos y concretos. Fundamentos de Ingeniería de SW 5 Esquema de Persistencia [1] Esquema de persistencia es un conjunto reutilizable de clases que presentan servicios a los objetos persistentes Se utiliza para trabajar con bases de datos relacionales, una API de servicios de datos orientados a registros (Microsoft ODBC) u otro mecanismo de almacenamiento No se utiliza en Bases de Datos orientadas a objetos En general, este esquema debe traducir los objetos a registros para guardarlos en una base de datos y viceversa Fundamentos de Ingeniería de SW 6 3

Esquema de Persistencia [2] Objetos realizan llamadas a servicios implementados en el esquema de persistencia Definición n del sistema Traduce los objetos a registros y a la inversa para almacenarlos en algún medio de almacenamiento Esquema relacional de persistencia de objetos Base de Datos Relacional Fundamentos de Ingeniería de SW 7 Esquema de Persistencia - Requerimientos Un Esquema de Persistencia debería ofrecer los siguientes servicios: Almacenamiento y recuperación de objetos Transacciones del tipo commit y rollback commit - completar la transacción de guardar rollback - deshacer la transacción, restaurar el estado anterior El diseño de un EP debe considerar lo siguiente: Extendible para otros medios de almacenamiento Realizar la menor cantidad posible de modificaciones al código Fundamentos de Ingeniería de SW 8 4

Términos [1] Mapeo Relación entre una clase y su almacenamiento persistente (p.ej. una tabla de la BD), y entre los atributos del objeto y los campos (columnas) de un registro. Identidad del Objeto Los registros y los objetos deben tener un identificador único para relacionarlos fácilmente y evitar duplicados. Broker (Intermediario de Base de Datos) Agente especializado ( broker ) de la Base de Datos se encarga de materializar y desmaterializar. Materialización Es el acto de transformar una representación no orientada a objetos (e.g registros) a objetos. Desmaterialización Acto contrario a Materializar. Fundamentos de Ingeniería de SW 9 Términos [2] Caché Los Brokers poseen un caché (generalmente en memoria principal) en donde almacenan los objetos materializados. Materialización lenta por demanda (MLPD) La materialización se lleva a cabo únicamente cuando el objeto almacenado es necesitado por otro. Referencias inteligentes Para hacer transparente la MLPD se crea una referencia inteligente llamada agente virtual. Objetos complejos Materializaciones de estructuras complejas de objetos. Fundamentos de Ingeniería de SW 10 5

Términos [3] Estado de la transacción del Objeto El estado de un objeto persistente puede modificarse en una transacción, por lo que es deseable llevar un registro de los cambios que sufre para realizar la actualización. Operaciones de transacciones Operaciones commit y rollback. Búsqueda Localización y materialización de los objetos a partir de algunos criterios. Fundamentos de Ingeniería de SW 11 Mapeo Cómo mapear un objeto a un archivo o a un esquema de bases de datos relacional? El patrón Representación de objetos como tablas propone definir una tabla por objeto persistente, en donde sus atributos equivalgan a una columna de la tabla Es una buena aproximación para tipos primitivos de datos, pero para tipos complejos, este método no es tan simple Fundamentos de Ingeniería de SW 12 6

Identidad del Objeto [1] Cómo identificar a que instancia de objeto corresponden los registros de la tabla? Conviene contar con un medio que relacione los registros con los objetos y que asegure la no duplicidad de éstos. El patrón Identificador de Objetos (IDO) propone asignar un IDO a cada registro y objeto (o agente de un objeto) que los relacione. En general, es un valor alfanumérico. Toda tabla de la base de datos relacional tiene un IDO como clave primaria, el que también está contenido como atributo en el objeto. Fundamentos de Ingeniería de SW 13 Identidad del Objeto [2] Ejemplo: Venta Fecha IDO hora :Venta fecha=1/1/1997 Ido=xyz123 Hora=10:00 IDO Fecha Hora setermina() Xyz123 1/1/1997 10:00 :Venta Abc345 2/2/1997 14:00 El IDO puede definirse en un objeto Agente fecha=2/2/1997 Ido=Abc345 Hora=14:00 Clave Primaria Fundamentos de Ingeniería de SW 14 7

Broker (Intermediario de la BD) [1] Quién es responsable de materializar y desmaterializar los objetos desde un almacenamiento persistente, p.ej. EspecificacionDeProducto? El patrón Experto señala que debería hacerlo la clase de objeto persistente EspecificacionDeProducto. No es muy buena solución: Existiría un muy alto acoplamiento. Se pierde la cohesión pues la responsabilidad está fuera del dominio del objeto. Fundamentos de Ingeniería de SW 15 Broker (Intermediario de la BD) [2] El patrón Intermediario de Base de Datos propone construir una clase que se encargue de materializar, desmaterializar y guardar un objeto en un objeto caché (Clase intermediaria). Cada objeto persistente puede tener su propia clase intermediaria y que los mecanismos de almacenamiento pueden contar con varias clases de Intermediarios. Superclase abstracta de todos los intermediarios de bases de datos relacionales IntermediariodeEP Clase concreta encargada de materializar los objetos Ventas a partir de una base de datos relacional Intermediariode EPRelacional Intermediariode EPArchivos IntermediarioRelacional Intermediario IntermediariodeArchivos Intermediariode deespecifdeproducto RelacionaldeVentas EspecifdeProductos ArchivodeVentas Fundamentos de Ingeniería de SW 16 8

Diseño de Intermediarios: Método de la Plantilla El patrón utilizado para el diseño de clases intermediarias. Se define una clase plantilla, la cual puede ser utilizada para definir el esqueleto de un algoritmo: con partes variables que se pueden modificar al heredarse a una subclase. e invariables, que no pueden ser modificadas. Estos métodos pueden o no estar en una subclase y por general llaman a otros métodos. Se sigue el Principio de Hollywood: no nos llame, nosotros le llamaremos. Es decir, un método de una subclase será ejecutado sólo si este es llamado desde la clase en la cual fue definido. Fundamentos de Ingeniería de SW 17 Diseño de Intermediarios: Método de la Plantilla Ejemplo: metododeplantilla {.. operacionprimitiva() operacionconcreta() } Operaciones abstractas primitivas: -partes variables -se desplazan (emiten) en la subclase Operaciones concretas -comportamiento por omisión -si puede ser desplazado en una subclase, recibe el nombre de método de gancho Método de plantillas: define el esqueleto de un algoritmo con partes variables e invariables. Clase Abstracta MetododePlantilla() operacionprimitiva() operacionconcreta() Clase Concreta operacionprimitiva() Fundamentos de Ingeniería de SW 18 9

Materialización: Patrón método de plantillas [1] La lógica de materialización suele requerir que se genere una instancia de la clase apropiada y que luego se desplacen los datos del registro hacia los atributos de la nueva instancia. IntermediariodeEP RegistrodeBDR objectwith(anoid) : Object incache(anoid) : Object materializewith(anoid) : Object campo(nombredearchivo) : Objeto 1 IntermediarioEPRelacional IntermediariodeEPdeArchivos Registro-actual-de 1 IntermediarioRelacionaldeEspecific aciondeproducto currentrecordasobject() : Object materializewith(oid) : Object selectfirst(query) : Object currentrecordasobject() : ProdSpec materializewith(oid) : Object IntermediarioRelacionaldeVentas currentrecordasobject() : Sale Una técnica totalmente diferente para materializar a partir de archivos planos. Fundamentos de Ingeniería de SW 19 Materialización : Patrón método de plantillas [2] Tener un Intermediario para los mecanismos de almacenamiento persistente es muy útil para desarrollador. Puede agregar más clases para adaptarla a nuevos medio o a los ya existentes. Clase IntermediariodeEP se comporta como un agente virtual. A través del método objectwith(anoid) toma el identificador como parámetro y devuelve su objeto. Posee manejo de Caché. Si el objeto ya ha sido referenciado antes, no será materializado nuevamente. El método de la plantilla define partes variables e invariables: Invariables: Métodos que no pueden ser modificados. Variables: Métodos que pueden ser adaptados por los programadores para amoldar el esquema a un tipo específico de tecnología o método. Fundamentos de Ingeniería de SW 20 10

Materialización : Patrón método de plantillas [3] Características clásicas del diseño de esquemas: Uso de métodos definidos con anterioridad en superclases abstractas. Incorporación de subclases definidas por el programador. Definición de los métodos de operación primitiva en las subclases para completar los métodos de plantilla heredados. Fundamentos de Ingeniería de SW 21 Caché El mecanismo de caché puede ser utilizado para dos cosas: Mejorar el desempeño. Materializar es lento. Soporte de las operaciones de administración de transacciones. El patrón Administración de Caché propone asignar a los intermediarios la responsabilidad de administrar el caché. Si se tiene un intermediario diferente para cada tipo de objeto persistente, cada uno de ellos deberá tener su propia caché. Al materializar un objeto este se deja en caché con su identificador como clave. El intermediario primero buscará en este antes de materializar un objeto. Fundamentos de Ingeniería de SW 22 11

Caché: Administración de Transacciones IntermediariodeEP CachedeObjetos objectwith(anoid): Object incache(anoid): Object materializewith(anoid): Object 1 Guarda-objetos-en 6 Add(OID, Object) Find(OID): Object isempty (): Boolean Otra forma de conservar los objetos es en varias cachés, según el estado que presenten dentro del contexto de la transacción actual. El intermediario conserva hasta 6 tipos diferentes de cachés lo que permite sentar las bases para realizar las transacciones sobre la BD. Fundamentos de Ingeniería de SW 23 Caché: Tipos Los 6 tipos de cachés son: Caché Limpia y Nueva: Objetos nuevos sin modificaciones. Caché Limpia y Vieja: Objetos viejos que se materializan de una BD sin modificaciones. Caché Sucia y Nueva: Objetos nuevos, modificados. Caché Sucia y Vieja: Objetos viejos que se materializaron de una BD y que fueron modificados. Caché Eliminar Nueva: Objetos nuevos a eliminar. Caché Eliminar Vieja: Objetos viejos que se materializaron a partir de una base de datos y que deben ser eliminados. Fundamentos de Ingeniería de SW 24 12

Referencias Inteligentes Materialización lenta por demanda: materialización de un objeto sólo ocurre cuando sea absolutamente necesario. Se puede implementar a través de un agente virtual. Agente Virtual (Proxy): representante de un objeto real. Este es el encargado de materializar al objeto real por primera vez cuando se referencia. Los clientes deberán interactuar con el agente en vez de hacerlo con el objeto real. Un objeto cliente tiene una referencia al objeto Agente Virtual y no al sujeto real. El agente virtual implementa la misma interfaz que ese sujeto. Fundamentos de Ingeniería de SW 25 Referencias Inteligentes: Ejemplo Ejemplo con VentasLineadeProductos y EspecificaciondeProducto. El diseño está basado en el supuesto que los agentes conocen el identificador de objetos de su sujeto real. Cuando la materialización es requerida, el identificador sirve para localizar y recuperar el sujeto real. <<Clase>> VentasLineadeProducto cantidad Subtotal() n <<Interfaz>> IEspecificaciondeProducto descripcion() precio() cup() Descrita_por <<Clase>> <<Clase>> AgenteEspecificaciondeProducto EspecificaciondeProducto ido : IDO descripcion Agente_de precio description() cup 1 getrealsubject() materializesubject() n 1 descripcion() price() precio() cup() cup() Fundamentos de Ingeniería de SW 26 13

Agente Virtual (Proxy) Generalizado La especificación de todos los agentes puede definirse en una superclase llamada AgenteVirtual. Así solo es necesario modificar las instancias específicas para atender a los diferentes objetos reales que componen el sistema. <<Clase>> AgenteVirtual ido : IDO getrealsubject() materializesubject() <<Clase>> AgenteVirtualConcreto solicitud() n comportamiento y atributos generales de todos los agentes <<Interfaz>> InterfazdeAgente solicitud() Agente-de <<Clase>> SujetoReal solicitud() Fundamentos de Ingeniería de SW 27 1 Agentes Virtuales (Proxies) e intermediarios en BD Un agente virtual (AV) puede colaborar con un Intermediario de Bases de Datos ( Broker ) a fin de Materializar un objeto, utilizando el identificador de objetos usado por el agente. <<Clase>> AgenteVirtual ido : IDO getrealsubject() materializesubject() Materializa-a partir de 1 1 IntermediariodeEP objectwith() incache() materializewith() if (realsubject not materialized) materializesubject() return realsubject Fundamentos de Ingeniería de SW 28 14

Conexión entre AV e Intermediario de BD Cómo un AV concreto sabe cuál intermediario de BD habrá de utilizar? Utilizando el patrón Método de Fábrica: La operación primitiva se encarga de crear una instancia. El agente es responsable de pedir el representante para la BD. Es conveniente tener una sola instancia de cada intermediario. Cuando se usan agentes virtuales, conviene que toda referencia a objetos se efectúe a través de objetos agente y no a través de referencias directas. Todas las definiciones de atributos se refieren a objetos agentes a interfaces, no a objetos directos. Todos los parámetros se refieren a objetos agente o a interfaces. Fundamentos de Ingeniería de SW 29 Conexión entre AV e Intermediario de BD Método Fabrica <<Clase>> AgenteVirtual ido : IDO createbroker() getbroker() getrealsubject() materializesubject() //método de plantilla if(broker not created) broker:=createbroker() Return broker intermediario 1 1 realsubject:= getbroker().objectwith(ido) IntermediariodeEPRelacional ObjectWith() <<Clase>> AgenteEspecificaciondeProducto createbroker() description() price() upc() IntermediariodeEPRelacional return ProductSpecificationRelationalBroker.Instance() Fundamentos de Ingeniería de SW 30 15

Cómo representar Relaciones en Tablas Cómo representar las relaciones de objetos en una tabla de una base de datos relacional? Utilizando el patrón Representación de objetos como tablas. Según la relación entre los objetos se propone: Asociaciones uno a uno. Colocar una clave foránea del IDO en una o en las dos tablas que representan los objetos en la relación. Asociaciones uno a muchos: Crear una tabla asociativa que registre los identificadores de cada objeto en la relación. Asociaciones muchos a muchos: Crear una tabla asociativa que registre todos los identificadores de objetos en la relación. Fundamentos de Ingeniería de SW 31 Patrón Instanciación de Objetos Complejos [1] Problema: Cuándp implementar Agentes Virtuales e Intermediarios de BD? Cuando los objetos pueden pertenecer a una jerarquía de composición profunda. Cuando si se quiere materializar un objeto es posible que haya que materializar también decenas de objetos relacionados. La materialización de una jerarquía integra de composición usa el espacio lenta e ineficientemente. Solución: Aplazar la materialización de los objetos, dependiendo de los patrones de acceso y los requerimientos de desempeño, hasta que sea necesario. Hay veces en que conviene materializar uno o dos niveles de profundidad Con un intermediario distinto para cada objeto persistente, es posible decidir, intermediario por intermediario, el grado de materialización de los objetos persistentes y sus objetos asociados Fundamentos de Ingeniería de SW 32 16

Patrón Instanciación de Objetos Complejos [2] Ejemplo: Materializar la instancia VentasLineadeProducto. Suponer que la información se encuentra almacenada en las siguientes tablas. IDO Cantidad IDO descripcion precio cup vli1 1 p1 pañuelos 1.50 111 vli2 2 p2 tempeh 2.25 222 ventaslineadeproducto EspecifdeProducto VLI-IDO vli1 vli2 EP-IDO P1 P2 ventaslineadeproducto-a-especifdeproducto Fundamentos de Ingeniería de SW 33 Patrón Instanciación de Objetos Complejos [3] Se sabe que el IDO de VentasLineadeProducto es vli1. Si se ejecuta el siguiente código: //Crear el agente AgenteVentasLineadeProducto unvli= new AgenteVentasLineadeProducto( vli1 ), //Causa materialización de los objetos Int total = unvli.subtotal(); Fundamentos de Ingeniería de SW 34 17

Patrón Instanciación de Objetos Complejos [4] 1: o:=getrealsubject() Crear("vli1") t:=subtotal() : AgenteVentasLineaDeProducto 2: t:=subtotal() o : VentasLineaDeProducto o:=getrealsubject() 1: [not materialized] materializesubject() 1.1: b:=getbroker() : AgenteVentasLineaDeProducto 1.2: o:=objectwith((ido) Finalmente, llega a este mensaje N: o:=currentrecordasobject() VentasLineadeProducto vli:=new VentasLineadeProducto vli.cantidad(currentrecord.field("cantidad )) //recuperar el IDO de EspecifDeProducto asociado SELECT * from VentasLineadeProducto-a-EspecifiDeProducto b : IntermediarioVentasLineaDeProducto wherevli-ido= :ido EspecifDeProdIDO=currentRecord.field("EP-IDO") //crear el intermediario a la EspecifDeProducto IntermediarioEspecifdeProducto intermediario = new IntermediarioEspecifiDeProducto(EspecifDeProdIDO) //guardar intermediario en VLI vli.especifdeproducto=intermediario return vli Fundamentos de Ingeniería de SW 35 Patrón Instanciación de Objetos Complejos [5] VentasLineadeProducto referencia a un agente, no a la EspecificaciondeProductos real. Esta última no se materializará mientras no se le envíe el mensaje precio. Fundamentos de Ingeniería de SW 36 18

Patrón Instanciación de Objetos Complejos [6] 2: o:=getrealsubject() 1: p:=precio() t:=subtotal() : VentasLineaDeProducto : AgenteEspecifDeProducto 3: p:=precio() o : EspecificacionDeProducto o:=getrealsubject() 1: [not materialized] materializesubject() 1.1: b:=getbroker() : AgenteEspecifDeProducto 1.2: o:=objectwith(()ido) Finalmente, llega a este mensaje N: o:=currentrecordasobject() EspecificacionDeProducto ep:=newespecificaciondeproducto ep.descripcion=currentrecord.field("descripcion") ep.precio=currentrecord.field("precio") ep.cup=currentrecord.field("cup") b : IntermediarioEspecifDeProducto return ep Fundamentos de Ingeniería de SW 37 Operaciones Transaccionales [1] Estado de transacción de los objetos: Limpio y nuevo. Objetos nuevos, sin modificaciones Limpio y viejo. Objetos viejos, sin modificaciones Sucio y nuevo. Objetos nuevos, sin modificaciones Sucio y viejo. Objetos viejos materializados a partir de una base de datos con modificaciones Eliminar nuevo. Objetos nuevos que deben ser eliminados Eliminar viejo. Objetos viejos que fueron materializados a partir de una base de datos y que deben ser eliminados El Intermediario de BD conservará cachés especiales para cada uno de estos estados y garantizará con ello que un objeto está en la caché apropiada. Fundamentos de Ingeniería de SW 38 19

Operaciones Transaccionales [2] Cómo se ensucia un objeto? Un objeto se ensucia al modificar uno de sus atributos a través de un método mutador (establecedor) Por ejemplo: // clase EspecificacióndeProducto void price(float p) { price = p; BrokerServer.instance().dirty(this); } Al ServidordeIntermediario (Fachada) se le notificará que un objeto est á sucio Este encontrará el Intermediario apropiado de la BD para esta clase de objetos y le notificará que el objeto está sucio El Intermediario introduce el objeto en una caché sucia. Vieja y sucia si era un objeto materializado Fundamentos de Ingeniería de SW 39 Operaciones Transaccionales [3] Cómo eliminar? Es necesario registrar explícitamente el hecho para que se pueda realizar la modificación correspondiente en la BD luego de una operación commit Por ejemplo: // clase CatalogodeProductos void removeproductspec(productspec p) { // eliminar p en la colección de ProductSpec ProductSpec.remove(p); // notificarle al intermediario que p debe eliminarse BrokerServer.instance().delete(p); } Al ServidordeIntermediario se le notificará que un objeto est á sucio Fundamentos de Ingeniería de SW 40 20

Operaciones Transaccionales [4] Operación commit Una vez se decide instalar la transacción, se envía un mensaje commit a la Fachada ServidordeIntermediario BrokerServer.instance().commit(); El método ServidordeAgente.commit simplemente dirige un mensaje commit a cada intermediario. void BrokerServer.commit() { } for each broker b b.commit() Fundamentos de Ingeniería de SW 41 Operaciones Transaccionales [5] En una transacción los objetos pueden ser creados, modificados y eliminados. Suponiendo que se encuentren en la caché del estado correspondiente de la transacción, el mensaje commit debe cumplir con las siguientes reglas: Caché Nueva y Limpia - Insertar en BD, Dirigirse a Caché Vieja y Limpia Caché Vieja y Limpia - Ignorar, no han cambiado Caché Nueva y Sucia - Insertar en BD, Dirigirse a Caché Vieja y Limpia Caché Vieja y Sucia - Actualizar en BD, Dirigirse a Caché Vieja y Limpia Caché Nueva Eliminada - Eliminar en caché Caché Vieja Eliminada - Eliminar en DB, Eliminar en caché Fundamentos de Ingeniería de SW 42 21

Operación rollback. Operaciones Transaccionales [6] Una vez decidido someter la transacción a un rollback, se envía un mensaje rollback a la Fachada ServidordeIntermediario BrokerServer.instance().rollback(); El método ServidordeAgente.rollback simplemente dirige un mensaje rollback a cada intermediario. Las reglas del rollback son las siguientes: Caché Vieja y Limpia - Ignorar, no han cambiado. El resto de las cachés - Eliminar en la caché. Fundamentos de Ingeniería de SW 43 Busca de objetos en almac. persistente [1] Recuperar un registro a partir de un almacenamiento persistente depende de las herramientas, bibliotecas y del sistema operativo. Por ejemplo, en Windows se puede utilizar los servicios del DAO. Dentro del esquema se definió el método IntermediariodeEPRelacional.SeleccionarPrimero(consulta) para localizar el primer registro que cumpla con los criterios de la consulta. En general, un Intermediario de BD debe ofrecer 2 formas de búsqueda: Búsqueda mediante el identificador de objetos. Búsqueda mediante criterios arbitrarios, como las clave primaria del dominio, por ejemplo, RUT. Fundamentos de Ingeniería de SW 44 22

Busca de objetos en almac. persistente [2] Con qué criterio debería recuperarse el objeto raíz en una jerarquía de composición? Los objetos raíz no pueden materializarse utilizando Agentes Virtuales y realizando una búsqueda con sus identificadores de objeto como clave de consulta. Por ejemplo, una instancia Venta y sus instancias asociadas VentasLineadeProductos y sus EspecificacionesdeProductos. Las instancias asociadas se materializan utilizando Agentes Virtuales en base al valor de identificador de objetos del raíz (Venta), pero cómo se prepara la escena y se introduce en la memoria esta primera instancia de Venta? Fundamentos de Ingeniería de SW 45 Busca de objetos en almac. persistente [3] Este problema indica la necesidad de contar con capacidad de búsqueda orientada al dominio. En el ejemplo se podría utilizar la fecha y hora para buscar una instancia de Venta. IntermediarioRelacionaldeVentas CurrentRecordasObject():Venta() VentaconFechayHora(fecha,hora):Venta() selectfirst("date = ",fecha,"and time = ",hora) return currentrecordasobject() Fundamentos de Ingeniería de SW 46 23

Diseños Alternativos [1] Metadatos e Intermediarios parametrizados Definir Metadatos (datos acerca de datos) respecto al mapeo de clases y tablas, respecto al mapeo de nombres de atributos y campos, etc. Los metadatos se pueden conservar en un objeto.metadatosdealmacenamientopersistente. No es necesario generar una jerarquía de intermedios. Por ejemplo, es posible que el IntermediariodeEPRelacional sea una clase instanciada y parametrizada con metadatos. o No se requieren subclases de IntermediarioEPRelacional. Metadatos es un enfoque más flexible y robusto que el de formación de subclases. Se recomienda en aplicaciones que contengan muchas clases de objetos persistentes. Fundamentos de Ingeniería de SW 47 Diseños Alternativos [2] Objetos Consulta A diferencia de las consultas de cadenas simples (por ejemplo OID=123 ) es posible crear una clase Consulta cuyas instancias estén parametrizadas con expresiones booleanas. Este esquema tiene la ventaja de abstraer de cualquier lenguaje de manipulación de datos, p.ej. SQL. Cambio de intermediarios y de intermediarios de bases de datos en la memoria. Consiste en crear un Intermediario en-la Memoria que no guarde objetos en un almacenamiento persistente cuando se envía la señal de commit. Es útil durante el desarrollo y las pruebas para evitar la complejidad y desempeño de un intermediario real. Fundamentos de Ingeniería de SW 48 24

Diseños Alternativos [3] Se puede desconectar un intermediario y conectar otro, sin afectar a los objetos cliente. Así, se puede utilizar in Intermedio en-la Memoria durante algún periodo y luego reemplazarlo por un intermedio relacional o plano. IntermediariodeEP Intermediario utilizado en las pruebas IntermediariodeEPRelacional IntermediariodeEPdeArchivos IntermediariodeEPenMemoria Fundamentos de Ingeniería de SW 49 Diseños Alternativos [4] Comparación entre estados de transacción y cachés múltiples. Una forma eficiente de recordar el estado de transacción de un objeto es colocándolo en una caché de intermediarios, por ej. ViejaLimpia o ViejaSucia. Un diseño alterno es donde cada objeto se asocia a un objeto EstadodeTransacción que indica si es viejo y limpio, viejo y sucio, etc. Todos los objetos pueden estar en una caché, y el estado de transacción del objeto se conoce mediante el objeto asociado de estado y no mediante su pertenencia a la caché. No conviene agregar directamente el conocimiento de la persistencia a las definiciones del objeto de dominio. Fundamentos de Ingeniería de SW 50 25

Diseños Alternativos [5] Se recomienda las siguientes opciones: Si se usa una superclase común ObjetoPersistente, el estado es un atributo definido en esa clase. En un Mapa (Dictionary o Hashtable) que conserva el intermediario. La clave del Mapa es el objeto, el valor asociado Mapa es el EstadodeTransacción del objeto. Como un atributo del AgenteVirtual Este diseño presenta una complicación: si varios agentes se relacionan con el mismo objeto real, todos ellos deberán permanecer sincronizados. Fundamentos de Ingeniería de SW 51 Diseños Alternativos [6] EstadodeTra nsaccion commit()() rollback()() EstadoViejoLimpio EstadoViejoSucio commit()() rollback()() commit()() rollback()() Fundamentos de Ingeniería de SW 52 26

Quiz Cuál es la necesidad real de agentes e intermediarios? Cómo el diseño de los agentes e intermediarios da soporte a alta cohesión y bajo acoplamiento? Se cumple la arquitectura multicapa? Fundamentos de Ingeniería de SW 53 27