Arquitectura

UNIVERSIDAD
NACIONAL
MAYOR DE
SAN MARCOS
FACULTAD DE
INGENIERÍA
DE SISTEMAS
E
“SISTEMA DE GESTIÓN DE ALMACÉN PARA LA EMPRESA

HYDRO’SPA SERVICIOS GENERALES SAC”
DOCUMENTO DE LA ARQUITECTURA DEL SOFTWARE
AGUIRRE POZO, MULLER

LLONTOP AVLA, CARLOS
MORAN INFANTES, JESUS
NEYRA ANAYA, PAMELA
ROCA CUSY, BRANCO
YSHARA GARCÍA, MITSUO

HYDRO’SPA SERVICIOS GENERALES SAC
“Sistema de Gestión de Almacén para la

empresa HYDRO’SPA Servicios Generales SAC”
DOCUMENTO DE LA ARQUITECTRA
Versión 1.0
1
Contenido
1. Introducción............................................................................................................ 4
1.1 Propósito......................................................................................................... 4
1.2 Alcance............................................................................................................ 4
1.3 Definiciones, Siglas, y Abreviaturas.................................................................4
1.3.1 Definiciones..............................................................................................5
1.3.2 Acrónimos................................................................................................6
1.4 Referencias.....................................................................................................6
1.5 Visión General del Documento........................................................................6
2. REPRESENTACIÓN ARQUITECTÓNICA.................................................................7
3. METAS Y RESTRICCIONES ARQUITECTÓNICAS.................................................7
3.1 Metas................................................................................................................... 7
3.2 Restricciones........................................................................................................7
4. VISTA DE CASOS DE USO......................................................................................8
4.1 Descripción del Negocio.......................................................................................8
4.2 Identificación de los procesos del negocio...........................................................9
4.3 Procesos de negocio relevantes para el sistema..................................................9
4.4 Descripción de los procesos del negocio relevantes para el sistema...................9
4.4.1 PN1: Gestión de distribución de bienes........................................................9
4.4.2 PN2: Gestión de abastecimiento de bienes...................................................9
4.5 Modelo de Dominio.............................................................................................10
4.6 Identificar Actores...............................................................................................10
4.7 Casos de uso relevantes organizado por paquetes............................................11
4.7.1 Paquete Gestión de distribución de bienes.................................................11
4.8 Descripción de los casos de uso relevantes para la arquitectura.......................11
4.8.1 Registrar Hoja de Pedidos de Bienes..........................................................12
4.8.2 Revisar Hoja de Pedido de Bienes...............................................................14
4.8.3 Modificar Hoja de pedido.............................................................................15
4.8.4 Registrar Cliente..........................................................................................16
4.8.5 Registrar Pago.............................................................................................17
4.9. Interfaz de Usuario............................................................................................18
4.10 Sección de restricciones...................................................................................24
4.10.1 Normativas.................................................................................................24
4.10.2 Estándares.................................................................................................25
4.10.3 Tecnología.................................................................................................25
4.10.4 Soporte......................................................................................................25
2
4.11 Sección de QoS...............................................................................................25

4.11.1 Usabilidad..................................................................................................25
4.11.2 Eficiencia...................................................................................................25
4.11.3 Seguridad..................................................................................................25
4.11.4 Confiabilidad..............................................................................................26
4.11.5 Mantenimiento...........................................................................................26
5. Vista Lógica..........................................................................................................26
5.1. Estilo arquitectónico.......................................................................................26
5.2. Arquitectura lógica de la aplicación................................................................28
5.2.1. Visión general.........................................................................................28
5.3 Identificación de las clases del diseño................................................................30
5.3.1 Diagrama de secuencias del paquete Gestión de Distribución de Bienes....30
Agrupando las clases en subsistemas.....................................................................35
6. Vista de despliegue:.............................................................................................35
7.Vista de implementación.......................................................................................36
3
1. Introducción
La parte más importante en la creación del software es la ARQUITECTURA DEL
SOFTWARE, que es la que provee de una estructura sólida y organizada al sistema.
Sirve como medio de comunicación entre el arquitecto de software y otros miembros
del equipo de proyectos respecto a las decisiones significativas para la arquitectura
que se lleva a cabo en el proyecto.
Por ello, el presente documento hace una descripción y brinda una visión general de la
arquitectura del Sistema de gestión de abastecimiento de bienes, el cual es el software
a desarrollar por el grupo de trabajo.
1.1 Propósito
El documento a desarrollar titulado “Documento de Arquitectura de Software” brinda
una descripción detallada de la arquitectura del Sistema de gestión de abastecimiento
de bienes, para la empresa Hydro’Spa a través de diferentes vistas arquitectónicas, las
cuales ilustran un aspecto en particular del software a desarrollarse. De esta forma, se
pretende brindarle al lector una visión global y comprensible del diseño general del
tema presentado.
1.2 Alcance
El DAS del Sistema de gestión de abastecimiento de bienes profundiza principalmente
en las vistas de caso de uso y lógica, aprovechando también algunos de los elementos
más relevantes de las otras vistas (de procesos, de implementación y de despliegue).
Además, a través de estas vistas se podrá realizar especificaciones sobre la
distribución a realizarse y el uso de capas a utilizar.
1.3 Definiciones, Siglas, y Abreviaturas

Es conveniente brindar algunas definiciones y acrónimos de términos usados en el
presente documento que necesitan de alguna explicación para su correcta
interpretación.
4
1.3.1 Definiciones
Término Definición
Usuario del sistema que puede participar

Actor
de un caso de uso.
Conjunto de elementos estáticos,

propios del diseño intelectual del
sistema, que definen y dan forma tanto
al código fuente, como al
Arquitectura de Software
comportamiento del software en tiempo
de ejecución. Naturalmente este diseño
arquitectónico ha de ajustarse a las
necesidades y requisitos del proyecto.
Bizagi Software para modelar procesos.
Secuencia de acciones que el sistema

Caso de Uso realiza, la cual proporciona un resultado
de valor observable.
Actividad creativa que tiene por fin

Diseño proyectar objetos para después
fabricarlos.
Especifica el comportamiento y limita el

Escenario interés de un área específica del sistema
para uno o varios stakeholders.
Software que actúa de interfaz entre los

dispositivos de hardware y los
Sistema operativo
programas usados por el usuario para
utilizar un computador.
Agrupaciones de casos de uso y actores

Paquetes
por funcionalidad que proveen.
5
1.3.2 Acrónimos
Rational Unified Process (Proceso

RUP
Unificado de Rational)
Unified Modeling Language (Lenguaje

UML
de Modelado Unificado)
1.4 Referencias
Documento Versión Fecha de la versión
Modelo del Negocio del Sistema

2.0 24/09/2017
Modelo de Análisis del Sistema

2.0 01/10/2017
1.5 Visión General del Documento

El documento detalla la arquitectura del software a desarrollar, siguiendo como base
la plantilla elaborada para el artefacto Software Arquitecture Document del proceso de
desarrollo de software elaborado por RUP.
Se presenta de manera clara los casos de uso que tienen impacto en la arquitectura
del sistema, empleando un lenguaje sencillo y directo.
Así también en las siguientes secciones se presentará las descripciones de los
subsistemas con los que cuenta el sistema de distribución de bienes de la empresa
Hydro’Spa.
6
2. REPRESENTACIÓN ARQUITECTÓNICA
Para el diseño del sistema se ha escogido una arquitectura de cuatro capas
-Presentación, Negocio, Persistencia, Soporte-. La elección de esta arquitectura se
basa en que la asignación de responsabilidades a cada capa es independiente de la
otra, por lo tanto nos permite tener en cada capa componentes altamente reutilizables
y la escalabilidad que se necesita al modificar clases sin tener que efectuar mayores
cambios en niveles distintos a éste gracias a la separación de sub tareas en las cuales
cada una tiene una responsabilidad y un nivel de abstracción diferente.
Se desarrollará una sola aplicación, ésta permitirá el acceso de usuarios registrado al
sistema a partir de la interfaz gráfica incluida en la capa de presentación la cual
controlará la interacción con el usuario y que instará a la Capa de Negocio el servicio
requerido, en esta capa se encontrará la lógica de negocio y se dará el tratamiento
necesario a los datos obtenidos de la Capa de Persistencia en la cual se recuperarán
los datos necesarios de la base de datos. Además se contará con una Capa de
Soporte transversal a la aplicación que se encargará de la seguridad de ésta así como
también del manejo de excepciones.
La arquitectura se basará en el modelo ‘4+1’, que contendrá vista lógica, vista de
procesos, vista de despliegue y vista física, y la última vista con la función de
relacionar las 4 vistas citadas.
3. METAS Y RESTRICCIONES ARQUITECTÓNICAS

La meta principal de la arquitectura del sistema es mostrar los aspectos principales
que influirán en la etapa de desarrollo.
Se tomarán en cuenta las siguientes metas y restricciones para el diseño de la
arquitectura del sistema:
3.1 Metas
Para poder acceder a las funciones del sistema se necesitará un código de usuario
válido así como una contraseña. Dependiendo de los roles de cada usuario se
habilitara/deshabilitarán funcionalidades y opciones de manejo del sistema para evitar
la toma de decisiones por personal no autorizado y proteger información confidencial.
3.2 Restricciones
• El sistema usará como gestor de base de datos Oracle 11g, en el cual será
necesario la creación de una copia de las tablas para no poner en riesgo el
funcionamiento y/o la integridad de los datos almacenados.
• Las características técnicas de las computadoras que serán utilizadas no deberán
presentar potencias menores a las brindadas por un procesador Core i5, con al menos
4 GB de RAM y 500 MB de espacio libre en el disco. El Sistema operativo será
Windows XP/7/8.1/10.
7
4. VISTA DE CASOS DE USO
Descripción del
negocio
Actores Modelo del Casos de Uso

dominio
4.1 Descripción del Negocio

HYDRO’SPA Servicios Generales SAC es una empresa dedicada a brindar servicios de
construcción, remodelamiento, equipamiento y mantenimiento de Piscinas, Piletas, entre
otros.
El almacén está ubicado en Huaycán en el distrito de Ate, cerca al domicilio del dueño.
Posee las dimensiones siguientes:
 ALTO: 2.80 m
 ANCHO 7.10 m
 LARGO 7.80 m
Se almacenan bienes dentro de las siguientes categorías, según nuestra evaluación:

 Motores eléctricos
 Válvulas
 Tuberías
 Pegamentos
 Materiales de Construcción
 Accesorios de Iluminación
 Herramientas
 Abrasivos
 Accesorios eléctricos
 Productos de Aseo
 Elementos de Fijación
Actualmente el almacén se encuentra ocupado al 70%, sin embargo, los bienes que lo llenan
no están ubicados de la manera adecuada.
No hay una división por sectores que facilite la búsqueda de bienes, por lo que existe una gran
pérdida de tiempo y materiales al realizar esta tarea. También se han reportado casos en los
que se encuentran los bienes después de que haya pasado el plazo de la solicitud de pedidos,
en el peor de los casos este se encuentra malogrado o vencido por falta de control.
8
4.2 Identificación de los procesos del negocio

Se identifican 2 procesos del negocio:
 PN1:Gestión de distribución de bienes
 PN2:Gestión de abastecimiento de bienes
4.3 Procesos de negocio relevantes para el sistema
El proceso relevante del sistema es el proceso de “Gestión de distribución de bienes”
ya que en él se centra el negocio; PN1 se basa en la venta de los productos que se
encuentran en el almacén, consta de un registro previo de la persona a quien se le
entregarán los productos, el seguimiento del pedido, involucra desde la solicitud hasta
la entrega.
4.4 Descripción de los procesos del negocio relevantes para el sistema
4.4.1 PN1: Gestión de distribución de bienes
4.4.2 PN2: Gestión de abastecimiento de bienes
9
4.5 Modelo de Dominio
4.6 Identificar Actores

Los trabajadores del negocio que se convierten en actores del sistema son los
siguientes:
● Gerente de Administración y Ventas

Es quien da la orden de retirar los bienes del almacén y revisa la hoja de
solicitud de bienes para luego realizar el pedido formal de los bienes al
proveedor luego de haber realizado cotizaciones.
● Cliente
Verifica que los bienes retirados de almacén estén en buen estado para la
obra.
● Encargado de almacén
Se encarga de recibir la orden de retiro de bienes y de proporcionar lo
solicitado para alguna obra. Recepciona los bienes que ingresan a almacén y
actualiza el stock de dichos materiales. Además, cuando se hace algún pedido
de almacén y no hay suficientes materiales en stock, genera una hoja de
materiales faltantes que luego serán solicitados.
10
4.7 Casos de uso relevantes organizado por paquetes

4.7.1 Paquete Gestión de distribución de bienes
4.8 Descripción de los casos de uso relevantes para la arquitectura
11
4.8.1 Registrar Hoja de Pedidos de Bienes

ID: CUS-01
Caso de Uso: Registrar de Hoja de Pedido de Bienes
Actor: Gerente de Administración y Ventas
Descripción: El jefe de producción podrá añadir un nuevo diseño en el catálogo
de diseño de productos, así como modificar el diseño o eliminarlo
del catálogo.
Precondición: El Gerente de Administración y ventas debe haber ingresado
correctamente al sistema
Flujo Principal: Añadir Hoja de Pedido de Bienes
1. El CUS empieza cuando el Gerente de Administración hace click en
“Generar Hoja de Pedidos”
2. El sistema mostrará una interfaz que permita identificar al cliente.
3. El gerente identificará al cliente mediante su DNI.
4. El sistema muestra un menú con las siguientes opciones :
a. Registrar hoja de pedidos
b. Modificar hoja de pedidos
c. Eliminar hoja de pedidos
5. El gerente hace click en “Registrar hoja de pedidos”.
6. El sistema muestra la interfaz “Hoja de pedidos”.
7. El Gerente de Administración y Ventas llena los siguientes campos :
● Código de cliente
● Fecha y Hora de Llegada
● Obra
● Código de Material
● Nombre de Material
● Cantidad de Material
● Estado
8. El Gerente de Administración y Ventas pulsa en el botón “Enviar”.
9. El sistema verificará los datos registrados
10. El sistema enviará la hoja de pedidos y mostrará el mensaje “Hoja de
pedidos correctamente enviada”.
11. El CUS finaliza.
Flujo alternativo
12
-El caso de uso puede ser cancelado en el caso que exista algún error en la
hoja de pedidos.
-El formato en el ingreso de datos o cambios es incorrecto; entonces

aparecerá el siguiente mensaje “Datos incorrectos”.
-Búsqueda de un cliente que no existe; si se quiere identificar un cliente que

no existe el sistema deberá preguntar si desea registrar al cliente y mostrar la
respectiva interfaz.
-La hoja de pedidos puede ser eliminada en cualquier momento, para esto se
mostrará un mensaje de confirmación para realizar la acción
Post- Se ha enviado la hoja de pedidos al Encargado del Almacén

condición :
4.8.2 Revisar Hoja de Pedido de Bienes
13
ID: CUS-02
Caso de Uso: Revisar Hoja de Pedido de Bienes
Actor: Encargado de Almacén
Descripción: El Encargado de Almacén podrá revisar las Hojas de Pedidos
registradas con anterioridad en el sistema.
Precondición: El usuario ha sido admitido al sistema con el rol de Encargado de
Almacén.
Flujo Principal: Revisar
1. El CUS empieza cuando el Encargado de Almacén haga clic en “Listar Hoja
de Pedidos”.
2. El sistema muestra una ventana con las hojas de pedido del día.
3. El Encargado de Almacén selecciona cualquiera de las hojas de la lista.
4. Cuando el Encargado de Almacén selecciona la hoja, hace clic en “Ver
Detalle”.
5. El sistema muestra los detalles de la hoja de pedidos seleccionada.
 Código de la hoja de bienes.
 Fecha.
 DNI o RUC del cliente.
 Nombre del cliente.
6. El Encargado de Almacén evalúa los bienes solicitados y pulsa en “Evaluar
Disponibilidad”.
7. El sistema muestra un mensaje: “El almacén cuenta con lo solicitado”.
8. El sistema actualizará el stock de los bienes de manera automática.
9. El Encargado de Almacén pulsa el botón “Enviar hoja de pedidos aprobada” y
la hoja será guardada.
Post- Se ha enviado la hoja de pedido aprobada.

condición :
Flujo Alterno 1: Falta de disponibilidad
En el paso número 6:
1. Si al pulsar Evaluar Disponibilidad, todos los bienes no están disponibles.
2. El Sistema muestra un mensaje: “no se cuenta con lo solicitado”
3. El Sistema muestra el botón Generar hoja de bienes faltantes.
4. El encargado de almacén pulsa el botón “Generar hoja de bienes faltantes”
5. El encargado de almacén pulsa el botón “Enviar hoja de bienes faltantes”
6. Finaliza el Caso de Uso del Sistema.
4.8.3 Modificar Hoja de pedido

ID: CUS-03
Caso de Uso: Modificar Hoja de Pedido
14

Descripción: El gerente de Administración y Ventas podrá modificar las Hojas
de Pedidos registradas con anterioridad en el sistema.
Precondición: El usuario ha sido admitido al sistema con el rol de Gerente de
Administración y Ventas.
Flujo Principal: Modificar
11. El CUS empieza cuando el Gerente de Administración haga clic en “Hoja de
Pedidos”, el sistema muestra la interfaz Menú Principal y el Jefe de
Producción pulsa la opción “Mantener información del catálogo de diseño de
productos”.
12. El sistema muestra un menú con las siguientes opciones :
 Registrar hoja de pedidos
 Modificar hoja de pedidos
 Eliminar hoja de pedidos
13. El gerente hace clic en “Modificar hoja de pedidos”.
14. El sistema muestra la interfaz “Modificar hoja de pedidos”.
15. El sistema mostrará una tabla de todas las hojas de pedidos con los siguiente
campos:
 Código de la hoja de bienes.
 Fecha.
 DNI o RUC del cliente.
 Nombre del cliente.
16. El gerente dará clic a una de las filas.
17. El sistema mostrará una interfaz parecida a la de “Registrar hoja de pedidos”
pero se diferenciará en que los datos ya estarán llenados.
18. El gerente modificará los campos que considere necesarios.
19. El gerente de Administración y Ventas pulsa en el botón “Guardar cambios”.
20. El sistema guardará los cambios en la hoja de pedido y mostrará el mensaje
“Cambios correctamente realizados”.
Post- Se ha cambiado la hoja de pedidos al Encargado del Almacén.
condición :
Flujo Alterno 1: Datos Incorrectos
El formato en el cambio de datos es incorrecto; entonces aparecerá el siguiente
mensaje “Datos incorrectos”.
4.8.4 Registrar Cliente

ID: CUS-04
Caso de Uso: Registrar Cliente
15

Descripción: Registrar al cliente lo que permitirá establecer relación con las
hojas de pedidos, y mantenerlos en la lista de clientes de la
empresa.
Precondición: El usuario ha sido reconocido por el sistema.
Flujo Principal:
22. El CUS empieza cuando el Gerente de Administración hace clic en “Registrar
Cliente”.
23. El sistema mostrará un campo de texto para ingresar el DNI del cliente.
24. El Usuario dará click en evaluar para verificar que el DNI no pertenece a un
cliente ya registrado.
25. El sistema mostrará una ventana emergente con el mensaje de “DNI Válido” y
los botones de “Cancelar” y “Registrar”.
26. El usuario dará click en “Registrar”.
27. El sistema mostrará un formulario con los siguiente campos a rellenar:
 Nombre.
 Apellido.
 Teléfono.
 Dirección del cliente.
 Correo electrónico.
 RUC de la Empresa.
 Nombre de la Empresa.
 Dirección de la Empresa.
 Obra.
28. El gerente dará click en “Siguiente”.
29. El sistema mostrará una interfaz con los datos del cliente y los botones
“Cancelar” y “Finalizar Registro”.
30. El usuario en conformidad a lo mostrado dará click en “Finalizar Registro”.
31. El sistema mostrará un mensaje de confirmación: “Cliente Registrado”.
Post- Se registró en la base de datos el cliente, la empresa y su relación.
condición :
Flujo Alterno 2: Cliente Registrado.
Si el cliente registrado al evaluar el dni el sistema mostrará el mensaje:”Cliente

registrado anteriormente” y deshabilitará el botón de “Registrar”.
Flujo Alterno 1: Datos inválidos.
El formato en el cambio de datos es incorrecto; entonces aparecerá el siguiente
mensaje “Datos incorrectos”.
4.8.5 Registrar Pago

ID: CUS-05
16
Caso de Uso: Registrar Pago

Descripción: Registrar el pago de un pedido por lo cual se generará la factura
correspondiente y, a la vez, se emitirá la orden de entrega del
pedido.
Precondición: El usuario ha sido reconocido por el sistema.
El pedido debe haber sido registrado.
Flujo Principal:
33. El CUS empieza cuando el Gerente de Administración hace clic en “Registrar
Pago”.
34. El sistema mostrará una lista de todos los pedidos registrados y que no han
sido pagados, en la lista se muestra el código y el nombre del cliente a la cual
pertenece cada pedido. Habrá un campo para buscar un pedido por código.
35. El Usuario seleccionará el pedido y hará doble click sobre éste.
36. El sistema mostrará la información del pedido:
 Dni de cliente
 Código de pedido
 Obra
 Empresa
 Lista de Bienes Requeridos (incluido código y cantidad)
 Estado
 Fecha del pedido
 Total a Pagar
Y los botones “Cancelar” y “Registrar Pago”.
37. El usuario dará click en “Registrar Pago”.
38. El sistema mostrará una ventana de confirmación con el monto a pagar.
39. El gerente dará click en “Confirmar”.
40. El sistema mostrará un mensaje de operación exitosa, la factura será
impresa, el registro del pagó se guardará en la base de datos y la orden de
entrega del pedido será enviada.
Post- - Se registró en la base de datos el pago.
condición : - Se imprimió el comprobante de pago por el pedido.
- Se emitió la orden de entrega de pedido.
- El estado del pedido pasará de “Pendiente a pagar” a
“Monto total cancelado".
Flujo Alterno 1: Cancelar operación.
El registro del pago puede ser cancelado en cualquier momento a lo largo del caso
de uso.
17
4.9. Interfaz de Usuario

Esta sección presenta la captura de pantalla para algunos de los casos de uso
presentados en la sección anterior:
CUS-01: Registrar de Hoja de Pedido de Bienes
18
CUS-02: Revisar Hoja de Pedidos
19
CUS-03: Modificar Hoja de Pedidos
20
CUS-04: Registrar Cliente
21
CUS-05: Registrar Pago
22
4.10 Sección de restricciones

4.10.1 Normativas
 Licenciamiento
No existe regulación de licenciamiento para el “Sistema de Gestión de Almacén
para la empresa HYDRO’SPA Servicios Generales SAC” en el país. En cuanto
al software a utilizar, no es necesario conseguir licencia para el uso del IDE
NetBeans, ya que es una herramienta libre y gratuita sin restricciones de uso.
Para el uso del SGBD Oracle 11g se adquirirá una licencia de funcionamiento,
la cual cuenta con el precio que se especifica en el siguiente enlace:
http://www.oracleparamiempresa.com/promociones-precios.
 Formas de pago
Queda documentado la entrega al cliente de un comprobante de pago (boleta o
factura)
 Registro impositivo
La empresa HYDRO’SPA emite facturas a sus clientes cada vez que realizan
una transacción comercial. Por ello, la empresa está obligada a declarar sus
impuestos (IGV) mensualmente ante la SUNAT, que es el órgano constitucional
autónomo que se encarga de recaudar los impuestos a nivel nacional.
23
4.10.2 Estándares
 UML
Todos los artefactos utilizados para la comunicación, tanto entre los miembros
del equipo de desarrollo y los usuarios, y la respectiva documentación
requerida para el desarrollo del “Sistema de gestión de pedidos de ebanistería”
están basados en el Lenguaje de Modelamiento Unificado (UML).
4.10.3 Tecnología
 El “Sistema de gestión de pedidos de ebanistería” será desarrollado en el
lenguaje de programación orientada a objetos Java, el cual se complementará
con el entorno de desarrollo (IDE) “NetBeans 8.1”.
 El motor de base de datos a utilizar será el Oracle 11g y el entorno de
desarrollo será el SQLDeveloper.
 Las herramientas de modelado para el desarrollo del sistema son el “IBM
Rational Rose Enterprise Edition” y el “Bizagi Process Modeler” para el
diagrama de actividades de los procesos.
4.10.4 Soporte
 El “Sistema de Gestión de Almacén para la empresa HYDRO’SPA Servicios
Generales SAC” tendrá un mantenimiento progresivo en el cual se podrán
hacer modificaciones con la finalidad de incorporar nuevas funcionalidades y/o
eliminaciones las cuales estarán orientadas a mejorar las interacciones entre
usuario-sistema y cubrir los nuevos servicios brindados por la empresa
HYDRO’SPA.
4.11 Sección de QoS
4.11.1 Usabilidad
Las interfaces del “Sistema de Gestión de Almacén para la empresa HYDRO’SPA
Servicios Generales SAC” han sido desarrolladas para ser bastante amigables para
los usuarios ya que incluyen gráficos para su mayor entendimiento en cada una de
estas.
Debido a que el “Sistema de Gestión de Almacén para la empresa HYDRO’SPA
Servicios Generales SAC” está orientado solo para los miembros de la empresa
HYDRO’SPA, su uso está destinado únicamente para estos.
4.11.2 Eficiencia
El sistema tendrá una respuesta inmediata (a lo más cinco segundo) ya que no abarca
demasiadas funcionalidades, tampoco porque no realiza servicios en línea, así que no
depende del internet. Su rendimiento esta solamente limitado a la del ordenador en el
que esté instalado el “Sistema de Gestión de Almacén para la empresa HYDRO’SPA
Servicios Generales SAC”.
Otro motivo por el cual la repuesta será inmediata es que solo se limita a la inserción,
modificación y/o eliminación de datos, además el número de usuarios para el sistema
es de solo 2 (Gerente de Administración y Ventas y Encargado de Almacén).
4.11.3 Seguridad
El sistema permitirá el uso de sus distintas funcionalidades dependiendo del perfil con
24
el que el usuario accede al sistema, validando su ingreso a través de su usuario y

contraseña.
Los datos no pueden ser visualizados o manipulados desde el exterior ya que se usa
un motor de base de datos Oracle 11g al cual solo se puede acceder si es que loguea
el usuario registrado en el sistema.
4.11.4 Confiabilidad
El sistema siempre validara los datos ingresados y mostrara mensajes indicando la
posible solución en caso de presentar errores. En varios formularios se han
restringidos la digitación de ciertos caracteres para asegurar la validación de los datos
a la hora de ser guardados en el sistema.
En caso de que sucedan errores en el sistema, se mostraran mensajes indicando los
detalles de estos errores para que el usuario tome las medidas adecuadas ante estos.
4.11.5 Mantenimiento
El mantenimiento estará regido de acuerdo a las necesidades de la empresa y los
posibles fallos que surjan y que no se hayan identificado. Debido a que el sistema no
es de gran envergadura y solo está orientado a escritorio su mantenimiento futuro no
tendrá muchas dificultades incluso si el personal de desarrollo fuese diferente al inicial,
ya que además el código es bastante flexible.
5. Vista Lógica
5.1. Estilo arquitectónico
Se ha escogido una arquitectura de tres capas (presentación, negocio o lógica de la
aplicación y persistencia o datos). La utilización de esta arquitectura se debe a que las
distintas capas deben ser independientes unos de otros, de manera que se pueda
intervenir en el comportamiento de las clases en el nivel de aplicación sin afectar a las
demás capas.
25
Esquema básico de la arquitectura de tres capas.

 Capa de presentación
La capa de presentación es un conjunto de componentes software que permiten la
interacción con los usuarios a través de una representación visual de la aplicación,
proporcionando a los usuarios una forma de acceder a los datos y servicios que ofrece
el negocio.
 Capa de Negocio o Lógica de la aplicación
La capa de negocio es el conjunto de componentes software que implementan
completamente el comportamiento de las clases del dominio. En este nivel se
implementa la funcionalidad de la aplicación.
Esta capa sirve de enlace entre los niveles de presentación y de persistencia, ya que
la capa de presentación no accede de manera directa a la base de datos, sino que se
comunica con la capa de aplicación para demandarle el servicio deseado y
posteriormente la capa de aplicación se comunica con la capa de persistencia para
recuperar los datos necesarios.
 Capa de Persistencia o Datos
La capa de persistencia es el conjunto de componentes software que proporcionan
una serie de servicios que permiten a los objetos del dominio interactuar con su
repositorio permanente asociado.
La capa de persistencia se corresponde con la base de datos de la aplicación y las
distintas tablas que la conforman.
26
5.2. Arquitectura lógica de la aplicación

5.2.1. Visión general
5.2.1.1. Capa Especifica de la Aplicación

Es la traza de los paquetes encontrado en el modelo de análisis.
5.2.1.2. Capa General de la Aplicación

Es la relación que muestran los subsistemas de la capa específica de la aplicación
5.2.1.3. Capa Intermedia de la Aplicación y Software de la Aplicación

Constituye los cimientos del sistema ya que toda la funcionalidad descansa sobre
estos (software, SO, gestión de BD, etc.)
27
5.2.2. Identificando las interfaces entre capas
28
5.3 Identificación de las clases del diseño

5.3.1 Diagrama de secuencias del paquete Gestión de Distribución de Bienes
5.3.1.1 Registrar Hoja de Pedido de Bienes
29
5.3.1.2 Revisar Hoja de Pedidos
30
5.3.1.3 Modificar Hoja de Pedido
31
5.3.1.4 Registrar Cliente
32
5.3.1.5 Registrar Pago
5.3 Diagrama de subsistemas
33
Agrupando las clases en subsistemas
6. Vista de despliegue:
Ordenadores
Características:
Intel Core i5
Memoria Ram 4GB
Tarjeta gráfica de 2GB
Disco duro 500gb
Sistema operativo: Windows XP/7/8/10
Tipos
Nodos del encargado de Almacén:
Computadora que será utilizada por cada uno de los usuarios de la empresa, en este
caso, el encargado de Almacén, para acceder al sistema. Está conectada
34
directamente al servidor principal vía LAN.

Nodos del gerente de Administración y Ventas:
Computadora que será utilizada por cada uno de los usuarios de la empresa, en este
caso, el gerente de Administración y Ventas, para acceder al sistema. Está conectada
directamente al servidor principal vía LAN.
Switch
Características
Modelo: D-LINK no administrable de 8 puertos Fast Ethernet DES-1008ª
8 puertos 10, 100 Base-TX.
Soporte de Auto MDI MDI- en todos los puertos.
Control de Flujo 802.3x en cada puerto.
Plug & Play, no requiere configuración.
Servidor de base de datos
Características
Procesador: Intel Xeon E7 2.4 GHZ/acceso de memoria de hasta 1066Mhz
Memoria RAM 1TB DDR3
Disco duro SAS 9.6TB por chasis
Impresora de facturas
Características
Modelo: HP MULTIFUNCIONAL GT5820
Pantalla LCD con íconos y contador de CO
Bandeja de entrada de hasta 60 hojas
Red Inalámbrica
Bandeja de salida incorporada de hasta 25 H
Imprime 5000 pág. en negro
Imprime 8000 pág. a color
Imprime, copia y scanea
7.Vista de implementación
Descripción:
En esta vista de implementación se presenta el sistema en términos de componentes,
es decir ficheros de código fuente. Nos enfocaremos en la organización de los
módulos de software.
Se ha decidido hace el siguiente módulo Gestión de abastecimiento de bienes.
En esta vista también se explicara cual es la relación de entre los componentes y la
clase de diseño de cada módulo.
Diagrama de componentes:
35
Actividad implementar un subsistema
Subsistema de Implementación: Gestión de abastecimiento de bienes

Componente cliente
Interfaz registrar cliente
Cliente
Componente gestor de cliente
Gestor añadir cliente
Componente hoja de pedido de bienes
Interfaz registrar hoja de pedido de bienes
Interfaz modificar hoja de pedido de bienes
Interfaz revisar hoja de pedido de bienes
Hoja de pedido de bienes
Componente gestor de hoja de pedido de bienes
Gestor registrar hoja de pedido de bienes
Gestor modificar hoja de pedido de bienes
Componente hoja de bienes faltantes
Interfaz generar hoja de bienes faltantes
Bien faltante
Hoja de bienes faltantes
Componente gestor de hoja de bienes faltantes
Gestor añadir hoja de bienes faltantes
Componente Factura
Interfaz generar factura
Interfaz modificar factura
36
Interfaz eliminar factura

Factura
Componente gestor Factura
Gestor registrar factura
Gestor modificar factura
Gestor eliminar factura
8. MODELO DE DATOS
37
38

Arquitectura

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Arquitectura

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD

“SISTEMA DE GESTIÓN DE ALMACÉN PARA LA EMPRESA

AGUIRRE POZO, MULLER

“Sistema de Gestión de Almacén para la

4.11 Sección de QoS...............................................................................................25

1.3 Definiciones, Siglas, y Abreviaturas

Usuario del sistema que puede participar

Conjunto de elementos estáticos,

Bizagi Software para modelar procesos.

Secuencia de acciones que el sistema

Actividad creativa que tiene por fin

Especifica el comportamiento y limita el

Software que actúa de interfaz entre los

Agrupaciones de casos de uso y actores

Rational Unified Process (Proceso

Unified Modeling Language (Lenguaje

Documento Versión Fecha de la versión

Modelo del Negocio del Sistema

Modelo de Análisis del Sistema

1.5 Visión General del Documento

3. METAS Y RESTRICCIONES ARQUITECTÓNICAS

4. VISTA DE CASOS DE USO

Actores Modelo del Casos de Uso

4.1 Descripción del Negocio

Se almacenan bienes dentro de las siguientes categorías, según nuestra evaluación:

4.2 Identificación de los procesos del negocio

4.4.2 PN2: Gestión de abastecimiento de bienes

4.5 Modelo de Dominio

4.6 Identificar Actores

● Gerente de Administración y Ventas

4.7 Casos de uso relevantes organizado por paquetes

4.8 Descripción de los casos de uso relevantes para la arquitectura

4.8.1 Registrar Hoja de Pedidos de Bienes

-El formato en el ingreso de datos o cambios es incorrecto; entonces

-Búsqueda de un cliente que no existe; si se quiere identificar un cliente que

Post- Se ha enviado la hoja de pedidos al Encargado del Almacén

4.8.2 Revisar Hoja de Pedido de Bienes

Post- Se ha enviado la hoja de pedido aprobada.

4.8.3 Modificar Hoja de pedido

Actor: Gerente de Administración y Ventas

4.8.4 Registrar Cliente

Actor: Gerente de Administración y Ventas

Si el cliente registrado al evaluar el dni el sistema mostrará el mensaje:”Cliente

4.8.5 Registrar Pago

Caso de Uso: Registrar Pago

4.9. Interfaz de Usuario

CUS-02: Revisar Hoja de Pedidos

CUS-03: Modificar Hoja de Pedidos

CUS-04: Registrar Cliente

CUS-05: Registrar Pago

4.10 Sección de restricciones

el que el usuario accede al sistema, validando su ingreso a través de su usuario y

Esquema básico de la arquitectura de tres capas.

5.2. Arquitectura lógica de la aplicación

5.2.1.1. Capa Especifica de la Aplicación

5.2.1.2. Capa General de la Aplicación

5.2.1.3. Capa Intermedia de la Aplicación y Software de la Aplicación

5.2.2. Identificando las interfaces entre capas

5.3 Identificación de las clases del diseño

5.3.1.1 Registrar Hoja de Pedido de Bienes

5.3.1.2 Revisar Hoja de Pedidos

5.3.1.3 Modificar Hoja de Pedido

5.3.1.4 Registrar Cliente