Diseo: Particionamiento Arquitectural

Lic. Csar Alcntara Loayza

Introduccin

El particionamiento arquitectural es el proceso de dividir el sistema en capas de tecnologa y responsabilidad. Cada particin de dominio es nica; algunas son funciones de back office, mientras que otras son distribuidas o departamentales. Existe una variedad de tcnicas para particionar su arquitectura. Cada una tiene consecuencias para su aplicacin. Para cada particin de dominio necesitar definir una arquitectura.
2

CAL/Fundamentos

Arquitectura Antes Del diseo

Es importante que el particionamiento arquitectural se haga antes que el diseo de objetos. Arquitecturas diferentes resultan en requerimientos de diseo diferentes. Problemas tales como latencia, gestin de memoria y comunicaciones cambian con cada arquitectura elegida. Una arquitectura de dos capas no se transforma automticamente en una de tres o n capas. Cada cambio en la arquitectura cambia los requerimientos para el diseo de bajo nivel.
3

CAL/Fundamentos

Arquitectura Tecnologa

Las elecciones a nivel de arquitectura tambin restringen las opciones tecnolgicas que influyen a su vez en el diseo de bajo nivel. Por ejemplo, una decisin de usar Java sobre un servidor y Visual Basic en los clientes elimina las opciones de Java RMI y nos conducira hacia algo como CORBA. De igual forma, la eleccin de manejador de base de datos orientado a objetos elimina la necesidad de la transformacin objeto relacional.
4

CAL/Fundamentos

Estrategias Basada Tecnolgia

La tecnologa es una herramienta que hace posible nuevas oportunidades arquitecturales. Por ejemplo, el advenimiento de las PCs distribuy el poder de computacin entre los dispositivos diferentes del gran computador central. Una relacin cooperativa formada entre estas tecnologas, la que es ahora referida como dos capas o cliente servidor.

CAL/Fundamentos

Estrategias Basada Tecnolgia

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

CAL/Fundamentos

Distribuir Responsabilidades

Un aspecto significante de este cambio es la distribucin 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 lgica que interpreta los datos hasta la presentacin de la informacin
7

CAL/Fundamentos

Distribuir Responsabilidades

Presentacin

Lgica

Datos
CAL/Fundamentos

Distribuir Responsabilidades

Dividir estas diferentes responsabilidades soporta el desarrollo de productos especializados. Tambin crea un mercado para productos que proporcionan el pegamento, o conectividad entre las nuevas particiones arquitecturales.
9

CAL/Fundamentos

Distribuir Responsabilidades
Ejemplos de tecnologas especializadas

Presentacin

Componentes visuales como Java AWT y Swing classes, Controles OCX,etc. CORBA, RMI y un nmero de Productos midleware que Proporcionan mecanismos de Comunicacin entre los Componentes de la arquitectura

Lgica

Datos
CAL/Fundamentos

10

Distribuir Responsabilidades
Ejemplos de tecnologas especializadas

Presentacin

Ambientes de programacin Visual que soporten el desarrollo De aplicaciones cliente servidor E interfaces de usuario. Monitores de procesamiento de transacciones como Tivoli y Tuxedo que manejan volmenes de procesamiento y gestin de transacciones

Lgica

Datos
CAL/Fundamentos

Sistemas de gestion de base de datos que soporten datos (objetos) persistentes y su acceso
11

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 manufacturacin, desde la produccin de una pieza a la vez a la lnea de ensamblaje usando partes intercambiables.
12

CAL/Fundamentos

Arquitectura De Dos Capas

El trmino 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.
13

CAL/Fundamentos

Arquitectura De Dos Capas

Solicitud

Segundo Nivel

El usuario inicia todas las acciones. El resultado se presenta a travs de una interface que est diseada 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 transaccin y los datos
14

Primer Nivel

Respuesta

CAL/Fundamentos

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 algn lugar entre las reas de datos y lgica, asignando cada responsabilidad a un ambiente tecnolgico diferente.
15

CAL/Fundamentos

Arquitectura De Dos Capas

Presentacin Lgica
La aplicacin cliente tiende a manejar toda la lgica y presentacin que gobierna la funcin del negocio que el usuario quiere ejecutar, como anular una factura, ingresar una venta o colocar una orden.

Datos

El sistema central solo maneja la lgica que define las transacciones lgicas y el acceso a datos

CAL/Fundamentos

16

Arquitectura De Dos Capas

Los desarrolladores tambin han aprendido que cada vez que parten el sistema deben proporcionar una forma de que las diferentes piezas se comuniquen.

CAL/Fundamentos

17

Arquitectura De Dos Capas

Presentacin
Una vez que el sistema fue separado necesitamos tcnicas y tecnologas para preservar la comunicacin entre las partes.

Lgica
Particin de comunicacin

Datos
CAL/Fundamentos

18

Arquitectura De Dos Capas

Cohesin y acoplamiento: La clave para particionar es decidir con precisin que responsabilidades sern asignadas a cada particin. La base para esta decisin se halla en los principios de alta cohesin y bajo acoplamiento. Alta cohesin destaca la necesidad de tener un nico y muy claro propsito para cada particin.
19

CAL/Fundamentos

Arquitectura De Dos Capas

Acoplamiento dbil (o bajo) destaca la importancia de reducir las dependencias entre particiones tanto como sea posible. Ahora los principios de cohesin y acoplamiento se aplican a bloque completo de funcionalidad dentro del sistema y no solo a los mdulos de programa.
20

CAL/Fundamentos

Arquitectura De Dos Capas

Esta prctica ha abierto la puerta para mayores particionamientos y especialilzaciones siguiendo un patrn simple:

Separar Asignar responsabilida especfica Re-establecer comunicacin a travs de una interface.

21

CAL/Fundamentos

Arquitectura De Tres Capas

En la leccin anterior sobre arquitectura de dos capas aprendimos como podra particionar el sistema en dos segmentos. Lo que gui este proceso son los principios de alta cohesin y bajo acoplamiento. Esto identific un problema con la solucin de dos capas.
22

CAL/Fundamentos

Arquitectura De Tres Capas

El problema es que la lgica 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 lgica de un sistema se encuentra en la forma de transacciones; Las mismas transacciones pueden ser utilizadas por muchas aplicaciones clientes.
23

CAL/Fundamentos

Arquitectura De Tres Capas

Siguiendo nuestro patrn simple, por qu no separar el sistema otra vez y colocar toda esta lgica comn en su propia particin? Entonces se podra proporcionar una interface hacia sta para todas las aplicaciones cliente.

CAL/Fundamentos

24

Arquitectura De Tres Capas

Espectro de comportamientos del sistema

Presentacin
Interface
Presentacin y Lgica especfica de la aplicacin cliente.

Lgica
Interface

Lgica comn del negocio y gestin de transacciones.

Datos
CAL/Fundamentos

Integridad de transacciones y datos

25

Arquitectura De Tres Capas

El resultado es un alto grado de reuso (de la lgica del negocio) y de aplicaciones cliente menos inteligentes y simples. La aplicacin cliente no necesita conocer mucho de la lgica del negocio. Ellas slo necesitan conocer que transaccin (o servicios) estn disponibles y son vlidas para lo que ellas estan ayudando a que el usuario logre.
26

CAL/Fundamentos

Dos Capas vs Tres Capas

Tres Capas
Nmero de Usuarios Nmero grande o desconocido de usuarios: Los usuarios pueden ser de antemano desconocidos o su nmero ser muy grande. En cualquier situacin es dificil anticipar los requerimientos de diseo de la interface de usuario. Nmero limitado de usuario: Pocos usuarios requeriran acceso a la aplicacin. Esto podra ser porque la aplicacin es muy especializada o porque existe una necesidad de un grado mayor de seguridad

Dos Capas

CAL/Fundamentos

27

Dos Capas vs Tres Capas

Tres Capas
Interfaces Diversos usuarios requieren interfaces alternativas: Los usuarios son diversos y el consenso podra ser difcil sino imposible. La interface necesita proporcionar algn grado de versiones o cutomizacin. La mejor forma de proporcionar esto es separar la interface de la lgica de la aplicacin. Interface estandar: La interface del usuario est bien definida y estandarizada. Los cambios son limitados o fcilmente controlados a travs del acceso a los grupos de usuarios conocidos.

Dos Capas

CAL/Fundamentos

28

Dos Capas vs Tres Capas

Tres Capas
Implementacin Implementaciones Distribuidas: Se necesita instalar las aplicaciones en un nmero de localidades. Igualmente,la data podra estar separada por la localidad. Por ejemplo, ventas regionales pueden ser almacenadas en las regiones mas centralizadas. Implementaciones locales: Las aplicaciones solo sern usadas una o pocas veces en localidades predeterminadas.

Dos Capas

CAL/Fundamentos

29

Dos Capas vs Tres Capas

Tres Capas Dos Capas
Configuracin de estaciones de trabajo Configuraciones de estaciones de trabajo del usuario sin control o desconocidas: No se tiene control sobre el tipo de estacin de trabajo o la configuracin de las estaciones de trabajo. Control de la configuracin de las estaciones de trabajo del usuario: Los recursos del cliente sern configurados para manejar mucho del procesamiento de la aplicacin. Si los requerimientos de la aplicacin cambian se pueden controlar los recursos.

CAL/Fundamentos

30

Encapsulamiento

Cada particin encapsula un conjunto discreto de funciones. El trabajo interno de cada particin est oculto a otras partes del sistema. Ocultar el diseo interno permite, a los desarrolladores, alterar el diseo interno de la particin sin interferir con otras particiones. Por ejemplo, la base de datos podra cambiar o los servicios de la lgica del negocio podra re-rutear hacia otro servidor sin que la aplicacin cliente se entere o altere.
31

CAL/Fundamentos

Arquitectura N - Capas

Por ahora vemos un patron en formacin. 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. Podramos decir que una interface es solo un protocolo de comunicacin, no es as?, no siempre.
32

CAL/Fundamentos

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 programacin para manejar la transformacin, dirigiendo y ruteando datos entre las dos particiones. De hecho, este tipo de requerimientos es comn, lo que ha resultado en el desarrollo de recursos como ODBC y JDBC, componentes de interface estandar.
33

CAL/Fundamentos

Arquitectura N - Capas

O mejor an, considere el estandar CORBA, cuyo propsito es proporcionar un servicio de interface estandar entre componentes distribuidos del sistema. No hay lmite al nmero de capas o particiones que no sean las que persiguen el rendimiento, aspectos tecnolgicos y de buen diseo.
34

CAL/Fundamentos

Arquitectura N - Capas

Los principios conductores deberan ser siempre alta cohesin y bajo acoplamiento, junto con rendimiento e integridad del sistema.

CAL/Fundamentos

35

Arquitectura N - Capas

En las arquitecturas de dos y tres capas fue fcil ver que podran haber muchas aplicaciones cliente. Asumamos que la capa intermedia y ltima fueran centralizada. Pero no podran, estas capas, ser tan diversas como las aplicaciones cliente?.

CAL/Fundamentos

36

Arquitectura N - Capas

Por ejemplo, si una empresa a nivel nacional est dividida en regiones, es muy probable que el dato de cada regin est en una localidad diferente. De ser as, entonces la capa mas baja es realmente una coleccin de particiones con responsabilidades similares pero diferente contenido. No solo separa la capa mas baja, sino tambin debe proporcionar una nueva interface entre la capa media y el nuevo conjunto de particiones de datos.
37

CAL/Fundamentos

Arquitectura N - Capas
Presentacin
Interface

Tres capas con la capa de datos distribuida

Lgica
Acceso Datos distribuidos

Interface

CAL/Fundamentos

38

Arquitectura N - Capas

Multiples Servidores de Transaccin: Considere sistemas departamentales donde diferentes servidores manejan diferentes tipos de transacciones. Procesamiento de rdenes maneja las ordenes, mientras Recepcin de cuentas maneja las transacciones de facturacin y pagos. La capa media tambin es divida en varias particiones.
39

CAL/Fundamentos

Arquitectura N - Capas
Presentacin
Interface Capa Transaccin Distribuida

Tres capas con transaccin distribuida o capa intermedia

Interface

Data
CAL/Fundamentos

40

Arquitectura N - Capas

En algunos ambientes existen procesos especializados para casos especiales. Los clientes preferenciales pueden manejar sus ordenes y facturacin de modo diferente. En este caso puede haber una capa dentro de la misma capa de transaccin.

CAL/Fundamentos

41

Arquitectura N - Capas

recuerda, como la arquitectura establece nuevos requerimientos para el diseo?, ejemplo, podra usar la misma interface de diseo para una capa media centralizada que para una distribuida? Es muy diferente, de hecho, una razn 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.
42

CAL/Fundamentos

Arquitectura N - Capas
Presentacin
Interface Logica de Aplicacin Interface Logica de Transaccin Ventas Interface
Proceso Cliente Regular Proceso Cliente Preferente

Especializacin de la capa intermedia

Interface

Data
CAL/Fundamentos

43

Clientes Ligeros

Clientes ligeros: El advenimiento del Web nos ha conducido a la necesidad de aplicaciones cliente muy pequeas. Lo que las aplicaciones web requieren es separar la interface (la presentacin de la pantalla) de la lgica que gobierna el comportamiento de la interface.
44

CAL/Fundamentos

Clientes Ligeros

Esta solucin permite aplicaciones cliente mucho mas pequeas, mas rpidas descargas y mejores accesos a servicios en las capas mas bajas. Este tipo de particionamiento ha sido conducido por tecnologa como servidores web y aplicaciones Java servlet.
45

CAL/Fundamentos

Arquitectura 4 - Capas
Presentacin
Interface Lgica de Aplicacin Interface Lgica de Transaccin

Arquitectura bsica de cuatro capas.

Interface

Data
CAL/Fundamentos

46

Diagramas De Despliegue

Los diagramas de despliegue proporcionan una representacin visual de la distribucin fsica de la arquitectura. Esta vista puede ser valiosa para describir como soportar el particionamiento resultante de su anlisis arquitectural. Los diagramas de despliegue modelan los tipos de nodos que se usarn y muestra como se deberan conectar.
47

CAL/Fundamentos

Diagramas De Despliegue

En este punto del proyecto, el diagrama de despliegue ser solo un borrador. Sin embargo, an as, proporciona un marco en el cual capturar las restricciones de hardware que se levantan en subsiguientes actividades de diseo.

CAL/Fundamentos

48

Diagramas De Despliegue

En la siguiente diapositiva se muestran dos ejemplos de diagramas de despliegue, uno para una instalacin de tres capas y otra para cuatro capas. Nota sin embargo que tanto la instalacin de tres como de cuatro capas no tienen que instalar cada particin sobre una mquina separada.
49

CAL/Fundamentos

Diagramas De Despliegue
<<Workstation>> <<Workstation>>

Cliente

Cliente

<<ethernet>>

<<http>> Servidor de Aplicaciones <<ethernet>>

<<Server>>

Tres Capas

Servidor de Transacciones <<ethernet>>

<<Server>>

<<Server>>

Cuatro Capas

Servidor de Base Datos

Servidor de Transacciones
<<ethernet>> Servidor de Base Datos
<<Sever>>

<<Server>>

CAL/Fundamentos

50

Diagramas De Despliegue

Si necesita revise la PPT sobre diagramas de despliegue

UML Diagramas de Despliegue

CAL/Fundamentos

51

Diagramas De Despliegue

Configuracin de Hardware: A medida que procede con el diseo estar mas enterado de las necesidades de rendimiento para cada particin. Estos requerimientos sern 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.
52

CAL/Fundamentos

Resmen

El anlisis arquitectural es el primero de los dos pasos en el proceso de diseo. En esta fase se transforman los requerimientos, colectados en las fases de inicio del proyecto y anlisis del problema, en tecnologas y arquitectura adecuadas para soportar los requerimientos.
53

CAL/Fundamentos

Resmen

Antes se aprendi como particionar el dominio del problema. En esta seccin se aprendi como partir cada particin de dominio (o subsistemas) en capas tecnolgicas o niveles. El proceso de particionamiento sigue un patrn simple de separacin, asignamiento de responsabilidad y reconeccin usando interfaces.
54

CAL/Fundamentos

Resmen

El resultado es un diseo por capas con un conjunto de particiones altamente cohesivas y que estn dbilmente acopladas. Esta forma de arquitectura mejora la modularidad del sistema aislando cada nico tipo de problema de diseo. La modularidad, a su vez, permite un mantenimiento mas fcil del sistema.
55

CAL/Fundamentos

Ejercicio

Ver Documento Word:

Diseo - Arquitectura

CAL/Fundamentos

56