Diseo y Arquitectura de Software

Universidad Nacional a Distancia de Mexico UNADM

UNIDAD 3
Actividad 3: Sistemas Distribuidos
Alumno: Juan Luis Valds Galicia
Prof. MC Pablo Sanchez Luna

Introduccion:
En esta actividad se pretende integrar aspectos de la arquitectura de Sistemas Distribuidos al
modelo anterior que tiene ua embebidos la Arquitectura de CAPA y la MVC, no obstante y bajo la
misma concepcion, la arquitectura de sistemas distribuidos sera utilizada para definir mas a
detalle el sistema que se esta presentando.
Antes de iniciar con la diagramacion y propuesta del nuevo patron de arquitectura o de su
complemento, es menester entender algunos conceptos que pueden irse de nuestro rango de
vision y confundirlos en su semantica, las definiciones que propongo a continuacion son propias,
dado que los grandes autores de estos temas, en muchas de las ocasiones nos pueden dejar mas
confusos que de costumbre, como siempre, las correciones a las definiciones son bienvenidas.
ELEMENTO
SISTEMA

LOCAL

EXTERNO
DISTRIBUIDO

SISTEMA
DISTRIBUIDO

PROXY

SERVIDOR

STAND ALONE
PC

DEFINICION
Un sistema se entiende como un grupo de elementos que llevan a cabo
procesos entre si, son co-dependientes entre si y el resultado de su
proceso puede ser entrada para otros sistemas. Pueden ser sistemas
cerrados o abiertos, pero la realidad es que no se ha comprobado si
existen sistemas cerrados, porque al final todos los sistemas, son parte
de un un sistema mayor.
El adjetivo de local, se le da a los procesos o sistemas que trabajan de
forma independiente y que todo el resultado de sus procesos se queda
dentro del sistema, y aunque pudieramos decir que es un sistema
cerrado no lo es, porque esta interactuando con un agente externo que
genera la entrada para los procesos.
Local tambien quiere decir, que es solamente para AQU, para el lugar
donde estamos.
Se denomina externo al sistema o elemento que viene de fuera, que de
forma natural no pertenece al sistema pero que interactua con el.
Distribuido quiere decir dividido en varias partes, donde cada parte hace
o realiza alguna labor especial y cada parte tiene comunicacin con la
otra, aun asi; un sistema puede estar distribuido y hablar de un solo
sistema.
Es un sistema que se encuentra dividido en varias partes de forma fisica
o logica, donde cada parte realizar un proceso especifico y solo al mostrar
el resultado del proceso general se puede unificar, la union en ese
momento es abstracta, todos los elementos estan en sus respectivass
localidades.
Es un simulador de procesos, es un HW o SW que simula una accion, es
una vista que une a varios procesos, conocido comunmente como el
portero o intermediario entre la aplicacin y el usuario.
SW o HW que tiene la funcion de despachar solicitudes locales o
foraneas, de propios o de terceros, puede conectarse con otros servidores
o estar de forma stand alone.
Computadora fisicamente aislada que no tiene contacto con ninguna red
o con otro sistema, permanece sola.
Computadora personal con procesos locales pero que se puede convertir
en proxy, en servidor, en stand alone, o en un sistema que sea parte de
otro sistema.

Todas las definiciones anteriores son con el unico proposito de entender la diagramacion que
viene a continuacion y tambien con el objetivo de entender el porque la arquitectura de Sistemas
Distribuidos sera embebida en el modelo de capas y no sustituira ningun elemento de el.

Para iniciar con esta actividad vamos a retomar el ltimo diagrama de la arquitectura de capas,
que tiene ya embebido el modelo MVC como se muestra abajo. Ahora bien, cada una de las
vistas que podemos apreciar en las diferentes capas, son PROCESOS, que se tienen que mapear,
como se hizo al principio del cuatrimestre, cada vista tiene uno o varios procesos que debemos
de tomar en cuenta y definir si esos procesos se pueden hacer de forma local, o debemos de
hacerlos de forma distribuida.
Para lograr lo anterior, debemos de mapear primero cada capa para formarla como un proceso
aislado, es decir, deber de haber un proceso denominado VISTA O PRESENTACION, otro
CONTROL O APLICACIN, y otro DATOS o MODELO, es decir, para poder aplicar los conceptos del
Sistema Distribuido, deberemos de convertir las capas o vistas, en PROCESOS.

CAPA DE BASE DE DATOS O

MODELO

A continuacin veremos una tabla donde se mostraran los sub-procesos de cada uno de las
capas.

CAPA
PRESENTACI
ON

MVC
VISTA

PROCESO
VISTA

APLICACIN

CONTRO CONTROL
L

CAPA DE
DATOS

MODEL
O

CAPA DE DATOS

SUB-PROCESOS
Registro de clientes
Compra
Facturacin
Publicidad
Requerimientos de Mercadera
Pagos
Facturacin Electrnica
Validacin de tarjetas bancarias
Manejo de tickets
Control de inventarios
Creacin de pedidos
Reportes de administracin
Manejo de las bases de datos de:
Clientes
Productos
Ventas
Compras.

Los sub procesos ahora debern pasar por otra tabla que nos indique EN DONDE SE LLEVAN A
CABO, aqu definiremos con una breve descripcin del proceso si es local o forneo, si es
realizado por terceros o por el mismo sistema, veamos:
PROCE
SO
VISTA

SUBPROCESO
Registro de
clientes
Compra

DEFINICION
Formulario que llena el cliente con sus
datos, se asigna nmero de cliente para
poder realizar compras
Proceso de adquisicin de productos.

Pagos

Proceso que permite pagar por los

productos adquiridos.

Ticket

Proceso que genera comprobante de

compra

Facturacin

Proceso que permite emitir la factura de

la compra

DONDE SE
REALIZA
En el servidor WEB
donde est alojada la
pgina.
En el servidor WEB
donde est alojada la
pgina y comprueba el
gasto mediante peticin
de validacin a otro
servidor (banco)
En el servidor WEB
donde est alojada la
pgina y comprueba el
gasto mediante peticin
de validacin a otro
servidor (banco)
En el servidor WEB
donde est alojada la
pgina.
En el servidor WEB
donde est alojada la
pgina, hace peticin a
tercero para timbrar la
factura y a el SAT para
validarla

CLASIFICA
CION
INTERNO

EXTERNO

EXTERNO

INTERNO

EXTERNO

CONTR
OL

Publicidad

Banners de publicidad con ofertas y

promociones

Requerimientos
de compra

Proceso que se lleva a cabo para ubicar

los pedidos que la tienda hace a sus
proveedores

Facturacin
Electrnica

Aplicacin que se encarga de timbrar y

validar las facturas solicitadas por el
cliente

Manejo de
tickets

Aplicacin que se encarga de generar los

tickets como comprobante de ventas

Validacin de
tarjetas
bancarias

Aplicacin que se encarga de validar las

tarjetas bancarias que se ofrecen como
pago en la compra de los productos

Control de
inventarios

Aplicacin que se encarga de monitorear

los movimientos en el almacn de
mercaderas y lleva la administracin del
inventario.
Aplicacin que se encarga de crear los
pedidos u rdenes de compra para los
proveedores de acuerdo al requerimiento
de mercaderas.

Creacin de
pedidos

CAPA
DE
DATOS

En el servidor WEB
donde est alojada la
pgina.
En el servidor WEB
donde est alojada la
pgina, hace peticin a
servidor POP para envo
de e-mail

INTERNO

Aplicacin alojada en el
servidor de la empresa
pero con comunicacin
externa al tercero que
timbra
Aplicacin alojada en el
servidor donde est
alojada la pagina
Aplicacin alojada en el
servidor de la empresa
pero con comunicacin
al banco o bancos
emisores.
Aplicacin alojada en el
servidor de la empresa.

EXTERNO

Aplicacin alojada en el
servidor de la empresa
pero en comunicacin
con un servidor POP para
envo de e-mail al
proveedor.
Aplicacin alojada en el
servidor de la empresa
MYSQL

INTERNO

EXTERNO

INTERNA

EXTERNA

INTERNO

Reportes de
administracin
Clientes

Aplicacin que se encarga de generar

reportes de ventas a la administracin
Administra y almacena datos de clientes

INTERNO

Productos

MYSQL

INTERNO

Ventas

Administra y almacena datos de productos

y proveedores
Administra y almacena datos de ventas

MYSQL

INTERNO

Compras.

Administra y almacena datos de compras

MYSQL

INTERNO

INTERNO

Como podemos ver la tabla define qu proceso son aptos para que se hagan de forma
independiente, es decir, que proceso podemos delegar para que se hagan en otro servidor y
cuales, es obligado que se hagan de forma externa y aqu es donde comenzamos a embeber la
nueva arquitectura.
LA ARQUITECTURA DE SISTEMAS DISTRIBUIDOS
Porque es necesario dividir en procesos las tres capas del modelo?
Cuando hablamos de procesos hablamos de conceptos puramente abstractos, es decir, sabemos
que hacen pero es difcil ver el proceso como tal a menos que sea en un diagrama o una prueba
de escritorio, en la arquitectura de Sistemas Distribuidos y utilizando las bases de la arquitectura

PAC, vemos que en la capa que en el MVC pudiera ser de control, esta arquitectura la toma como
una capa de Abstraccin.
Identificar cada proceso en cada capa, nos permitir abstraerlo, diagramarlo pero sobre todo,
destinarlo al equipo o elemento que lo pueda realizar mejor, en esto se basan los sistemas
distribuidos, en delegar procesos para quien los pueda hacer mejor.
El quien o el que, es donde tenemos que empezar a tomar definiciones, por eso se nos presentan
los Proxys, que son elementos parte de un sistema, que coadyuvan a la distribucin del trabajo,
una de las bases de esta arquitectura es la de MODULARIAR LOS PROCESOS por cada capa, para
que se lleven a cabo de forma efectiva. Despus de esto, es momento de integrar algunas
caractersticas de este modelo a la arquitectura que estamos trabajando, para esto tomaremos
un proceso de cada capa para ejemplificarlo.
En la tabla anterior pudimos identificar los procesos que se llevan a cabo en cada capa, y les
asignamos una clasificacin con dos valores, INTERNO o EXTERNO, vamos a definir estas dos
clases:
INTERNOS Son aquellos procesos que los puede realizar el sistema base de la empresa, con
aplicaciones localizadas de forma local en el servidor de la empresa.
EXTERNOS Son aquellos que se tienen que realizar fuera de ese sistema y con aplicaciones
externas pero utilizando una salida que genera el circulo interior, para arrancar sus propios
procesos.
De acuerdo a los procesos que ejemplificaremos el diagrama quedara as:

De acuerdo al diagrama arriba presentado, podemos identificar 6 procesos, los cuales ya

explicamos en la tabla anterior, lo importante del diagrama se destaca en que todo funcin como

un sistema con ciclos infinitos, y cada proceso se convierte en un mdulo que se puede modificar
o reparar sin afectar a los otros, por la simple razn de que cada mdulo o proceso tiene un
respaldo que le permitir hacerlo.
El proceso CLIENTE se convierte en un mdulo que se maneja de forma externa , a su vez, el
modulo SERVIDOR WEB es el nodo principal, a donde llegan y de donde salen los requerimientos
disparados por el proceso cliente, utiliza los proceso BANCO, SAT, Y PROVEEDOR, para procesar
consultas especificas del CLIENTE, y utiliza los recursos del mdulo SERVIDOR POP y de MY SQL,
para enviar datos y almacenarlos respectivamente.
Este proceso es el que se lleva a cabo en una tienda virtual, se aplica desde aqu el sistema
distribuido POR QUE CADA MODULO HACE UN PROCESO DIFERENTE y lo enva al solicitante una
vez realizado, en eso se basa la arquitectura de sistemas distribuidos.
COMO SE PUEDE MEJORAR ESTE MODELO SI YA SE TIENE EMBEBIDA DICHA
ARQUITECTURA?
Una de las razones por las que se manejan este tipo de arquitecturas es porque hay procesos
que NO SON PROPIOS, es decir, que maneja forzosamente terceros, y que se tienen que
incorporar al sistema, en este caso vemos la expedicin de la factura electrnica y la validacin
de las tarjetas de crdito o dbito, en el siguiente diagrama podemos apreciar los procesos
externo en el caso de las facturas.

En el caso del banco y de los proveedores es lo mismo, son procesos que son de terceros, y en
los cuales no podemos interferir, no obstante donde si pudiramos hacer una mejora con el fin
de dar ms amplitud al cliente en el uso de sus dispositivos, es al momento de configurar en el
mismo servidor WEB una aplicacin que permitiera identificar el tipo de dispositivo que el cliente
est usando y DIRIGIRLO a la aplicacin que le d una mejor experiencia de compra.
LA MEJORA

Originalmente el cliente ingresa a la pgina de la tienda mediante el explorador de internet, este

explorador muestra solamente lo que est programado en la pgina principal, pero en los
diferentes dispositivos puede haber diferentes versiones del explorador, algunos no mostraran
todo lo que la pagina original contiene.
Se sugiere entonces una aplicacin dentro de la pgina principal que identifique el tipo de
dispositivo que est usando el cliente y lo re-direccione a la pgina apta para la versin o tipo de
explorador que tiene en su dispositivo. Esto beneficiara en una mejor experiencia de compra
para el cliente y permitir obtener estadsticas acerca de las ventas.
El siguiente diagrama nos muestra de forma sencilla como se vera dicho proceso.

El diagrama muestra la pgina de bienvenida que ubica el tipo de dispositivo y de acuerdo a eso
lo dirige al catlogo configurado para esa versin o tipo del explorador, posteriormente, se
ejecuta el proceso del catlogo como tal, porque quiz para los dispositivos mviles no sea
necesario digitar la clave y usuario sino simplemente el nmero de telfono para realizar una
compra, pero despus de ese punto, los procesos sern los mismos.
La distribucin radica en que cada una de estas pginas si bien estar alojada en el mismo
servidor, cada una realizara un proceso diferente, lo que cumple con una de las caractersticas
de la Arquitectura de Sistemas Distribuidos.
EL HW EN LOS SISTEMAS DISTRIBUIDOS.
Por antonomasia, los sistemas actuales viven en sistemas distribuidos, es casi una regla, no
obstante se llega a omitir dependiendo del tamao de la empresa, ya que como se dijo
anteriormente, el hardware debe de comprarse en funcin de su uso y las ms de las veces los
servidores de aplicaciones, de correo y web, estn en un solo equipo fsico.

En el ejemplo que estamos trabajando podemos decir que el HW donde se aloja este sistema es
un sistema distribuido, pero TODO EL SISTEMA, no solo nuestras aplicaciones sino todo el
sistema, es decir, todo el servidor HTTP porque? Porque los operadores de Hosting manejan
servidores dedicados para el correo (POP) para las aplicaciones, para las bases de datos, y para
las pginas.
En el caso que nos ocupa nuestro sistema se distribuye pero dentro de la empresa de host, por
eso ser necesario que quien defina el tipo de dispositivo que el cliente utiliza para ingresar y
hacer la compra la verifique una pgina de inicio y no una aplicacin, porque al verificarla una
pgina, esta enviara las solicitudes pertinentes al resto de los objetos participantes, recordemos
que un sistema distribuido es aquel que delega actividades a otros sistemas o equipos.
Finalmente veamos un esquema de lo que pudiera ser un sistema distribuido.

Como podemos apreciar, los servidores fsicos estn conectados a un sistema en general que
permite establecer las comunicaciones de forma efectiva, y como podemos ver no se aprecia
PROXYS, que siendo nuestro punto final, debemos de entender.
El uso de Proxy, no es otra cosa ms que poner un intermediario entre las aplicaciones y el
usuario, que tan bueno o que tan malo sea, siempre va a quedar a criterio del Arquitecto que
disee el sistema, en lo personal no lo recomiendo, pero se utiliza mucho el uso de Proxy como
puertas o antesalas para que el usuario no entre ms all de lo que se est permitido, claro est,

el uso de Proxy es por seguridad, y como dije antes, el equipo se compra en base a las funciones
que va a realizar.

CONCLUSIONES
La arquitectura de Sistemas distribuidos es por antonomasia el paradigma del diseo, se utiliza
primordialmente como medida precautoria para evitar la cada sustancial y/o perdida de datos,
es altamente recomendable utilizarla en otros mbitos de la construccin de sistemas, tanto en
el SW como en el HW.
EL modelo final que se ha utilizado para este ejemplo nos permite entender que las tres
arquitecturas son compatibles y pueden trabajar de forma armnica en cada una de las capas
del sistema.
REFERENCIAS
FTE: Unidad_3_Aplicacion_de_sistemas.pdf