1. Prácticas Ingeniería del Software 3º
Arquitectura
Multicapa
Análisis y Diseño
Orientado a Objetos
UNIVERSIDAD DE
CASTILLA-LA MANCHA
ES de Informática de Ciudad Real
1

2. Arquitectura Multicapa
Idea:
– Cada capa compone un subsistema en el que se ubican
clases con responsabilidades propias
Objetivos
– Fomentar la reutilización del Software gracias a la
encapsulación y la herencia
– Para ello resulta imprescindible no acoplar clases, creando
una arquitectura del sistema apropiada
– Es interesante hacer abstracciones de las distintas
funcionalidades o responsabilidades del sistema
agrupándolas en capas.
Se obtendrán clases que serán independientes del resto, con lo
que se podrán reutilizar fácilmente.
2

3. Arquitectura Multicapa (II)
Beneficios (Larman, 1998):
– Aislamiento de la lógica de la aplicación en
componentes separados reutilizables en otras
aplicaciones.
– Distribución de capas en diferentes máquinas o
procesos, lo que puede mejorar el rendimiento,
aumentar la coordinación y la compartición de
información entre cliente y servidor.
– Dedicación de recursos a cada una de las capas
y posibilidad de desarrollarlas en paralelo.
3

4. Arquitectura Multicapa (III)
Ejemplo:
Interfaz LógicaDominio
Persistencia
4

5. Arquitectura Multicapa (IV)
Capas y Componentes de cada capa
– Presentación o Interfaz
Frames, cuadros de diálogo, Páginas Web, ...
– Lógica de Dominio
Todas los paquetes y clases relacionados con las reglas
del negocio.
– Persistencia
Todas los paquetes y clases relacionados con la forma de
almacenar los datos y los sistemas gestores de bases de
datos.
5

6. Arquitectura Multicapa (V)
Relaciones entre capas
– Se agrupan los componentes en paquetes que
suelen tener una relación de dependencia entre
ellos:
Dentro de un paquete hay elementos que necesitan de los
elementos del otro paquete.
– Los elementos de Presentación necesitan a los de
Lógica de Dominio para funcionar
Recogen/muestran información de/a los usuarios
Algunos objetos de la capa de presentación necesitan
conocer a algunos de la capa de lógica de dominio, pero
no al revés Los objetos del dominio no deben depender
de la presentación
6

7. Arquitectura Multicapa (VI)
– Los de Lógica de Dominio necesitan a los de
Persistencia para funcionar y éstos a los de
Lógica de Dominio.
Los objetos del dominio querrán almacenar datos pero
necesitan conocer a objetos de la capa de persistencia.
Pero será necesario que los de persistencia conozcan el
estado de los de dominio, por lo que la relación de
dependencia es mutua
Es poco deseable que los componentes de la lógica del
dominio dependan de alguien, y menos de la
Presentación porque será necesario que funcionen con
cualquier tipo de pantalla.
7

8. Arquitectura Multicapa (VII)
– Dentro de cada uno se pueden establecer
diferentes subsistemas o subcapas que pueden
encerrar diferentes funcionalidades.
Interfaz LógicaDominio
Bancos Cuentas
Persistencia
8

9. Arquitectura Multicapa (VIII)
Operaciones Persistencia (CRUD)
– Create, se utilizan para desmaterializar
Operación Insert en BB.DD relacionales
– Read, se utilizan para materializar
Operación Select en BB.DD relacionales
– Update, se utilizan para actualizar el estado de una
base de datos
Operación Update en BB.DD relacionales
– Delete, Se utilizan para eliminar registros de la
base de datos
Operación Delete en BB.DD relacionales
9

10. Arquitectura Multicapa (IX)
– Proceso de Materialización
:Objeto1 insert
Desmaterializar
BB.DD
Materializar
:Objeto2 select
10

11. Arquitectura Multicapa (X)
Problema
– El principal problema es el acoplamiento entre las
clases de distintas capas
Solución
– Aplicando patrones de diseño
Para construir la base de datos del sistema a partir del
diagrama de clases (ej. Patrón 1C1T)
Para acceder a la BB.DD (ej. Patrón Agente / Broker)
Para sincronizar el interfaz de usuario con lo que pasa en
la capa de aplicación (ej. Patrón Observador)
11

12. Patrón 1C1T
Consiste en que cada clase del diagrama de
clase se va a convertir en una tabla relacional.
– Las relaciones de herencia se transforman en
restricciones de clave 1:1
– Las asociaciones de agregación se traducen en
relaciones de clave externa cuya cardinalidad
depende de la multiplicidad de la asociación o
agregación.
12

13. Patrón Agente o Broker
Un Agente o Broker
– es una clase que se encarga de dar acceso a la
base de datos a los objetos de la capa de dominio,
de manera que se consigue un cierto
desacoplamiento de éstos.
– Es la única clase que tiene un conocimiento directo
de la base de datos, ofreciendo una interfaz con las
aplicaciones CRUD.
13

14. Patrón Agente o Broker (I)
Un Agente o Broker
14

15. Patrón Agente o Broker (I)
Un Agente o Broker. Patrón Singleton:
package persistencia;
import java.sql.*;
public class Agente {
protected static Agente mInstancia=null;
protected Connection mBD;
protected Agente() throws Exception {
Class.forName(quot;sun.jdbc.odbc.JdbcOdbcDriverquot;);
String url=quot;jdbc:odbc.JdbcOdbcDriverquot;;
mBD=DriverManager.getConnection(url);
}
public static Agente getAgente() throws Exception {
if (mInstancia==null) {
mInstancia=new Agente();
}
return mInstancia;
}
…..
15

16. Patrón Modelo- Vista- Controlador
MVC
– Permite desacoplar la interfaz de usuario de la
lógica de dominio
– Resuelve el problema de sincronización entre
objetos que trabajan sobre los mismos datos.
– Se crea una clase intermedia que es conocida por
la clase de dominio y que conoce a los distintos
interfaces. Cuando se producen cambios en la
instancia de la clase de dominio los notifica a la
clase de interfaz, quedando una vista consistente
para todos los que estén usando esa clase.
16

17. Patrón Modelo- Vista- Controlador
MVC: Patrón Observador
17

18. Problemas
1. Estudia algunas ventajas y desventajas de
separar un diseño en capas.
2. Plantea un ejemplo de sistema Multicapa,
identificando algunos componentes por cada
capa.
3. Investiga más sobre los patrones descritos en
las transparencias.
4. Modifica el ejemplo multicapa que has creado
con los patrones.
5. Implementa ese ejemplo en un lenguaje OO
18