Diseo y Arquitectura de Software

Universidad Nacional a Distancia de Mexico UNADM

UNIDAD 3
EVIDENCIA DE APRENDIZAJE
Alumno: Juan Luis Valds Galicia
Prof. MC Pablo Sanchez Luna

Instrucciones:
Modificar el modelo de arquitectura que se ha generado para que se incluya el soporte de acceso
desde dispositivos moviles, esta modificacion se debera hacer tomando como base lo expuesto
en las unidades anteriores, utilizando capas logicas y fisicas en distintos niveles de la
arquitectura propuesta para el caso de la tienda de conveniencia.
Introduccion:
De acuerdo a lo expuesto anteriormente se propone visualizar a detalle el proceso de compra en
su modalidad de vista de cliente y determinar cual es el tipo de dispositivo que utiliza para
realizar la compra, enfocado directamente en el caso de los dispositivos moviles basicamente
telefonos celulares y tabletas con dispositivos 3G o BAM.
La creciente demanda en el comercio electronico y la movilidad de los dispositivos ha orillado a
los fabricantes tanto de SW como de HW a mejorar sus interfaces y estandarizar sus conexiones,
es muy dificil no encontrar en estos dias, telefonos o tabletas que no tengan la disponibilidad de
ingresar a la red, y hacer operaciones de compra en ella.
Desafortunadamente la seguridad se ha vigilado poco y hay muchos sitos maliciosos que
perpetran atentados contra sitios bien establecidos con el fin de generar desconfianza y crear
panico en los compradores sin mencionar el hurto de las bases de datos del establecimiento que
es atacado.
La compra mediante dispositivos moviles debe de ser alentada al mismo tiempo que el uso de
antivirus y anti-spyware que permite el uso correcto de aplicaciones de Billetera electronica o el
uso de dinero electronico en aplicaciones de billetera electronica, lo cual permitiria de muchas
formas agilizar el comercio.
En las siguientes lineas estableceremos los proceso que se llevaran a cabo para definir un
sistema que permita la comercializacion de productos a traves de la red, pero con el uso de
dispositivos electronicos.

PROCESO DE COMPRA
Como ya defini, el proceso de compra es aquel que involucra al CLIENTE y al SISTEMA que
representa la empresa, este proceso se lleva cabo interactuando ambos, (empresa y cliente)
dentro de un sistema computarizado en la WEB donde la empresa oferta artculos, el cliente los
ve, pregunta por la disposicin y decide o no comprarlos.
El pago de estos artculos tiene varias vertientes, uno puede ser contra entrega, el otro con
tarjeta de crdito, o depsito bancario, y el ms reciente que es el que aplicaremos junto con los
otros, el uso de Billetera electrnica o dinero electrnico, a continuacin definimos los tipos de
pago.
Despus de realizar la compra, la pgina solicita un tipo de pago, a continuacin enumeramos y
definimos los tipos de pago que utilizaremos en el ejemplo:
TIPO PAGO
TARJETA DE
CREDITO/DEBITO

DEPOSITO
BANCARIO

EFECTIVO
/CONTRA
ENTREGA

BILLETERA
ELECTRONICA

DINERO
ELECTRONICO

DEFINICION
Esta forma de pago consiste
en proporcionar el nmero
de tarjeta de dbito o
crdito en un apartado
especial de la pgina.
En esta forma de pago se le
proporciona al cliente un
nmero de cuenta bancario
para que realice el depsito
del total de la compra y
posteriormente se le solicita
que enve el comprobante
va e-mail para enviar el
producto a su domicilio.
Se le entrega al cliente un
nmero de compra con el
cual esperara a la empresa
de mensajera para recibir
su producto.
Esta es una nueva forma de
pago que consiste en
ingresar en una aplicacin
los nmeros de las tarjetas
de crdito o dbito o hacer
depsitos en efectivo a una
cuenta para disponer de
ellos cuando se realice una
compra,
Consiste en hacer
comprar moneda
electrnica con cierto valor
y mantenerla en una cuenta
con la empresa que da el

PROCESO
Ingresa nmero de tarjeta y un tercero valida
la misma contra el banco, hace la solicitud de
la compra y regresa el resultado al
comprador y al vendedor
Asiste al banco a hacer el deposito, escanea
la ficha y la enva al vendedor, este libera el
producto para su entrega.

Recibe un nmero de orden de compra y

espera a la empresa de mensajera, en
cuanto reciba la mercanca en buen estado
realiza el pago al mensajero quien entrega
comprobante de la venta.
Una empresa ofrece la aplicacin para
guardar los nmeros de las tarjetas de
crdito o dbito, al momento de realizar la
compra, la aplicacin se conecta con la
pagina para definir la forma de pago, de
acuerdo al criterio del usuario, de ah en
adelante, sigue el mismo proceso que las
tarjetas de crdito, este medio de pago, es
del lado del cliente.
Una empresa ofrece el servicio de tarjetas
prepago, se pueden adquirir en cualquier
tienda o departamental, se activan las
tarjetas por un monto. Previamente se tiene
que tener una cuenta con dicha empresa

servicio, cuando, este medio

es para adquirir productos
de la misma empresa.
(Tarjetas prepago)

para almacenar el monto adquirido. Las

compras solo se pueden realizar en la
empresa que expidi la tarjeta.

PROCESO DE NEGOCIO
La empresa ha decidido tomar la opcin de poner una pgina principal de re-direccionamiento
para identificar cual es el dispositivo que est usando el cliente y as darle una buena
experiencia de compra, por lo tanto, el primer diagrama muestra el flujo de actividad para dicho
caso.

Este diagrama permite identificar el dispositivo que utiliza el cliente y direccionarlo a una
subpgina que contiene los elementos necesarios para que el cliente tenga una experiencia de
compra altamente reconfortarle. Las pginas de acuerdo al dispositivo de origen ofrecen una
distribucin y una lgica que brinde un total despliegue en el dispositivo de acuerdo a la
capacidad de este.
Podemos decir que para los dispositivos mviles, la distribucin grafica tiene que ser ms
sencilla que si fuera para una PC, quiz la letra ms grande y las imgenes ms explicativas,
todo lo anterior sin mencionar que los mtodos de pago en un DM(Dispositivo Mvil) tienen una
logstica diferente.
DEFINICIONES
Si vemos a grandes rasgos las definiciones de esta capa, quedaran como sigue:
CLIENTE
El cliente hace una solicitud de ingreso a la tienda virtual con el explorador de su equipo.
PAGINA DE BIENVENIDA

La pgina de bienvenida ejecuta una rutina que identifica el explorador de procedencia y con
esto define el lugar al cual tiene que enviar la solicitud, en este caso, a cualquiera de los tres
catlogos.
CATLOGO
El catalogo es una aplicacin hibrida probablemente basada en PHP, que permite mostrar al
usuario una pgina web que permita aprovechar todas las capacidades de su dispositivo, de la
misma forma, el diseo grfico, y lgico estn pensado en el uso del dispositivo mvil,

ARQUITECTURA DE SISTEMA
Si lo apreciaramos de modo particular, podemos decir que esta parte exclusiva del sistema,
abarca las arquitecturas que se han visto hasta el momento, ya que utilizaremos una capa de
presentacin o de vistas, una de control o de aplicaciones, y el modelo o bases de datos.
Cabe sealar que este sistema contiene la arquitectura para sistemas distribuidos embebidos en
el modelo de capas y el MVC, pues al realizar actividades entre diferentes sistemas, podemos
decir que se distribuyen los procesos con equipo y recursos ajenos al sistema fuente,
Como ya se mencion entonces en el diagrama anterior estamos viendo el proceso de la capa de
presentacin o de la capa de vista, si tuviramos que ver el diagrama completo seria como se ve
en la imagen, donde tomaremos el catalogo 1 como catalogo especial para los usuarios que
utilicen un dispositivo mvil, ya sea un celular o una Tablet con BAM.

En el siguiente esquema tomamos de forma directa el proceso que tendra que seguir el catalogo
1, y como ya conocimos la capa de presentacin, el esquema se enfocara de forma directa en la
capa de CONTROL:

DEFINICION DE ESQUEMA DE CAPA DE APLICACIN O DE CONTROL

En esta parte se integra el sistema distribuido puesto que empezamos a delegar algunos de los
procesos que se requieren en manos de terceros, junto con ellos podemos ver una breve
definicin de lo que cada proceso hace, esto con el fin de entender porque se debe de llamar a
terceros para realizar el proceso.

EL USO DEL PROXY

Aunque en las otras actividades se recomend no usar Proxy por el problema que resulta al
configurar y sobre todo al dirigir los procesos ah, en este caso se hace necesario por razones de
seguridad, el Proxy en este ejemplo funcionaria como un integrador, si se quiere ver desde una
analoga seria; como un mostrador en una tienda, un lugar virtual a donde se re-direccionar el
usuario para que haga la compra.
Recordando que el PROXY tiene la funcin de se representante de otros procesos, podemos
entender que el servidor Proxy atendera solicitudes de compra, de verificacin, de pago, de
comprobacin de saldo, etc., ayudando con esto a que los bases de datos permanezcan seguras
dentro del sistema que las utilice y que las aplicaciones sean totalmente transparentes para el
usuario.
EJEMPLO:
Un cliente entra a la pgina y despus de ver el catalogo que es ofrecido por el Proxy en su
calidad de servidor web, decide hacer la compra, el proxy se convierte entonces en la aplicacin
de verificacin de identidad del cliente, (como si el empleado del mostrador pidiera revisar la
membresa del cliente) una vez verificado eso, hace una llamada para verificar el saldo del
cliente, la llamada es a un tercero, al cual le pasan las credenciales del cliente y las verifica en su
propio sistema.
El verificador de saldo enva un mensaje al vendedor para decirle que la venta si procede porque
hay suficiente saldo en la cuenta del cliente, el vendedor hace la venta y crea la factura, est la
enva al tercero que la timbrara y la enviara Al SAT para su validacin, una vez que se valida, es
enviada al correo del cliente con una copia para la empresa, el cliente recibe el producto o se
enva al medio de entrega.

En cuanto la venta se lleva a cabo, la aplicacin o empresa que se encarga de administrar el

saldo, hace el descuento del mismo, lo convierte en moneda fraccionaria y lo deposita en la
cuenta del banco de la empresa.

ESQUEMA DE CAPA DE MODELO

Al utilizar fundamentos del sistema distribuido se hace menester mencionar que esta capa est
constituida por varias entidades conectadas virtualmente, pero en lugares distintos, incluso cada
una de ellas con un modelo o arquitectura diferentes, totalmente transparentes para el usuario
incluso para la empresa que oferta los productos.

Asi vemos entonces que despus de nuestra capa de control, existe la capa de modelo, y que
aun dentro de esa capa, se sigue dando la arquitectura MVC, ahora explicamos porque.
Lo que la aplicacin de la capa de presentacin enva a la capa de aplicacin es el resultado de
un proceso, ese resultado dispara otro proceso pero en la capa de presentacin del tercero, y
este a su vez, lo mando a su capa de control, procesa, enva lo datos a la capa de datos, y
regresa el resultado que se dispara otro proceso (pero ahora de recepcin) en el sistema que
originalmente lo mando.
No hay confusin si lo comparamos con una analoga en la misma tienda fsica, supongamos que
detrs del mostrador, est el vendedor, el cobrador, el administrador, y el que entrega la
mercanca, el juego empieza cuando el cliente solicita algo al vendedor, este a su vez ofrece,
dialoga y vende, cuando el cliente acepta, el vendedor lo pasa al cobrador, este recibe al cliente,
hace su cobro y le entrega un comprobante, internamente le da el comprobante al
administrador, este a su vez en su propio proceso, hace la factura y la enva al cliente por correo,
mientras que el cliente recoge en el rea de almacn, la mercanca adquirida con el
comprobante que le dieron al pagar.
En la analoga anterior, el cliente nunca vio que detrs del vendedor hay un sistema de
comisiones, o que procesos estn detrs del cobrador, como el sistema de la terminal de las
tarjetas de crdito, o el programa que utiliza el administrador para enviar las facturas, etc., todo
esto se llena de procesos, donde la salida de uno es la entrada de otro y viceversa, segn dicta
el SixSigma.

MODELO FINAL

Definitivamente darle un nombre o establecerlo como mtodo nico para resolver un problema
parecido creo que sera un error, porque al final es una arquitectura que se enriqueci (o se
empeor) con las aportaciones de un servidor, por lo que se entiende que es una arquitectura
basada en capas embebida con MVC y para sistemas distribuidos.

CONCLUSIONES
Las matemticas son una ciencia universal, que solo aportan funciones y mtodos para realizar
operaciones, lo mismo para sumar dinero en el banco, que enfermedades en un paciente en el
hospital. Las arquitecturas en sistemas son aportaciones y mtodos que pudieran resolver un
problema parecido, pero jams sern exactas, solo dan una opcin, pero cuando esa opcin se
utiliza para crear algo ms, algo fuera de lo cotidiano, es cuando se crea un paradigma, como las
matemticas solo proveen el medio, quien las usa aporta la creatividad.
En el presente trabajo no aporte nada diferente a lo ya establecido, simplemente lo acomode de
una forma distinta con el fin de solventar el problema segn mi perspectiva, y como es mi
perspectiva, siempre ser mi paradigma, y esos; hay que romperlos constantemente.

REFERENCIAS
FTE: Unidad_3_Aplicacion_de_sistemas.pdf