SlideShare una empresa de Scribd logo
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
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
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
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
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
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:
7
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
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
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
● 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
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
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
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:
15
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
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.
18
19
20
21
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/

Más contenido relacionado

La actualidad más candente

PRESENTACIÓN RUP
PRESENTACIÓN RUPPRESENTACIÓN RUP
PRESENTACIÓN RUP
MSc Aldo Valdez Alvarado
 
BPMN 2.0 en el Proceso de Desarrollo de Software
BPMN 2.0 en el Proceso de Desarrollo de SoftwareBPMN 2.0 en el Proceso de Desarrollo de Software
BPMN 2.0 en el Proceso de Desarrollo de Software
Johan Robles Solano
 
Sesion 3 2 modelo de analisis
Sesion 3 2 modelo de analisisSesion 3 2 modelo de analisis
Sesion 3 2 modelo de analisisJulio Pari
 
CUADRO COMPARATIVO TIPOS DE SERVIDORES Y EL MANEJO DE SUS DATOS
CUADRO COMPARATIVO TIPOS DE SERVIDORES Y EL MANEJO DE SUS DATOS CUADRO COMPARATIVO TIPOS DE SERVIDORES Y EL MANEJO DE SUS DATOS
CUADRO COMPARATIVO TIPOS DE SERVIDORES Y EL MANEJO DE SUS DATOS
Lina Chavez
 
Vistas Arquitectonicas Ingenieria de Software
Vistas Arquitectonicas Ingenieria de SoftwareVistas Arquitectonicas Ingenieria de Software
Vistas Arquitectonicas Ingenieria de SoftwareRoberth Loaiza
 
Génie Logiciel : Conception
Génie Logiciel : ConceptionGénie Logiciel : Conception
Génie Logiciel : Conception
Mohammed Amine Mostefai
 
2 1 vistas arquitectonicas
2 1 vistas arquitectonicas2 1 vistas arquitectonicas
2 1 vistas arquitectonicaslandeta_p
 
Estructura básica de un Sistema Operativo
Estructura básica de un Sistema Operativo Estructura básica de un Sistema Operativo
Estructura básica de un Sistema Operativo
lizbethvazquezramirez
 
Lectura 3 Modelo De Analisis
Lectura 3   Modelo De AnalisisLectura 3   Modelo De Analisis
Lectura 3 Modelo De Analisis
guest0a6e49
 
Diagrama de actividades
Diagrama de actividadesDiagrama de actividades
Diagrama de actividades
ElvisAR
 
Mapa Conceptual Servidores web
Mapa Conceptual Servidores webMapa Conceptual Servidores web
Mapa Conceptual Servidores webArturo_09
 
Diagramas estados
Diagramas estadosDiagramas estados
Diagramas estados
loco8888
 
Diagramas De Despligue Uml
Diagramas De Despligue UmlDiagramas De Despligue Uml
Diagramas De Despligue Uml
arcangelsombra
 
Algoritmos DEKKER y PETERSON
Algoritmos DEKKER y PETERSONAlgoritmos DEKKER y PETERSON
Algoritmos DEKKER y PETERSON
PANAFMX
 
Ingenieria de software basada en componentes -jeiner gonzalez blanco
Ingenieria de software basada en componentes  -jeiner gonzalez blancoIngenieria de software basada en componentes  -jeiner gonzalez blanco
Ingenieria de software basada en componentes -jeiner gonzalez blanco
Jeiner Gonzalez Blanco
 
Arquitectura de la nube: modelos de servicio y despliegue.
Arquitectura de la nube: modelos de servicio y despliegue.Arquitectura de la nube: modelos de servicio y despliegue.
Arquitectura de la nube: modelos de servicio y despliegue.
FranklinGomez38
 
Planificación por prioridad
Planificación por prioridadPlanificación por prioridad
Planificación por prioridadGarNav
 
CQRS + Event Sourcing
CQRS + Event SourcingCQRS + Event Sourcing
CQRS + Event Sourcing
Eric De Carufel
 
Modelado conceptual de aplicaciones web
Modelado conceptual de aplicaciones webModelado conceptual de aplicaciones web
Modelado conceptual de aplicaciones web
Grial - University of Salamanca
 
Mapa mental de hilos
Mapa mental de hilosMapa mental de hilos
Mapa mental de hilos
Benjamín Joaquín Martínez
 

La actualidad más candente (20)

PRESENTACIÓN RUP
PRESENTACIÓN RUPPRESENTACIÓN RUP
PRESENTACIÓN RUP
 
BPMN 2.0 en el Proceso de Desarrollo de Software
BPMN 2.0 en el Proceso de Desarrollo de SoftwareBPMN 2.0 en el Proceso de Desarrollo de Software
BPMN 2.0 en el Proceso de Desarrollo de Software
 
Sesion 3 2 modelo de analisis
Sesion 3 2 modelo de analisisSesion 3 2 modelo de analisis
Sesion 3 2 modelo de analisis
 
CUADRO COMPARATIVO TIPOS DE SERVIDORES Y EL MANEJO DE SUS DATOS
CUADRO COMPARATIVO TIPOS DE SERVIDORES Y EL MANEJO DE SUS DATOS CUADRO COMPARATIVO TIPOS DE SERVIDORES Y EL MANEJO DE SUS DATOS
CUADRO COMPARATIVO TIPOS DE SERVIDORES Y EL MANEJO DE SUS DATOS
 
Vistas Arquitectonicas Ingenieria de Software
Vistas Arquitectonicas Ingenieria de SoftwareVistas Arquitectonicas Ingenieria de Software
Vistas Arquitectonicas Ingenieria de Software
 
Génie Logiciel : Conception
Génie Logiciel : ConceptionGénie Logiciel : Conception
Génie Logiciel : Conception
 
2 1 vistas arquitectonicas
2 1 vistas arquitectonicas2 1 vistas arquitectonicas
2 1 vistas arquitectonicas
 
Estructura básica de un Sistema Operativo
Estructura básica de un Sistema Operativo Estructura básica de un Sistema Operativo
Estructura básica de un Sistema Operativo
 
Lectura 3 Modelo De Analisis
Lectura 3   Modelo De AnalisisLectura 3   Modelo De Analisis
Lectura 3 Modelo De Analisis
 
Diagrama de actividades
Diagrama de actividadesDiagrama de actividades
Diagrama de actividades
 
Mapa Conceptual Servidores web
Mapa Conceptual Servidores webMapa Conceptual Servidores web
Mapa Conceptual Servidores web
 
Diagramas estados
Diagramas estadosDiagramas estados
Diagramas estados
 
Diagramas De Despligue Uml
Diagramas De Despligue UmlDiagramas De Despligue Uml
Diagramas De Despligue Uml
 
Algoritmos DEKKER y PETERSON
Algoritmos DEKKER y PETERSONAlgoritmos DEKKER y PETERSON
Algoritmos DEKKER y PETERSON
 
Ingenieria de software basada en componentes -jeiner gonzalez blanco
Ingenieria de software basada en componentes  -jeiner gonzalez blancoIngenieria de software basada en componentes  -jeiner gonzalez blanco
Ingenieria de software basada en componentes -jeiner gonzalez blanco
 
Arquitectura de la nube: modelos de servicio y despliegue.
Arquitectura de la nube: modelos de servicio y despliegue.Arquitectura de la nube: modelos de servicio y despliegue.
Arquitectura de la nube: modelos de servicio y despliegue.
 
Planificación por prioridad
Planificación por prioridadPlanificación por prioridad
Planificación por prioridad
 
CQRS + Event Sourcing
CQRS + Event SourcingCQRS + Event Sourcing
CQRS + Event Sourcing
 
Modelado conceptual de aplicaciones web
Modelado conceptual de aplicaciones webModelado conceptual de aplicaciones web
Modelado conceptual de aplicaciones web
 
Mapa mental de hilos
Mapa mental de hilosMapa mental de hilos
Mapa mental de hilos
 

Destacado

Modelo 4+1
Modelo 4+1Modelo 4+1
Modelo 4+1
Israel Rey
 
Is.1p.5 arquitectura de software
Is.1p.5 arquitectura de softwareIs.1p.5 arquitectura de software
Is.1p.5 arquitectura de software
Universidad Politecnica de Catalunya
 
1.1ARQUITECTURA DE CUATRO MAS UN VISTAS
1.1ARQUITECTURA DE  CUATRO  MAS UN VISTAS1.1ARQUITECTURA DE  CUATRO  MAS UN VISTAS
1.1ARQUITECTURA DE CUATRO MAS UN VISTASadolfo0890
 
Arquitecturas de software - Parte 1
Arquitecturas de software - Parte 1Arquitecturas de software - Parte 1
Arquitecturas de software - Parte 1
Marta Silvia Tabares
 
Arquitectura de software
Arquitectura de softwareArquitectura de software
Arquitectura de softwareLiliana Pacheco
 

Destacado (8)

Modelo 4+1 vistas
Modelo 4+1 vistasModelo 4+1 vistas
Modelo 4+1 vistas
 
Módulo Ciclo de Charlas Profesionales 4+1
Módulo Ciclo de Charlas Profesionales 4+1Módulo Ciclo de Charlas Profesionales 4+1
Módulo Ciclo de Charlas Profesionales 4+1
 
Modelo 4+1
Modelo 4+1Modelo 4+1
Modelo 4+1
 
Is.1p.5 arquitectura de software
Is.1p.5 arquitectura de softwareIs.1p.5 arquitectura de software
Is.1p.5 arquitectura de software
 
1.1ARQUITECTURA DE CUATRO MAS UN VISTAS
1.1ARQUITECTURA DE  CUATRO  MAS UN VISTAS1.1ARQUITECTURA DE  CUATRO  MAS UN VISTAS
1.1ARQUITECTURA DE CUATRO MAS UN VISTAS
 
Vista lógica
Vista lógicaVista lógica
Vista lógica
 
Arquitecturas de software - Parte 1
Arquitecturas de software - Parte 1Arquitecturas de software - Parte 1
Arquitecturas de software - Parte 1
 
Arquitectura de software
Arquitectura de softwareArquitectura de software
Arquitectura de software
 

Similar a SAD Vistas "4+1" PoD

Especificación de requerimientos de software srs CURSO V AND V 7MO CICLO
Especificación de requerimientos de software srs CURSO V AND V 7MO CICLOEspecificación de requerimientos de software srs CURSO V AND V 7MO CICLO
Especificación de requerimientos de software srs CURSO V AND V 7MO CICLO
david grados
 
Tipos de arquitecturas de sistemas
Tipos de arquitecturas de sistemasTipos de arquitecturas de sistemas
Tipos de arquitecturas de sistemas
Rafael D Martinez
 
Guía de Estándar IEEE 830
Guía de Estándar IEEE 830Guía de Estándar IEEE 830
Guía de Estándar IEEE 830
Jose Luis Ortiz Acosta
 
Ieee 830
Ieee 830Ieee 830
Ciclo de vida cascada
Ciclo de vida cascadaCiclo de vida cascada
Ciclo de vida cascada
Jorge Ñauñay
 
Plan de pruebas_rev
Plan de pruebas_revPlan de pruebas_rev
Plan de pruebas_rev
Raul Mautino
 
6. Plan De Proyecto Bdtransito
6. Plan De Proyecto Bdtransito6. Plan De Proyecto Bdtransito
6. Plan De Proyecto Bdtransitojeison david
 
documento arquitectura
documento arquitecturadocumento arquitectura
documento arquitectura
Marco Alvarez Bustos
 
Administracion de datos
Administracion de datosAdministracion de datos
Administracion de datos
Usein Gonzalez
 
Tema 3 unidad v - scm
Tema 3   unidad v  - scmTema 3   unidad v  - scm
Tema 3 unidad v - scmUDO Monagas
 
Wholesite
WholesiteWholesite
Wholesite
Julio Ortega
 
Tipos de arquitecturas de sistemas
Tipos de arquitecturas de sistemasTipos de arquitecturas de sistemas
Tipos de arquitecturas de sistemas
Ivan Rene Bayona Salazar
 
Documentacion_de_proyectos_de_software
Documentacion_de_proyectos_de_softwareDocumentacion_de_proyectos_de_software
Documentacion_de_proyectos_de_software
fernaik
 
Manual técnico
Manual técnicoManual técnico
Manual técnico
UTPLCOMPUTACION
 
Manual técnico
Manual técnicoManual técnico
Manual técnico
UTPLCOMPUTACION
 
Fundamentos Básicos para el Diseño del Software - Sistemas II
Fundamentos Básicos para el Diseño del Software - Sistemas IIFundamentos Básicos para el Diseño del Software - Sistemas II
Fundamentos Básicos para el Diseño del Software - Sistemas II
JimmyWilfredMassVerd
 

Similar a SAD Vistas "4+1" PoD (20)

Especificación de requerimientos de software srs CURSO V AND V 7MO CICLO
Especificación de requerimientos de software srs CURSO V AND V 7MO CICLOEspecificación de requerimientos de software srs CURSO V AND V 7MO CICLO
Especificación de requerimientos de software srs CURSO V AND V 7MO CICLO
 
Tipos de arquitecturas de sistemas
Tipos de arquitecturas de sistemasTipos de arquitecturas de sistemas
Tipos de arquitecturas de sistemas
 
Guía de Estándar IEEE 830
Guía de Estándar IEEE 830Guía de Estándar IEEE 830
Guía de Estándar IEEE 830
 
Ieee830
Ieee830Ieee830
Ieee830
 
Ieee 830
Ieee 830Ieee 830
Ieee 830
 
Ciclo de vida cascada
Ciclo de vida cascadaCiclo de vida cascada
Ciclo de vida cascada
 
Plan de pruebas_rev
Plan de pruebas_revPlan de pruebas_rev
Plan de pruebas_rev
 
Modbus eai u5
Modbus eai u5Modbus eai u5
Modbus eai u5
 
6. Plan De Proyecto Bdtransito
6. Plan De Proyecto Bdtransito6. Plan De Proyecto Bdtransito
6. Plan De Proyecto Bdtransito
 
documento arquitectura
documento arquitecturadocumento arquitectura
documento arquitectura
 
Administracion de datos
Administracion de datosAdministracion de datos
Administracion de datos
 
Tema 3 unidad v - scm
Tema 3   unidad v  - scmTema 3   unidad v  - scm
Tema 3 unidad v - scm
 
Wholesite
WholesiteWholesite
Wholesite
 
Tipos de arquitecturas de sistemas
Tipos de arquitecturas de sistemasTipos de arquitecturas de sistemas
Tipos de arquitecturas de sistemas
 
Modelado
ModeladoModelado
Modelado
 
Modelado
ModeladoModelado
Modelado
 
Documentacion_de_proyectos_de_software
Documentacion_de_proyectos_de_softwareDocumentacion_de_proyectos_de_software
Documentacion_de_proyectos_de_software
 
Manual técnico
Manual técnicoManual técnico
Manual técnico
 
Manual técnico
Manual técnicoManual técnico
Manual técnico
 
Fundamentos Básicos para el Diseño del Software - Sistemas II
Fundamentos Básicos para el Diseño del Software - Sistemas IIFundamentos Básicos para el Diseño del Software - Sistemas II
Fundamentos Básicos para el Diseño del Software - Sistemas II
 

Más de Roberth Loaiza

Ionic framework UTPL
Ionic framework UTPLIonic framework UTPL
Ionic framework UTPL
Roberth Loaiza
 
Presentación gti
Presentación gtiPresentación gti
Presentación gti
Roberth Loaiza
 
Métodos de evaluación de proyectos de inversión
Métodos de evaluación de proyectos de inversiónMétodos de evaluación de proyectos de inversión
Métodos de evaluación de proyectos de inversión
Roberth Loaiza
 
IA Ensayo UTPL
IA Ensayo UTPLIA Ensayo UTPL
IA Ensayo UTPL
Roberth Loaiza
 
Métodos de evaluación de inversión de proyectos.
Métodos de evaluación de inversión de proyectos.Métodos de evaluación de inversión de proyectos.
Métodos de evaluación de inversión de proyectos.
Roberth Loaiza
 
Vistas arquitectonicas. _Ing Software
Vistas arquitectonicas. _Ing SoftwareVistas arquitectonicas. _Ing Software
Vistas arquitectonicas. _Ing SoftwareRoberth Loaiza
 
Escribir y publicar trabajos científicos.
Escribir y publicar trabajos científicos.Escribir y publicar trabajos científicos.
Escribir y publicar trabajos científicos.Roberth Loaiza
 
Biaventuras_Padre nuestro
Biaventuras_Padre nuestroBiaventuras_Padre nuestro
Biaventuras_Padre nuestroRoberth Loaiza
 
Necesidad de la recuperación
Necesidad de la recuperaciónNecesidad de la recuperación
Necesidad de la recuperación
Roberth Loaiza
 
Principio de arquímedes
Principio de arquímedesPrincipio de arquímedes
Principio de arquímedesRoberth Loaiza
 
Ecuaciones y desigualdades.
Ecuaciones y desigualdades. Ecuaciones y desigualdades.
Ecuaciones y desigualdades.
Roberth Loaiza
 
Informatica
InformaticaInformatica
Informatica
Roberth Loaiza
 

Más de Roberth Loaiza (15)

Ionic framework UTPL
Ionic framework UTPLIonic framework UTPL
Ionic framework UTPL
 
Presentación gti
Presentación gtiPresentación gti
Presentación gti
 
Métodos de evaluación de proyectos de inversión
Métodos de evaluación de proyectos de inversiónMétodos de evaluación de proyectos de inversión
Métodos de evaluación de proyectos de inversión
 
IA Ensayo UTPL
IA Ensayo UTPLIA Ensayo UTPL
IA Ensayo UTPL
 
Métodos de evaluación de inversión de proyectos.
Métodos de evaluación de inversión de proyectos.Métodos de evaluación de inversión de proyectos.
Métodos de evaluación de inversión de proyectos.
 
Vistas arquitectonicas. _Ing Software
Vistas arquitectonicas. _Ing SoftwareVistas arquitectonicas. _Ing Software
Vistas arquitectonicas. _Ing Software
 
Escribir y publicar trabajos científicos.
Escribir y publicar trabajos científicos.Escribir y publicar trabajos científicos.
Escribir y publicar trabajos científicos.
 
Biaventuras_Padre nuestro
Biaventuras_Padre nuestroBiaventuras_Padre nuestro
Biaventuras_Padre nuestro
 
Necesidad de la recuperación
Necesidad de la recuperaciónNecesidad de la recuperación
Necesidad de la recuperación
 
Diagrama de clases
Diagrama de clasesDiagrama de clases
Diagrama de clases
 
Modelado UML
Modelado UMLModelado UML
Modelado UML
 
Casos de uso
Casos de usoCasos de uso
Casos de uso
 
Principio de arquímedes
Principio de arquímedesPrincipio de arquímedes
Principio de arquímedes
 
Ecuaciones y desigualdades.
Ecuaciones y desigualdades. Ecuaciones y desigualdades.
Ecuaciones y desigualdades.
 
Informatica
InformaticaInformatica
Informatica
 

SAD Vistas "4+1" PoD

  • 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:
  • 7. 7
  • 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:
  • 15. 15
  • 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.
  • 18. 18
  • 19. 19
  • 20. 20
  • 21. 21 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/