Issuu on Google+

Diseño y Arquitectura de Software MODELOS DE ARQUITECTURA. Evidencia de Aprendizaje Unidad 2

JOSE LUIS LERMA PEREZ – AL10529689


Coñteñido Introducción...………………………………………………………………………….2 Patrones..…………………………………………………………………………...….3 Categoría de Patrones………………………………………………………………..5 Descripción del caso………………………………………………………………….8 Propuesta de Arquitectura de software……………………………………………..9 Objetivo………………………………………………………………………………..12 Diseño de la aplicación……………………………………………………………...13 Arquitectura…………………………………………………………………………...15 Vistas…………………………………………………………………………………..20 El modelo……………………………………………………………………………...23 El controlador…………………………………………………………………………24 Aplicación de la arquitectura MVL a Proyecto “BOL” ……………………………25 Arquitectura de la administración…………………………………………………..27 Conclusiones…………………………………………………………………………30 Referencias……...……………………………………………………………………30

José Luis Lerma Pérez

1


INTRODUCCION Hablar de arquitectura inmediatamente se nos viene a la imaginación la construcción de edificios modernos, estructuras impresionantes, centros comerciales ofreciendo una gran gama de posibilidades y comodidades, etc. y si de pronto viajamos a otra ciudad y somos un poco observadores nos daremos cuenta que algunos de ellos siguen el mismo patrón de construcción y de diseño.

Lo mismo pasa en el mundo del software, observaremos arquitecturas de software y patrones muy semejantes aunque entre ellos se administre y manipule información completamente opuesta.

La arquitectura de software es una pieza central del desarrollo de sistemas de software modernos. El objetivo de la arquitectura consiste en desarrollar sistemas de software en forma eficiente, estructurada y con capacidad de reúso. La arquitectura forma parte del proceso de diseño de software el cual también forma parte del proceso de desarrollo que comprende; requerimientos, diseño, implementación, pruebas y mantenimiento.

Los sistemas de software basados en Web han tenido un gran auge en las últimas décadas. Sus principales aplicaciones, los sistemas de comercio electrónico y las redes sociales han visto un crecimiento notable debido a la mejora de las tecnologías de Internet, de cómputo distribuido, de los lenguajes basados en objetos y las arquitecturas de hardware.

En la actualidad, empresas, organizaciones y personas emprendedoras tienen la opción de realizar un moderno tipo de venta denominado "venta online" (también conocido como venta en línea o venta en internet) con la finalidad de vender sus productos, servicios, ideas u otros, no solo en la ciudad o país donde residen, sino también, en otros países del mundo y además, durante las 24 horas del día y los 7 días de la semana. José Luis Lerma Pérez

2


PATRONES| Considerando algunos de los patrones existentes se observa que ellos pueden cubrir varios rangos de escala y abstracción:

- Estructurar un sistema de software dentro de subsistemas. - Soportar el refinamiento de subsistemas y componentes o la relación entre ellos. - Ayudar a implementar aspectos particulares de diseño en un lenguaje de programación específico.

Para refinar dicha escala podemos agrupar los patrones que representan un rango similar de abstracción en tres categorías: - Patrones Arquitectónicos - Patrones de Diseño - Idioms

Patrones Arquitectónicos

Los patrones arquitectónicos son plantillas que describen los principios estructurales globales que construyen las distintas Arquitecturas de Software viables. Plantean una organización estructural fundamental para un sistema de software, expresando un conjunto de subsistemas predefinidos, especificando responsabilidades y organizando las relaciones entre ellos. La selección de un patrón arquitectónico es además una decisión fundamental de diseño cuando se desarrolla un sistema de software.

Patrones de Diseño

Un patrón de diseño provee un esquema para refinar componentes de un sistema de software y la forma en que se relacionan entre sí. Describe una José Luis Lerma Pérez

3


estructura generalmente recurrente de comunicación de componentes que resuelve un problema de diseño general dentro de un contexto particular. Los patrones de diseño son patrones de granularidad media, ya que tienen menor nivel de abstracción que los patrones arquitectónicos pero tienden a ser independientes de un lenguaje de programación en particular o de un paradigma de programación.

La aplicación de un patrón de diseño no tiene un efecto fundamental en la estructura del sistema de software global, pero tiene gran injerencia sobre la arquitectura de un subsistema.

Idioms

Los Idioms están relacionados con la implementación de diseño de problemas particulares. Un Idiom es un patrón de bajo nivel específico para un lenguaje de programación.

Describe

como

implementar

aspectos

particulares

de

componentes o las relaciones entre ellos usando las características dadas por el lenguaje.

Los Idioms representan el nivel más bajo de patrones y direccionan tanto aspectos de diseño como de implementación.

José Luis Lerma Pérez

4


CATEGORIA DE PATRONES

Los patrones arquitectónicos representan el nivel más alto dentro del sistema de patrones y expresan el esquema de la estructura fundamental de la organización para sistemas de software. Proveen un conjunto de subsistemas predefinidos, especifican sus responsabilidades e incluyen reglas y guías para organizar las relaciones entre ellos. Cada patrón ayuda a lograr una propiedad específica del sistema global como es la adaptabilidad de la interfaz de usuario. Los patrones que dan soporte a propiedades similares pueden ser agrupados en las siguientes categorías:

José Luis Lerma Pérez

5


- Del fango a la estructura. Ayudan a evitar un “mar” de componentes u objetos. En particular apoyan una descomposición controlada de una tarea del sistema global en sub tareas cooperantes. Esta categoría incluye los patrones Layers, Pipes and Filters y Blackboard.

- Sistemas Distribuidos: incluye el patrón Broker y hace referencia a dos patrones que se encuentran en otras categorías, Microkernel y Pipes and Filters. El patrón Broker provee una infraestructura completa para aplicaciones distribuidas. Los patrones Microkernel y Pipes and Filters consideran la distribución como un concepto secundario y están ubicados bajo sus respectivas categorías primarias.

- Sistemas Interactivos: En esta categoría entran dos patrones el Model-ViewController (MVC) y el Presentation–Abstraction–Control (PAC). Ambos apoyan la estructuración de sistemas de software que ofrecen la interacción usuariocomputadora.

- Sistemas Adaptables: Los patrones Reflection y Microkernel apoyan fuertemente la extensión de aplicaciones y su adaptación a desenvolverse con la tecnología y cambios en los requisitos funcionales. La selección de un patrón arquitectónico debería ser conducida por las propiedades generales de la aplicación a estudiar. Por ejemplo, si el sistema propuesto es un sistema interactivo o uno que tendrá diferentes variantes, la elección del patrón debería estar influenciada más allá de los requerimientos no funcionales de la aplicación, como la modificabilidad

y la fiabilidad. La

selección de un patrón arquitectónico, o la combinación de varios, es solamente el primer paso cuando se diseña la arquitectura de software de un sistema.

José Luis Lerma Pérez

6


Hay puntos que son recomendables para tener en cuenta al momento de elegir un patrón arquitectónico: • Es útil explorar varias alternativas antes de decidir sobre un patrón arquitectónico específico. • Diferentes patrones arquitectónicos implican diferentes consecuencias, aún si direccionan al mismo o problemas similares. • Muchos sistemas de software no pueden ser estructurados de acuerdo a un patrón arquitectónico simple, dando soporte a requerimientos del sistema que solamente pueden ser solucionados mediante la aplicación de diferentes patrones arquitectónicos.

Un patrón arquitectónico particular, o una combinación de éstos, no es una arquitectura de software completa, es un framework estructural para un sistema de software que debe ser luego especificado y refinado. Esto incluye la tarea de integrar la funcionalidad de las aplicaciones con el framework y detallar sus componentes y relaciones.

Dentro de los patrones arquitectónicos se pueden citar: Layers, Pipes and Filters, Blackboard, Broker, Model-View–Controller, Presentation– Abstraction– Control, Microkernel y Reflection. En el capítulo siguiente se verá con más detalle cada uno de estos patrones.

José Luis Lerma Pérez

7


DESCRIPCION DEL CASO BOL (Buying OnLine) es una nueva empresa que lanzará ventas de artículos por internet, para lograr su objetivo, ha lanzado una convocatoria a Despachos que desarrollan software.

BOL requiere una página de Internet en donde promocionar sus artículos y gestionar las ventas., tiene que ser amigable para el cliente, además rápida, confiable y segura. Además competitiva y lograr los objetivos de venta en tiempo y forma.

Las ventas determinaran el flujo de inventarios de los artículos, los precios, las promociones. Así como las ponderar las ventas y ganancias.

Además asegurar la confidencialidad de los clientes, su perfil y sus operaciones realizadas. Satisfacer las necesidades de los clientes para que sean recurrentes y además proporcionen comentarios de satisfacción y de confianza para nuevos posibles clientes.

José Luis Lerma Pérez

8


PROPUESTA DE ARQUITECTURA Se va desarrollar una aplicación web para la empresa BOL donde pueda vender sus artículos y administrar sus ventas mediante el modelo de arquitectura.

Una arquitectura implementada para el caso: Modelo-Vista-Contolador (MVS)

Modelo Vista Controlador (MVC) es un patrón o modelo de abstracción de desarrollo de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de negocio en tres componentes distintos (modelo, vista y controlador). El patrón de llamada y retorno MVC (según la CMU), se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página, el modelo es el Sistema de Gestión de Base de Datos y la Lógica de negocio, y el controlador es el responsable de recibir los eventos de entrada desde la vista.

José Luis Lerma Pérez

9


Un modelo de arquitectura está indicado por la presencia de un controlador entre el navegador del cliente y las vistas que presentan el contenido. El controlador recibe cada petición http e invoca la operación del modelo solicitado de la operación y estado de la sesión. Este proceso se observa en la siguiente figura:

La misma información es presentada en forma diferente en diferentes vistas. Los cambios en los datos se deben reflejar inmediatamente en las vistas y el comportamiento. Los cambios a la interfaz del usuario deben ser fáciles, e incluso posibles en tiempo de ejecución. José Luis Lerma Pérez

10


Las vistas muestra los datos producidos por el modelo, normalmente, con una apariencia común y en este modelo, las vistas (paginas JSP o Servlets) están aisladas unas de otras.

Una vista compuesta compone sub vistas separadas en una página con un diseño específico. Cada sub vista (navegación, cuerpo, etc.) es un componente separado.

La vista compuesta controla la apariencia de todas las sub vistas, de forma que se centraliza el control sobre la apariencia de toda la aplicación. Además las subsistemas se utiliza por referencia, en vez de mantener copy-paste.

José Luis Lerma Pérez

11


OBJETIVO El objetivo de proyecto es automatizar la “Empresa BOL”, que venderá sus artículos por medio de internet. La aplicación tendrá dos interfaces web, a través de la interfaz de tienda acceden los clientes y mediante la interfaz de Administración acceden las administración de la tienda.

Los artículos estarán organizados mediante categorías o departamentos y existirán artículos destacados que aparecerán en el escaparate de la tienda. 

Todos los clientes podrán realizar las siguientes operaciones

Ver todos los artículos con los que cuentan la tienda

Las listas de productos estarán organizada por categorías

Ver los detalles de un producto

Seleccionar un artículo y añadirlo a la carrito de compra

Visualizar la carrito de la compra y modificar la cantidad de requerida de cada producto

Realiza el pedido con los productos de la carrito

José Luis Lerma Pérez

12


DISENO DE LA APLICACION Para el diseño de nuestra aplicación empezaremos evaluando los requisitos funcionales y determinar la implementación óptima para cumplir con ellos. Con el análisis de casos de uso identificaremos a los actores en nuestro sistema y las operaciones que puede realizar.

Nuestra aplicación en un caso típico de comercio electrónico. El cliente selecciona elementos del catálogo, los lleva a la carrito de compra donde selecciona la cantidad de cada artículo y la aplicación muestra el precio unitario, el subtotal y el preci9 total. Cuando el cliente tiene los artículos que desea en la carrito, realiza el pedido, suministrando los datos de envío y una tarjeta de crédito.

La siguiente figura muestra el diagrama de caso de uso para nuestro sistema. El diagrama muestra a los actores principales del sistema y sus respectivas acciones. 

Un cliente navega por el catalogo, gestiona la cuenta y realiza pedidos

Un administrador gestiona tienda

José Luis Lerma Pérez

13


Una vez que hemos determinado los requisitos de nuestro sistema podemos comenzar con el diseño de la aplicación. Puesto que nuestro objetivo es desarrollar una aplicación web interactiva, la arquitectura que se elige para el desarrollo de nuestro sistema será Modelo-Vistas-Controlador

José Luis Lerma Pérez

14


ARQUITECTURA La arquitectura MVC se adapta bien a nuestro sistema. Siendo que podemos descomponer nuestro sistema en tres bloques lógicos, el primero es el relativo a los aspectos de presentación, el segundo es aquel que trata con el modelo y los datos, y el tercero es el que recibe e intercepta las peticiones del usuario, y controla el flujo para responder estas peticiones.

Los controladores reciben la entrada, normalmente como eventos que codifican los movimientos del mouse o entrada del teclado. Los eventos son traducidos para servir a las demandas del modelo o las vistas. El usuario interactúa con el sistema solamente a través de los controladores.

El modelo encapsula los datos centrales y tiene la funcionalidad de la aplicación.

Es

un

componente

totalmente

independiente

de

las

representaciones específicas de salidas o del comportamiento de la entrada

Diferentes vistas presentan la información del modelo al usuario de distintas maneras. Pueden existir múltiples vistas de un mismo modelo, pero cada vista tiene una relación uno a uno con un controlador. Cada vista define un procedimiento de actualización que se activa por el mecanismo de propagación de cambios. Cuando es llamado el procedimiento de actualización, una vista recupera los valores de datos actuales del modelo para ser mostrados, y los pone en la pantalla

Como el aspecto de la interfaz gráfica de nuestro sistema cambia a menudo, su comportamiento cambia menos frecuente y el modelo de datos, es relativamente estable. De esta forma, será más fácil el código que ha de implementar

objetos de

presentación

después

de

que

la

aplicación

desplegada.. José Luis Lerma Pérez

15


La siguiente fase del proceso del diseño es partir la aplicación en módulos y objetos que implementen los diferentes requisitos funcionales

El siguiente diagrama muestra los casos de uso de la interfaz de usuario de nuestra aplicación

José Luis Lerma Pérez

16


José Luis Lerma Pérez

17


Un cliente que accede a la tienda, es pera ver los siguientes elementos:

Barra de navegación de tareas comunes Un catálogo que proporciona una vista organizada de los contenidos de la aplicación Un mecanismo de búsqueda Una vista detallada de cada producto Una vista del carrito de la compra que deja a los clientes revisar y modificar los contenidos del carrito Una vista de pedido que permita a los clientes introducir información sobre la entrega del pedido y medio de pago Una vista que confirma la compra

Una vez que los requisitos funcionales están identificados debemos identificar unidades de modelo de datos y lógica de presentación y modelarlos como objetos. Esto lo haremos identificando las opciones al nivel más alto y después iremos bajando hacia niveles inferiores.

La organización general de la aplicación sigue la arquitectura MVC ya que proporciona la estructura adecuada para manejar aplicaciones orientadas a las presentaciones complejas. Por otra parte, el diseño interno de algunos componentes individuales siguen patrones J2EE

El diseño de la aplicación consiste en partir en bloques pertenecientes al modelo, las vistas y el controlador, como se muestra en la siguiente figura

José Luis Lerma Pérez

18


José Luis Lerma Pérez

19


VISTAS Nuestra aplicación utilizará la tecnología JavaServer (JSP) para gestionar la presentación de las vistas del usuario. Además se podrá utilizar tecnología Servlets para la generación de gráficos u otras representaciones binarias en caso de que sea necesario.

Cuando se diseñan las vistas de la aplicación, se debe tener en cuenta los siguientes puntos:

1. Separa la lógica de presentación de la lógica de negocio y control

Nuestra aplicación utiliza JSP orientados a la presentación de la vista y no contienen lógica de control (la lógica de control la gestiona un controlador). De esta forma, es fácil reutilizar porciones de la lógica de presentación. También es importante evitar poner lógica de Scriptlests e embebidos.

La aplicación utilizará un patrón View Helpler que encapsula la lógica de presentación en un Custom tag JSP, clases Java para contener los datos y un JavaBean para obtener la fecha y hora del sistema. La lógica de presentación implementada en JavaBeans está separada de los datos y es modular y reutilizable, ya que define una vez y se reutiliza por referencia en múltiples paginas JSP.

José Luis Lerma Pérez

20


2. Gestión de la apariencia de las paginas

El diseño gráfico de la tienda se ha realizado intentando mantener un aspecto común a través de todas las páginas de la aplicación. Todas las paginas presentan la misma estructura: una cabecera, la parte más alta, una barra de navegación a la izquierda y un pie de página y son independientes unos de otros.

La siguiente figura muestra dos páginas de nuestra web. Aquí podemos ver que presentan un aspecto similar aunque el contenido de ambas es muy diferente.

BOL Regístrate Productos

Opina Estatus de pedidos

José Luis Lerma Pérez

21


Para que el aspecto de las páginas de la tienda sea similar, se utiliza un mecanismo de plantilla, como es el patrón de diseño de vista compuesta. La plantilla determinada como ensamblar las vistas en una única vista compuesta y consolida el aspecto de la aplicación en un único punto, haciendo fácil modificar el aspecto desde un punto centralizado. Además, la plantilla separa el aspecto del contenido.

3. Separación de roles de desarrollo

La arquitectura MVC proporciona los medios para separar el trabajo de los desarrolladores con diferentes perfiles, facilitando que cada grupo trabaje de forma independiente.

La aplicación utiliza un patrón View Helpler para separar datos de presentación de la lógica del negocio, permitiendo que los diseñadores gráficos realicen cambios en la presentación de las vistas sin afectar la funcionalidad. Por otra parte los desarrolladores Java pueden implementar la lógica de la aplicación sin afectar el diseño de las páginas.

José Luis Lerma Pérez

22


EL MODELO El modelo de la arquitectura MVC encapsula objetos de negocios y API de la funcionalidad de la aplicación. Nuestro proyecto utilizará clases Java para implementar su lógica de negocio.

Cuando se diseña el modelo de la aplicación, se debe tener en cuenta los siguientes puntos:

-Desarrollar el código como componentes para facilitar la realización.

El desarrollo de las aplicaciones se mejora si los desarrolladores diseñan el código en forma modular, como componentes reutilizables, para ser independientes unos de los otros. De esta formo cuando los componentes están muy desacoplados entre si, los cambios que se realizan en un componente no afecta el resto de los componentes.

-Separación de roles de desarrollo

De la misma forma que en el desarrollo de las vistas, el desarrollo de los componentes es más efectivo cuando los roles de desarrollo están separados. Por ejemplo si, si los desarrolladores de base de datos implementan objetos de acceso de datos, se oculta a los desarrolladores de la lógica de negocio los detalles de implementación de las llamadas de acceso a la base de datos.

José Luis Lerma Pérez

23


EL CONTROLADOR El controlador en la arquitectura MVC controla el flujo de la aplicación y sirve como cola de unión entre el modelo y las vistas, ya que ejecuta lógica de negocios entre el modelo en respuesta

a peticiones de usuario y a

continuación selecciona a la siguiente vista a mostrar. El controlador desacopla la presentación de datos la lógica y de datos.

La tienda virtual utiliza un Servlet como controlador. El Servlet controlador recibe peticiones http y las pasa al gestor de flujo, que selecciona la acción a realizar en base a la operación solicitada y la ejecuta. Después el gestor de flujo selecciona la siguiente vista a mostrar y se la pasa de vuelta al Servlet controlador que hace la redirección apropiada.

El controlador de la aplicación incluye también un filtro de peticiones que proporciona servicios de log a la aplicación. Filtra los parámetros recibidos en la petición y los pone como atributos y redirige la petición al controlador de administración si se recibe la cadena “admin” en la petición al controlador de la tienda tienda, localizando la operación realizada, o deja pasar la petición si se trata de peticiones de imagen gif o jpg.

José Luis Lerma Pérez

24


APLICACION DE LA ARQUITECTURA MVC La arquitectura de nuestra tienda virtual contiene un conjunto de componentes divididos en bloques de modelo, vistas y controlador. Examinando la arquitectura de la aplicación en más detalle, siguiendo una petición de usuario recibida. La siguiente figura muestra la descomposición de la tienda en componentes.

El cliente interactúa con diferentes vistas presentadas en el navegador y eventualmente, envía una petición al http. La petición va a la sección Controlador donde es interceptada por el filtro. El filtro recibe la petición, hace log de la petición y parámetros recibidos y selecciona el controlador de tienda o de administración o el recurso al que pasa la petición. El controlador de la tienda recibe la petición, recoge la operación a realizar y llama al gestor de flujo para que ejecute la operación. El gestor de flujo selecciona a la acción a realizar y la ejecuta. La acción recoge los datos necesarios de la petición y ejecuta la lógica de negocios requerida en el modelo.

El modelo accede a los datos almacenados en la base de datos de la tienda mediante un pool de conexiones. También contiene la funcionalidad de la carrito de compras.

De nuevo el bloque controlador, la acción devuelve los resultados de la operación en la propia petición para que sean mostrados por las visitas apropiadas. El gestor de flujo selecciona la siguiente vista a mostrar en función del resultado de la acción y se la pasa de regreso al servlet controlador que hace las redirecciones apropiadas.

En el bloqueador de vistas compuesta recibe las páginas de contenido a

José Luis Lerma Pérez

25


mostrar y la incluye para forma una única página que mostrar al cliente. La página de contenido recibe los datos y los presenta, ayudándose de custom tag que encapsulan la lógica necesaria y hacen uso de clases Java que encapsulan los datos.

José Luis Lerma Pérez

26


ARQUITECTURA DE LA ADMINISTRACION Para el diseño de la aplicación de administración denla tienda de convivencia, se han seguido los mismos pasos que para la Tienda Virtual, teniendo en cuenta las siguientes consideraciones.

El filtro es común para la parte pública (tienda virtual) que para la aplicación de administración.

El controlador gestiona la seguridad y el límite el acceso a la aplicación a los usuarios registrados que tengan permiso de administración.

Los datos de usuarios y permiten se almacenados en una base de datos diferentes de la tienda y son accedidos mediante un modelo también diferente.

Se ha optado por no utilizar un gestor de flujo que seleccione la acción a ejecutar y la vista a mostrar. Esta funcionalidad se ha incluido en el propio Servlet controlador. Para determinar qué operación realizar de utiliza el parámetro denomina “acción”

Con objeto de mostrar paginas JSP en las que se mezcle la lógica de negocio con la presentación no se utilizan los tags, si no que la funcionalidad esta embebida en los Scriptlets dentro de las páginas.

Las siguientes figuras muestran los casos de uso y la descomposición de la administración en componentes.

José Luis Lerma Pérez

27


José Luis Lerma Pérez

28


José Luis Lerma Pérez

29


CONCLUSIONES Después de haber trabajado con esta propuesta de arquitectura MVC, debemos de resaltar que no es la única adaptable al proyecto, que encontramos más opciones, pero también hay que destacar que no todas son aplicables. Por lo tanto es importante conocer la estructura que ofrece cada una de ellas y al momento de enfrentarse ante un nuevo proyecto saber cuál es la más adecuada.

Independientemente de la metodología implementada, la intención es obtener una arquitectura con la documentación necesaria, y asegurar que el sistema cumple con los servicios y la funcionalidad que espera el usuario, además de los atributos de calidad asociados que deben cumplirse, y que dirigen las decisiones al momento de la construcción de la arquitectura del sistema.

Rubros importantes como la seguridad e integridad de la información manipulada siempre tendrá que estar presente y a la vanguardia para todos los actores que interactúan.

REFERENCIAS

http://es.wikipedia.org/wiki/Arquitectura_de_software

http://prof.usb.ve/lmendoza/Documentos/PS6116/Guia%20Arquitectura%20v.2.pdf

http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=materias:introarq.pdf

José Luis Lerma Pérez

30


Evidencia U2 DAS UNADM