Arquitectura multicapas orientadas a objetos

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

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

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

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

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

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

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

8. Visibilidad de muchas clases a partir de otros paquetes. Dominio Venta Pago Catalogo de productos Descripción de Producto ... ... ... ... Interfaz de BDR ... ... ... ... Seguridad FachadaBD Broker Proxy Fachada de seguridad Usuario ... ... ... ... ... obtener(id) Objeto guardar(Objeto) agregarUsuario (usuario) ... ... ... Visibilidad de una o de unas cuantas clases en cada paquete de servicios. 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.

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

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

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

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

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

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

15. Oprime botón Cajero alIntroducirProducto() 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). Presentación :EsquemadeVentas “asociacion” 1:introducirProducto(cup,cant) Coordinador de aplicaciones “asociacion” :CoordinadordeTPDV 1.1:introducirProducto(cup,cant) 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 Dominio :TPDV Coordinadores de las aplicaciones (cont.)