Anda di halaman 1dari 15

Arquitectura multicapas orientadas a objetos

Descomposición de la capa de la lógica de aplicaciones:


• Objetos del dominio.
• Servicios.

Presentación TPDVApplet

Conceptos del
Pago Venta dominio
Lógica de
Interfaz de la Generador de Servicios
aplicaciones
Base de datos reportes

Almacenamiento Base de Datos

María Eugenia Valencia


Dpto. Ciencias de la Computación
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.

María Eugenia Valencia


Dpto. Ciencias de la Computación
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.

María Eugenia Valencia


Dpto. Ciencias de la Computación
Representación de la Arquitectura con
Paquetes UML

Presentación
Conceptos de dominio
Presentación

Lógica de Dominio

Elementos básicos Ventas


aplicaciones
Servicios

Almacenamiento Base de datos

Paquetes en UML Diagrama de paquetes de la


arquitectura
María Eugenia Valencia
Dpto. Ciencias de la Computación
Ejemplo de paquetes y de dependencias
Presentación1

Dominio

Capa de servicios
de alto nivel Interfaz de base Interfaz de base
orientada a de datos relacional Comunicación de datos orientada Reportes
objetos a objetos

Ejemplos:
Capa de servicios 1. Applets de Java,
de bajo nivel Esquemas de aplicaciones documentos y vistas MFC
(orientados a y bibliotecas de soportes2 VisualParts de VisualAge
objetos y no 2.JDK, MFC,STL
orientados a
objetos)
Base de datos Base de datos
relacional orientada a objetos

María Eugenia Valencia


Dpto. Ciencias de la Computación
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.

María Eugenia Valencia


Dpto. Ciencias de la Computación
Estratos y particiones

Dominio

Elementos básicos Ventas Productos

Estratos verticales
Servicios

Interfaz de base
Interfaz de base Reportes
Comunicación de datos orientada
de datos relacional
a objetos

Particiones horizontales
María Eugenia Valencia
Dpto. Ciencias de la Computación
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.
Visibilidad de muchas clases
a partir de otros paquetes.
Dominio

Venta Pago Catalogo de Descripción de


productos Producto
... ... ... ...
... ... ... ...

Interfaz de BDR Seguridad

FachadaBD Broker Proxy Fachada de Usuario


... seguridad
... ... ... ...
obtener(id)
agregarUsuario ...
Objeto ... ... (usuario)
guardar(Objeto)
Visibilidad de una o de unas cuantas
clases en cada paquete de servicios.
María Eugenia Valencia
Dpto. Ciencias de la Computación
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.

María Eugenia Valencia


Dpto. Ciencias de la Computación
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.
María Eugenia Valencia
Dpto. Ciencias de la Computación
Comparación entre la conformidad y la violación
del patrón Separación Modelo-Vista

Capa de presentación (vista)

1:introducirProducto(cup,cant) 1:presentarMensaje(mens)

:TPDV :TPDV
Capa de dominio (modelo) Mal.
Bien.
No es conveniente enviar mensajes ni
Mensajes de la capa de vista a la de realizar el acoplamiento de la capa de
presentación. Soporta la separacion modelo a la de vista.
modelo-vista

María Eugenia Valencia


Dpto. Ciencias de la Computación
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.

María Eugenia Valencia


Dpto. Ciencias de la Computación
Publicar-Suscribir con notificación de los
eventos
crear( ) 1:suscribir(v,unMensaje,”nuevo impuesto”
v:ventanadeVenta :AdministradordeEventos

Un “mensaje” o
“Metodo” del objeto

ajustarImpuesto( ) 1:Eventose;al(“nuevo impuesto”)


:Venta :AdministradordeEventos

1.1:unMensaje()

v:VentanadeVenta

María Eugenia Valencia


Dpto. Ciencias de la Computación
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
alIntroducirProducto()
Presentación :Vistade Venta
“asociacion”

1:introducirProducto(cup,cant)
Coordinador de “asociacion”
aplicaciones :DocumentodeVenta

1.1:introducirProducto(cup,cant) “asociacion”
“asociacion”
Dominio :TPDV :Venta
“asociacion”

María Eugenia Valencia


Dpto. Ciencias de la Computación
Coordinadores de las aplicaciones (cont.)

Oprime botón

Cajero
alIntroducirProducto() Subclase del esquema
(Frame) de java.
Presentación :EsquemadeVentas
“asociacion” Creada por el coordinador TPDV

1:introducirProducto(cup,cant) Envia eventos al coordinador de


Coordinador de “asociacion” aplicaciones, que a su vez puede
aplicaciones :CoordinadordeTPDV enviarlos al controlador de la capa
de dominio (TPDV, por ejemplo).
1.1:introducirProducto(cup,cant)
El coordinador de aplicaciones
Dominio :TPDV 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

María Eugenia Valencia


Dpto. Ciencias de la Computación