Diseño:Particionamiento Arquitectural
Lic. César Alcántara Loayza
2CAL/Fundamentos
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.
3CAL/Fundamentos
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.
4CAL/Fundamentos
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.
5CAL/Fundamentos
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.
6CAL/Fundamentos
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.
Estrategias Basada Tecnológia
7CAL/Fundamentos
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
Distribuir Responsabilidades
8CAL/Fundamentos
Distribuir Responsabilidades
Presentación
Lógica
DatosEs
pect
ro d
e R
espo
nsab
ilidad
es
9CAL/Fundamentos
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.
Distribuir Responsabilidades
10CAL/Fundamentos
Distribuir Responsabilidades
Presentación
Lógica
Datos
Ejemplos de tecnologías especializadas
Componentes visuales como Java AWT y Swing classes, Controles OCX,etc.
CORBA, RMI y un número de Productos midleware que Proporcionan mecanismos deComunicación entre los Componentes de la arquitectura
11CAL/Fundamentos
Distribuir Responsabilidades
Presentación
Lógica
Datos
Ejemplos de tecnologías especializadas
Ambientes de programación Visual que soporten el desarrollo De aplicaciones cliente servidorE interfaces de usuario.
Monitores de procesamiento de transacciones como Tivoli y Tuxedo que manejan volúmenes de procesamiento y gestión de transacciones
Sistemas de gestion de base de datos que soporten datos (objetos) persistentes y su acceso
12CAL/Fundamentos
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.
13CAL/Fundamentos
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.
14CAL/Fundamentos
Arquitectura De Dos Capas
PrimerNivel
SegundoNivel
El usuario inicia todas las acciones. El resultado se presenta a través de una interface que está diseñada para interpretar y mostrar sobre la PC
El sistema legado coordina todas las solicitudes del usuario, proporciona acceso a los datos solicitados y asegura la integridad de la transacción y los datos
Solicitud
Respuesta
15CAL/Fundamentos
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.
Arquitectura De Dos Capas
16CAL/Fundamentos
Arquitectura De Dos Capas
Presentación
Lógica
Datos
La aplicación cliente tiende a manejar toda la lógica y presentación que gobierna la función del negocio que el usuario quiere ejecutar, como anular una factura, ingresar una venta o colocar una orden.
El sistema central solo maneja la lógica que define las transacciones lógicas y el acceso a datos
17CAL/Fundamentos
Los desarrolladores también han aprendido que cada vez que parten el sistema deben proporcionar una forma de que las diferentes piezas se comuniquen.
Arquitectura De Dos Capas
18CAL/Fundamentos
Arquitectura De Dos Capas
Presentación
Lógica
Datos
Partición de comunicación
Una vez que el sistema fue separado necesitamos técnicas y tecnologías para preservar la comunicación entre las partes.
19CAL/Fundamentos
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.
Arquitectura De Dos Capas
20CAL/Fundamentos
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.
Arquitectura De Dos Capas
21CAL/Fundamentos
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.
Arquitectura De Dos Capas
22CAL/Fundamentos
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.
23CAL/Fundamentos
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.
Arquitectura De Tres Capas
24CAL/Fundamentos
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.
Arquitectura De Tres Capas
25CAL/Fundamentos
Espectro de comportamientos del sistema
Arquitectura De Tres Capas
Presentación
Lógica
Datos
Interface
Interface
Presentación y Lógica específ ica de la aplicación cliente.
Lógica común del negocio y gestión de transacciones.
Integridad de transacciones y datos
26CAL/Fundamentos
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.
Arquitectura De Tres Capas
27CAL/Fundamentos
Dos Capas vs Tres Capas
Número l imitado de usuario: Pocos usuarios requeriran acceso a la aplicación. Esto podría ser porque la aplicación es muy especializada o porque existe una necesidad de un grado mayor de seguridad
Número grande o desconocido de usuarios: Los usuarios pueden ser de antemano desconocidos o su número ser muy grande. En cualquier situación es dificil anticipar los requerimientos de diseño de la interface de usuario.
Tres Capas Dos Capas
Número de Usuarios
28CAL/Fundamentos
Dos Capas vs Tres Capas
Interface estandar: La interface del usuario está bien definida y estandarizada. Los cambios son limitados o fácilmente controlados a través del acceso a los grupos de usuarios conocidos.
Diversos usuarios requieren interfaces alternativas: Los usuarios son diversos y el consenso podría ser difícil sino imposible. La interface necesita proporcionar algún grado de versiones o cutomización. La mejor forma de proporcionar esto es separar la interface de la lógica de la aplicación.
Tres Capas Dos Capas
Interfaces
29CAL/Fundamentos
Dos Capas vs Tres Capas
Implementaciones locales: Las aplicaciones solo serán usadas una o pocas veces en localidades predeterminadas.
Implementaciones Distribuidas: Se necesita instalar las aplicaciones en un número de localidades. Igualmente,la data podría estar separada por la localidad. Por ejemplo, ventas regionales pueden ser almacenadas en las regiones mas centralizadas.
Tres Capas Dos Capas
Implementación
30CAL/Fundamentos
Dos Capas vs Tres Capas
Control de la configuración de las estaciones de trabajo del usuario: Los recursos del cliente serán configurados para manejar mucho del procesamiento de la aplicación. Si los requerimientos de la aplicación cambian se pueden controlar los recursos.
Configuraciones de estaciones de trabajo del usuario sin control o desconocidas: No se tiene control sobre el tipo de estación de trabajo o la configuración de las estaciones de trabajo.
Tres Capas Dos Capas
Configuración de estaciones de trabajo
31CAL/Fundamentos
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.
32CAL/Fundamentos
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.
33CAL/Fundamentos
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.
Arquitectura N - Capas
34CAL/Fundamentos
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.
Arquitectura N - Capas
35CAL/Fundamentos
Los principios conductores deberían ser siempre alta cohesión y bajo acoplamiento, junto con rendimiento e integridad del sistema.
Arquitectura N - Capas
36CAL/Fundamentos
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?.
37CAL/Fundamentos
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.
Arquitectura N - Capas
38CAL/Fundamentos
Tres capas con la capa de datos distribuida
Arquitectura N - Capas
Presentación
Lógica
Acceso Datosdistribuidos
Interface
Interface
Mar
ket i n
g
Re c
epci
ó n
Ven t
as
Pag o
s
39CAL/Fundamentos
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.
Arquitectura N - Capas
40CAL/Fundamentos
Ven t
as
Pag o
s
Tres capas con transacción distribuida o capa intermedia
Arquitectura N - Capas
Presentación
Capa Transacción Distribuida
Data
Interface
Interface
Mar
ket i n
g
Re c
epci
ó n
41CAL/Fundamentos
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.
Arquitectura N - Capas
42CAL/Fundamentos
¿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.
Arquitectura N - Capas
43CAL/Fundamentos
Especialización de la capa intermedia
Arquitectura N - Capas
ProcesoCliente
Preferente
ProcesoClienteRegular
Presentación
Logica de Aplicación
Data
Interface
Interface
InterfaceLogica de
Transacción VentasInterface
44CAL/Fundamentos
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.
Clientes Ligeros
45CAL/Fundamentos
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.
46CAL/Fundamentos
Arquitectura 4 - Capas
Arquitectura básica de cuatro capas.
Presentación
Lógica de Aplicación
Data
Interface
Interface
Interface
Lógica de Transacción
47CAL/Fundamentos
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.
48CAL/Fundamentos
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.
Diagramas De Despliegue
49CAL/Fundamentos
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.
Diagramas De Despliegue
50CAL/Fundamentos
Diagramas De Despliegue<<Workstation>>
Cliente
<<Server>>Servidor de
Transacciones
<<Server>>Servidor deBase Datos
<<Workstation>>Cliente
<<Server>>Servidor deAplicaciones
<<Server>>Servidor de
Transacciones
<<Sever>>Servidor deBase Datos
<<http>><<ethernet>>
<<ethernet>><<ethernet>>
<<ethernet>>
Cuatro Capas
TresCapas
51CAL/Fundamentos
Si necesita revise la PPT sobre diagramas de despliegue UML – Diagramas de Despliegue
Diagramas De Despliegue
52CAL/Fundamentos
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.
Diagramas De Despliegue
53CAL/Fundamentos
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.
54CAL/Fundamentos
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.
Resúmen
55CAL/Fundamentos
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.
Resúmen
56CAL/Fundamentos
Ejercicio Ver Documento Word:
Diseño - Arquitectura