drs u2 ea_fegc

1 Carmen Gpe Fernández Gascón

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


Í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


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 Creación Factory Method Abstract Factory

Estructural Adapter Clss Adapter Object

Comportamiento Interpreter Chain of Responsibility

Object Builder Protitype Singleton

Bridge Composite Decorator Facade Flyweight Proxy

Command Iterator Mediator Memento State Strategy Visitor


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.


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.


.


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.


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.


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.

drs u2 ea_fegc

Documents