1. Diseño:
Particionamiento Arquitectural
Lic. César Alcántara Loayza

2. Introducción
 El particionamiento arquitectural es el
proceso de dividir el sistema en capas de
tecnología y responsabilidad. Cada partición
de dominio es única; algunas son funciones
de back office, mientras que otras son
distribuidas o departamentales. Existe una
variedad de técnicas para particionar su
arquitectura. Cada una tiene consecuencias
para su aplicación. Para cada partición de
dominio necesitará definir una arquitectura.
CAL/Fundamentos 2

3. Arquitectura Antes Del diseño
 Es importante que el particionamiento
arquitectural se haga antes que el diseño de
objetos. Arquitecturas diferentes resultan en
requerimientos de diseño diferentes.
Problemas tales como latencia, gestión de
memoria y comunicaciones cambian con cada
arquitectura elegida. Una arquitectura de dos
capas no se transforma automáticamente en
una de tres o n capas. Cada cambio en la
arquitectura cambia los requerimientos para el
diseño de bajo nivel.
CAL/Fundamentos 3

4. Arquitectura  Tecnología
 Las elecciones a nivel de arquitectura también
restringen las opciones tecnológicas que
influyen a su vez en el diseño de bajo nivel.
Por ejemplo, una decisión de usar Java sobre
un servidor y Visual Basic en los clientes
elimina las opciones de Java RMI y nos
conduciría hacia algo como CORBA. De igual
forma, la elección de manejador de base de
datos orientado a objetos elimina la necesidad
de la transformación objeto relacional.
CAL/Fundamentos 4

5. Estrategias Basada
Tecnológia
 La tecnología es una herramienta que hace
posible nuevas oportunidades
arquitecturales. Por ejemplo, el advenimiento
de las PC´s distribuyó el poder de
computación entre los dispositivos diferentes
del gran computador central. Una relación
cooperativa formada entre estas tecnologías,
la que es ahora referida como dos capas o
cliente servidor.
CAL/Fundamentos 5

6. Estrategias Basada
Tecnológia
 La PC ahora controla la interface del
usuario, de este modo los nuevos
dispositivos clientes inician
solicitudes al computador central, el
que ahora, juega el rol de servidor. Un
servidor es principalmente pasivo;
espera por solicitudes, procesa las
solicitudes, regresa una respuesta y
espera por otra solicitud.
CAL/Fundamentos 6

7. Distribuir Responsabilidades
 Un aspecto significante de este cambio
es la distribución de responsabilidades.
 En un nivel muy simple se puede
imaginar que el sistema total necesita
un espectro que va desde el acceso a
datos, pasa por la lógica que interpreta
los datos hasta la presentación de la
información
CAL/Fundamentos 7

8. Distribuir Responsabilidades
Espectro de Responsabilidades
Presentación
Lógica
Datos
CAL/Fundamentos 8

9. Distribuir Responsabilidades
 Dividir estas diferentes
responsabilidades soporta el
desarrollo de productos
especializados. También crea un
mercado para productos que
proporcionan el “pegamento”, o
conectividad entre las nuevas
particiones arquitecturales.
CAL/Fundamentos 9

10. Distribuir Responsabilidades
Ejemplos de tecnologías especializadas
Componentes visuales como
Java AWT y Swing classes,
Presentación Controles OCX,etc.
CORBA, RMI y un número de
Productos midleware que
Lógica Proporcionan mecanismos de
Comunicación entre los
Componentes de la
arquitectura
Datos
CAL/Fundamentos 10

11. Distribuir Responsabilidades
Ejemplos de tecnologías especializadas
Ambientes de programación
Visual que soporten el desarrollo
Presentación De aplicaciones cliente servidor
E interfaces de usuario.
Monitores de procesamiento
de transacciones como Tivoli
Lógica y Tuxedo que manejan
volúmenes de procesamiento
y gestión de transacciones
Datos Sistemas de gestion de base de
datos que soporten datos
(objetos) persistentes y su
CAL/Fundamentos acceso 11

12. Reuso
 Cada producto está para ayudar a resolver
una parte de las necesidades totales del
procesamiento de datos. Debido a que los
productos estan focalizados, tienden a ser
muy especializados y reusables. Este cambio
en el desarrollo de software es identico en
naturaleza al cambio en la manufacturación,
desde la producción de una pieza a la vez a
la línea de ensamblaje usando partes
intercambiables.
CAL/Fundamentos 12

13. Arquitectura De Dos Capas
 El término “arquitectura de dos capas” se ha
referido a una arquitectura que consiste de
aplicaciones cliente remotas que conversan con
un gran sistema corporativo centralizado. Las
aplicaciones cliente que corren sobre PC o
estaciones de trabajo remotas han evolucionado
para manejar mas y mas tareas de procesamiento
y los sistemas que se ejecutan en mainframes
centralizados o servidores se han convertido
principalmente en gestores de transacciones y
servicios de acceso a base de datos.
CAL/Fundamentos 13

14. Arquitectura De Dos Capas
El usuario inicia todas las
Solicitud acciones. El resultado se
presenta a través de una
Segundo interface que está diseñada
Nivel para interpretar y mostrar
sobre la PC
El sistema legado coordina
todas las solicitudes del
Primer usuario, proporciona acceso a
Nivel Respuesta los datos solicitados y
asegura la integridad de la
transacción y los datos
CAL/Fundamentos 14

15. Arquitectura De Dos Capas
 Lo aprendido de la arquitectura de dos
capas: Se ha aprendido que las
responsabilidades del sistema
funcionalmente diferentes se pueden aislar y
manejar independiente. Lo que se ha hecho,
esencialmente, es partir el espectro de
responsabilidades en algún lugar entre las
áreas de datos y lógica, asignando cada
responsabilidad a un ambiente tecnológico
diferente.
CAL/Fundamentos 15

16. Arquitectura De Dos Capas
La aplicación cliente
tiende a manejar toda la
lógica y presentación que
Presentación gobierna la función del
negocio que el usuario
quiere ejecutar, como
anular una factura,
Lógica ingresar una venta o
colocar una orden.
El sistema central solo
maneja la lógica que
Datos define las transacciones
lógicas y el acceso a
datos
CAL/Fundamentos 16

17. Arquitectura De Dos Capas
 Los desarrolladores también han
aprendido que cada vez que parten
el sistema deben proporcionar una
forma de que las diferentes piezas
se comuniquen.
CAL/Fundamentos 17

18. Arquitectura De Dos Capas
Una vez que el
Presentación sistema fue separado
necesitamos técnicas
y tecnologías para
preservar la
Lógica comunicación entre
las partes.
Partición de
comunicación
Datos
CAL/Fundamentos 18

19. Arquitectura De Dos Capas
 Cohesión y acoplamiento: La clave
para particionar es decidir con
precisión que responsabilidades serán
asignadas a cada partición. La base
para esta decisión se halla en los
principios de alta cohesión y bajo
acoplamiento. Alta cohesión destaca
la necesidad de tener un único y muy
claro propósito para cada partición.
CAL/Fundamentos 19

20. Arquitectura De Dos Capas
 Acoplamiento débil (o bajo) destaca la
importancia de reducir las
dependencias entre particiones tanto
como sea posible.
 Ahora los principios de cohesión y
acoplamiento se aplican a bloque
completo de funcionalidad dentro del
sistema y no solo a los módulos de
programa.
CAL/Fundamentos 20

21. Arquitectura De Dos Capas
 Esta práctica ha abierto la puerta para
mayores particionamientos y
especialilzaciones siguiendo un patrón
simple:
 Separar
 Asignar responsabilida específica
 Re-establecer comunicación a través de una
interface.
CAL/Fundamentos 21

22. Arquitectura De Tres Capas
 En la lección anterior sobre arquitectura
de dos capas aprendimos como podría
particionar el sistema en dos
segmentos. Lo que guió este proceso
son los principios de alta cohesión y
bajo acoplamiento. Esto identificó un
problema con la solución de dos capas.
CAL/Fundamentos 22

23. Arquitectura De Tres Capas
 El problema es que la lógica que controla
el sistema se divide entre el cliente y el
computador central. Este arreglo resulta
en redundancia entre las dos capas y
entre sistemas. Es mas, En gran medida
la lógica de un sistema se encuentra en
la forma de transacciones; Las mismas
transacciones pueden ser utilizadas por
muchas aplicaciones clientes.
CAL/Fundamentos 23

24. Arquitectura De Tres Capas
 Siguiendo nuestro patrón simple, ¿por
qué no separar el sistema otra vez y
colocar toda esta lógica común en su
propia partición? Entonces se podría
proporcionar una interface hacia ésta
para todas las aplicaciones cliente.
CAL/Fundamentos 24

25. Arquitectura De Tres Capas
 Espectro de comportamientos del sistema
Presentación y Lógica
Presentación específica de la
aplicación cliente.
Interface
Lógica común del negocio
Lógica y gestión de
transacciones.
Interface
Integridad de
Datos transacciones y datos
CAL/Fundamentos 25

26. Arquitectura De Tres Capas
 El resultado es un alto grado de reuso (de
la lógica del negocio) y de aplicaciones
cliente menos inteligentes y simples. La
aplicación cliente no necesita conocer
mucho de la lógica del negocio. Ellas sólo
necesitan conocer que transacción (o
servicios) están disponibles y son válidas
para lo que ellas estan ayudando a que el
usuario logre.
CAL/Fundamentos 26

27. Dos Capas vs Tres Capas
Tres Capas Dos Capas
Número de Usuarios
Número grande o Número limitado de
desconocido de usuarios: usuario: Pocos usuarios
Los usuarios pueden ser de requeriran acceso a la
antemano desconocidos o su aplicación. Esto podría ser
número ser muy grande. En porque la aplicación es muy
cualquier situación es dificil especializada o porque existe
anticipar los requerimientos de una necesidad de un grado
diseño de la interface de mayor de seguridad
usuario.
CAL/Fundamentos 27

28. Dos Capas vs Tres Capas
Tres Capas Dos Capas
Interfaces
Diversos usuarios Interface estandar: La
requieren interfaces interface del usuario está bien
alternativas: Los usuarios definida y estandarizada. Los
son diversos y el consenso cambios son limitados o
podría ser difícil sino fácilmente controlados a
imposible. La interface través del acceso a los grupos
necesita proporcionar algún de usuarios conocidos.
grado de versiones o
cutomización. La mejor forma
de proporcionar esto es
separar la interface de la
lógica de la aplicación.
CAL/Fundamentos 28

29. Dos Capas vs Tres Capas
Tres Capas Dos Capas
Implementación
Implementaciones Implementaciones
Distribuidas: Se necesita locales: Las aplicaciones
instalar las aplicaciones en un solo serán usadas una o
número de localidades. pocas veces en localidades
Igualmente,la data podría predeterminadas.
estar separada por la
localidad. Por ejemplo, ventas
regionales pueden ser
almacenadas en las regiones
mas centralizadas.
CAL/Fundamentos 29

30. Dos Capas vs Tres Capas
Tres Capas Dos Capas
Configuración de estaciones de trabajo
Configuraciones de Control de la
estaciones de trabajo del configuración de las
usuario sin control o estaciones de trabajo del
desconocidas: No se tiene usuario: Los recursos del
control sobre el tipo de cliente serán configurados
estación de trabajo o la para manejar mucho del
configuración de las procesamiento de la
estaciones de trabajo. aplicación. Si los
requerimientos de la
aplicación cambian se pueden
controlar los recursos.
CAL/Fundamentos 30

31. Encapsulamiento
 Cada partición encapsula un conjunto discreto de
funciones. El trabajo interno de cada partición
está oculto a otras partes del sistema. Ocultar el
diseño interno permite, a los desarrolladores,
alterar el diseño interno de la partición sin
interferir con otras particiones. Por ejemplo, la
base de datos podría cambiar o los servicios de la
lógica del negocio podría re-rutear hacia otro
servidor sin que la aplicación cliente se entere o
altere.
CAL/Fundamentos 31

32. Arquitectura N - Capas
 Por ahora vemos un patron en formación.
Si podemos partir un sistema en dos
capas, luego en tres capas, ¿entonces por
qué no en n capas?. De hecho, si ud. mira
de nuevo la arquitectura de tres capas,
observará que tiene cinco capas.
Podríamos decir que una interface es solo
un protocolo de comunicación, ¿no es así?,
no siempre.
CAL/Fundamentos 32

33. Arquitectura N - Capas
 Por ejemplo, considere una interface entre un
servidor de objetos y un servidor de base de
datos relacional. La interface es realmente
una capa de programación para manejar la
transformación, dirigiendo y ruteando datos
entre las dos particiones. De hecho, este tipo
de requerimientos es común, lo que ha
resultado en el desarrollo de recursos como
ODBC y JDBC, componentes de interface
estandar.
CAL/Fundamentos 33

34. Arquitectura N - Capas
 O mejor aún, considere el estandar
CORBA, cuyo propósito es
proporcionar un servicio de interface
estandar entre componentes
distribuidos del sistema.
 No hay límite al número de capas o
particiones que no sean las que
persiguen el rendimiento, aspectos
tecnológicos y de buen diseño.
CAL/Fundamentos 34

35. Arquitectura N - Capas
 Los principios conductores deberían
ser siempre alta cohesión y bajo
acoplamiento, junto con rendimiento
e integridad del sistema.
CAL/Fundamentos 35

36. Arquitectura N - Capas
 En las arquitecturas de dos y tres
capas fue fácil ver que podrían haber
muchas aplicaciones cliente.
Asumíamos que la capa intermedia y
última fueran centralizada. Pero ¿no
podrían, estas capas, ser tan diversas
como las aplicaciones cliente?.
CAL/Fundamentos 36

37. Arquitectura N - Capas
 Por ejemplo, si una empresa a nivel nacional
está dividida en regiones, es muy probable que
el dato de cada región esté en una localidad
diferente. De ser así, entonces la capa mas baja
es realmente una colección de particiones con
responsabilidades similares pero diferente
contenido. No solo separa la capa mas baja, sino
también debe proporcionar una nueva interface
entre la capa media y el nuevo conjunto de
particiones de datos.
CAL/Fundamentos 37

38. Arquitectura N - Capas
Presentación
 Tres capas con la capa
de datos distribuida
Interface
Lógica
Interface
Acceso Datos
distribuidos
Recepción
Marketing
Ventas
Pagos
CAL/Fundamentos 38

39. Arquitectura N - Capas
 Multiples Servidores de Transacción:
Considere sistemas departamentales
donde diferentes servidores manejan
diferentes tipos de transacciones.
Procesamiento de órdenes maneja las
ordenes, mientras Recepción de
cuentas maneja las transacciones de
facturación y pagos. La capa media
también es divida en varias particiones.
CAL/Fundamentos 39

40. Arquitectura N - Capas
Presentación  Tres capas con
transacción
distribuida o capa
Interface
Capa Transacción intermedia
Distribuida
Recepción
Marketing
Ventas
Pagos
Interface
Data
CAL/Fundamentos 40

41. Arquitectura N - Capas
 En algunos ambientes existen procesos
especializados para casos especiales.
Los clientes preferenciales pueden
manejar sus ordenes y facturación de
modo diferente. En este caso puede
haber una capa dentro de la misma
capa de transacción.
CAL/Fundamentos 41

42. Arquitectura N - Capas
 ¿recuerda, como la arquitectura establece
nuevos requerimientos para el diseño?,
ejemplo, ¿podría usar la misma interface de
diseño para una capa media centralizada que
para una distribuida? Es muy diferente, de
hecho, una razón de que se halla desarrollado
el estandar CORBA fue la necesidad de una
arquitectura que soporte el procesamiento
distribuido en las capas medias y bajas.
CAL/Fundamentos 42

43. Arquitectura N - Capas
Presentación  Especialización
Interface de la capa
Logica de Aplicación intermedia
Interface
Logica de
Transacción Ventas
Interface
Proceso Proceso
Cliente Cliente
Regular Preferente
Interface
Data
CAL/Fundamentos 43

44. Clientes Ligeros
 Clientes ligeros: El advenimiento del
Web nos ha conducido a la necesidad
de aplicaciones cliente muy pequeñas.
Lo que las aplicaciones web requieren
es separar la interface (la presentación
de la pantalla) de la lógica que
gobierna el comportamiento de la
interface.
CAL/Fundamentos 44

45. Clientes Ligeros
 Esta solución permite aplicaciones
cliente mucho mas pequeñas, mas
rápidas descargas y mejores accesos
a servicios en las capas mas bajas.
Este tipo de particionamiento ha sido
conducido por tecnología como
servidores web y aplicaciones Java
servlet.
CAL/Fundamentos 45

46. Arquitectura 4 - Capas
Presentación
Interface
 Arquitectura básica
Lógica de Aplicación
de cuatro capas.
Interface
Lógica de
Transacción
Interface
Data
CAL/Fundamentos 46

47. Diagramas De Despliegue
 Los diagramas de despliegue proporcionan
una representación visual de la distribución
física de la arquitectura. Esta vista puede
ser valiosa para describir como soportar el
particionamiento resultante de su análisis
arquitectural. Los diagramas de despliegue
modelan los tipos de nodos que se usarán
y muestra como se deberían conectar.
CAL/Fundamentos 47

48. Diagramas De Despliegue
 En este punto del proyecto, el
diagrama de despliegue será solo un
borrador. Sin embargo, aún así,
proporciona un marco en el cual
capturar las restricciones de
hardware que se levantan en
subsiguientes actividades de diseño.
CAL/Fundamentos 48

49. Diagramas De Despliegue
 En la siguiente diapositiva se muestran
dos ejemplos de diagramas de
despliegue, uno para una instalación de
tres capas y otra para cuatro capas.
Nota sin embargo que tanto la
instalación de tres como de cuatro
capas no tienen que instalar cada
partición sobre una máquina separada.
CAL/Fundamentos 49

50. Diagramas De Despliegue
<<Workstation>> <<Workstation>>
Cliente Cliente
<<ethernet>> <<http>>
<<Server>>
Cuatro
Tres <<Server>> Servidor de
Servidor de Aplicaciones Capas
Capas Transacciones
<<ethernet>>
<<ethernet>>
<<Server>>
<<Server>> Servidor de
Servidor de Transacciones
Base Datos <<ethernet>>
<<Sever>>
Servidor de
Base Datos
CAL/Fundamentos 50

51. Diagramas De Despliegue
 Si necesita revise la PPT sobre
diagramas de despliegue
 UML – Diagramas de Despliegue
CAL/Fundamentos 51

52. Diagramas De Despliegue
 Configuración de Hardware: A medida que
procede con el diseño estará mas enterado
de las necesidades de rendimiento para cada
partición. Estos requerimientos serán
traducidos algunas veces en requerimientos
de hardware en la forma de memoria,
velocidad de procesador, velocidades de
conecciones de red o modem, etc. Estos
requerimientos se pueden modelar
directamente en el diagrama de despliegue.
CAL/Fundamentos 52

53. Resúmen
 El análisis arquitectural es el primero de
los dos pasos en el proceso de diseño.
En esta fase se transforman los
requerimientos, colectados en las fases
de inicio del proyecto y análisis del
problema, en tecnologías y arquitectura
adecuadas para soportar los
requerimientos.
CAL/Fundamentos 53

54. Resúmen
 Antes se aprendió como particionar el
dominio del problema. En esta sección
se aprendió como partir cada partición
de dominio (o subsistemas) en capas
tecnológicas o niveles. El proceso de
particionamiento sigue un patrón
simple de separación, asignamiento
de responsabilidad y reconección
usando interfaces.
CAL/Fundamentos 54

55. Resúmen
 El resultado es un diseño por capas
con un conjunto de particiones
altamente cohesivas y que están
débilmente acopladas. Esta forma de
arquitectura mejora la modularidad del
sistema aislando cada único tipo de
problema de diseño. La modularidad, a
su vez, permite un mantenimiento mas
fácil del sistema.
CAL/Fundamentos 55

56. Ejercicio
 Ver Documento Word:
 Diseño - Arquitectura
CAL/Fundamentos 56