1. Universidad Abierta y a Distancia de México
Diseño y Arquitectura del Software
Título del Trabajo: (Evidencia de Aprendizaje) Lenguaje descriptor y patrones
de arquitectura de software
Nombre del Alumno: Carmen Guadalupe Fernández Gascón
Nombre del Facilitador: Judith Rubí Sánchez Garcia
Irapuato, Guanajuato a 13 de Enero del 2014
1
Carmen Gpe Fernández Gascón
2. Índice
Contenido
Introducción ........................................................................................................................................ 3
Clasificación .................................................................................................................................. 3
Case de Estudio ................................................................................................................................... 4
Lista de requerimientos ...................................................................................................................... 4
Definición del Patrón Seleccionado .................................................................................................... 5
Estructura del Patrón Seleccionado .................................................................................................... 5
Nombre del Patrón .......................................................................................................................... 5
Código en Java para accesar a la Base de Datos ............................................................................. 9
Conclusiones ..................................................................................................................................... 10
Fuentes de consulta: ......................................................................................................................... 10
2
Carmen Gpe Fernández Gascón
3. Evidencia de Aprendizaje U2:
Introducción
Un patrón describe un problema a ser resuelto, una solución y el contexto en el
cual la solución trabaja.
Nomina una técnica y describe su costo y su beneficio, de acuerdo a Coad, los
patrones de diseño son identificados al observar los bloques de construcción de
más bajo nivel; esto es sus clases y objetos y las relaciones entre ellos (Pree,
1995).
Clasificación
Los patrones se definen utilizando formatos consistentes. Una buena
definición de un patrón permite entenderlo inmediatamente, y además
provee todos los detalles necesarios para implementarlo y considerar las
consecuencias de su aplicación.
Alcance
Propósito
Clase
Estructural
Adapter Clss
Adapter Object
Object
3
Creación
Factory Method
Abstract Factory
Builder
Protitype
Singleton
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Carmen Gpe Fernández Gascón
Comportamiento
Interpreter
Chain of
Responsibility
Command
Iterator
Mediator
Memento
State
Strategy
Visitor
4. Case de Estudio
“Una tienda de conveniencia necesita automatizar sus procesos de compra, venta
y seguimiento de clientes. Lo desea hacer a través de venta en línea para sus
clientes y que sus proveedores puedan acceder a un sitio privado y vean
automáticamente las existencias del producto que surten, al mismo tiempo los
usuarios podrán comentar sobre su experiencia de compra en línea o en el sitio;
estos comentarios los podrán hacer a través de un equipo de cómputo
convencional o mediante un dispositivo móvil que será capaz de conectarse al sitio
de la tienda. El gerente de la tienda necesita que se obtengan tendencias de
ventas y que se haga una posible sugerencia a los compradores sobre la base a
sus compras anteriores, y sobre todo considerando su perfil (se entiende que el
sistema deberá generar ese perfil en el que se incluya la edad, el sexo, la
ubicación, los amigos, las fotografías, su grado escolar y comentarios hechos).
Deberá ser fácil de usar para todos los usuarios y deberá manejar diferentes tipos
de roles (administrador del sitio, gerente general, gerente de tienda, vendedor,
proveedor, usuario normal) y cada uno tendrá acceso a diferentes privilegios
asignados por el administrador del sitio”
Lista de requerimientos
a) Automatización de los procesos (Compra, Venta y Seguimiento a Clientes).
b) Acceso al sistema vía Internet (Computadoras y dispositivos móviles).
c) La gerencia requiere de la información generada para analizar tendencias
de ventas para el seguimiento adecuado a clientes.
d) En base a las ventas efectuadas el sistema deberá efectuar sugerencias de
compra a los usuarios conforme a su historial de compras.
e) Recabar información para crear perfiles de los clientes.
f) Manejar roles de acceso y de seguridad.
g) Sistema fácil de manejar tanto para la empresa como para los clientes.
4
Carmen Gpe Fernández Gascón
5. Definición del Patrón Seleccionado
El patrón MVC es un patrón arquitectónico de tres capas conceptuales, fue
definido en un principio para sistemas usuario-máquina y en la actualidad es
aplicado a los Sistemas de Información Distribuidos, No solo define tres capas de
una arquitectura 3-tier (Presentación, Lógica de negocios y datos), más bien
define las responsabilidades y las dependencias dependiendo de los objetivos que
representa en tres paradigmas (Modelo, Vista y Controlador).
Estructura del Patrón Seleccionado
Nombre del Patrón: Model View Controller (MVC).
Justificación: Se selecciono un patrón para sistemas interactivos, ya que estos
permiten un grado alto de interacción del usuario, generalmente, con la ayuda de
interfaces de usuario gráficas. El objetivo es robustecer la utilidad de una
aplicación. Estos sistemas proporcionan un acceso conveniente a sus servicios, lo
cual permite a los usuarios aprender la aplicación y producir resultados
rápidamente.
Problema: La empresa requiere de un aplicativo para el control de sus compras,
ventas y toma de decisiones que sea de fácil uso, disponible en cualquier lugar
para cualquier cliente y proveedor, operado desde cualquier plataforma, y que sea
de rápida respuesta.
Motivación: La empresa está segura que con un aplicativo adecuado, el control
de sus ventas y la accesibilidad del aplicativo incrementarán sus ingresos, además
de controlar sus existencias y optimizar sus compras, sin tener stocks muertos.
Aplicabilidad: Cualquier modificación a los módulos, no interferirá con ninguno de
los procesos debido a la modularidad con que se diseñara, la plataforma en la que
estará alojado tampoco será problema, el uso de dispositivos portátiles dará una
amplia cobertura de acceso.
5
Carmen Gpe Fernández Gascón
8. Participantes: Clientes, Proveedores, Usuarios Empresa, Artículos, Almacén.
Colaboraciones:
Clientes: Accesa al sistema solicitando el producto o mercancía que
requiere, genera la orden de compra correspondiente, paga y recibe su
producto.
Proveedores: Accesa al sistema para verificar las existencias de los
productos que surte a la empresa, genera su orden de envió o de pago,
verifica deposito o pago y envía producto.
Almacén: Registra dentro del sistema la entrada de producto de acuerdo a
la orden de envió, registra la salida del producto de acuerdo a la orden de
compra.
Usuarios: Dependiendo del perfil al firmarse, tendrá los respectivos
atributos a los que tiene permitido.
Artículos: Son registrados dentro del sistema, en cada uno de ellos se
llevara la existencia, se sacan las estadísticas requeridas por la empresa
para su toma de decisiones.
Consecuencias: El objetivo es robustecer la utilidad de una aplicación. Estos
sistemas proporcionan un acceso conveniente a sus servicios, lo cual permite a
los usuarios aprender la aplicación y producir resultados rápidamente, MVC
separa al modelo de los componentes de la interfaz de usuario.
Múltiples vistas pueden ser implementadas y usadas con un simple modelo, el
mecanismo de propagación de cambios del modelo asegura que todos los
observadores registrados son notificados de los cambios en los datos de la
aplicación, en el momento correcto. Esto sincroniza todas las vistas y
controladores dependientes.
Implementación: Como el modelo es independiente de todo el código de la
interfaz de usuario, exportar una aplicación MVC a una nueva plataforma no
afectaría la funcionalidad central de la aplicación, solo es necesario la
implementación conveniente para esa plataforma, de los componentes vistas y
controladores.
La misma información se presenta de distintas formas, cambios en los datos
deben reflejarse en la interfaz inmediatamente, las interfaces deben modificarse
fácilmente, ojalá durante la ejecución, distintas interfaces portables no deben
afectar la operación esencial.
8
Carmen Gpe Fernández Gascón
9. Código de Ejemplo: Accesa al sistema para verificar las existencias de los
productos que surte a la empresa, genera su orden de envió o de pago, verifica
deposito o pago y envía producto, Cliente accesa al sistema genera su pedido,
registra o avisa del depósito o pago para que le sea surtido su pedido. La
Gerencia accesa al sistema analiza el comportamiento de las Compras y Ventas
efectuadas.
Código en Java para accesar a la Base de Datos
import java.sql.*;
class BasedeDatos{
String driver,url,login,password;
Connection conexion;
BasedeDatos(){
driver="com.mysql.jdbc.Driver";
url=new String("jdbc:mysql://localhost/test");
login=new String("root");
password=new String(" ");
try{ Class.forName(driver).newInstance();
conexion=DriverManager.getConnection(url,login,password);
System.out.println("Base de Datos ok...");
}
catch (Exception exc){
System.out.println("Error al tratar de abrir la base de Datos"); }
}
}
class PruebaBasedeDatos{
public static void main(String args[]){
BasedeDatos bd =new BasedeDatos(); }
}
Patrones relacionados: Patrón Arquitectónico BROKER, ya que es un patrón
arquitectónico aplicado en la estructuración de sistemas distribuidos en los cuales
es necesaria la interacción remota de componentes altamente desacoplados, lo
anterior se logra al introducir un componente BROKER cuya función principal es
lograr el desacoplamiento de los clientes y de los servidores, también registra a los
servidores, logrando de esta forma que los servicios que estos ofrecen estén
disponibles a los posibles clientes.
9
Carmen Gpe Fernández Gascón
10. Conclusiones
En base a los requerimientos que la empresa requiere para el control de sus
procesos, y en las características actuales en el desarrollo de sistemas me
encontré en las disyuntiva entre seleccionar un patrón para sistemas Distribuidos
como el BROKER ó de uno para Sistema Interactivos como el MVC (Model View
Controller), aunque mi experiencia es mínima en estos temas, decidí enfocar el
proyecto en el MVC, ya que este tipo de patrón permite un grado alto de
interacción del usuario, generalmente, con la ayuda de interfaces de usuario
gráficas.
Algunas de las características las tome de trabajos y documentos encontrados que
se referían al tema en cuestión, posiblemente se adapte otro patrón mejora al
escogido pero creo que con más experiencia y conocimiento sabré elegir el mejor
que se adapte a los requerimientos exigidos. MVC brinda probablemente la más
conocida organización arquitectónica para los sistemas de software interactivos.
Fuentes de consulta:
1. Arquitectura de Software: Estilos y Patrones, Adriana Sandra Almeira.
2. Universidad Nacional de la Patagonia San Juan Bosco Argentina, 2007.
3. Introducción a los Patrones (Diseño y arquitectura), Prof. Sergio Ochoa,
2005.
10
Carmen Gpe Fernández Gascón
