SISTEMA INTEGRAL DE GESTION DE VENTAS

Documento de Arquitectura de Software

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.

1.3 Definiciones, acrónimos y abreviaturas

● 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

El estilo arquitectónico escogido para el Sistema fue el Cliente/Servidor de 3 capas ya que se

adapta a las necesidades del Sistema. El Sistema requiere una máquina servidor que
responderá a las peticiones de varios clientes. El Sistema estará estructurado en las capas del
estilo de arquitectura: Datos, Negocio y Presentación.
El proyecto realizado otorgará soporte a distintos tipos de cliente: Jefe de área de Ventas,
Cliente externo y mensajero de ventas, dónde cada uno implementa alguno de los procesos de
negocio mencionados, por lo que es necesario una diferenciación entre el acceso a datos y la
lógica del negocio, así mismo, la vista que se tendrá del Sistema no será la misma para cada
uno de estos, por lo cual el uso de 3 capas se escogió para el Sistema.

3. Metas de arquitectura y limitaciones

3.1 Metas

● El Sistema deberá permitir a los usuarios acceder sin problemas de confiabilidad o

seguridad, asegurando un rendimiento máximo.
● Los datos almacenados deberán ser íntegros a pesar del paso del tiempo y deberán
estar disponibles en base a la accesibilidad que posea cada usuario del Sistema.
● El Sistema debe ser la base de una mejor gestión de los recursos de la empresa
Process Control, disminuyendo costos administrativos asociados a tareas repetitivas.

3.2 Limitaciones especiales

No existen limitaciones especiales para el Sistema desarrollado.

6
4. VISTA DE CASOS DE USO

4.1 Descripción del Negocio

La empresa Process Control S.A. se encarga de la compra y venta de productos industriales.
Para el proceso de venta, los potenciales clientes se acercan a la empresa para solicitar una
cotización de los productos que desea; se evalúa si es factible la realización de los productos y
se informa al área de ventas para empaquetar los productos que se van a entregar al cliente.
Para el proceso de compra, cuando se observa la escasez de un producto o cuando se solicita
un producto por parte del cliente que no tiene stock, se comunica con el proveedor para
coordinar la petición de los productos.

4.2 Procesos del Negocio

➢ Entregar Pedido

Figura 1. Modelado del negocio – Proceso Entregar pedido.

7
➢ Evaluar pedido

Figura 2. Modelado del negocio – Proceso Evaluar pedido.

8
 ➢ Importar producto

Figura 3. Modelado del negocio – Proceso Importar producto.

4.3 Modelo de dominio

9
 Figura 4. Modelo del dominio.

4.4 Actores

Figura 5. Actores del Sistema.

10
Identificamos a cuatro Actores del Sistema:

● Cliente: Actor encargado de registrarse y de realizar los pedidos.

● Sistema: Actor encargado de enviar notificaciones y generar identificadores.
● Mensajero: Actor encargado de cambiar el estado de los pedidos.
● Jefe de Área de Ventas: Actor encargado de administrar la disponibilidad de productos

4.5 Casos de Uso del Sistema

4.5.1 Diagrama de Casos de Uso del Sistema

Figura 6. Diagrama general de casos de uso.

11
4.5.2 Paquetes de CUS
4.5.2.1. P001 Gestión de Información de clientes

4.5.2.2. P002 Gestión de Adquisición de Pedido

4.5.2.3. P003 Gestión de la Información de venta

12
4.5.2.4. P004 Gestión de los Productos

4.5.2.5. P005 Gestión del comportamiento del pedido

4.5.2.6. P006 Gestión del manejo del producto

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

4.6.1 Descripción CUS – Agregar Producto al Carro de Compras

NOMBRE Agregar Producto al Carro de Compras

Actores Cliente
Caso de uso que permite al Cliente agregar un producto al carro de
Descripción 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

NOMBRE Mostrar Catálogo

Actores Cliente
Caso de uso permite al Cliente observar el catalogo de productos de
Descripción
la empresa.
Flujo Principal
1. El caso de uso inicia cuando el Cliente selecciona la opción “Catálogo de Productos”.
2. El sistema muestra una pantalla con los nombres de los productos que ofrece la
empresa.
3. El cliente selecciona el producto para conocer sus datos.
4. El sistema muestra una ventana con la información del producto (código, nombre,
precio).
5. El sistema finaliza el caso de uso.
Flujo Alternativo

No presenta

15
4.6.3 Descripción CUS Mantener Carro de Compras

NOMBRE Mantener Carro de Compras

Actores Cliente
Caso de uso que permite al Cliente mantener la información de su carro de
Descripción
compras (Modificar y eliminar productos).
Flujo Principal
1. El caso de uso comienza cuando el Cliente selecciona la opción “Mostrar carro de
compras”.
2. El sistema obtiene los datos de los productos del carro de compras.
3. El sistema muestra una pantalla con los productos registrados en el carro de compras y
los datos de los productos (Nombre, descripción, cantidad, precio, subtotal) y total del
precio a pagar.
4. El caso de uso finaliza.
Flujo Alternativo

Continuar con la compra

En el paso 3. Si el Cliente selecciona la opción “Continuar con la compra”.
Llamar al CUS101 – Mostrar catálogo.
El caso de uso finaliza.

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.

5.2 Diseño de Paquetes de gran importancia en la Arquitectura

5.2.1. Capa WEB
Para nuestro sistema implementaremos una parte web. Para acceder a esta capa en la
parte web será a través de un browser (páginas HTML) sobre una dirección URL
asignada al Sistema.

5.2.2. Capa Controlador

La capa controlador ofrece una interfaz de aplicaciones para las distintas solicitudes que
la capa web le envíe. Esta será implementada utilizando Spring MVC y Thymeleaf como
motor de plantillas HTML.

5.2.3. Capa de Servicios

La capa de servicio contiene las clases que implementan la lógica de negocio de la
aplicación. Básicamente consta de las Clases de Negocio donde se encuentran las
clases que rigen los procesos, implementando las reglas del negocio. Esta capa
interactúa con la capa de repositorio de datos.

5.2.4. Capa de Repositorio

La capa de persistencia almacena las clases que representan el modelo relacional en
una base de datos en forma de orientación a objetos. Estas clases interactúan mediante
drivers con la base de datos MySql.

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.

5.3 Realizaciones de casos de uso

Diagrama de Clases

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

Figura 8. Diagrama de secuencia CUS101-Mostrar Catálogo.

19
5.3.2 CUS105 – Agregar producto al carro de compras
Diagrama de Secuencia

Figura 9.Diagrama de secuencia CUS105-Agregar productos al carro de compras.

5.3.3 CUS102 – Mantener carro de compras

Diagrama de Secuencia

Figura 10.Diagrama de secuencia CUS102-Mantener carro de compras

20
6. VISTA DE PROCESOS
El Sistema a desarrollar no presenta alta concurrencia, por lo que no se ha aplicado la Vista de
procesos.

7. VISTA FÍSICA

7.1 Diagrama de despliegue

Figura 11. Diagrama de despliegue

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.

8.2 Servicios de Persistencia

● 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

8.3 Diagrama Entidad – Relación

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