Documento Arquitectura 1

Waldo S
Sistema de Gestión de Documentos
Documento de la Arquitectura del Software
Versión 7.0
Sistema de Gestión der Pedidos de Ebanistería Versión: 7.0
Documento de la Arquitectura de Software Fecha: 20/02/2014
Historia de Revisión
Fecha Versión Descripción Autor
Vista de casos de uso del

21/01/2014 1.0 Equipo de trabajo
negocio
Vista de casos de uso del

23/01/2014 2.0 Equipo de trabajo
negocio
30/01/2014 3.0 Vista lógica Equipo de trabajo
1/02/2014 4.0 Vista lógica Equipo de trabajo
11/02/2012 5.0 Vista despliegue Equipo de trabajo
17/02/2014 6.0 Vista de implementación Equipo de trabajo
20/02/2014 7.0 Vista de implementación Equipo de trabajo
Confidencial Obregón SRL, 2014 Página 2 de 42

Tabla de contenido
1. Introducción 6
1.1 Propósito Error! Bookmark not defined.
1.2 Alcance 6
1.3 Definiciones, Siglas, y Abreviaturas 6
1.3.1 Definiciones 7
1.3.2 Acrónimos 8
1.4 Referencias 8
1.5 Vista Global 8
2. Representación Arquitectónica 9
3. Metas y Restricciones Arquitectónicas 9

3.1 Metas 9
3.2 Restricciones 9
4. Vista de Casos de Uso 10

4.1 Descripción del Negocio Error! Bookmark not defined.
4.2 Identificación de los procesos del negocio 10
4.3 Procesos de negocio relevantes para el sistema 11
4.4 Descripción de los procesos del negocio relevantes para el sistema 12
4.4.1 PN1: Proceso de Atención al cliente 12
4.4.2 PN2: Proceso de Gestión de tareas a operariosError! Bookmark not
defined.
4.5 Modelo de Dominio 13
4.6 Identificar a los actores 13
4.7 Casos de uso relevantes organizado por paquetes 14
4.7.1 Paquete Negocio Principal 14
4.8 Descripción de los casos de uso relevantes para la arquitectura 15
4.8.1 Descripción de los casos de uso relevantes para el proceso Atención al cliente
15
3. Cancelar registro de cotización Error! Bookmark not defined.
4.8.2 Descripción de los casos de uso relevantes para el proceso Gestión de Tareas
Error! Bookmark not defined.
4.8.3 Descripción de los casos de uso relevantes para el paquete Seguridad Error!
Bookmark not defined.
4.9 Interfaz de Usuario 20
4.10 Sección de restricciones 24

4.10.1 Normativas 24
4.10.2 Estándares 24
4.10.3 Tecnología 24
4.10.4 Soporte 25
4.11 Sección de QoS 25
4.11.1 Usabilidad 25
4.11.2 Eficiencia 25
4.11.3 Seguridad Error! Bookmark not defined.
4.11.4 Confiabilidad 26
4.11.5 Mantenimiento 26
4.11.6 Estándares 26
5. Vista Lógica 27
5.1 Estilo arquitectónico 27
5.2 Arquitectura lógica de la aplicación 28
5.2.1 Visión general 28
5.2.2 Identificando las Interfaces entre capas 29
5.3 Identificación de las clases del diseño 29
5.3.1 Diagramas de secuencias del paquete Atención al cliente 29
5.3.2 Diagrama de secuencias del paquete Gestión de tareas de operarios Error!
5.3.3 Diagrama de subsistemas 34
5.3.4 Agrupación de las clases de diseño en Subsistema del paquete Atención al
cliente 35
5.3.4.1 Diagrama de clases de diseño del subsistema Servicio al cliente 36
5.3.4.1.1 Asignación de Operaciones 36
5.3.4.1.2 Diagrama de clases del diseño 38
5.3.4.2 Diagrama de clases de diseño del subsistema Gestión de productos Error!
5.3.4.2.1 Asignación de Operaciones Error! Bookmark not defined.
5.3.4.2.2 Diagrama de clases del diseño Error! Bookmark not defined.
5.3.5 Agrupación de las clases de diseño en Subsistema del paquete Gestión de
tareas de operarios Error! Bookmark not defined.
5.3.5.1 Diagrama de clases de diseño del subsistema Gestión de tareas de operarios
Error! Bookmark not defined.
5.3.5.1.1 Asignación de Operaciones Error! Bookmark not defined.
5.3.5.1.2 Diagrama de clases del diseño Error! Bookmark not defined.

6. Vista de despliegue 27
6.1 Servidor de base de datos 40
6.2 Switch Error! Bookmark not defined.
6.3 Computadoras 41
7. Vista de implementación Error! Bookmark not defined.

7.1 Descripción Error! Bookmark not defined.
7.2 Diagrama de componentes Error! Bookmark not defined.
7.2.1 Actividad implementar un subsistema Error! Bookmark not defined.
7.2.2 Diagrama general de componentes Error! Bookmark not defined.
8. Vista de Datos Error! Bookmark not defined.

8.1 Modelo Relacional Error! Bookmark not defined.
8.2 Tipo de Base de datos: Base de datos centralizado.Error! Bookmark not
defined.

Documento de la Arquitectura del Software

1. Introducción
Imaginemos la construcción de algún edificio; primero se comienza por los cimientos, luego
las columnas y vigas, hasta tener un esqueleto de soporte. Por último se construyen las
paredes, ventanas, pisos, etc. Entonces, es ilógico suponer que las paredes se levantan antes
que las columnas. En resumen, primero se establece el esqueleto o soporte del edificio y
después se ensamblan las partes restantes. Esta estrategia es aplicable a la creación de
software, con la diferencia de que éste no se rige por leyes físicas ni por procedimientos, sino
que es experimental.
Entonces, se concluye que la parte más importante en la creación del software (haciendo una
analogía con la idea de la construcción del edificio) es el “esqueleto” o, en nuestro caso, la
ARQUITECTURA DEL SOFTWARE, que es la que provee de una estructura sólida y
organizada al sistema.
Por ello, el presente documento hace una descripción y brinda una visión general de la
arquitectura del Sistema de gestión de pedidos de ebanistería, el cual es el software a
desarrollar por el grupo de trabajo.
1.1 Alcance
El DAS del Sistema de gestión de pedidos de ebanistería 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.2 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.

1.2.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,
Arquitectura de Software como al 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 programas
Sistema operativo
usados por el usuario para utilizar un
computador.
Agrupaciones de casos de uso y actores

Paquetes
por funcionalidad que proveen.

1.2.2 Acrónimos
Rational Unified Process (Proceso Unificado

RUP
de Rational)
Unified Modeling Language (Lenguaje de

UML
Modelado Unificado)
1.3 Referencias
Documento Versión Fecha de la versión
Especificación de Requisitos de
software 1.0 09/11/2013
Modelo del Negocio del Sistema

2.0 20/09/2013
Modelo de Análisis del Sistema

2.0 16/12/2013
Glosario de términos
2.0 08/10/2013
1.4 Vista Global

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 gestión de pedidos de ebanistería de la empresa Obregón
SRL.

2. Representación Arquitectónica
Para el diseño del sistema de gestión de documentos se ha escogido una arquitectura cliente-
servidor. La utilización de esta arquitectura se debe a la necesidad de aportar facilidad y
velocidad al usuario al momento de acceder o manejar de cualquier manera la información
de los documentos mediante llamadas al servidor y respuestas de éste. Además, se evitará
la principal desventaja de este tipo de arquitectura al tener solamente un usuario que efectúa
llamadas.
Se desarrollará una sola aplicación integrada, en la que solo se permitirá el acceso al usuario
registrado en el sistema a partir de la interfaz gráfica perteneciente a la capa del cliente que
se comunicará mediante llamadas con la capa del servidor dentro de la cual encontraremos
la base de datos.
La arquitectura se basará en el modelo ‘4+1’, que contendrá las vistas de Casos de Uso,
Lógica, Implementación, Procesos y Despliegue.
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 al Sistema de gestión de documentos, se requiere de un código de
usuario válido, así como de una contraseña.
3.2 Restricciones
 El sistema de gestión de pedidos de ebanistería usará como motor de base de datos
Oracle 11g.
 Las características técnicas de las computadoras que serán utilizadas no deberán
presentar potencias menores a las brindadas por un procesador Celeron N4100, con
al menos 2GB de RAM y 1GB de espacio libre en el disco. El Sistema operativo será
Windows XP/ Windows 7/Windows 8.

4. Vista de Casos de Uso
Descripción del
negocio
Actores Modelo del Casos de Uso

dominio
4.1 Descripción del Negocio

La Unidad de Matrícula es el área encargada de organizar el proceso de Matrícula, mantener
actualizado los archivos académicos de los estudiantes y llevar el registro de grados y títulos
de la facultad. Organiza el archivo de Actas y todos los documentos relacionados con la
actividad académica. Administra los certificados de estudio, constancias, matrícula, actas y
registros, también procesa toda la documentación necesaria para la expedición y entrega de
los carnés universitarios. El área también se encarga de validar consultas de datos hechas
por terceros.
El mayor problema de la organización es que no tiene registrado la información de cada
usuario, todo está realizado por papeles, los cuales se guardan en un almacén que no posee
la protección necesaria. Cabe recalcar que la información ingresada es de mucha importancia
y no se puede dejar permitir la pérdida de datos. Esta manera de ingreso ralentiza el proceso
de revisión, extendiéndolo más de 2 meses, que en sí son innecesarios para este proceso.
Debido a esto se ocasiona negligencia con los usuarios mayormente en el proceso de
matrícula.
La unidad de matrícula no cuenta actualmente con la tecnología necesaria para la
implementación del sistema de digitalización de documentos, por esto es necesario y posible
la compra de equipos de cómputo que serán instalados en las diferentes áreas de la empresa
y que permitan el correcto funcionamiento del sistema.
El sistema que se planea desarrollar será aceptado por el administrador ya que les brinda
beneficios, es decir, les da mayores facilidades para que realicen sus labores y controlen a
los trabajadores que tienen a su cargo, además dicho administrador realizara una
capacitación especial durante una semana para poder utilizar el sistema adecuadamente. Lo
que se busca es almacenar correctamente la información ingresada por el usuario
(Documentos, fotos, copias, etc.), también debemos poder dejarles visualizar su información

respectiva a cada usuario de una forma en que puedan comprender su proceso de matrícula.
Resolvemos consultas de la universidad pedidas por terceros con el fin de validar dicha
información. Realizamos el proceso de matrícula indicando que cursos se matriculó cada
usuario y permitirles ver su historial académico.
4.2 Identificación de los procesos del negocio

Se identifican 3 procesos del negocio:
 PN1: Gestión de Documentos
 PN2: Gestión de Digitalización
 PN3: Gestión de Trámites
4.3 Procesos de negocio relevantes para el sistema
Los procesos relevantes del sistema será únicamente Gestión de Documentos, ya que en
este se centra el negocio; PN1 se basa en las operaciones que se pueden realizar a la hora
de gestionar un documento sustancial de un alumno en el sistema, el cual será realizado
por el administrador del sistema.

4.4 Descripción de los procesos del negocio relevantes para el sistema

4.4.1 PN1: Proceso de Gestión de Documentos

4.5 Modelo de Dominio
4.6 Identificar a los actores

Los trabajadores del negocio que se convierten en actores del sistema son los siguientes:
 Administrador
Responsable de la digitalización y categorización de los archivos que se convertirán
a documentos digitalizados.
Jefe de Produccion Supervisor de

Administrador
tareas

4.7 Casos de uso relevantes organizado por paquetes

4.7.1 Paquete Negocio Principal

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

4.8.1 Descripción de los casos de uso relevantes para el proceso Gestión de
Documentos
ID: CUS-01
Caso de Uso: Registrar Documento
Actor: Administrador
Descripción: El administrador podrá registrar un nuevo documento al sistema
Precondición: El Administrador ha ingresado al sistema con su nombre de usuario y
contraseña respectivo.
Flujo Principal: Añadir Diseño
1. El CUS empieza cuando el Administrador pulsa la opción “Registrar Documento”
en la sub-interfaz “Barra Lateral”.
2. El sistema muestra la interfaz “Registrar Documento” con un formulario que
contiene los siguientes campos (Código, Tipo de Documento, Nombre, Código de
Alumno, Descripción), y un botón “Registrar Documento”. El sistema muestra la
interfaz “Mantener información del catálogo de diseño de producto”.
3. El Administrador registra los datos del formulario de la interfaz “Registrar
Documento”
4. Al concluir el llenado de datos el Administrador pulsa el botón “Registrar
Documento”.
5. El Sistema verifica que los campos obligatorios no estén vacíos.
6. El Sistema verifica que los campos concuerden con los datos definidos por cada
campo.
7. El Sistema verifica que los campos no repetibles no sean iguales a los de
documentos ya registrados anteriormente.
8. El Sistema registra el nuevo documento al alumno seleccionado.
9. El Sistema muestra un mensaje de confirmación “Documento registrado
exitosamente”.
10. El CUS finaliza.
Post-condición : Se ha registrado el documento del usuario correctamente.

Flujo Alterno 1: Cancelar

1. El administrador pulsa cualquier otro botón y se redirecciona a otra interfaz
Flujo Alterno 2: Campos obligatorios vacíos
1. En el paso 5 si el sistema detecta que los campos obligatorios están vacíos, el
sistema muestra un mensaje de error “Campos obligatorios del Documento están
vacíos”, señalando con rojo los campos obligatorios sin llenar.
Flujo Alterno 3: Campos no repetibles ya existentes
1. En el paso 7 si el sistema detecta que los campos no repetibles ya existen, el
sistema muestra un mensaje de error “Campos no repetibles de Documento ya
existen”, señalando con rojo los campos no repetibles ya existentes.
Flujo Alterno 4: Campos ingresados inválidos
1. En el paso 6 si el sistema detecta que los tipos de campos ingresados son
inválidos, mostrará un mensaje de error “Campos ingresados de Documento son
inválidos”, señalando con rojo los campos inválidos.
ID: CUS-02
Caso de Uso: Buscar Documento
Descripción: El administrador tendrá la posibilidad de buscar un documento en la
base de datos del sistema
Precondición: 1. El Administrador ha ingresado al sistema con su nombre de
usuario y contraseña respectivo.
2. El administrador cuenta por lo menos con un dato necesario del
alumno para buscar un documento
Flujo Principal:

1. El CUS empieza cuando el Administrador pulsa la opción “Buscar documento” en la

sub-interfaz “Barra Lateral”.
2. El Sistema muestra la interfaz “Buscar documento” con un formulario que contiene
las siguientes opciones de criterio (Código, Apellidos, DNI) para determinar el
campo según el cual se buscará el documento, un campo “dato” para introducir el
valor del criterio de búsqueda, las opciones de tipo documento (historial
académico, constancia de matrícula, rectificación de matrícula), un botón “Buscar
Documento” para iniciar la búsqueda del documento y un botón “Volver”.
3. El administrador selecciona el criterio de búsqueda del documento.
4. El administrador introduce el valor del criterio de búsqueda del documento dentro
del campo “dato”.
5. Al finalizar la escritura del valor del criterio, el administrador pulsa el botón “buscar
documento”.
6. El sistema verifica que el valor escrito en el campo “dato” coincide con el formato
del criterio seleccionado.
7. El sistema verifica que exista el dato ingresado.
8. El sistema inicia la búsqueda del documento.
9. El sistema muestra una nueva ventana donde se podrá visualizar el documento
buscado.
10. El CUS finaliza.
Post-condición : Se visualiza el documento buscado del alumno en caso de que exista,

en caso contrario, se notificará que el documento no existe
1. El administrador pulsa el botón volver.
2. El sistema cierra la ventada de “Buscar Documento”.
3. Se regresa a la ventana de la interfaz principal.
Flujo Alterno 2: Error de formato en el campo “dato”

1. Si en el paso 4 el formato del dato ingresado no coincide con el formato del criterio
de búsqueda, el sistema muestra un sistema de error “Formato incorrecto”,
remarcando en rojo el recuadro del campo “dato”.
Flujo Alterno 3: Dato no existente
1. Si en el paso 7 el sistema detecta que el dato ingresado no existe, se mostrará un
aviso “Alumno no registrado” y se marcará el campo “dato” en rojo.
Flujo Alterno 4: Documento no existente
1. Si en el paso 3.1.8 el sistema detecta que el documento buscado no existe para el
alumno especificado, se mostrará un aviso “documento no existente”.

ID: CUS-03
Caso de Uso: Editar documento
Descripción: Este administrador ya dentro de la aplicación desea modificar la
información del usuario, con la finalidad de cambiar los datos por
comodidad de la empresa o del usuario.
Precondición: Para abrir el editado del programa previamente el usuario ha tenido que
ser registrado sino no podría editarse un usuario que no exista en la
base de datos
Flujo Básico:
1. El CUS inicia cuando el administrador pulsa la opción “Editar Documento” en la

sub-interfaz.
2. El Sistema muestra la interfaz “Editar Documento” el cual tiene las siguientes
funciones que se puede realizar, se puede hacer el cambio de una parte o toda la
documentación del usuario, y finaliza con el botón guardar información.
3. Solo el administrador tiene la función de editar documentación y guardarla.
4. El sistema tiene la opción de editar, así como guardar la documentación editada.
5. El sistema al guardar la edición del documento automáticamente se cambia en la
base de datos del programa.
6. Si el administrador por error quiere cierra la aplicación mientras está editando le
mostrara un error diciendo “Desea guardar los cambios. Si desea pulse guardar,
Caso contrario pulse salir”.
7. El CUS finaliza.
Post-condición : El correcto guardado en la base de dato. Para eso se asignará

un botón con la funcionalidad de llenar la información en la base
de datos.

El administrador al pulsar el botón y regresa a la interfaz principal.
Flujo Alterno 2: Error al guardar los datos
La aplicación tendrá partes donde no se admitan números o caracteres y el programa

deberá avisar o impedirá que esos errores ocurran, para que el llenado de la base de datos
sea sin errores.
Flujo Alterno 3: Campos editados sin llenar
Al editar lo campos puede que se deje dicho campo vació sistema te informara sobre la
falta del llenado de dichos campos que son obligatorios.

ID: CUS-04
Caso de Uso: Eliminar documento
Descripción: El administrador podrá borrar un documento que se encuentra dentro
de la Base de datos del sistema.
Precondición: El Administrador ha ingresado al sistema con su nombre de usuario y
contraseña respectivo.
Flujo Principal:
1. El Administrador pulsa la opción “Eliminar Documento” en la interfaz “Busca”
Documento”.
2. El Sistema muestra la sub-interfaz “Eliminar Documento” con una ventana
preguntando si el administrador está seguro de eliminar dicho documento, con los
botones “Cancelar” y “Eliminar Documento”.
3. El Administrador selecciona la opción Eliminar Documento.
4. El sistema verifica si el identificador del documento a eliminar existe en la base
de datos.
5. El Sistema muestra un mensaje de confirmación “Documento eliminado
exitosamente”.
6. El CUS finaliza.
Post-condición : Se elimina el documento del usuario correctamente.

En el paso 2, El administrador pulsa la opción “Cancelar” y se cierra la sub-interfaz “Eliminar
Documento
Flujo Alterno 2: Documento a eliminar no identificado
En el paso 4, El sistema detecta que no existe ningún documento registrado en la base de datos con
el identificador dado, el sistema mostrará un mensaje de error “Documento a eliminar no existe”.

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 Documento

 CUS-02: Buscar Documento.

 CUS-03: Editar Documento.
 CUS-04: Eliminar Documento.


Sección de restricciones
4.9.1 Normativas
 Licenciamiento
No es necesario obtener un licenciamiento debido a que estamos usando software
de código abierto.
4.9.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.9.3 Tecnología
 El Sistema será desarrollado en el lenguaje de programación de servidor PHP, se
utilizará el entorno de programación Laravel (Framework) y se usará el paquete de
instalación de servidor XAMPP para utilizar de una manera fácil el servidor local
Apache y MySQL.
 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.
 Uso de uno de estos sistemas operativos: Windows10, Windows8 o Windows7

4.9.4 Soporte
El “Sistema de gestión de documentos” 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 el área de Matrícula.
4.10 Sección de QoS

4.10.1 Usabilidad
Las interfaces del “Sistema de gestión de documentos” 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 documentos” está orientado solo para los miembros
de la unidad de matrícula, su uso está destinado únicamente para estos.
4.10.2 Eficiencia
El sistema tendrá una respuesta inmediata (a lo más un 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 documentos”.
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 1 (Administrador).

4.10.3 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.10.4 Mantenimiento
El mantenimiento estará regido de acuerdo a las necesidades de la Unidad de matrícula 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.
4.10.5 Estándares
Se usara un estándar para todas las ventanas e interfaces las cuales están especificadas en
el documento “Estándares de Interfaz Gráfica.docx”.
Asimismo se tendrá un estándar para el nombre de los formularios, clases, variables, métodos
y los códigos.

5. Vista Lógica
5.1 Estilo arquitectónico
Para el diseño del sistema de gestión de documentos se ha escogido una arquitectura cliente-
servidor. La utilización de esta arquitectura se debe a la necesidad de aportar facilidad y
velocidad al usuario al momento de acceder o manejar de cualquier manera la información
de los documentos mediante llamadas al servidor y respuestas de éste. Además, se evitará
la principal desventaja de este tipo de arquitectura al tener solamente un usuario que efectúa
llamadas.
 Capa de cliente
La capa del cliente abarca el conjunto de componentes software que permitirán al usuario
comunicarse con el sistema de manera gráfica y amigable para efectuar las peticiones a la
capa del servidor y modificar u obtener la información (documento) deseada mediante
ventanas. Espera, recibe y muestra las respuestas del servidor.
 Capa de intermedia
En la capa intermedia encontraremos la lógica de la aplicación necesaria para permitir la
comunicación efectiva entre la capa del cliente y la capa del servidor. Se encarga de convertir
las peticiones del cliente a una forma a la que la capa del servidor pueda responder, y
transformar esta respuesta obtenida en información utilizable para la capa del cliente.
 Capa de servidor
La capa del servidor será la que estará a la escucha de las peticiones del cliente que llegarán
en el formato adecuado mediante la capa intermedia, procesará la petición y la enviará de
vuelta a la capa intermedia. En esta capa encontraremos el repositorio que nos permitirá la
persistencia.

5.2 Arquitectura lógica de la aplicación

5.2.1 Visión general

5.2.2 Identificando las Interfaces entre capas
5.3 Identificación de las clases del diseño

5.3.1 Diagramas de secuencias del paquete Gestión de documentos
 CUS-01: Registrar documento
IU_AñadirDocumento C_AñadirDocumento E_TipoDocumento E_Documento
<<Clase>> <<Clase>> <<Clase>>

Interfaz AgregarDocumento <<Clase>>
Gestor AñadirDocumento Tipo Documento Documento

: Interfaz : Gestor AñadirDocumento : Tipo : Documento

Administrador :
AgregarDocumento Documento
Usuario
Pulsa "Añadir documento"
Muestra opciones
Selecciona TipoDocumento
EnviarOpcionTipoDocumento()
ObtenerInformacionTipoDocumento()
EnviarCamposNecesarios()
MostrarCampos()
Ingresa datos
VerificarDatos()
VerificarDatosDocumento()
ConfirmarDatosDocumento()
ConfirmarDocumento()
GenerarCodigoDocumento()
GuardarDocumento()
RetornaConfirmación()
RetornarMensajeConfirmacionDocumento()
MostrarMensajeConfirmación
Pulsa "Salir"

 CUS-02: Buscar Documento
IU_ConsultarDocumento E_ConsultarDocumento
C_ConsultarDocumento
Interfaz : BusquedaDocumento Gestion: ConsultarDocumento Documento
: Administrador : IU_ConsultarDocumento : : E_ConsultarDocumento

C_ConsultarDocumento
PulsaConsularDocumen...
MostrarIUConsultar()
IngresarDatosSolicitadosDelDocumen...
BuscarDocumento()
BuscarConsulta()
ExisteDocumento()
ObtenerInformacionDelDocumento()
EntragarDatosDelDocumento()
MostrarDocumento()
MuestraDocumento()

 CUS-03: Editar Documento.
IU_ModificarDocumento C_ModificarDocumento E_Documento
Interfaz : ModificarDocumento GestorModificacion

Documento
: Administador : IU_ModificarDocumento : C_ModificarDocumento : E_Documento
PulsarModificarDocumen...
MuestrarInterfazModificar()
IngresarDatosDelDocumen...
PulsarBuscar()
BuscarDocumento()
VerificaDatosDelDocumento
ExisteDocumento()
MostrarVistaPrevia()
PulsarModificar()
Modificar()
GuardarDocumentoModificado()

 CUS-04: Eliminar Documento.

5.3.2 Diagrama de subsistemas

5.3.3 Agrupación de las clases de diseño en Subsistema del paquete Gestión de

Documentos
Clases:
 Interfaz Menú principal
 Interfaz Añadir Documento
 Interfaz Modificar Documento
 Interfaz Buscar Documento
 Interfaz Eliminar Documento
 Gestor Añadir Documento
 Gestor Modificar Documento
 Gestor Buscar Documento
 Gestor Eliminar Documento
 Documento

5.3.3.1 Diagrama de clases de diseño del subsistema Servicio al cliente
5.3.3.1.1 Asignación de Operaciones
Clase: Interfaz Añadir Documento
RESPONSABILIDADES COLABORACIONES
Llamar interfaz añadir cotización Clase: Interfaz Menú Principal
Clase: Interfaz Modificar Documento
Llamar interfaz Modificar Documento Clase: Interfaz Menú Principal.
Clase: Interfaz Buscar Documento
Llamar interfaz Buscar Documento Clase: Interfaz Menú Principal.
Clase: Interfaz Eliminar Documento
Llamar interfaz eliminar Documento Clase: Interfaz Menú Principal.

Clase: Gestor Modificar cotización
Verificar la validez de los cambios
Guardar los cambios Clase: Interfaz modificar documento.
Clase: Gestor Añadir cotización
Registrar producto Clase: Interfaz añadir Documento
Verificar validez del documento Clase: Interfaz añadir Documento
Guardar los cambios Clase: Interfaz añadir Documento
Clase: Gestor Eliminar cotización
Verificar Identificador del documento Clase: Interfaz eliminar Documento
Confirmar eliminar del Documento Clase: Interfaz eliminar Documento.
Eliminar Documento Clase: Interfaz eliminar Documento.
Clase : Gestor Buscar Documento
Verificar Identificador del documento Clase: Interfaz Buscar Documento
Solicitar el documento verificado Clase: Interfaz Buscar Documento

Clase : Documento
Registra los datos del documento Clase: Gestor Añadir Documento
Obtener el código y el nombre de un Clase: Gestor Buscar Documento

determinado Documento
Clase: Gestor Modificar Documento
Eliminar el registro de un Documento Clase: Gestor Eliminar cotización
Agregar un nuevo Documento Clase: Gestor Añadir Documento
5.3.3.1.2 Diagrama de clases del diseño


6. Vista de despliegue
6.1 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

6.2 Computadoras
 Características
 Intel Core i2/i3/i5/i7
 Memoria Ram 1gb
 Disco duro 128Gb minimo
 Sistema operativo: Windows XP/7/8/10
6.3 Impresora
 Caracteristicas
 Impresión continúa.
 Impresora con escáner.
 Impresora con depósitos rellenables.
 Impresión doble cara.
 Conexión de red y wi-fi
 Tipos:
- PC Administrador
Computadora que será utilizada por el administrador del Área de Matrícula de la
Facultad de Ingeniería de Sistemas e Informática, en este caso, encargado de
despacho, para acceder al sistema.


Documento Arquitectura 1

Cargado por

Información del documentohacer clic para expandir la información del documento

Copyright:

Formatos disponibles

Documento Arquitectura 1

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

Documento Arquitectura 1

Cargado por

Copyright:

Formatos disponibles

Waldo S

Sistema de Gestión de Documentos

Documento de la Arquitectura del Software

Fecha Versión Descripción Autor

Vista de casos de uso del

Vista de casos de uso del

30/01/2014 3.0 Vista lógica Equipo de trabajo

1/02/2014 4.0 Vista lógica Equipo de trabajo

11/02/2012 5.0 Vista despliegue Equipo de trabajo

17/02/2014 6.0 Vista de implementación Equipo de trabajo

20/02/2014 7.0 Vista de implementación Equipo de trabajo

Confidencial Obregón SRL, 2014 Página 2 de 42

3. Metas y Restricciones Arquitectónicas 9

4. Vista de Casos de Uso 10

Confidencial Obregón SRL, 2014 Página 3 de 42

Confidencial Obregón SRL, 2014 Página 4 de 42

7. Vista de implementación Error! Bookmark not defined.

8. Vista de Datos Error! Bookmark not defined.

Confidencial Obregón SRL, 2014 Página 5 de 42

Documento de la Arquitectura del Software

Confidencial Obregón SRL, 2014 Página 6 de 42

Usuario del sistema que puede participar

Conjunto de elementos estáticos, propios

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

Confidencial Obregón SRL, 2014 Página 7 de 42

Rational Unified Process (Proceso Unificado

Unified Modeling Language (Lenguaje de

Documento Versión Fecha de la versión

Modelo del Negocio del Sistema

Modelo de Análisis del Sistema

1.4 Vista Global

Confidencial Obregón SRL, 2014 Página 8 de 42

3. Metas y Restricciones Arquitectónicas

Confidencial Obregón SRL, 2014 Página 9 de 42

4. Vista de Casos de Uso

Actores Modelo del Casos de Uso

4.1 Descripción del Negocio

Confidencial Obregón SRL, 2014 Página 10 de 42

4.2 Identificación de los procesos del negocio

Confidencial Obregón SRL, 2014 Página 11 de 42

4.4 Descripción de los procesos del negocio relevantes para el sistema

Confidencial Obregón SRL, 2014 Página 12 de 42

4.5 Modelo de Dominio

4.6 Identificar a los actores

Jefe de Produccion Supervisor de

Confidencial Obregón SRL, 2014 Página 13 de 42

4.7 Casos de uso relevantes organizado por paquetes

Confidencial Obregón SRL, 2014 Página 14 de 42

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

Confidencial Obregón SRL, 2014 Página 15 de 42

Flujo Alterno 1: Cancelar

Confidencial Obregón SRL, 2014 Página 16 de 42

1. El CUS empieza cuando el Administrador pulsa la opción “Buscar documento” en la