sesion 7_1 diseño - particionamiento arquitectural

8/3/2019 Sesion 7_1 Diseo - Particionamiento Arquitectural

1/56

Diseo:Particionamiento Arquitectural

Lic. Csar Alcntara Loayza


2/56

CAL/Fundamentos 2

Introduccin El particionamiento arquitectural es el

proceso de dividir el sistema en capas de

tecnologa y responsabilidad. Cada particinde dominio es nica; algunas son funcionesde back office, mientras que otras sondistribuidas o departamentales. Existe una

variedad de tcnicas para particionar suarquitectura. Cada una tiene consecuenciaspara su aplicacin. Para cada particin dedominio necesitar definir una arquitectura.


3/56

CAL/Fundamentos 3

Arquitectura Antes Del diseo Es importante que el particionamiento

arquitectural se haga antes que el diseo de

objetos. Arquitecturas diferentes resultan enrequerimientos de diseo diferentes.Problemas tales como latencia, gestin dememoria y comunicaciones cambian con cadaarquitectura elegida. Una arquitectura de doscapas no se transforma automticamente enuna de tres o n capas. Cada cambio en laarquitectura cambia los requerimientos para eldiseo de bajo nivel.


4/56

CAL/Fundamentos 4

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 sobreun servidor y Visual Basic en los clienteselimina las opciones de Java RMI y nosconducira hacia algo como CORBA. De igualforma, la eleccin de manejador de base dedatos orientado a objetos elimina la necesidadde la transformacin objeto relacional.


5/56

CAL/Fundamentos 5

Estrategias Basada Tecnolgia La tecnologa es una herramienta que hace

posible nuevas oportunidades arquitecturales.

Por ejemplo, el advenimiento de las PCsdistribuy el poder de computacin entre losdispositivos diferentes del gran computadorcentral. Una relacin cooperativa formada

entre estas tecnologas, la que es ahorareferida como dos capas o cliente servidor.


6/56

CAL/Fundamentos 6

La PC ahora controla la interface delusuario, de este modo los nuevos

dispositivos clientes inician solicitudesal computador central, el que ahora,

juega el rol de servidor. Un servidores principalmente pasivo; espera porsolicitudes, procesa las solicitudes,regresa una respuesta y espera porotra solicitud.

Estrategias Basada Tecnolgia


7/56

CAL/Fundamentos 7

Un aspecto significante de este cambioes la distribucin de responsabilidades.

En un nivel muy simple se puedeimaginar que el sistema total necesitaun espectro que va desde el acceso a

datos, pasa por la lgica que interpretalos datos hasta la presentacin de lainformacin

Distribuir Responsabilidades


8/56

CAL/Fundamentos 8


Presentacin

Lgica

Datos


9/56

CAL/Fundamentos 9

Dividir estas diferentesresponsabilidades soporta el

desarrollo de productosespecializados. Tambin crea unmercado para productos queproporcionan elpegamento, oconectividad entre las nuevasparticiones arquitecturales.



10/56

CAL/Fundamentos 10


Presentacin

Lgica

Datos

Ejemplos de tecnologas especializadas

Componentes visuales comoJava AWT y Swing classes,

Controles OCX,etc.

CORBA, RMI y un nmero deProductos midleware queProporcionan mecanismos deComunicacin entre losComponentes de laarquitectura


11/56

CAL/Fundamentos 11


Presentacin

Lgica

Datos

Ejemplos de tecnologas especializadas

Ambientes de programacinVisual que soporten el desarrollo

De aplicaciones cliente servidorE interfaces de usuario.

Monitores de procesamiento detransacciones como Tivoli yTuxedo que manejan

volmenes de procesamiento ygestin de transacciones

Sistemas de gestion de base dedatos que soporten datos

(objetos) persistentes y su acceso


12/56

CAL/Fundamentos 12

Reuso Cada producto est para ayudar a resolver

una parte de las necesidades totales delprocesamiento de datos. Debido a que losproductos estan focalizados, tienden a sermuy especializados y reusables. Este cambioen el desarrollo de software es identico ennaturaleza al cambio en la manufacturacin,desde la produccin de una pieza a la vez a lalnea de ensamblaje usando partesintercambiables.


13/56

CAL/Fundamentos 13

Arquitectura De Dos Capas El trmino arquitectura de dos capas se ha

referido a una arquitectura que consiste deaplicaciones cliente remotas que conversan con ungran sistema corporativo centralizado. Lasaplicaciones cliente que corren sobre PC oestaciones de trabajo remotas han evolucionadopara manejar mas y mas tareas de procesamientoy los sistemas que se ejecutan en mainframescentralizados o servidores se han convertidoprincipalmente en gestores de transacciones yservicios de acceso a base de datos.


14/56

CAL/Fundamentos 14

Arquitectura De Dos Capas

PrimerNivel

SegundoNivel

El usuario inicia todas lasacciones. El resultado sepresenta a travs de unainterface que est diseadapara interpretar y mostrarsobre la PC

El sistema legado coordinatodas las solicitudes delusuario, proporciona acceso alos datos solicitados y asegurala integridad de la transacciny los datos

Solicitud

Respuesta


15/56

CAL/Fundamentos 15

Lo aprendido de la arquitectura de dos capas:Se ha aprendido que las responsabilidades

del sistema funcionalmente diferentes sepueden aislar y manejar independiente. Loque se ha hecho, esencialmente, es partir elespectro de responsabilidades en algn lugar

entre las reas de datos y lgica, asignandocada responsabilidad a un ambientetecnolgico diferente.



16/56

CAL/Fundamentos 16


Presentacin

Lgica

Datos

La aplicacin cliente tiendea manejar toda la lgica ypresentacin que gobiernala funcin del negocio queel usuario quiere ejecutar,como anular una factura,ingresar una venta ocolocar una orden.

El sistema central solomaneja la lgica quedefine las transaccioneslgicas y el acceso a datos


17/56

CAL/Fundamentos 17

Los desarrolladores tambin hanaprendido que cada vez que parten

el sistema deben proporcionar unaforma de que las diferentes piezas secomuniquen.



18/56

CAL/Fundamentos 18


Presentacin

Lgica

Datos

Particin decomunicacin

Una vez que el sistemafue separadonecesitamos tcnicas ytecnologas parapreservar lacomunicacin entre laspartes.


19/56

CAL/Fundamentos 19

Cohesin y acoplamiento: La clavepara particionar es decidir con

precisin que responsabilidades sernasignadas a cada particin. La basepara esta decisin se halla en losprincipios de alta cohesin y bajo

acoplamiento.Alta cohesin destaca lanecesidad de tener un nico y muyclaro propsito para cada particin.



20/56

CAL/Fundamentos 20

Acoplamiento dbil (o bajo) destaca laimportancia de reducir las

dependencias entre particiones tantocomo sea posible.

Ahora los principios de cohesin yacoplamiento se aplican a bloquecompleto de funcionalidad dentro delsistema y no solo a los mdulos deprograma.



21/56

CAL/Fundamentos 21

Esta prctica ha abierto la puerta paramayores particionamientos y

especialilzaciones siguiendo un patrnsimple:

Separar

Asignar responsabilida especfica Re-establecer comunicacin a travs de una

interface.



22/56

CAL/Fundamentos 22

Arquitectura De Tres Capas En la leccin anterior sobre arquitectura

de dos capas aprendimos como podra

particionar el sistema en dossegmentos. Lo que gui este procesoson los principios de alta cohesin y

bajo acoplamiento. Esto identific unproblema con la solucin de dos capas.


23/56

CAL/Fundamentos 23

El problema es que la lgica que controlael sistema se divide entre el cliente y el

computador central. Este arreglo resultaen redundancia entre las dos capas yentre sistemas. Es mas, En gran medidala lgica de un sistema se encuentra en

la forma de transacciones; Las mismastransacciones pueden ser utilizadas pormuchas aplicaciones clientes.

Arquitectura De Tres Capas


24/56

CAL/Fundamentos 24

Siguiendo nuestro patrn simple, por

qu no separar el sistema otra vez ycolocar toda esta lgica comn en supropia particin? Entonces se podraproporcionar una interface hacia stapara todas las aplicaciones cliente.



25/56

CAL/Fundamentos 25

Espectro de comportamientos del sistemaArquitectura De Tres Capas

Presentacin

Lgica

Datos

Interface

Interface

Presentacin y Lgicaespecfica de la aplicacin

cliente.

Lgica comn del negocioy gestin de transacciones.

Integridad detransacciones y datos


26/56

CAL/Fundamentos 26

El resultado es un alto grado de reuso (dela lgica del negocio) y de aplicaciones

cliente menos inteligentes y simples. Laaplicacin cliente no necesita conocermucho de la lgica del negocio. Ellas slonecesitan conocer que transaccin (o

servicios) estn disponibles y son vlidaspara lo que ellas estan ayudando a que elusuario logre.



27/56

CAL/Fundamentos 27

Dos Capas vs Tres Capas

Nmero limitado deusuario: Pocos usuariosrequeriran acceso a laaplicacin. Esto podra serporque la aplicacin es muyespecializada o porque existeuna necesidad de un grado

mayor de seguridad

Nmero grande o

desconocido de usuarios:Los usuarios pueden ser deantemano desconocidos o sunmero ser muy grande. Encualquier situacin es dificilanticipar los requerimientos de

diseo de la interface deusuario.

Tres Capas Dos Capas

Nmero de Usuarios


28/56

CAL/Fundamentos 28


Interface estandar: Lainterface del usuario est biendefinida y estandarizada. Loscambios son limitados ofcilmente controlados atravs del acceso a los gruposde usuarios conocidos.

Diversos usuarios

requieren interfacesalternativas: Los usuariosson diversos y el consensopodra ser difcil sinoimposible. La interfacenecesita proporcionar algn

grado de versiones ocutomizacin. La mejor formade proporcionar esto esseparar la interface de lalgica de la aplicacin.


Interfaces


29/56

CAL/Fundamentos 29


Implementaciones locales:Las aplicaciones solo sernusadas una o pocas veces enlocalidades predeterminadas.

Implementaciones

Distribuidas: Se necesitainstalar las aplicaciones en unnmero de localidades.Igualmente,la data podraestar separada por lalocalidad. Por ejemplo, ventas

regionales pueden seralmacenadas en las regionesmas centralizadas.


Implementacin


30/56

CAL/Fundamentos 30


Control de la configuracinde las estaciones detrabajo del usuario: Losrecursos del cliente sernconfigurados para manejarmucho del procesamiento dela aplicacin. Si los

requerimientos de la aplicacincambian se pueden controlarlos recursos.

Configuraciones de

estaciones de trabajo delusuario sin control odesconocidas: No se tienecontrol sobre el tipo deestacin de trabajo o laconfiguracin de las estaciones

de trabajo.


Configuracin de estaciones de trabajo


31/56

CAL/Fundamentos 31

Encapsulamiento Cada particin encapsula un conjunto discreto de

funciones. El trabajo interno de cada particin

est oculto a otras partes del sistema. Ocultar eldiseo interno permite, a los desarrolladores,alterar el diseo interno de la particin sininterferir con otras particiones. Por ejemplo, la

base de datos podra cambiar o los servicios de lalgica del negocio podra re-rutear hacia otroservidor sin que la aplicacin cliente se entere oaltere.


32/56

CAL/Fundamentos 32

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 noen n capas?. De hecho, si ud. mira denuevo la arquitectura de tres capas,

observar que tiene cinco capas. Podramosdecir que una interface es solo un protocolode comunicacin, no es as?, no siempre.


33/56

CAL/Fundamentos 33

Por ejemplo, considere una interface entre unservidor de objetos y un servidor de base dedatos relacional. La interface es realmenteuna capa de programacin para manejar latransformacin, dirigiendo y ruteando datosentre las dos particiones. De hecho, este tipode requerimientos es comn, lo que haresultado en el desarrollo de recursos comoODBC y JDBC, componentes de interfaceestandar.

Arquitectura N - Capas


34/56

CAL/Fundamentos 34

O mejor an, considere el estandarCORBA, cuyo propsito es

proporcionar un servicio de interfaceestandar entre componentesdistribuidos del sistema.

No hay lmite al nmero de capas oparticiones que no sean las quepersiguen el rendimiento, aspectostecnolgicos y de buen diseo.



35/56

CAL/Fundamentos 35

Los principios conductores deberanser siempre alta cohesin y bajo

acoplamiento, junto con rendimientoe integridad del sistema.



36/56

CAL/Fundamentos 36

Arquitectura N - Capas En las arquitecturas de dos y tres capas

fue fcil ver que podran haber muchas

aplicaciones cliente.Asumamos que lacapa intermedia y ltima fuerancentralizada. Pero no podran, estas

capas, ser tan diversas como lasaplicaciones cliente?.


37/56

CAL/Fundamentos 37

Por ejemplo, si una empresa a nivel nacional estdividida en regiones, es muy probable que el

dato de cada regin est en una localidaddiferente. De ser as, entonces la capa mas bajaes realmente una coleccin de particionesconresponsabilidades similares pero diferente

contenido. No solo separa la capa mas baja, sinotambin debe proporcionar una nueva interfaceentre la capa media y el nuevo conjunto departiciones de datos.



38/56

CAL/Fundamentos 38

Tres capas con la capade datos distribuida

Arquitectura N - CapasPresentacin

Lgica

Acceso Datosdistribuidos

Interface

Interface


39/56

CAL/Fundamentos 39

Multiples Servidores de Transaccin:Considere sistemas departamentales

donde diferentes servidores manejandiferentes tipos de transacciones.Procesamiento de rdenes maneja lasordenes, mientras Recepcin de

cuentas maneja las transacciones defacturacin y pagos. La capa mediatambin es divida en varias particiones.



40/56

CAL/Fundamentos 40

Tres capas contransaccin distribuidao capa intermedia

Arquitectura N - CapasPresentacin

Capa TransaccinDistribuida

Data

Interface

Interface


41/56

CAL/Fundamentos 41

En algunos ambientes existen procesosespecializados para casos especiales.

Los clientes preferenciales puedenmanejar sus ordenes y facturacin demodo diferente. En este caso puede

haber una capa dentro de la mismacapa de transaccin.



42/56

CAL/Fundamentos 42

recuerda, como la arquitectura establecenuevos requerimientos para el diseo?,

ejemplo, podra usar la misma interface dediseo para una capa media centralizada quepara una distribuida? Es muy diferente, dehecho, una razn de que se halla desarrollado

el estandar CORBA fue la necesidad de unaarquitectura que soporte el procesamientodistribuido en las capas medias y bajas.



43/56

CAL/Fundamentos 43

Especializacinde la capaintermedia


Proceso

ClientePreferente

Proceso

ClienteRegular

Presentacin

Logica de Aplicacin

Data

Interface

Interface

InterfaceLogica de

Transaccin VentasInterface


44/56

CAL/Fundamentos 44

Clientes ligeros: El advenimiento delWeb nos ha conducido a la necesidad

de aplicaciones cliente muy pequeas.Lo que las aplicaciones web requierenes separar la interface (la presentacin

de la pantalla) de la lgica quegobierna el comportamiento de lainterface.

Clientes Ligeros


45/56

CAL/Fundamentos 45

Clientes Ligeros Esta solucin permite aplicaciones

cliente mucho mas pequeas, mas

rpidas descargas y mejores accesos aservicios en las capas mas bajas. Estetipo de particionamiento ha sido

conducido por tecnologa comoservidores web y aplicaciones Javaservlet.


46/56

CAL/Fundamentos 46

Arquitectura 4 - Capas

Arquitectura bsicade cuatro capas.

Presentacin

Lgica de Aplicacin

Data

Interface

Interface

Interface

Lgica deTransaccin


47/56

CAL/Fundamentos 47

Diagramas De Despliegue Los diagramas de despliegue proporcionan

una representacin visual de la distribucin

fsica de la arquitectura. Esta vista puedeser valiosa para describir como soportar elparticionamiento resultante de su anlisis

arquitectural. Los diagramas de desplieguemodelan los tipos de nodos que se usarny muestra como se deberan conectar.


48/56

CAL/Fundamentos 48

En este punto del proyecto, eldiagrama de despliegue ser solo un

borrador. Sin embargo, an as,proporciona un marco en el cualcapturar las restricciones de hardware

que se levantan en subsiguientesactividades de diseo.

Diagramas De Despliegue


49/56

CAL/Fundamentos 49

En la siguiente diapositiva se muestrandos ejemplos de diagramas de

despliegue, uno para una instalacin detres capas y otra para cuatro capas.Nota sin embargo que tanto la

instalacin de tres como de cuatrocapas no tienen que instalar cadaparticin sobre una mquina separada.



50/56

CAL/Fundamentos 50


Cliente

Servidor deTransacciones

Servidor deBase Datos

Cliente

Servidor deAplicaciones

Servidor deTransacciones

Servidor de

Base Datos

CuatroCapas

TresCapas


51/56

CAL/Fundamentos 51

Si necesita revise la PPT sobrediagramas de despliegue

UML Diagramas de Despliegue



52/56

CAL/Fundamentos 52

Configuracin de Hardware: A medida queprocede con el diseo estar mas enteradode las necesidades de rendimiento para cada

particin. Estos requerimientos serntraducidos algunas veces en requerimientosde hardware en la forma de memoria,velocidad de procesador, velocidades de

conecciones de red o modem, etc. Estosrequerimientos se pueden modelardirectamente en el diagrama de despliegue.



53/56

CAL/Fundamentos 53

Resmen El anlisis arquitectural es el primero de

los dos pasos en el proceso de diseo.

En esta fase se transforman losrequerimientos, colectados en las fasesde inicio del proyecto y anlisis del

problema, en tecnologas y arquitecturaadecuadas para soportar losrequerimientos.


54/56

CAL/Fundamentos 54

Antes se aprendi como particionar eldominio del problema. En esta seccin

se aprendi como partir cada particinde dominio (o subsistemas) en capastecnolgicas o niveles. El proceso departicionamiento sigue un patrn

simple de separacin, asignamiento deresponsabilidad y reconeccin usandointerfaces.

Resmen


55/56

CAL/Fundamentos 55

El resultado es un diseo por capas conun conjunto de particiones altamente

cohesivas y que estn dbilmenteacopladas. Esta forma de arquitecturamejora la modularidad del sistemaaislando cada nico tipo de problema

de diseo. La modularidad, a su vez,permite un mantenimiento mas fcil delsistema.

Resmen


56/56

EjercicioVer Documento Word:

Diseo - Arquitectura

sesion 7_1 diseño - particionamiento arquitectural

Documents