El documento presenta la arquitectura del sistema PoD para la venta de instrumentos y accesorios musicales. Describe las diferentes vistas de la arquitectura, incluyendo escenarios, lógica, procesos, implementación y despliegue. La arquitectura sigue un estilo de cliente-servidor y tres capas, y usa JEE y MVC. Las capas son presentación, negocio y datos. La capa de negocio contiene servicios para clientes, administración y sistemas externos. La capa de datos almacena catá
Resumen del Rational Unified Process (RUP) para la materia de Análisis y Diseño de Sistemas de Información (INF - 162) de la carrera de Informática de la Universidad Mayor de San Andrés
En este documento explica en que consiste BPMN 2.0, explica cada uno de sus elementos y aborda la importancia que tendría de utilizarla como soporte en las etapas de análisis y diseño en un entorno de desarrollo de software.
CUADRO COMPARATIVO TIPOS DE SERVIDORES Y EL MANEJO DE SUS DATOS Lina Chavez
ESTE CUADRO COMPARATIVO DA LA INFORMACIÓN NECESARIA PARA COMPRENDER MAS A FONDO EL USO QUE DA CADA SERVIDOR A SUS DATOS Y EL DESARROLLO EN EL CUAL SE PRESENTA SU SERVICIO A LOS CLIENTES Y SUS NECESIDADES.
Cette présentation décrit un concept architecture qui n'est pas nouveau, la séparation des commande et des requête et un autre les événements comme source d'information.
Ensemble ils forment un duo imbattable pour développer des application performantes et robustes.
Resumen del Rational Unified Process (RUP) para la materia de Análisis y Diseño de Sistemas de Información (INF - 162) de la carrera de Informática de la Universidad Mayor de San Andrés
En este documento explica en que consiste BPMN 2.0, explica cada uno de sus elementos y aborda la importancia que tendría de utilizarla como soporte en las etapas de análisis y diseño en un entorno de desarrollo de software.
CUADRO COMPARATIVO TIPOS DE SERVIDORES Y EL MANEJO DE SUS DATOS Lina Chavez
ESTE CUADRO COMPARATIVO DA LA INFORMACIÓN NECESARIA PARA COMPRENDER MAS A FONDO EL USO QUE DA CADA SERVIDOR A SUS DATOS Y EL DESARROLLO EN EL CUAL SE PRESENTA SU SERVICIO A LOS CLIENTES Y SUS NECESIDADES.
Cette présentation décrit un concept architecture qui n'est pas nouveau, la séparation des commande et des requête et un autre les événements comme source d'information.
Ensemble ils forment un duo imbattable pour développer des application performantes et robustes.
1. 1
UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA
La Universidad Católica de Loja
ESCUELA DE SISTEMAS INFOMÁTICOS Y COMPUTACIÓN
Sistema PoD
Roberth Loaiza |Gerardo Gutiérrez
SAD VERSIÓN 0.1
2. 2
1 Tabla de contenido
1. INTRODUCCIÓN .......................................................................................................................................................3
1.1. PROPÓSITO....................................................................................................................................................... 3
1.2. ALCANCE........................................................................................................................................................... 3
1.3. DEFINICIONES, ACRÓNIMOS, YABREVIACIONES.................................................................................. 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. PAQUETESDEDISEÑ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
9. VISTA DE DESPLIEGUE....................................................................................................................................... 16
10. Anexos …………………………………………………………………………………………………………………………………………………17
3. 3
1. INTRODUCCIÓN
Este documento brinda una perspectiva de alto nivel del Sistema Empresarial PoD el cual tiene
como principal objetivoprestarel serviciode ventade instrumentosyaccesoriosmusicales basado
enlas necesidadesde losclientes.El sistemareúne unaserie de tiendasque proveenlos catálogos
de los instrumentos que ofrecenconel finde completarel pedidodel cliente,siendoeste 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]
2. REPRESENTACIÓN ARQUITECTÓNICA
Comose había mencionadoanteriormente SAShace 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
4. 4
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
requerimientosfuncionalesdel sistemaPoDydescribiendolapersistenciadel sistema
y la forma en que se van a almacenar los datos del sistema.
● Vista lógica: Esta vistadescribe latrasformaciónde 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 estavistase pueden encontrar los principales procesos e hilos
que utilizael sistema para manejar los eventos y así responder a los requerimientos
funcionales sin olvidar los requerimientos no funcionales.
● Vista de implementación:La vistade implementacióndescribecómose implementan
los componentes físicos mostrados en la vista de despliegue agrupándolos en
subsistemas organizados en capas y jerarquías, y también ilustra las dependencias
entre ellos.
● Vista de despliegue:Estavistadescribe comolosrequerimientosnofuncionalestales
como disponibilidad, confiablidad (tolerancia a fallos), desempeño y escalabilidad,
son mapeados en la ejecución y procesamiento del sistema PoD.
5. 5
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 sistemadebe ofrecerbuenanavegabilidadenel sistema,brindándole linksymedios
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úsquedasde losproductosdebensereficientes,losresultados 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ónal sistema debe hacerse mediante un computador conectado a Internet.
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
tienenencuentaalgunosdetallestécnicosyde describe de formageneral cómose realizará la
implementación en la plataforma de ejecución.
6. 6
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
VistaControlador(MVC).Laideaesque por mediodel conceptode cadauno de esosestilosse
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
implementarloscomponentesconmayorfacilidadyfavoreciendo la integridad de los datos y
la modificabilidaddel sistema. Adicionalmente se hace uso del modelo MVC debido a que la
aplicaciónnecesitade múltiplesvistasparaunconjuntocomúnde informaciónyuncontrol de
las mismas.
En la ilustración # se muestra la representación total de esta vista:
8. 8
5.2.PAQUETES DE DISEÑO ARQUITECTÓNICAMENTE SIGNIFICATIVOS
5.2.1.Paquete Capa del cliente
Este paquete representael clientedel estiloarquitectónicoCliente-Servidor,endonde el
cliente esque quienhace lassolicitudes,atravésdel navegador, sobre los servicios que
están en el servidor.
5.2.5.Paquete Capa de presentación
Dentrode este paquete se encuentratodoel códigonecesarioparalainterfazde usuario
y donde no se contiene la lógica del negocio. En este paquete es donde se maneja el
patrón MVC,a travésdel cual se separa lapresentaciónde lainformaciónalosusuariosy
el acceso de datos controlado.
9. 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
interaccionesconel usuarioyel modelo.De igual formaestossonlosencargadosde
mantener actualizadas las vistas, JSPs para este caso.
5.2.4.3. Modelo
Este subsistemaesel que tiene lafunciónde ocultar toda la implementación de las
reglasdel negocioatravésde una interfazque recibalas peticiones del controlador
y las trasmita a la capa de negocio para que sean resueltas. Para lograr ese fin se
definióel usode dos patrones de diseño J2EE conocidos como Business Delagate y
Service Locator. El primero, Business Delegate es utilizado para reducir el
acoplamientoentre losclientes 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. 10
5.2.4.1. Session Facades
Este es un patrónque se utilizapara proporcionar una interfaz sencilla que soporte
un conjuntode casosde usorelacionados,paraeste casolosserviciosengeneral del
sistema POD. De acuerdo a lo anterior y con el fin de reducir el acoplamiento se
definierontresinterfacesSessionFacade:Serviciosde 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 relacionadosconlosclientes,Serviciosparagestorde rolesyServicios
para administrar POD, relacionados con el administrador del sistema y por último
Serviciosconentidadesexternas relacionadoscon 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. 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 sonloscomponentesque vanagestionarlaspeticionesacercade losservicios,
teniendoencuentael mapeode la información que se debe hacer desde los Entity
beans.
5.2.4.4. Entity Beans
Estos sonlosobjetosencargadosde mapearo vincularlascolumnasde una tabla de
la base de datos con losatributosde 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 lossistemasexternos.Paralagestiónde losdatosse 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. 12
5.2.5.Paquete Capa de Datos
Este paquete contiene laformaenque estáorganizadalabase de datos del sistema
POD. A continuación se muestra el paquete:
5.2.4.1. Catálogo Principal
Esta es labase de datosprincipal 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
Dentrode la base de datosestaes todala informaciónrelacionadasconlosusuarios
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. 13
clientesyServientrega,lacual eslaentidadencargadade recogery llevarlosproductos
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. 14
aplicaciones
Contenedor de
aplicaciones
Manejar
solicitudes
Servicios del
sistema POD
Mensajes
Contenedor de
aplicaciones
Servicios del
sistema POD
Realizar
conexión
Contenedor de
aplicaciones
Servicios del
sistema POD
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:
16. 16
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
Puerto: 8080
Servidor Web- Servidor de Servidor en el cual se Interfaz RMI-IIOP
17. 17
Tomcat aplicaciones-
WebLogic
ejecutan los
componentes visuales y
de conexión con el
servidor de aplicaciones.
Base de
datos-
Oracle 10i
Servidor de
aplicaciones-
WebLogic
Base de datos para la
persistencia de la
aplicación.
API JBDC
Puerto: 1522
Servidor de
aplicaciones-
WebLogic
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.