Sesion 7 1 diseño particionamiento arquitectural

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


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.


10CAL/Fundamentos


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


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.


16CAL/Fundamentos


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.


18CAL/Fundamentos


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.


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.


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.


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.


25CAL/Fundamentos

Espectro de comportamientos del sistema


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.


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


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.


Interfaces

29CAL/Fundamentos


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.


Implementación

30CAL/Fundamentos


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.


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.


35CAL/Fundamentos

Los principios conductores deberían ser siempre alta cohesión y bajo acoplamiento, junto con rendimiento e integridad del sistema.


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.


38CAL/Fundamentos

Tres capas con la capa de datos distribuida


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.


40CAL/Fundamentos

Ven t

as

Pag o

s

Tres capas con transacción distribuida o capa intermedia


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.


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.


43CAL/Fundamentos

Especialización de la capa intermedia


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.


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


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.


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

Sesion 7 1 diseño particionamiento arquitectural

Documents

Transcript of Sesion 7 1 diseño particionamiento arquitectural