Sesion 7 1 diseño   particionamiento arquitectural
Upcoming SlideShare
Loading in...5
×
 

Sesion 7 1 diseño particionamiento arquitectural

on

  • 558 views

 

Statistics

Views

Total Views
558
Views on SlideShare
558
Embed Views
0

Actions

Likes
0
Downloads
12
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Sesion 7 1 diseño   particionamiento arquitectural Sesion 7 1 diseño particionamiento arquitectural Presentation Transcript

  • Diseño:Particionamiento Arquitectural Lic. César Alcántara Loayza
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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ónCAL/Fundamentos 7
  • Distribuir Responsabilidades Espectro de Responsabilidades Presentación Lógica DatosCAL/Fundamentos 8
  • 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
  • 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 DatosCAL/Fundamentos 10
  • 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 suCAL/Fundamentos 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 manufacturación, desde la producción de una pieza a la vez a la línea de ensamblaje usando partes intercambiables.CAL/Fundamentos 12
  • 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
  • Arquitectura De Dos Capas El usuario inicia todas las Solicitud acciones. El resultado se presenta a través de unaSegundo interface que está diseñadaNivel para interpretar y mostrar sobre la PC El sistema legado coordina todas las solicitudes delPrimer usuario, proporciona acceso aNivel Respuesta los datos solicitados y asegura la integridad de la transacción y los datos CAL/Fundamentos 14
  • 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
  • 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 datosCAL/Fundamentos 16
  • 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
  • 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 DatosCAL/Fundamentos 18
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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 datosCAL/Fundamentos 25
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Arquitectura N - Capas Presentación  Tres capas con la capa de datos distribuida Interface Lógica Interface Acceso Datos distribuidos Recepción Marketing Ventas PagosCAL/Fundamentos 38
  • 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
  • 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 DataCAL/Fundamentos 40
  • 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
  • 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
  • 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 DataCAL/Fundamentos 43
  • 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
  • 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
  • Arquitectura 4 - Capas Presentación Interface  Arquitectura básica Lógica de Aplicación de cuatro capas. Interface Lógica de Transacción Interface DataCAL/Fundamentos 46
  • 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
  • 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
  • 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
  • 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 DatosCAL/Fundamentos 50
  • Diagramas De Despliegue  Si necesita revise la PPT sobre diagramas de despliegue  UML – Diagramas de DespliegueCAL/Fundamentos 51
  • 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
  • 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
  • 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
  • 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
  • Ejercicio  Ver Documento Word:  Diseño - ArquitecturaCAL/Fundamentos 56