Arquitectura multicapas orientadas a objetos Descomposición de la capa de la lógica de aplicaciones: Objetos del dominio. Servicios. Presentación TPDVApplet Lógica de aplicaciones Pago Interfaz de la Base de datos Venta Generador de reportes Conceptos del dominio Servicios Almacenamiento Base de Datos

Motivos para usar arquitectura multicapas Aislamiento de la lógica de aplicaciones en componentes independientes susceptibles de reutilizarse después en otros sistemas. Distribución de las capas en varios nodos físicos de computo y en varios procesos. Esto puede mejorar el desempeño, la coordinación y el compartir la información en un sistema de cliente-servidor.

Motivos para usar arquitectura multicapas Asignación de los dise;adores para que construyan determinadas capas; por ejemplo, un equipo que trabaje exclusivamente en la capa de presentación. Y así se brinda soporte a los conocimientos especializados en las habilidades de desarrollo y también a la capacidad de realizar actividades simultaneas en equipo.

Representación de la Arquitectura con Paquetes UML Conceptos de dominio Ventas Elementos básicos Lógica de aplicaciones Dominio Servicios Almacenamiento Base de datos Paquetes en UML Diagrama de paquetes de la arquitectura

Ejemplo de paquetes y de dependencias Reportes Presentación1 Dominio Interfaz de base de datos relacional Comunicación de datos orientada a objetos Esquemas de aplicaciones y bibliotecas de soportes2 Base de datos relacional orientada a objetos Ejemplos: 1. Applets de Java, documentos y vistas MFC VisualParts de VisualAge 2.JDK, MFC,STL Capa de servicios de alto nivel orientada a objetos Capa de servicios de bajo nivel (orientados a objetos y no orientados a objetos)

Identificación de los Paquetes Agrupe los elementos en 1 paquete así: Agrupe los elementos para ofrecer en un paquete un servicio común (o una familia de servicios relacionados), con un nivel relativamente alto de acoplamiento y colaboración. En cierto nivel de abstracción, se vera el paquete como muy cohesivo (tiene responsabilidades estrechamente relacionadas). En cambio, habrá relativamente bajo acoplamiento y colaboración entre los elementos de diferentes paquetes.

Estratos y particiones Estratos verticales Dominio Elementos básicos Ventas Productos Servicios Interfaz de base de datos relacional Comunicación de datos orientada a objetos Reportes Particiones horizontales

Visibilidad entre las clases de paquetes La visibilidad a las clases en diferentes paquetes conforman típicamente el siguiente patrón: Acceso a los paquetes del dominio. Acceso a los paquetes de servicios. Acceso a los paquetes de presentación. Dominio Visibilidad de muchas clases a partir de otros paquetes. Venta Pago Catalogo de productos Descripción de Producto ... Interfaz de BDR Visibilidad de una o de unas cuantas clases en cada paquete de servicios. FachadaBD Broker Proxy Seguridad Fachada de seguridad Usuario obtener(id) Objeto guardar(Objeto) agregarUsuario (usuario)

Interfaz de los paquetes de servicios: El patrón fachada Fachada Contexto/problema Se requiere una interfaz común y unificada para un conjunto heterogéneo de interfaces, un subsistema por ejemplo. ¿Qué hacer? Solución Definir una clase individual que unifique la interfaz y le asigne la responsabilidad de colaborar con el subsistema.

Sin visibilidad directa respecto a la ventanas: el patrón de Separación Modelo-Vista Separación Modelo-Vista Contexto/problema Conviene desacoplar los objetos dominio (modelos) y las ventanas (vistas), a fin de brindar soporte a un mayor reuso de los objetos dominio y reducir al mínimo el impacto que los cambios de la interfaz tienen en ellos. ¿Qué hacer? Solución Definir las clases de dominio (modelo) para que no tengan acoplamiento ni visibilidad directa respecto a la clases ventana (vista) y para que los datos de la aplicación y de la funcionalidad se conserven en las clases de dominio, no en las de ventana.

Comparación entre la conformidad y la violación del patrón Separación Modelo-Vista Capa de presentación (vista) :TPDV 1:introducirProducto(cup,cant) Bien. Mensajes de la capa de vista a la de presentación. Soporta la separacion modelo-vista Capa de dominio (modelo) :TPDV 1:presentarMensaje(mens) Mal. No es conveniente enviar mensajes ni realizar el acoplamiento de la capa de modelo a la de vista.

La comunicación indirecta en un sistema El patrón Publicar-Suscribir Publicar-Suscribir Contexto/problema Un cambio de estado (un evento) ocurre dentro de un editor del evento y otros objetos dependen de él (suscriptores del evento). Pero el Editor no debería tener conocimiento de sus Suscriptores.¿Qué hacer? Solución Defina un sistema de notificación de eventos para que el Editor pueda notificarlos indirectamente a los Suscriptores.

Publicar-Suscribir con notificación de los eventos v:ventanadeVenta :AdministradordeEventos crear( ) 1:suscribir(v,unMensaje,”nuevo impuesto” Un “mensaje” o “Metodo” del objeto :Venta :AdministradordeEventos ajustarImpuesto( ) 1:Eventose;al(“nuevo impuesto”) v:VentanadeVenta 1.1:unMensaje()

Coordinadores de las aplicaciones Es una clase que tiene la responsabilidad de mediar entre la capa de interfaz y la del dominio. Oprime botón Cajero :Vistade Venta :DocumentodeVenta :TPDV :Venta alIntroducirProducto() “asociacion” 1:introducirProducto(cup,cant) 1.1:introducirProducto(cup,cant) Presentación Coordinador de aplicaciones Dominio

Coordinadores de las aplicaciones (cont.) Oprime botón Cajero :EsquemadeVentas :CoordinadordeTPDV :TPDV alIntroducirProducto() “asociacion” 1:introducirProducto(cup,cant) 1.1:introducirProducto(cup,cant) Presentación Coordinador de aplicaciones Dominio Subclase del esquema (Frame) de java. Creada por el coordinador TPDV Envia eventos al coordinador de aplicaciones, que a su vez puede enviarlos al controlador de la capa de dominio (TPDV, por ejemplo). El coordinador de aplicaciones de Java que crea las ventanas (por ejemplo, los objetos Frame y Dialog) y que media entre la capa de ventanas y la de dominio