sad vistas "4+1" pod

Roberth Loaiza |Gerardo Gutiérrez

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

La Universidad Católica de Loja

ESCUELA DE SISTEMAS INFOMÁTICOS Y COMPUTACIÓN

Sistema PoD

1

Tabla de contenid

1 o

1. INTRODUCCIÓN....................................................................................................................................................3

1.1. PROPÓSITO......................................................................................................................................................................3

1.2. ALCANCE.......................................................................................................................................................................... 3

1.3. DEFINICIONES, ACRÓNIMOS, Y ABREVIACIONES..........................................................................................3

2. REPRESENTACIÓN ARQUITECTÓNICA.........................................................................................................3

3. OBJETIVOS Y LIMITACIONES DE LA ARQUITECTURA.............................................................................5

3.1. OBJETIVOS GENERALES............................................................................................................................................5

3.2. RESTRICCIONES............................................................................................................................................................5

4. VISTA DE ESCENARIOS......................................................................................................................................5

5. VISTA LÓGICA.......................................................................................................................................................5

5.1. DESCRIPCIÓN.................................................................................................................................................................6

5.2. PAQUETES DE DISEÑO ARQUITECTÓNICAMENTE SIGNIFICATIVOS...................................................8

5.2.1. PAQUETE CAPA DEL CLIENTE................................................................................................................8

5.2.5. PAQUETE CAPA DE PRESENTACIÓN....................................................................................................8

5.2.4.1. VISTA..............................................................................................................................................................9

5.2.4.2. CONTROLADOR..........................................................................................................................................9

5.2.4.3. MODELO........................................................................................................................................................9

5.2.5. PAQUETE CAPA DE NEGOCIO.................................................................................................................9

5.2.4.1. SESSION FACADES...................................................................................................................................10

5.2.4.2. SESSION BEANS........................................................................................................................................10

5.2.4.3. BUSINESS OBJECTS.................................................................................................................................11

5.2.4.4. ENTITY BEANS..........................................................................................................................................11

5.2.4.5. MECANISMOS DE COMUNICACIÓN.....................................................................................................11

5.2.5. PAQUETE CAPA DE DATOS...................................................................................................................12

5.2.4.1. CATÁLOGO PRINCIPAL..........................................................................................................................12

5.2.4.2. CATÁLOGO DE TIENDAS AFILIADAS.................................................................................................12

5.2.4.3. USUARIOS...................................................................................................................................................12

5.2.5. PAQUETE SISTEMAS EXTERNOS........................................................................................................12

6. VISTA DE PROCESOS........................................................................................................................................13

8. VISTA DE IMPLEMENTACIÓN........................................................................................................................14

1.1. DESCRIPCIÓN...............................................................................................................................................................14

2

SAD VERSIÓN 0.1

9. VISTA DE DESPLIEGUE....................................................................................................................................16

10. Anexos …………………………………………………………………………………………………………………………………………………17

3

1. INTRODUCCIÓN

Este documento brinda una perspectiva de alto nivel del Sistema Empresarial PoD el cual tiene como principal objetivo prestar el servicio de venta de instrumentos y accesorios musicales basado en las necesidades de los clientes. El sistema reúne una serie de tiendas que proveen los catálogos de los instrumentos que ofrecen con el fin de completar el pedido del cliente, siendo este proceso trasparente para el cliente.

1.1.PROPÓSITO

Este documento tiene como propósito describir el modelo arquitectónico del Sistema Empresarial PoD por medio de diferentes vistas con el fin de entregar una perspectiva global del diseño, modelamiento y funcionamiento de la aplicación y de esta forma cumplir los requerimientos funcionales y atributos de calidad descritos previstos para el sistema.

1.2.ALCANCE

El presente documento se basa en la descripción de arquitectura de Krutchen (Kruchten, 1995), que destaca los aspectos más importantes de cada vista, brindando éste como una herramienta y fuente de información para los usuarios, stakeholders, diseñadores e implementadores del sistema. Su alcance va hasta la definición, formulación y estructuración final de la arquitectura que será desarrollada e implementada por SAS para la construcción del sistema PoD. Adicionalmente se definirán y especificarán los aspectos más relevantes como el tamaño, el rendimiento y la calidad del sistema.

1.3.DEFINICIONES, ACRÓNIMOS, Y ABREVIACIONES

● Caso de uso: Secuencia de interacciones general entre uno o más actores y el sistema.[2]● EJB: Entity Java Bean.● Html: Hyper Text Markup Language.● http:● JDBC: ● JPA: Java Persistance API.● JSP: Java Server Pages.● MVC: Modelo Vista Controlador.● RMI: Remote Method Invocation● SMTP: PoDple Mail Transfer Protocol● RMI-IIOP: Java Remote Method Invocation ● Vista: Subconjunto de un modelo. [2]

4

2. REPRESENTACIÓN ARQUITECTÓNICA

Como se había mencionado anteriormente SAS hace uso del modelo de Philippe Kruchten de 4+1, a partir del cual se describen las abstracciones, la descomposición y la composición que deben ser seguidas para el desarrollo del sistema, de tal forma que se pueda tomar una decisión respecto a la selección del o de los estilos arquitectónicos que representan el sistema. Es importante mencionar que a través de las vistas 4+1 se mostrará cómo se satisfacen los requerimientos funcionales, sin embargo también cómo se satisfacen los requerimientos no funcionales del sistema, tales como confiabilidad, escalabilidad, portabilidad y disponibilidad.

Ilustración 1 Modelo de vistas 4+1

● Escenarios: Esta vista describe la integración de las demás vistas por medio de la especificación de casos de uso y el modelo entidad relación, definiendo los requerimientos funcionales del sistema PoD y describiendo la persistencia del sistema y la forma en que se van a almacenar los datos del sistema.

● Vista lógica: Esta vista describe la trasformación de los requerimientos funcionales a servicios para usuarios finales, de modo tal que se realiza una descomposición del sistema. Esta vista muestra de manera amplia cómo es que el sistema PoD debe funcionar.

● Vista de procesos: En esta vista se pueden encontrar los principales procesos e hilos que utiliza el sistema para manejar los eventos y así responder a los requerimientos funcionales sin olvidar los requerimientos no funcionales.

● Vista de implementación: La vista de implementación describe cómo se implementan los componentes físicos mostrados en la vista de despliegue agrupándolos en

5

subsistemas organizados en capas y jerarquías, y también ilustra las dependencias entre ellos.

● Vista de despliegue: Esta vista describe como los requerimientos no funcionales tales como disponibilidad, confiablidad (tolerancia a fallos), desempeño y escalabilidad, son mapeados en la ejecución y procesamiento del sistema PoD.

3. OBJETIVOS Y LIMITACIONES DE LA ARQUITECTURA

3.1.OBJETIVOS GENERALES

● El sistema debe tener una alta disponibilidad para atender sin ningún problema las peticiones de todos los usuarios.

● El sistema debe ofrecer buena navegabilidad en el sistema, brindándole links y medios de búsqueda para encontrar la información acerca de los instrumentos y accesorios musicales que necesite el cliente.

● Las búsquedas en el sistema debe permitir hacerse bajos dos criterios, uno que es para encontrar la fórmula a menor costo y otro para encontrar los productos que al ser enviados se demoren menos en llegar a la casa.

● Las búsquedas de los productos deben ser eficientes, los resultados se deben mostrar a los usuarios en un tiempo promedio de 2 segundos.

● Las búsquedas de los productos deben ser transparentes para los usuarios. ● Ofrecer un buen rendimiento durante la navegación a través del portal.● Ofrecer una interfaz amigable para la modificación o actualización del catálogo de

productos para el administrador del sistema PoD.● El sistema debe mantener la integridad de los datos que contiene y evitar la

modificación de estos por usuarios no autorizados.

3.2.RESTRICCIONES

● El sistema no debe permitir que haya concurrencia en la modificación de la información, es decir que únicamente el administrador del sistema es quien debe manejar los cambios del sistema.

● Para que un cliente haga una compra debe estar registrado en el sistema.● La conexión al sistema debe hacerse mediante un computador conectado a Internet.

6

4. VISTA DE ESCENARIOS

5. VISTA LÓGICA

En esta vista se pueden observar las partes arquitecturalmente significativas del diseño del modelo, teniendo en cuenta los principales paquetes y componentes y sus relaciones. Se tienen en cuenta algunos detalles técnicos y de describe de forma general cómo se realizará la implementación en la plataforma de ejecución.

5.1.DESCRIPCIÓN

De forma más puntual, esta vista está representada a través de los estilos arquitectónicos, Cliente- Servidor, arquitectura de tres capas, arquitectura JEE, empleando el patrón Modelo Vista Controlador (MVC). La idea es que por medio del concepto de cada uno de esos estilos se pueda adaptar un estilo arquitectónico único para el sistema POD.

Se toma como concepto el de Cliente-Servidor porque la aplicación debe ser distribuida; se mezclan los estilos de tres capas y arquitectura JEE para poder identificar con claridad las capas en las cuales va a estar distribuido el sistema y sus responsabilidades, permitiendo implementar los componentes con mayor facilidad y favoreciendo la integridad de los datos y la modificabilidad del sistema. Adicionalmente se hace uso del modelo MVC debido a que la aplicación necesita de múltiples vistas para un conjunto común de información y un control de las mismas.

En la ilustración # se muestra la representación total de esta vista:

7

5.2.PAQUETES DE DISEÑO ARQUITECTÓNICAMENTE SIGNIFICATIVOS

5.2.1.Paquete Capa del cliente

Este paquete representa el cliente del estilo arquitectónico Cliente-Servidor, en donde el cliente es que quien hace las solicitudes, a través del navegador, sobre los servicios que están en el servidor.

5.2.5.Paquete Capa de presentación

Dentro de este paquete se encuentra todo el código necesario para la interfaz de usuario y donde no se contiene la lógica del negocio. En este paquete es donde se maneja el patrón MVC, a través del cual se separa la presentación de la información a los usuarios y el acceso de datos controlado.

9

5.2.4.1. Vista

El subsistema vista es el encargado de desplegar todas las interfaces del sistema ante el usuario a través de los Java Server Pages (JSP).

5.2.4.2. Controlador

El subsistema controlador es el gestor de eventos que llegan provenientes del cliente. El manejo de esos eventos se hace a través de los Servlets (responde a cualquier tipo de solicitudes, éstos son utilizados comúnmente para extender las aplicaciones alojadas por servidores web), quienes controlan la secuencia de las interacciones con el usuario y el modelo. De igual forma estos son los encargados de mantener actualizadas las vistas, JSPs para este caso.

5.2.4.3. Modelo

Este subsistema es el que tiene la función de ocultar toda la implementación de las reglas del negocio a través de una interfaz que reciba las peticiones del controlador y las trasmita a la capa de negocio para que sean resueltas. Para lograr ese fin se definió el uso de dos patrones de diseño J2EE conocidos como Business Delagate y Service Locator. El primero, Business Delegate es utilizado para reducir el acoplamiento entre los clientes y los servicios de negocio. Además este se encarga de ocultar los detalles de la implementación de los servicios de negocio. Por otra parte el patrón Service Locator es utilizado para reducir la complejidad del código, proporcionando un punto de control y mejorando el rendimiento proporcionando facilidades de caché.

5.2.5.Paquete Capa de negocio

Este paquete es el que contiene las reglas de negocio que están segmentadas en subpaquetes y componentes las cuales son accedidas desde el paquete de Capa de presentación por el modelo.

En la siguiente ilustración se muestra el paquete completo:

10

5.2.4.1. Session Facades

Este es un patrón que se utiliza para proporcionar una interfaz sencilla que soporte un conjunto de casos de uso relacionados, para este caso los servicios en general del sistema POD. De acuerdo a lo anterior y con el fin de reducir el acoplamiento se definieron tres interfaces Session Facade: Servicios de POD, Gestor de POD y Gestor de comunicación externa. La primera se refiere la interfaz que comunicará con los servicios que POD le suministra a los clientes. La segunda se refiere a la interfaz que hace comunicación con todos los servicios relacionados con la administración de los usuarios del sistema y del sistema mismo. Por último, la tercera interfaz es para todos los servicios que implican comunicación con sistemas externos.

5.2.4.2. Session Beans

En los Session Beans es donde se va a manejar toda la lógica de negocio. Para facilitar su entendimiento, implementación y modificabilidad se segmentaron los servicios del sistema de acuerdo a tres actores principales identificados en los escenarios, ver sección 4. Se dividieron en, Servicios de POD, los cuales están directamente relacionados con los clientes, Servicios para gestor de roles y Servicios para administrar POD, relacionados con el administrador del sistema y por último Servicios con entidades externas relacionados con los sistemas externos con lo que se comunica el sistema POD.

Dentro de los Servicios de POD se encuentran la funcionalidades principales del sistema tales como:

11

● Buscar producto● Comprar producto● Consultar catálogo● Consultar historial de compras● Manejar carrito de compras

Dentro de los Servicios para gestor de roles y Servicios para administrar POD se encuentran funcionalidades tales como:

● Registrar usuario● Eliminar usuario● Afiliar instrumento● Eliminar instrumento● Consultar instrumento● Actualizar catálogo

Por último en los Servicios con entidades externas se encuentra funcionalidades como:

● Hacer pedido● Verificar información financiera● Enviar productos

5.2.4.3. Business Objects

Estos son los componentes que van a gestionar las peticiones acerca de los servicios, teniendo en cuenta el mapeo de la información que se debe hacer desde los Entity beans.

5.2.4.4. Entity Beans

Estos son los objetos encargados de mapear o vincular las columnas de una tabla de la base de datos con los atributos de cualquier objeto. Estos están segmentados de acuerdo a los servicios del sistema, tal y como se describe en la sección 5.2.3.2.

5.2.4.5. Mecanismos de comunicación

Este componente se refiere a la forma en que la capa de negocio se va a comunicar con la capa de datos y con los sistemas externos. Para la gestión de los datos se hace uso del controlador de la base de datos, el JDBC, mientras que para el envío de mensajes a los sistemas externos se hace uso del protocolo SMTP.

12

5.2.5.Paquete Capa de Datos

Este paquete contiene la forma en que está organizada la base de datos del sistema POD. A continuación se muestra el paquete:

5.2.4.1. Catálogo Principal

Esta es la base de datos principal del sistema en donde se va a guardar información sobre el catálogo de productos único del sistema.

5.2.4.2. Catálogo de tiendas afiliadas

Este componente se refiere a los inventarios de cada una de las tiendas afiliadas al sistema que hacen parte del catálogo principal.

5.2.4.3. Usuarios

Dentro de la base de datos esta es toda la información relacionadas con los usuarios y sus compras.

5.2.5.Paquete Sistemas externos

Este paquete se refiere a las entidades con las que el sistema POD tiene que comunicarse para llevar a cabo la completitud de los servicios solicitados por los clientes. Como están descritos en la sección 4, los actores externos son VISA, MASTERCAD, como agentes financieros para verificar la información crediticia de los

13

clientes y Servientrega, la cual es la entidad encargada de recoger y llevar los productos a los clientes.

6. VISTA DE PROCESOS

7. Ilustración 1. Vista de procesos

Esta sección describe la descomposición del sistema en los procesos de peso ligero (solo hilos de control) y los procesos de peso pesado (agrupaciones de los procesos de peso ligero).La vista de proceso describe la estructura de procesos del sistema. Dentro de los procesos, se encuentran los hilos arquitectónicamente importantes. En esta vista se describen las tareas (procesos y subprocesos) que participan en la ejecución del sistema, sus interacciones y configuraciones, así como la asignación de los objetos a las tareas.

Grupo Proceso inicial

Proceso Final

Modo de comunicación

Cliente/Contenedor Web

Navegar Gestionar eventos

Interrupciones

Contenedor web Gestionar eventos

Desplegar eventos

Mensajes

Contenedor web Gestionar eventos

Invocar peticiones

Mensajes

Contenedor web/ Contenedor de

Invocar peticiones

Manejar solicitudes

Mensajes

14

aplicacionesContenedor de aplicaciones

Manejar solicitudes

Servicios del sistema POD

Mensajes

Contenedor de aplicaciones


Realizar conexión

Contenedor de aplicaciones


Mapear información de servicios

Contenedor de aplicaciones/Sistemas externos

Realizar conexión

Procesar mensajes

Mensajes

Contenedor de aplicaciones/Base de datos

Mapear imformación

Gesionar datos

Tabla 1. Documentación de la vista de procesos

8. VISTA DE IMPLEMENTACIÓN

En esta vista se enfoca el diseño sobre la estructuración y organización de los módulos del sistema, describiendo a fondo los componentes y las relaciones que fueron necesitados para el desarrollo de este.

1.1.DESCRIPCIÓN

Para el diseño de esta vista, al igual que en la vista lógica se emplearon como estilos arquitectónicos, la arquitectura de tres capas, la arquitectura JEE y el patrón MVC. Como se había descrito en la vista lógica se escogen los estilos por capas para organizar jerárquicamente los módulos del sistema, en donde cada capa provee de servicios a la capa superior y es servido por la capa inferior.

La vista de implementación completa se muestra a continuación:

15

Ilustración 2 Vista de implementación

9. VISTA DE DESPLIEGUE

10. Ilustración 3. Vista de Despliegue

En esta vista se muestran las relaciones físicas de los distintos nodos que componen el sistema y representa la disposición de las instancias de componentes de ejecución en instancias de nodos conectados por enlaces de comunicación.

Esta vista permite determinar las consecuencias de la distribución y la asignación de recursos, y adicionalmente la configuración en funcionamiento del sistema, incluyendo su hardware y su software.

Nodo inicial

Nodo final Descripción Interconexión

Cliente Servidor Web-Tomcat

PC desde el que accede a la aplicación

Protocolo de transferencia http

17

Puerto: 8080Servidor Web-Tomcat

Servidor de aplicaciones-WebLogic

Servidor en el cual se ejecutan los componentes visuales y de conexión con el servidor de aplicaciones.

Interfaz RMI-IIOP

Base de datos-Oracle 10i


Base de datos para la persistencia de la aplicación.

API JBDCPuerto: 1522


Servidor Web-Tomcat

Servidor en el cual se ejecutan los componentes de la capa de negocio y de conexión del sistema.

Interfaz RMI-IIOP

11. Tabla 2. Documentación de Vista de despliegue

ANEXOS.

Presentación de la Arquitectura antes mencionada.

18

Referencia:

- Arquitectura tomada de Tatiana Oquendo, Olga Sarmiento, Diego Valdeblánquez, Software Architecture Solutions, Edición 2009, Tomada el 01-06-2015, URL=

http://arquitectura2010-1.googlecode.com/svn/trunk/

23

sad vistas "4+1" pod

Documents