Академический Документы
Профессиональный Документы
Культура Документы
Versión 1.0
1
Historial de Revisiones
Fecha Versión Descripción Autor
03/06/2017 1.0 Elaboración de documento de -Grupo de trabajo
arquitectura
2
Índice
1. Introducción 5
1.1 Objetivo 5
1.2 Alcance 5
1.3 Definiciones, acrónimos y abreviaturas 5
1.4 Resumen 5
2. Representación Arquitectónica 6
3. Metas de arquitectura y limitaciones 6
3.1 Metas 6
3.2 Limitaciones especiales 6
4. VISTA DE CASOS DE USO 7
4.1 Descripción del Negocio 7
4.2 Procesos del Negocio 7
4.3 Modelo de dominio 9
4.4 Actores 10
4.5 Casos de Uso del Sistema 11
4.5.1 Diagrama de Casos de Uso del Sistema 11
4.5.2 Paquetes de CUS 12
4.5.2.1. P001 Gestión de Información de clientes 12
4.5.2.2. P002 Gestión de Adquisición de Pedido 12
4.5.2.3. P003 Gestión de la Información de venta 12
4.5.2.4. P004 Gestión de los Productos 13
4.5.2.5. P005 Gestión del comportamiento del pedido 13
4.5.2.6. P006 Gestión del manejo del producto 13
4.6 Descripción de los Casos de Uso del Sistema 14
4.6.1 Descripción CUS – Agregar Producto al Carro de Compras 14
4.6.2 Descripción CUS Mostrar Catálogo 15
4.6.3 Descripción CUS Mantener Carro de Compras 16
5. VISTA LÓGICA 17
5.1 Resumen 17
5.2 Diseño de Paquetes de gran importancia en la Arquitectura 17
3
5.2.1. Capa WEB 17
5.2.2. Capa Controlador 17
5.2.3. Capa de Servicios 17
5.2.4. Capa de Repositorio 17
5.2.5. Capa de Datos 18
5.3 Realizaciones de casos de uso 18
Diagrama de Clases 18
5.3.1 CUS101 – Mostrar catálogo 19
5.3.2 CUS105 – Agregar producto al carro de compras 20
Diagrama de Secuencia 20
5.3.3 CUS102 – Mantener carro de compras 20
Diagrama de Secuencia 20
6. VISTA DE PROCESOS 21
7. VISTA FÍSICA 21
8. VISTA DE DATOS 21
8.1 Distribución 21
8.2 Servicios de Persistencia 21
8.3 Diagrama Entidad – Relación 22
8.4 Diagrama Lógico 23
8.5 Diagrama Físico 24
9. CALIDAD 25
9.1 Usabilidad 25
9.2 Eficiencia 25
9.3 Seguridad 25
9.4 Disponibilidad 25
4
Documento de Arquitectura de Software
1. Introducción
El presente documento nos da una vista de alto nivel de la Arquitectura del Sistema Integral de
Gestión de Ventas para la empresa Process Control. Se muestran los objetivos, los principales
procesos de negocio, el estilo arquitectónico que se aplicará en el Sistema y las distintas vistas
basadas en el modelo 4+1.
1.1 Objetivo
Este documento tiene el objetivo de proporcionar una visión general de la arquitectura global
del Sistema Integral de Gestión de Ventas para la empre Process Control con el fin que no sólo
un personal o revisor técnico sea capaz de conocer y entender el presente proyecto, sino que
cualquier colaborador relacionado al área de aplicación del proyecto tenga una idea general de
éste.
1.2 Alcance
En el presente documento abarcaremos los casos de uso más importantes para el Sistema
Integral de Gestión de Ventas en base al modelo de vistas 4+1, además de mencionar los
procesos de negocio del sector, modelo de datos e información adicional.
● Orden de pedido: Código único que se genera al realizar alguna compra de producto
● Catálogo de producto: Lista de productos disponibles para la venta
● Registro de ventas: Lista de ventas concretadas en un periodo de tiempo especifico
● Pedido: Lista de productos requeridos por parte del cliente
1.4 Resumen
El Documento de Arquitectura de Software brindará una visión general del Sistema Integral de
Gestión de Ventas.
5
En las siguientes secciones se explayará lo concerniente a las distintas vistas del modelo 4+1:
Vista de Casos de Uso, Vista Lógica, Vista de Procesos, Vista de Implementación y Vista de
Despliegue. Luego de esto, el lector tendrá un mejor entendimiento del Sistema Integral de
Gestión de Ventas.
2. Representación Arquitectónica
3.1 Metas
6
4. VISTA DE CASOS DE USO
7
➢ Evaluar pedido
8
➢ Importar producto
9
Figura 4. Modelo del dominio.
4.4 Actores
10
Identificamos a cuatro Actores del Sistema:
11
4.5.2 Paquetes de CUS
4.5.2.1. P001 Gestión de Información de clientes
12
4.5.2.4. P004 Gestión de los Productos
13
4.6 Descripción de los Casos de Uso del Sistema
Se han identificado los siguientes CUS que son relevantes para la arquitectura del Sistema:
● CUS Agregar Productos al Carro de Compras
● CUS Mostrar Catálogo
● CUS Mantener Carro de Compras
Flujo Principal
1. El caso de uso inicia cuando el Cliente selecciona la opción “Añadir al carro de
compras”.
2. El sistema muestra una pantalla con información del producto (código, nombre,
precio, cantidad).
3. El Cliente indica la cantidad a comprar y selecciona la opción “Añadir”.
4. El sistema registra los cambios en el carro de compras.
5. Llamar al CUS102 – Mantener productos al carro de compras.
6. El sistema finaliza el caso de uso.
Flujo Alternativo
La cantidad solicitada es nula
En el paso 3, si el Cliente selecciona una cantidad del producto igual a cero, el sistema
muestra un mensaje indicando que debe solicitar al menos una unidad del producto.
14
4.6.2 Descripción CUS Mostrar Catálogo
No presenta
15
4.6.3 Descripción CUS Mantener Carro de Compras
Realizar compra
En el paso 3. Si el Cliente selecciona la opción “Comprar”.
Llamar al CUS103 – Guardar pedido.
El caso de uso finaliza.
16
5. VISTA LÓGICA
5.1 Resumen
En esta sección se presenta los niveles de capas de la aplicación, empezando por la capa
específica de la aplicación, la capa general de la aplicación, la capa intermedia y la capa de
software y sus relaciones de dependencia para cada uno de ellos. Luego, se procederá a ver a
nivel lógico los CUS más relevantes.
17
5.2.5. Capa de Datos
La capa de Datos es donde residen los datos y es la encargada de acceder a los
mismos. Está formada por uno gestor de bases de datos que realiza todo el
almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de
información desde la capa de negocio. Esta será implementada usando MySql 5.7.
Figura 7.Observación: Utilizar zoom para observar con detalle o ver el modelado.
18
5.3.1 CUS101 – Mostrar catálogo
Diagrama de Secuencia
19
5.3.2 CUS105 – Agregar producto al carro de compras
Diagrama de Secuencia
7. VISTA FÍSICA
8. VISTA DE DATOS
8.1 Distribución
No hay distribución a nivel de datos, todas las tablas radican en la misma base de datos.
● En el nivel inferior se encuentra el motor de base de datos que para el sistema será
21
MySQL.
● Por encina se encuentra la tecnología de acceso a datos que se implementara haciendo
uso del patrón de diseño DAO.
● Sobre el módulo de acceso a datos se ubica la capa de objetos de negocio
Figura 12. Observación: Utilizar zoom para observar con detalle o ver el modelado.
22
8.4 Diagrama Lógico
Figura 13. Observación: Utilizar zoom para observar con detalle o ver el modelado.
23
8.5 Diagrama Físico
Figura 14. Observación: Utilizar zoom para observar con detalle o ver el modelado.
24
9. CALIDAD
9.1 Usabilidad
Un atributo de calidad muy importante para este Sistema es la facilidad de uso mediante
interfaces amigables para los usuarios, con las cuáles la interacción se dé de forma fluida y
simple.
El Sistema contara mensajes de ayuda en los lugares necesarios donde el usuario presente
una posible inquietud.
9.2 Eficiencia
El Sistema se enfoca en la disminución de tiempo en el proceso de gestión de ventas actual en
la empresa Process Control S.A., por lo cual debe ser capaz de responder adecuadamente a
las necesidades del usuario eficientemente.
Al ser un Sistema Web, debe operar correctamente en las computadoras dónde se acceda a
este desde un navegador. Los datos modificados deben ser actualizados en la base de datos y
estar disponibles con un tiempo no mayor a 3 segundos.
9.3 Seguridad
El Sistema debe garantizar la confidencialidad de todos los datos manejados por éste, ya que
al utilizar información de terceros a la empresa, esta debe ser guardada de manera segura para
no sufrir problemas en el futuro. Debe tener la capacidad de monitorear y controlar a quiénes
utilizan los recursos de éste, con la capacidad de detectar personas no gratas mediante los
diferentes mecanismos de seguridad.
9.4 Disponibilidad
El Sistema debe estar disponible durante todo el horario de trabajo de la empresa Process
Control S.A. y ser compatible con la mayoría (sino todos) de los navegadores web modernos.
El Sistema debe ser tolerante ante las fallas, con el fin de lograr una disponibilidad del 99,99%
de las veces en las que un usuario intente acceder.
25