Está en la página 1de 76

Clínica San Sebastián

Análisis de Sistemas

Especificación de Casos de Uso del Negocio

Versión 2.0
Documento de la Arquitectura de Software

Tabla de contenido
1. Introducción 5
1.1 Propósito 5
1.2 Alcance 5
1.3 Definiciones, Siglas, y Abreviaturas 5
1.3.1 Definiciones 6
1.3.2 Acrónimos 7
1.4 Referencias 7
1.5 Vista Global 7

2. Representación Arquitectónica 8

3. Metas y Restricciones Arquitectónicas 8


3.1 Metas 8
3.2 Restricciones 8

4. Vista de Casos de Uso 9


4.1 Descripción del Negocio 9
4.2 Identificación de los procesos del negocio 10
4.3 Procesos de negocio relevantes para el sistema 10
4.4 Descripción de los procesos del negocio relevantes para el sistema 11
4.4.1 PN1: Proceso de Atención al cliente 11
4.5 Modelo de Dominio 12
12
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
4.8.2 Descripción de los casos de uso relevantes para el paquete Seguridad 26
4.9 Interfaz de Usuario 28
4.10 Sección de restricciones 41
4.10.1 Normativas 41
4.10.2 Estándares 41
4.10.3 Tecnología 41
4.10.4 Soporte 42
4.11 Sección de QoS 42
4.11.1 Usabilidad 42

Clínica San Sebastián, 2020 Página 2 de 76


Documento de la Arquitectura de Software

4.11.2 Eficiencia 42
4.11.3 Seguridad 42
4.11.4 Confiabilidad 43
4.11.5 Mantenimiento 43
4.11.6 Estándares 43

5. Vista Lógica 43
5.1 Estilo arquitectónico 43
5.2 Arquitectura lógica de la aplicación 45
5.2.1 Visión general 45
5.2.2 Identificando las Interfaces entre capas 46
5.3 Identificación de las clases del diseño 47
5.3.1 Diagramas de secuencias del paquete Atención al cliente 47
5.3.2 Diagrama de subsistemas 57
5.3.3 Agrupación de las clases de diseño en Subsistema del paquete Atención al cliente 58
5.3.3.1 Diagrama de clases de diseño del subsistema Servicio al cliente 59
5.3.3.1.1 Asignación de Operaciones 59
5.3.3.1.2 Diagrama de clases del diseño 63
5.3.3.2 Diagrama de clases de diseño del subsistema Gestión de productos 64
5.3.3.2.1 Asignación de Operaciones 64
5.3.3.2.2 Diagrama de clases del diseño 68

6. Vista de despliegue 69
6.1 Servidor de base de datos 69
6.2 Switch 69
6.3 Servidor de base de datos 70
6.4 Switch 70
6.5 Computadoras 70

7. Vista de implementación 71
7.1 Descripción 71
7.2 Diagrama de componentes 71
7.2.1 Actividad implementar un subsistema 71
71
 Subsistema de Implementación: Servicio al cliente 72
 Componente Cotización 72
 Componente Gestor Cotización 72
 Componente Pedido 72
 Componente Gestor Pedido 72

Clínica San Sebastián, 2020 Página 3 de 76


Documento de la Arquitectura de Software

 Componente Producto 72
 Componente Cliente 72
 Subsistema de Implementación: Gestión de producto 73
 Componente Producto 73
 Componente Diseño de producto 73
 Componente Gestor diseño de producto 73
 Componente Ubicación de diseño 73
 Componente Gestor Seleccionar diseño del catalogo 73
 Componente Gestor Registrar producto 74
7.2.2 Diagrama general de componentes 75

8. Vista de Datos 76
8.1 Modelo Relacional 76
8.2 Tipo de Base de datos: Base de datos centralizado. 77

Clínica San Sebastián, 2020 Página 4 de 76


Documento de la Arquitectura de Software

Especificación de Casos de Uso del Negocio

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 citas, 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 citas, para la Clínica San
Sebastián 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 citas 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.

Clínica San Sebastián, 2020 Página 5 de 76


Documento de la Arquitectura de Software

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 comportamiento del
Arquitectura de Software
software en tiempo de ejecución.
Naturalmente este diseño arquitectónico
ha de ajustarse a las necesidades y
requisitos del proyecto.

StarUML, 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.

Clínica San Sebastián, 2020 Página 6 de 76


Documento de la Arquitectura de Software

1.3.2 Acrónimos

Rational Unified Process (Proceso


RUP
Unificado de Rational)

Unified Modeling Language (Lenguaje de


UML
Modelado Unificado)

1.4 Referencias

Documento Versión Fecha de la versión

Especificación de Requisitos de
software 1.0 17/01/2020

Modelo del Negocio del Sistema


2.0 17/01/2020

Modelo de Análisis del Sistema


2.0 17/01/2020

Glosario de términos
2.0 17/01/2020

1.5 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 citas de la clínica San Sebastián.

Clínica San Sebastián, 2020 Página 7 de 76


Documento de la Arquitectura de Software

2. Representación Arquitectónica
Para el diseño del sistema de gestión de pedidos se ha escogido una arquitectura cliente-
servidor de tres capas (Presentación, Aplicación y Persistencia). La utilización de esta
arquitectura se debe a que distintos niveles son independientes unos de los otros, esto nos
permite poder cambiar el comportamiento de las clases en el nivel de aplicación sin que ello
influya en las otras capas.
Se desarrollará una sola aplicación integrada, en la que solo se permitirá el acceso a los
usuarios registrados en el sistema a partir de la Interfaz gráfica la cual pertenece a la capa de
Presentación que se comunica con la capa de Aplicación para demandarle el servicio deseado,
ya que esta capa es la que se comunica con la de persistencia para recuperar los datos
necesarios de 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 citas, se requiere de un código de usuario válido,
así como de una contraseña. Además, dependiendo del perfil del usuario se deshabilitarán
opciones de manejo del Sistema para proteger información confidencial.
3.2 Restricciones
 El sistema de gestión de citas usará como motor de base de datos Mysql.
 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 i3, con al menos
512 MB de RAM y 500 MB de espacio libre en el disco. El Sistema operativo será
Windows XP/ Windows 8/Windows 10.

Clínica San Sebastián, 2020 Página 8 de 76


Documento de la Arquitectura de Software

4. Vista de Casos de Uso

Descripción del
negocio

Actores Modelo del Casos de Uso


dominio

4.1 Descripción del Negocio


Clínica San Sebastián es una clínica que lleva más de 5 años brindando servicios de salud de
calidad
Cuando un paciente desea ser atendido en la clínica se debe acercar al área de recepción,
pedirá informes sobre costo, especialidad y doctores. Si el paciente desea sacar una cita, la
recepcionista buscará su historial clínico en el almacén. Si el paciente es nuevo la
recepcionista le dará una ficha para que complete sus datos que se solicitan, cuando haya
terminado la recepcionista procede a guardar su historia clínica al almacén. La recepcionista
evaluará si se realizará un descuento sobre la cita, después le dará un ticket con la
especialidad y el monto a pagar y lo registrará a la cola de pacientes con cita de esa
especialidad. El paciente se dirigirá al cajero en el área de facturación con el ticket a pagar, el
cajero le cobrará la cantidad determinada y le sellará el ticket y le dará su boleta de pago. El
paciente irá con el supervisor de citas de la especialidad a la que pagó a entregarle el ticket
sellado. El supervisor verificará los datos y la fecha, si los datos son correctos procederá a
buscar su historia clínica en el almacén y llevarlo al consultorio y pueda ser atendido y sellar
su ticket con el sello de atendido.
En caso de que el paciente ya tenga una historia clínica y tenga agendada una cita, se dirigirá
al consultorio de su especialidad, el supervisor de citas verificará su ticket, los datos, la fecha
y sellado. El supervisor de citas deberá buscar su historia clínica al almacén para llevarlo al
consultorio y pueda ser atendido. El supervisor de citas procederá a sellar su ticket con el
sello de atendido.
Otra actividad que está incluida en Atención al cliente es cuando el gerente general desea
registrar un doctor, el doctor viene con su horario disponible y la especialidad, el gerente

Clínica San Sebastián, 2020 Página 9 de 76


Documento de la Arquitectura de Software

general lo registra en su base de datos de Excel.


4.2 Identificación de los procesos del negocio
Se identifica 1 proceso del negocio:
 PN1: Atención al cliente
4.3 Procesos de negocio relevantes para el sistema
Los procesos relevantes del sistema son los procesos de “Atención al cliente” ya que en él se
centra el negocio; PN1 se basa en la atención al cliente, desde que se registra su historia
clínica, solicita cita y es atendido. Hay un contacto directo con el paciente para que de la
información suficiente en su registro. También implica cuando el gerente general registra a
los doctores y gestiona horarios. Es el proceso de negocio más importante debido a que hay
una gran interacción con el paciente.

Clínica San Sebastián, 2020 Página 10 de 76


Documento de la Arquitectura de Software

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


4.4.1 PN1: Proceso de Atención al cliente
Documento de la Arquitectura de Software

4.5 Modelo de Dominio


Documento de la Arquitectura de Software

4.6 Identificar a los actores


Los trabajadores del negocio que se convierten en actores del sistema son los siguientes:
 Gerente General
El Gerente general es el encargado de registrar nuevas especialidades, horarios y
doctores en el sistema.
 Supervisor de citas
El supervisor de citas se encarga de actualizar la historia clínica del paciente y atender
la cita.
 Recepcionista
Actor encargado de informar sobre horarios, doctor y costo al paciente además de
hacer el proceso de registro obteniendo los datos del paciente para verificar en el
sistema y registrar la cita
Documento de la Arquitectura de Software

4.7 Casos de uso relevantes organizado por paquetes


4.7.1 Paquete Negocio Principal
Documento de la Arquitectura de Software

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 Atención al cliente

ID: CUS-01
Caso de Uso: Registrar paciente
Actor: Recepcionista
Descripción: Se registra al paciente en el sistema.
Precondición: El usuario ha ingresado al sistema con su nombre de usuario y
contraseña dependiendo de su rol.
El paciente no está registrado
Flujo Principal:

1. El CUS empieza cuando la recepcionista pulsa la interfaz “Nuevo paciente”


2. El sistema muestra la interfaz “Nuevo paciente” la cual contiene seis TextField para
DNI, nombres, apellidos, dirección, teléfono y celular, también 2 ComboBox uno
para género que tiene los valores de “N” (por defecto), “M” (masculino) y “F”
(femenino), el otro para tipo de sangre con los valores “No especificado” (por
defecto), “A+”, “A-“, “B+”, “B-“, “AB+”, “AB-“. Además tiene, un DataPicker para
elegir la fecha de nacimiento y un botón “Crear paciente”.
3. El recepcionista digita y selecciona todos los datos solicitados en los respectivos
TextField, ComboBox, DataPicker.
4. El recepcionista pulsa el botón “Crear paciente”.
5. El sistema verifica si todos los datos han sido ingresados.
6. El sistema guarda los datos en la tabla Paciente de la base de datos.
7. El sistema envía un mensaje de confirmación.
8. El CUS finaliza.

Post-condición : Se registrado correctamente al paciente.


Flujo Alterno 1: Llenado de datos incompleto
Documento de la Arquitectura de Software

1. El CUS empieza cuando la recepcionista pulsa la interfaz “Nuevo paciente”


2. El sistema muestra la interfaz “Nuevo paciente” la cual contiene seis TextField para
DNI, nombres, apellidos, dirección, teléfono y celular, también 2 ComboBox uno
para género que tiene los valores de “N” (por defecto), “M” (masculino) y “F”
(femenino), el otro para tipo de sangre con los valores “No especificado” (por
defecto), “A+”, “A-“, “B+”, “B-“, “AB+”, “AB-“. Además tiene, un DataPicker para
elegir la fecha de nacimiento y un botón “Crear paciente”.
3. La recepcionista digita solo algunos datos de todos los solicitados.
4. La recepcionista pulsa el botón “Crear paciente”.
5. El sistema verifica si todos los datos han sido ingresados.
6. El sistema mostrará una ventana de alerta que dice “Ingrese los datos
correctamente”.
7. La recepcionista pulsa “Aceptar” en la ventana.
8. La recepcionista continua con el registro.
9. El CUS finaliza.
Flujo Alterno 2: Cancelar
1. En cualquier momento el recepcionista pulsa “Cerrar”, el sistema no guarda ningún
dato.
2. El CUS finaliza.

ID: CUS-02
Caso de Uso: Actualizar historia clínica
Actor: Supervisor de citas
Descripción: En este caso de uso el supervisor actualiza las historias clínicas
agregando su diagnóstico a medida que los pacientes asistan a sus citas.
Precondición: El usuario ha ingresado al sistema con su nombre de usuario y
contraseña dependiendo de su rol.
El paciente esté registrado en el sistema.
Flujo Básico:
Documento de la Arquitectura de Software

1. El CUS empieza el sistema muestra la interfaz con tres ventanas “Datos del
paciente”, “Atención y “Mostrar Historial Médico”.
2. El supervisor pulsa la ventana “Datos del paciente”.
3. El sistema muestra la interfaz “Atención” el cual contiene nueve TextField de DNI,
Nombres, apellidos, fecha de nacimiento, dirección, teléfono, celular, género y tipo
de sangre.
4. El sistema accede a la base de datos donde está almacenado los datos del paciente
con ese número de cita a atender, es mostrado en los TextField correspondiente.
5. El supervisor pulsa la interfaz “Atención”.
6. El Sistema muestra la interfaz “Atención” que contiene cinco TextField para el
resumen de diagnóstico, peso, talla, pulso, presión, también hay dos TextArea para
que se escriba el diagnóstico completo y la receta. Por último, hay un botón
“Registrar”.
7. El supervisor de citas, digita todos los datos solicitados cuando el paciente ya se
haya atendido con el doctor y este le haya dado la información necesaria para
actualizar su historia clínica.
8. El Sistema muestra un mensaje de alerta que dice: “Historia clínica actualizada”.
9. El CUS finaliza.

Post-condición : Se ha registrado actualizado correctamente la historia clínica.


Flujo Alterno 1: Cancelar
1. En cualquier momento el supervisor de citas pulsa “Cerrar”, el sistema no guarda
ningún dato.
2. El CUS finaliza.
Documento de la Arquitectura de Software

ID: CUS-03
Caso de Uso: Registrar doctor
Actor: Gerente general
Descripción: En este caso de uso, el gerente registra un doctor al sistema.
Precondición: El usuario ha ingresado al sistema con su nombre de usuario y
contraseña dependiendo de su rol.
Se registre al doctor en una especialidad ya registrada.
Flujo Principal:
1. El CUS empieza cuando la gerente general pulsa la interfaz “Nuevo médico”.
2. El sistema muestra la interfaz “Nuevo médico” la cual contiene seis TextField en
un cuadro para código, apellidos, nombres, dirección, celular y teléfono, también 2
ComboBox uno para especialidad que tiene los valores de las especialidades
registradas y otro para género con los valores “N” (no especificado), “M”
(masculino) y “F” (femenino). Además, tiene un DataPicker para elegir la fecha de
nacimiento y el botón “Añadir médico”. En la parte inferior de la ventana se
muestra otro cuadro con el título de “Crear Especialidades” que contiene un
TextField con nombre “Nombre especialidad” y un botón “Crear Especialidad”
3. El recepcionista digita y selecciona todos los datos solicitados en los respectivos
TextField, ComboBox, DataPicker.
4. El recepcionista pulsa el botón “Añadir médico”.
5. El sistema verifica si todos los datos han sido ingresados.
6. El sistema guarda los datos en la tabla Medico de la base de datos.
7. El sistema envía un mensaje de confirmación.
8. El CUS finaliza.
Post-condición : Se ha registrado correctamente a un médico.
Flujo Alterno 1: Llenado de datos incompleto.
Documento de la Arquitectura de Software

1. El CUS empieza cuando la gerente general pulsa la interfaz “Nuevo médico”.


2. El sistema muestra la interfaz “Nuevo médico” la cual contiene seis TextField en
un cuadro para código, apellidos, nombres, dirección, celular y teléfono, también
2 ComboBox uno para especialidad que tiene los valores de las especialidades
registradas y otro para género con los valores “N” (no especificado), “M”
(masculino) y “F” (femenino). Además, tiene un DataPicker para elegir la fecha
de nacimiento y el botón “Añadir médico”. En la parte inferior de la ventana se
muestra otro cuadro con el título de “Crear Especialidades” que contiene un
TextField con nombre “Nombre especialidad” y un botón “Crear Especialidad”
3. El recepcionista digita y selecciona algunos de los datos solicitados en los
respectivos TextField, ComboBox, DataPicker.
4. El recepcionista pulsa el botón “Añadir médico”.
5. El sistema verifica si todos los datos han sido ingresados.
6. El sistema muestra un mensaje de alerta que dice “Ingrese los datos
correctamente”.
7. El CUS finaliza.
Flujo Alterno 2: Cancelar
3. En cualquier momento el gerente general pulsa “Cerrar”, el sistema no guarda
ningún dato.
4. El CUS finaliza.

ID: CUS-04
Caso de Uso: Registrar horarios
Actor: Gerente General
Descripción: En este caso de uso el gerente registra los horarios al sistema.
Precondición: El usuario ha ingresado al sistema con su nombre de usuario y
contraseña dependiendo de su rol.
El médico a asociar ya ha sido registrado y la especialidad.
Flujo Principal:
Documento de la Arquitectura de Software

1. El CUS empieza cuando el Gerente General selecciona la pestaña “Gestionar


horarios”.
2. El sistema muestra la interfaz “Gestionar horarios” que contiene dos secciones, en la
parte superior un cuadro con un TextField para código de médico, cinco ComboBox
para seleccionar el día con los valores de todos los días de la semana, hora de inicio
con valores de las horas desde 00:00 hasta 23:00, hora fin con valores de las horas
desde 00:00 hasta 23:00 y sede con los valores de la sede registrada, también dos
botones “Eliminar horario” y “Añadir horario”. En la sección inferior de la ventana
hay un TextArea.
3. El gerente ingresa y selecciona todos los datos solicitados y pulsa “Añadir horario”.
4. El sistema verifica los datos ingresados y busca el código del médico en la tabla
Médico de la base de datos.
5. El sistema guarda el horario en la tabla Horario de la base de datos.
6. El sistema muestra en el TextArea de la ventana los datos del médico al que está
asociado ese horario y su horario.
7. El CUS finaliza.

Post-condición : Se ha registrado el horario correctamente.


Flujo Alterno 1: Llenado de campos incompleto
1. El CUS empieza cuando el Gerente General selecciona la pestaña “Gestionar
horarios”.
2. El sistema muestra la interfaz “Gestionar horarios” que contiene dos secciones, en la
parte superior un cuadro con un TextField para código de médico, cinco ComboBox
para seleccionar el día con los valores de todos los días de la semana, hora de inicio
con valores de las horas desde 00:00 hasta 23:00, hora fin con valores de las horas
desde 00:00 hasta 23:00 y sede con los valores de la sede registrada, también dos
botones “Eliminar horario” y “Añadir horario”. En la sección inferior de la ventana
hay un TextArea.
3. El gerente ingresa y selecciona solo algunos de los datos solicitados y pulsa “Añadir
horario”.
4. El sistema muestra un mensaje de error que dice “Ingrese un horario” si es que el
gerente no ha ingresado uno, o que dice “Solo números al código” si es que no ha
digitado ningún código.
5. El CUS finaliza.
Flujo Alterno 2: Eliminar horario
Documento de la Arquitectura de Software

1. Empieza en el paso 3 del flujo principal, el gerente digita y selecciona todos los
datos solicitados.
2. El gerente pulsa el botón “Eliminar horario”
3. El sistema verifica los datos ingresados y busca el horario en la tabla Horario de la
base de datos.
4. El sistema muestra en el TextArea de la ventana los datos del médico al que está
asociado ese horario y su horario.
5. El sistema muestra un mensaje de confirmación.
6. El CUS finaliza.
Flujo Alterno 3: Cancelar
5. En cualquier momento el gerente general pulsa “Cerrar”, el sistema no guarda
ningún dato.
6. El CUS finaliza.

ID: CUS-05
Caso de Uso: Registrar cita
Actor: Recepcionista
Descripción: Se realiza el registro de las citas en el sistema.
Precondición: El usuario ha ingresado al sistema con su nombre de usuario y
contraseña dependiendo de su rol.
El paciente debe estar registrado.
La especialidad que elija debe estar registrada.
Flujo Principal:
Documento de la Arquitectura de Software

1. El CUS empieza cuando la recepcionista selecciona la pestaña “Citas”.


2. El sistema muestra la interfaz “Citas” que contiene dos secciones, en la parte
superior un cuadro con un TextField para DNI de paciente, dos ComboBox para
seleccionar la especialidad con los valores de las especialidades registradas, otro
para seleccionar la sede en este caso es sede única. También un DataPicker para
seleccionar la fecha de la cita y dos botones “Sacar cita” y “Generar ticket”. En la
sección inferior de la ventana hay un TextArea.
3. La recepcionista ingresa y selecciona todos los datos solicitados y pulsa “Sacar cita”.
4. El sistema verifica los datos ingresados y busca el DNI del paciente en la tabla
Paciente de la base de datos.
5. El sistema guarda la cita en la tabla Cita de la base de datos.
6. El sistema muestra un mensaje de confirmación que dice “Cita añadido”.
7. El sistema muestra en el TextArea de la ventana los datos de la cita, del médico y
del paciente respectivamente.
8. La recepcionista pulsa el botón “Generar ticket”.
9. El sistema muestra un mensaje de alerta con los datos del ticket como número de
cita, código del médico, DNI del paciente, fecha, hora, código de sede y el botón
“Imprimir”.
10. La recepcionista pulsa el botón “Imprimir”.
11. El CUS finaliza.

Post-condición : Se ha registrado el cita correctamente.


Flujo Alterno 1: Llenado de campos incompleto
1. El CUS empieza cuando la recepcionista selecciona la pestaña “Citas”.
2. El sistema muestra la interfaz “Citas” que contiene dos secciones, en la parte
superior un cuadro con un TextField para DNI de paciente, dos ComboBox para
seleccionar la especialidad con los valores de las especialidades registradas, otro
para seleccionar la sede en este caso es sede única. También un DataPicker para
seleccionar la fecha de la cita y dos botones “Sacar cita” y “Generar ticket”. En la
sección inferior de la ventana hay un TextArea.
3. La recepcionista ingresa y selecciona algunos de los datos solicitados y pulsa “Sacar
cita”.
4. El sistema verifica los datos ingresados.
5. El sistema muestra un mensaje de alerta que dice “Ingrese solo número al DNI” si es
que el recepcionista digitó mal el DNI. Y otro mensaje de alerta si no ha ingresado
los demás datos que dice “Ingrese todos los datos correctamente”.
6. El CUS finaliza.
Flujo Alterno 2: Paciente no encontrado
Documento de la Arquitectura de Software

1. Empieza en el paso 4 del flujo principal.


2. El sistema verifica los datos ingresados y busca al paciente en la tabla Paciente de la
base de datos.
3. El sistema muestra un mensaje de alerta que dice “Paciente no encontrado”.
4. El CUS finaliza.
Flujo Alterno 3: Cancelar
7. En cualquier momento el recepcionista pulsa “Cerrar”, el sistema no guarda ningún
dato.
8. El CUS finaliza.

ID: CUS-06
Caso de Uso: Atención cita
Actor: Supervisor de citas
Descripción: En este caso de uso el supervisor atiende las citas registradas.
Precondición: El usuario ha ingresado al sistema con su nombre de usuario y
contraseña dependiendo de su rol.
El paciente tiene registrado una cita en el sistema.
Flujo Básico:

1. El CUS empieza cuando el supervisor de citas haya entrado a su cuenta.


2. El sistema muestra su interfaz principal que contiene un cuadro con un TextField de
número de cita y dos botones “Atender” y “Eliminar cita”.
3. El supervisor digita el número de cita del paciente y pulsa “Atender”.
4. El sistema busca el DNI ingresado en la tabla Cita de la base de datos.
5. El sistema muestra la interfaz de atención.
6. El CUS finaliza.

Post-condición : Se ha atendido la cita.


Flujo Alterno 1: Cita no encontrada
1. El CUS comienza en el paso 4, el sistema accede a la base de datos busca la cita con
ese número de cita en la tabla Cita de la base de datos.
2. El sistema muestra un mensaje de alerta que dice “Cita no encontrada”.
3. El CUS finaliza.
Flujo Alterno 2: Eliminar cita
Documento de la Arquitectura de Software

1. El CUS empieza cuando el supervisor de citas haya entrado a su cuenta.


2. El sistema muestra su interfaz principal que contiene un cuadro con un TextField de
número de cita y dos botones “Atender” y “Eliminar cita”.
3. El supervisor digita el número de cita del paciente y pulsa “Eliminar cita”.
4. El sistema busca el DNI ingresado en la tabla Cita de la base de datos.
5. El sistema muestra un mensaje de alerta que dice “Cita eliminada correctamente”.
6. El CUS finaliza.
Flujo Alterno 3: Cancelar
1. En cualquier momento el supervisor de citas pulsa “Cerrar”, el sistema no guarda
ningún dato.
2. El CUS finaliza.

ID: CUS-07
Caso de Uso: Registrar especialidad
Actor: Gerente general
Descripción: En este caso de uso el gerente registra especialidad.
Precondición: El usuario ha ingresado al sistema con su nombre de usuario y
contraseña dependiendo de su rol.
Flujo Básico:
Documento de la Arquitectura de Software

1. El CUS empieza cuando la gerente general pulsa la interfaz “Nuevo médico”.


2. El sistema muestra la interfaz “Nuevo médico” la cual contiene seis TextField en
un cuadro para código, apellidos, nombres, dirección, celular y teléfono, también 2
ComboBox uno para especialidad que tiene los valores de las especialidades
registradas y otro para género con los valores “N” (no especificado), “M”
(masculino) y “F” (femenino). Además, tiene un DataPicker para elegir la fecha de
nacimiento y el botón “Añadir médico”. En la parte inferior de la ventana se
muestra otro cuadro con el título de “Crear Especialidades” que contiene un
TextField con nombre “Nombre especialidad” y un botón “Crear Especialidad”
3. El recepcionista digita la especialidad en el TextField “Nombre especialidad”.
4. El recepcionista pulsa el botón “Crear Especialidad”.
5. El sistema verifica el dato ingresado y que no contenga símbolos como coma,
punto, guion, etc.
6. El sistema guarda el dato en la tabla Especialidades de la base de datos.
7. El sistema muestra un mensaje de confirmación que dice “Especialidad agregada
correctamente”.
8. El CUS finaliza.
Post-condición : Se ha registrado la especialidad.
Flujo Alterno 1: Campo sin llenar o con símbolos.
4. El CUS comienza en el paso 5, el sistema detecta los símbolos en el dato ingresado o
el campo vacío.
5. El sistema muestra un mensaje de alerta que dice “Ingrese especialidad
correctamente”
6. El CUS finaliza.
Flujo Alterno 2: Cancelar
1. En cualquier momento el supervisor de citas pulsa “Cerrar”, el sistema no guarda
ningún dato.
2. El CUS finaliza.

4.8.2 Descripción de los casos de uso relevantes para el paquete Seguridad


ID: CUS-08
Documento de la Arquitectura de Software

Caso de Uso: CUS Mantener usuario.


Actor: Gerente general
Descripción: Se realiza el registro de nuevos usuarios.
Precondición: El usuario ha ingresado al sistema con su nombre de usuario y
contraseña dependiendo de su rol.

Flujo Principal:
1. El CUS comienza cuando el gerente general pulsa en la pestaña “Gestionar
usuarios”.
2. El sistema muestra la interfaz “Gestionar usuarios” que contiene un cuadro con tres
TextField para Nombre de usuario, contraseña y un ComboBox para el tipo con las
opciones “A” (administrador), “U” (recepcionista), “M” (supervisor de citas) y dos
botones “Agregar” y “Eliminar”.
3. El gerente digita el usuario, contraseña y selecciona el tipo.
4. El gerente pulsa el botón “Agregar”.
5. El sistema guarda el usuario en la base de datos en la tabla Login.
6. El sistema muestra un mensaje de confirmación que dice “Usuario agregado
correctamente”.
7. El CUS finaliza.
Post-condición : El usuario queda registrado correctamente.
Flujo Alterno : Eliminar usuario
1. El CUS comienza en el paso 4 del flujo principal, el gerente pulsa el botón
“Eliminar”.
2. El sistema accede a la base de datos y busca en la tabla Login.
3. El sistema muestra un mensaje de confirmación que dice “Usuario eliminado
correctamente”.
4. El CUS finaliza
Flujo Alterno : Cancelar
1. En cualquier momento el supervisor de citas pulsa “Cerrar”, el sistema no guarda
ningún dato.
2. El CUS finaliza.

ID: CUS-09
Documento de la Arquitectura de Software

Caso de Uso: CUS Conexión al sistema.


Actor: Gerente general
Descripción: Permite acceder al sistema mediante la identificación de los usuarios.
Precondición: El usuario debe existir en el sistema.
Flujo Principal:
1. El CUS comienza cuando el sistema muestra al usuario la ventana de acceso con
los campos “Usuario” y “Contraseña” con los botones “Ingresar”.
2. El usuario introduce nombre y contraseña.
3. El sistema verifica que el usuario este registrado en el sistema, buscando en la tabla
Login de la base de datos, y que no haya campos vacíos.
4. El sistema permite el acceso del usuario al sistema mostrando las interfaces
iniciales.
5. El usuario accede al sistema.
6. El CUS finaliza.
Post-condición : Los datos introducidos para acceder son correctos y el usuario accede al
sistema.
Flujo Alterno 1: Datos ingresados incorrectos
1. El nombre y/o contraseña son erróneos.
2. El sistema muestra un mensaje de error que dice “Usuario incorrecto, el usuario no
existe” o “Contraseña incorrecta, la contraseña está equivocada”.
3. El sistema permite introducir de nuevo el nombre y la contraseña.
4. El CUS finaliza.

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 paciente
Documento de la Arquitectura de Software
Documento de la Arquitectura de Software

 CUS-02: Actualizar historia clínica


Documento de la Arquitectura de Software
Documento de la Arquitectura de Software

 CUS-03: Registrar doctor.


Documento de la Arquitectura de Software
Documento de la Arquitectura de Software

 CUS-04: Registrar horarios


Documento de la Arquitectura de Software

Falta eliminar horario


Documento de la Arquitectura de Software

 CUS-05: Registrar Cita


Documento de la Arquitectura de Software

Falta generar ticket

 CUS-06: Atención citas

Falta eliminar cita

 CUS-07: Registrar especialidad


Documento de la Arquitectura de Software
Documento de la Arquitectura de Software

 CUS-08: Mantener usuario

Falta gestión usuario

 CUS-09: Conexión al sistema


Documento de la Arquitectura de Software
Documento de la Arquitectura de Software
Documento de la Arquitectura de Software

4.10 Sección de restricciones


4.10.1 Normativas
 Licenciamiento
No existe regulación de licenciamiento para el “Sistema de gestión de citas” en el país
en el que reside la Clínica San Sebastián. 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 Mysql se utilizaremos
la versión gratuita.
 Formas de pago
De acuerdo a las reglas de la Clínica San Sebastián, para comenzar con la elaboración
de un pedido se debe cancelar el 30% del monto total y para que esto quede
documentado se le entrega al cliente un comprobante de pago (boleta o factura), lo
mismo sucede con el saldo restante; estas restricciones serán soportadas por el
“Sistema de gestión de citas”.
 Registro impositivo
La Clínica San Sebastián 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.
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 citas” están basados en el Lenguaje de
Modelamiento Unificado (UML).
4.10.3 Tecnología
 El “Sistema de gestión de citas” será desarrollado en el lenguaje de programación
orientada a objetos Java, el cual se complementará con el entorno de desarrollo (IDE)
“NetBeans 7.4”.
 El motor de base de datos a utilizar será Mysql.
 Las herramientas de modelado para el desarrollo del sistema son el “StarUML” y el
“Bizagi Process Modeler” para el diagrama de actividades de los procesos.
Documento de la Arquitectura de Software

4.10.4 Soporte
El “Sistema de gestión de citas” 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 Clínica San Sebastián.

4.11 Sección de QoS


4.11.1 Usabilidad
Las interfaces del “Sistema de gestión de citas” han sido desarrolladas para ser bastante
amigables para los usuarios.
Debido a que el “Sistema de gestión de citas” está orientado solo para los miembros de la
Clínica San Sebastián, su uso está destinado únicamente para estos. Se podría hacer factible
su uso para otras empresas, las cuales estén orientadas al rubro del sector salud y que sus
reglas del negocio se aproximen a las de la clínica San Sebastián.
4.11.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 citas”.
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 3 (Gerente general, Supervisor de citas y Recepcionista).
4.11.3 Seguridad
El sistema permitirá el uso de sus distintas funcionalidades dependiendo del perfil con el que
el usuario accede al sistema, validando su ingreso a través de su usuario y contraseña (ya sea
Gerente general, Supervisor de citas o Recepcionista). Por lo tanto, no puede haber filtro de
información de un usuario a otro ya que cualquier acción realizada por uno de estos será
registrada en el sistema como un historial junto con los datos personales.
Los datos no pueden ser visualizados o manipulados desde el exterior ya que se usa un motor
de base de datos Mysql al cual solo se puede acceder si es que loguea el usuario registrado en
el sistema.
Documento de la Arquitectura de Software

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.
4.11.6 Estándares
Se usará 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 sistema arquitectónico se ha escogido una arquitectura de tres capas (presentación,
aplicación y persistencia). La utilización de esta arquitectura se debe a que los distintos
niveles son independientes unos de otros de manera que, por ejemplo, se puede cambiar
fácilmente el comportamiento de las clases en el nivel de aplicación sin que ello influya en
las otras capas.

Esquema básico de la arquitectura de tres capas.


Documento de la Arquitectura de Software

 Capa de presentación
La capa de presentación es un conjunto de componentes software que implementan 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 y controlar los datos y los servicios de
los objetos. A partir de la interfaz gráfica, el usuario podrá interactuar con las distintas
ventanas de la aplicación para poder obtener toda la información que desee.
 Capa de 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, especificadas en la fase de modelado
conceptual. Es en este nivel donde 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 a la base de datos directamente, sino que se comunica con la capa de
aplicación para demandarle el servicio deseado y es la capa de aplicación la que 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.

5.2 Arquitectura lógica de la aplicación


5.2.1 Visión general
Documento de la Arquitectura de Software
Documento de la Arquitectura de Software

5.2.2 Identificando las Interfaces entre capas


Documento de la Arquitectura de Software

5.3 Identificación de las clases del diseño

: Interfaz Menú : Interfaz Mantener información del : Interfaz Añadir : Interfaz Ventana : Gestor Añadir : Ubicación del : Diseño de
: Jefe de
Principal catálogo de diseño de productos Diseño Explorador Diseño diseño Producto
Producción
Selecciona "Atención al cliente"

Muestra opciones

Pulsa "Mantener información del


Jefe de
catálogo de diseño de productos"
Producción

LlamarInterfaz()

Muestra Interfaz " Mantener Información del catálogo diseño de Productos"

IU_Añadir diseño al catálogo IU_VentanaE xplorador C_Añadir diseño al


catálogo E_Ubicación del diseño E_Diseño de Producto

Interfaz Menú Principal


Pulsa "Añadir" Interfaz Añadir Diseño Interfaz Ventana Explorador Gestor Añadir Diseño Ubicación del diseño Diseño de Producto

LlamarInterfazAñadirDiseño()
Interfaz Mantener información del
catálogo de diseño de productos

Muestra Interfaz "Añadir Diseño"

Pulsa "Buscar"

LlamarInterfazVentanaExplorador()

Muestra Interfaz "Ventana Explorador"

Selecciona Ubicación de diseño

Pulsa "Abrir"

SolicitarDirecciónArchivo()

ObtenerDireccionArchivo(string URL)

VerificarSiEsImagen(string URL)

Muestra imagen en vista previa

Pulsa "Guardar"

SolicitarGuardarDiseñoProducto()

GeneraCódigo(int CodDiseño)

GuardarDiseñoProducto(int CodDiseño, string URL)

MostrarMensajeDeConfirmación()

5.3.1 Diagramas de secuencias del paquete Atención al cliente


 CUS-01: Mantener información de catálogo de diseño de productos

 Primer escenario: Añadir diseño al catalogo


Documento de la Arquitectura de Software

 Segundo escenario: Modificar diseño del catalogo

Jefe de
Producción

IU_Modificar diseño del catálogo IU_VentanaExplorador C_Modificar diseño del E_Ubicación del diseño E_Diseño de Producto
catálogo

Interfaz Menú Principal Interfaz Modificar Diseño Interfaz Ventana Explorador Gestor Modificar Diseño Ubicación del diseño Diseño de Producto

Interfaz Mantener información del catálogo


de diseño de productos

: Interfaz Menú : Interfaz Mantener información del : Interfaz Modificar : Interfaz Ventana : Gestor Modificar : Ubicación del : Diseño de
: Jefe de Principal catálogo de diseño de productos Diseño Explorador Diseño diseño Producto
Producción

Selecciona "Atención al cliente"

Muestra opciones

Pulsa "Mantener información de


catálogo de diseño de Productos"

LlamarInterfaz()

Muestra interfaz "Mantener Información del Catálogo de productos"

Pulsa "Modificar"

LlamarInterfazModificarDiseño()

Muestra interfaz "Modificar Diseño"

Ingresa código de diseño de producto

Pulsa "Buscar"

VerificarCódigoIngresado(int CodDiseño)

BuscarCódigoDiseño(int CodDiseño)

Código encontrado

ObtenerDirecciónArchivo(string URL)

Dirección de archivo

Mostrar imagen en vista previa

Pulsa "Buscar" en el campo Nuevo Diseño

LlamarInterfazVentanaExplorador()

Muestra interfaz "Ventana Explorador"

Selecciona Ubicación de nuevo diseño

Pulsa "Abrir"

SolicitarDirecciónArchivo()

ObtenerDirecciónArchivo(string URL)

Dirección de archivo

VerificarSiEsImagen(string URL)

Mostrar imagen en vista previa

Pulsa "Modificar"

SolicitarGuardarDiseñoProducto()

GuardarDiseñoProducto(int CodDiseño, string URL)

MostrarMensajeDeConfirmación()
Documento de la Arquitectura de Software

 Tercer escenario: Eliminar diseño del catalogo

C_Eliminar diseño del E_Diseño de Producto


IU_Eliminar dis eño del catálogo
catálogo

Interfaz Menú Principal Interfaz Eliminar Diseño Gestor E liminar Diseño Diseño de Producto

Interfaz Mantener información del catálogo


de diseño de productos

Jefe de
Producc ión

: Interfaz Menú : Interfaz Mantener información del : Interfaz : Gestor : Diseño de


: Jefe de Principal catálogo de diseño de productos Eliminar Diseño Eliminar Diseño Producto
Producción

Selecciona "Atención al cliente"

Muestra opciones

Pulsa "Mantener información del


catálogo de diseño de productos"

LlamarInterfaz()

Mostrar interfaz "Mantener información de catálogo de diseño de productos"

Pulsa "Eliminar"

LlamarInterfazEliminarDiseño()

Muestra interfaz "Eliminar Diseño"

Ingresa código de diseño de producto

Pulsa "Buscar"

VerificarCódigoIngresado(int CodDiseño)

BuscarCódigoDiseño(int CodDiseño)

Código encontrado

ObtenerDirecciónArchivo(string URL)

Dirección de archivo

Mostrar imagen en vista previa

Pulsa "Eliminar"

SolicitarDirecciónArchivo()

ObtienerDirecciónArchivo(string URL)

Muestra imagen en vista previa

SolicitarEliminarDiseño()

EliminarDiseño(int CodDiseño)

MostrarMensajeDeConfimación()

Pulsa "Aceptar"
Documento de la Arquitectura de Software

CUS-02: Seleccionar diseño del catálogo de productos.

Jefe de
Producción

IU_Seleccionar diseño del catálogo E_Diseño de Product o


C_Seleccionar diseño de catálogo E_Producto

Interfaz Registrar Producto Interfaz Seleccionar Gestor Seleccionar diseño del catálogo Diseño de Producto Product o
diseño del catálogo

: Interfaz Registrar : Interfaz Seleccionar : Gestor Seleccionar diseño : Diseño de : Producto


: Jefe de Producto diseño del catálogo del catálogo Producto
Producción
Pulsa "Seleccionar Diseño"

LlamarInterfaz()

Muestra interfaz "Seleccionar diseño del catalogo de productos"

Selecciona diseño de producto

SolicitarDirecciónArchivo()

ObtenerDirecciónArchivo(string URL)

Pulsa "Guardar"

SolicitarGuardarDiseñoProducto()

GuardarDiseñoProducto(int CodDiseño, string URL)

 CUS-03: Registrar producto.

IU_RegistrarProducto E_DiseñoDeProducto E_Producto


C_RegistrarProducto

InterfazRegistrarCotizacion InterfazRegistrarProducto GestorRegistrarProducto DiseñoDeProducto Producto


(from ClasesDeDiseño) (from ClasesDeDiseño) (from ClasesDeDiseño) (from ClasesDeDiseño) (from ClasesDeDiseño)
Documento de la Arquitectura de Software

: InterfazRegistrarCotizacion : InterfazRegistrarProducto : GestorRegistrarProducto : DiseñoDeProducto : Producto

: Jefe de
Producción

1: Pulsa "Registrar producto"

2: LlamarInterfazRegistrarProducto()

3: Mostrar Interfaz "Registrar producto"

4: Ingresa datos solicitados

5: Pulsa "Seleccionar diseño"

6: SeleccionarDiseñoDelCatalogo()

7: ObtenerDatosDeDiseño()

8: Retornar codigo y vista previa

9: Mostrar codigo y vista previa

10: Pulsa "Registrar"

11: VerificarCamposVacios()

12: GenerarCodigo()

13: AgregarNuevoProducto(int cod, String nombre, String material, String acabado, String desc)

14: MostrarMensajeDeConfirmacion()

 CUS-04: Mantener información de la Cotización.

 Primer escenario: Añadir cotización

IU_AñadirCotizacion C_AñadirCotizacion E_Cotizacion E_Cliente E_Producto

Cotizacion Producto
Interfaz Menu principal Interfaz añadir cotizacion

Interfaz Mantener informacion de la cotizacion Gestor Añadir cotizacion Cliente


Documento de la Arquitectura de Software

Interfaz Menu Interfaz Mantener Interfaz Añadir Gestor añadir Cliente Cotizacion Producto
: Jefe de Produccion
principal informacion de la cotizacion cotizacion cotizacion
Selecciona "Atencion al Cliente"

Muestra opciones

Pulsa "Mantener informacion de la cotizacion"

LlamarInterfarMantenerCotizacion()

Muestra interfaz "Mantener informacion de la cotizacion"

Pulsa "Agregar"

Llam arInterfazAñadirCotizacion()

Muestra interfaz "Añadir cotizacion"

Ingresar datos de cotizacion

Ingresar datos del cliente

Pulsa "Registrar producto"

RegistrarProducto()

RegistrarDatosProducto()

Entregar datos de productos

ObtenerCodigoNombreProducto(int: CodProducto)

Entregar codigo y nombre de productos regis trados

Mostrar datos de productos registrados

Continuar ingres ando datos cotizacion

Pulsa "Guardar"

VerificarCampos NoVacios()

VerificarExistenciaCodigoCotizcion(int: NumCotizacion)

Bus carNumeroCotizacion(int: CodCotizacion)

Confirmar existencia cotizacion

GuardarCambios()

GuardarDatos Cotizacion()

GuardarDatosCliente()

Mostrar mens aje exitoso


Documento de la Arquitectura de Software

 Segundo escenario: Modificar Cotización

IU_ModificarCotizacion
C_ModificarCotizacion E_Cotizacion E_Cliente E_Producto

Cotizacion Producto
Interfaz Menu principal Interfaz Modificar cotizacion

Gestor Modificar cotizacion Cliente


Interfaz Mantener informacion de la cotizacion

Interfaz Menu Interfaz Mantener Interfaz Modificar Gestor Modificar Cliente Cotizacion Producto
: Jefe de Produccion principal informacion de la cotizacion cotizacion cotizacion
Selecciona "Atencion al cliente"

Muestra opciones

Pulsa "Mantener informacion de la cotizacion"

LlamarInterfazMantenerCotizacion()

Muestra interfaz "Mantener informacion de la cotizacion"

Pulsa "Modificar"

LlamarInterfazModificarCotizacion()

Muestra interfaz "Modificar cotizacion"

Ingresar "Numero de cotizacion"

Pulsa "Buscar"

VerificarExistenciaCotizacion(int: NumCotizacion)

BuscarNumeroCotizacion(int: NumCotizacion)

Confirmar existencia cotizacion

ObtenerDatosCotizacion(int: NumCotizacion)

Entregar datos cotizacion

ObtenerDatosCliente(int: id_cliente)

Entregar datos del cliente

ObtenerCodigoNombreProducto(int: CodProducto)

Entregar codigo y nombre de productos registrados

Mostrar datos obtenidos

Modificar datos

Pulsa "Guardar"

GuardarCambios()

GuardarCambiosCliente()

GuardarCambiosCotizacion()

GuardarCambiosProductos()
Documento de la Arquitectura de Software

 Tercer escenario: Eliminar Cotización

IU_EliminarCotizacion E_Cliente E_Cotizacion E_Producto


C_EliminarCotizacion

Cliente Producto
Interfaz Menu principal Interfaz Eliminar cotizacion

Interfaz Mantener informacion de la cotizacion Gestor Eliminar cotizacion Cotizacion

Interfaz Menu Interfaz Mantener informacion de Interfaz Eliminar Gestor Eliminar Cliente Cotizacion Producto
: Jefe de Produccion principal la cotizacion cotizacion cotizacion
Selecciona "Atencion al cliente"

Muestra opciones

Pulsa "Mantener informacion de la cotizacion"

LlamarInterfazMantenerCotizacion()

Pulsa "Eliminar"

LlamarInterfazEliminarCotizacion()

Muestra interfaz "Elim inar cotizacion"

Ingresar "Numero de cotizacion"

Pulsa "Buscar"

VerificarExistenciaCotizacion()

BuscarNumeroCotizacion(int: NumCotizacion)

Confirm ar existencia de cotizacion

ObtenerDatosCotizacion(int: NumCotizacion)

Entregar datos de cotizacion

ObtenerDatosCliente(int: CodCliente)

Entregar datos del cliente

ObtenerCodigoNombreProducto(int: CodProductos)

Entregar codigo y nombre de productos registrados

Mostrar datos obtenidos

Pulsa "Eliminar"

ConfirmarEliminarCotizacion()

Mostrar mensaje de confirmacion

Pulsa "Si"

EliminarCotizacion()

EliminarDatosCotizacion(int: NumCotizacion)

EliminarDatosCliente(int: id_cliente)

EliminarDatosProductos(int: CodProductos)
Documento de la Arquitectura de Software

 CUS-05: Registrar Pedido.

E_Pedido
IU:RegistrarPedido C_RegistrarPedido E_Cotizacion

InterfazMenuPrincipal InterfazRegistrarPedido GestorRegistrarPedido Cotizacion Pedido

: JefeDeProduccion InterfazMenuPrincipal : InterfazRegistrarPedido : GestorRegistrarPedido : Cotizacion : Pedido

Selecciona "Atencion al cliente"

Muestra opciones del MenuAtencionClientes

Pulsa "Registrar Pedido"

llamar interfaz()

MuestraInterfazRegistrarPedido

Ingresanumero de cotizacion

Pulsa "Buscar"

verificarNumerodeCotizacion(int numcot)

BuscarNumerodeCotizacion(int numcot)

ObtenerDatosCotizacion(int numcot)

Devulve datos de cotizacion

MostrarDatosCotizacion

Pulsa "Guardar"

SolicitarGuardarPedido()

GuardarPedido(Pedido pedido)

MostrarMensaje()
Documento de la Arquitectura de Software

5.3.2 Diagrama de subsistemas


Documento de la Arquitectura de Software

5.3.3 Agrupación de las clases de diseño en Subsistema del paquete Atención al cliente
 Subsistema Servicio al cliente
Clases:
 Interfaz Menú principal
 Interfaz Mantener información de la cotización
 Interfaz Añadir cotización
 Interfaz Modificar cotización
 Interfaz Eliminar cotización
 Interfaz Registrar Pedido
 Gestor Añadir cotización
 Gestor Modificar cotización
 Gestor Eliminar cotización
 Gestor Registrar Pedido
 Cotización
 Cliente
 Producto
 Pedido
 Subsistema Gestión de producto
Clases:
 Interfaz Menú principal
 Interfaz Registrar Cotización
 Interfaz Mantener información del catálogo de diseño de producto
 Interfaz Seleccionar diseño del catalogo
 Interfaz Registrar producto
 Interfaz Añadir Diseño
 Interfaz Modificar diseño
 Interfaz Eliminar diseño
 Interfaz Ventana Explorador
 Gestor Añadir Diseño
 Gestor Modificar Diseño
 Gestor Eliminar Diseño
 Gestor Seleccionar diseño del catalogo
 Gestor Registrar producto
Documento de la Arquitectura de Software

 Ubicación del diseño


 Diseño de producto
 Producto

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 Mantener información de la cotización


RESPONSABILIDADES COLABORACIONES

Hace una llamada a la Interfaz mantener Clase: Interfaz menú principal


información de la cotización

Clase: Interfaz Añadir cotización


RESPONSABILIDADES COLABORACIONES

Llamar interfaz añadir cotización Clase: Interfaz mantener información de la


cotización.

Clase: Interfaz Modificar cotización


RESPONSABILIDADES COLABORACIONES

Llamar interfaz eliminar cotización Clase: Interfaz mantener información de la


cotización.

Clase: Interfaz Eliminar cotización


RESPONSABILIDADES COLABORACIONES

Llamar interfaz eliminar cotización Clase: Interfaz mantener información de la


cotización.

Clase: Interfaz Registrar Pedido


RESPONSABILIDADES COLABORACIONES
Documento de la Arquitectura de Software

Hace una llamada al Interfaz Registrar Clase :Interfaz Menú Principal


pedido

Clase: Gestor Añadir cotización


RESPONSABILIDADES COLABORACIONES

Registrar producto Clase: Interfaz añadir cotización

Verificar campos no vacíos Clase: Interfaz añadir cotización

Verificar existencia de Cotización Clase: Interfaz añadir cotización.

Guardar los cambios Clase: Interfaz añadir cotización.

Clase: Gestor Modificar cotización


RESPONSABILIDADES COLABORACIONES

Verificar existencia de la cotización

Guardar los cambios Clase: Interfaz modificar cotización.

Clase: Gestor Eliminar cotización


RESPONSABILIDADES COLABORACIONES

Verificar número de la cotización Clase: Interfaz eliminar cotización.

Confirmar eliminar de la cotización Clase: Interfaz eliminar cotización.

Eliminar la cotización Clase: Interfaz eliminar cotización.

Clase : Gestor Registrar Pedido


RESPONSABILIDADES COLABORACIONES
Documento de la Arquitectura de Software

Verificar Numero de cotización Clase :Interfaz Registrar Pedido

Solicitar Guardar Pedido Clase: Interfaz Registrar Pedido

Clase: Cotización
RESPONSABILIDADES COLABORACIONES

Buscar número de la cotización Clase: Gestor modificar cotización, Gestor


registrar pedido.

Obtener datos de la cotización Clase: Gestor modificar cotización, Gestor


registrar pedido.

Eliminar datos de la cotización Clase: Gestor eliminar cotización.

Guardar cambios de la cotización Clase: Gestor modificar cotización.

Guardar datos de la cotización Clase: Gestor añadir cotización.

Clase: Cliente
RESPONSABILIDADES COLABORACIONES

Guardar datos del cliente Clase: Gestor añadir cotización.

Obtener datos del cliente Clase: Gestor modificar cotización, Gestor


eliminar cotización.

Guardar cambios del cliente Clase: Gestor modificar cotización.

Eliminar datos del cliente Clase: Gestor eliminar cotización.

Clase : Producto

RESPONSABILIDADES COLABORACIONES

Registra los datos de un producto Clase: Gestor Añadir cotización


Documento de la Arquitectura de Software

Obtener el código y el nombre de un Clase: Gestor Modificar cotización


determinado producto
Clase: Gestor Eliminar cotización

Eliminar el registro de un producto Clase: Gestor Eliminar cotización

Agregar un nuevo registro de producto Clase: Gestor Registrar producto

Guardar el diseño de un producto Clase: Gestor Seleccionar Diseño del


catálogo

Clase: Pedido
RESPONSABILIDADES COLABORACIONES

Buscar Numero del pedido Clase :Gestor registrar tareas


Clase : Gestor Tareas Asignadas a operario

Guardar información del Pedido Clase :Gestor Registrar Pedido


Documento de la Arquitectura de Software

5.3.3.1.2 Diagrama de clases del diseño

Interfaz Menu Principal

InterfazMantener Informacion de la Cotizacion Interfaz EliminarCotizacion

LlamarInterfazMantenerCotizacion() LlamarInterfazEliminarCotizacion()
...

Interfaz Añadir Cotizacion Interfaz Modificar Cotizacion

LlamarInterfazAñadirCotirzacion()
... LlamarInterfazModificarCotizacion()
...

Interfaz Registrar Pedido

LlamarInterfazRegistrarPedido()
...

Gestor RegistrarPedido Gestor Modificar Cotizacion

VerificarNumeroCotizacion(Numcot : Integer)
... VerificarExistenciaCotizacion(NumCotizacion : Integer)
...
SolicitarGuardarPedido() GuardarCambios()

Gestor Añadir Cotizacion


Gestor Eliminar Cotizacion

RegistrarProducto()
VerificarExistenciaCotizacion()
...
VerificarCamposVacios(NumCotizacion : Integer)
...
ConfirmarEliminarCotizacion()
VerificarExistenciaCodigoCotizacion()
EliminarCotizacion()
GuardarCambios()

Producto
Codigo : Integer
Nombre : String
Material : String
TipoAcabado : String
Descripcion : String
PrecioUnitario : Double
Cantidad : Integer

RegistrarProducto()
ObtenerNombreCodigoProducto(CodProducto : Integer)
elimiarDatosProducto(CodProducto : Integer)
AgregarNuevoProducto(prod : Producto)
GuardarDiseñoProduto(CodDiseño : Integer, URL : String)
1..*
Incluye

1
Cotizacion
NumCotizacion : Integer
CodProducto : Integer
NomProducto : String Cliente
Cantidad : Integer
CodCliente : Integer
FechaMaxValidez : Date
NomClient : String
FechaEntrega : Date
Solicita Direccion : String
TipoEntrega : String
Telefono : String
CotaInicial : Double
PrecioUnitario : Double 0..* 1
ObtenerDatosCliente(idCliente : Integer)
...
PrecioTotal : Double
GuardarCambiosCliente()
EliminarDatosCliente(IdCliente : Integer)
...
BuscarNumeroCotizacion(CodCotizacion : Integer)
...
GuardarDatosCliente()
GuardarDatosCotizacion()
ObtenerDatosCotizacion()
GuardarCambiosCotizacion()
EliminarDatosCotizacion(NumCotizacion : Integer)
...

Pedido
Estado : String

GuardarPedido(Pedido : Pedido)
BuscarNumeroPedido(NumPedido : Integer)

5.3.3.2 Diagrama de clases de diseño del subsistema Gestión de productos

5.3.3.2.1 Asignación de Operaciones


Documento de la Arquitectura de Software

Clase: Interfaz Mantener información del catálogo de diseño de productos


RESPONSABILIDADES COLABORACIONES

Hace una llamada a la interfaz Mantener Clase: Interfaz Menú Principal


información del catálogo de diseño de
productos

Clase: Interfaz Seleccionar Diseño del catálogo


RESPONSABILIDADES COLABORACIONES

Hace una llamada a la interfaz Clase: Interfaz Registrar Producto


Seleccionar Diseño del catálogo

Clase: Interfaz Registrar producto

RESPONSABILIDADES COLABORACIONES

Hace una llamada a la interfaz “Registrar Clase: Interfaz Registrar Cotización


producto”

Clase: Interfaz Añadir Diseño


RESPONSABILIDADES COLABORACIONES

Hace una llamada a la interfaz Añadir Clase: Interfaz Mantener información del
Diseño catálogo de diseño de productos

Mostrar mensaje de confirmación Clase: Gestor Añadir Diseño


Documento de la Arquitectura de Software

Clase: Interfaz Modificar Diseño


RESPONSABILIDADES COLABORACIONES

Hace una llamada a la interfaz Modificar Clase: Interfaz Mantener información del
Diseño catálogo de diseño de productos

Mostrar mensaje de confirmación Clase: Gestor Modificar Diseño

Clase: Interfaz Eliminar Diseño


RESPONSABILIDADES COLABORACIONES

Hace una llamada a la interfaz Eliminar Clase: Interfaz Mantener información del
Diseño catálogo de diseño de productos

Mostrar mensaje de confirmación Clase: Gestor Eliminar Diseño

Clase: Interfaz Ventana Explorador


RESPONSABILIDADES COLABORACIONES

Hace una llamada a la interfaz Ventana Clase: Interfaz Añadir Diseño


Explorador Clase: Interfaz Modificar Diseño

Clase: Gestor Añadir Diseño


RESPONSABILIDADES COLABORACIONES

Solicitar Dirección Archivo Clase: Interfaz Ventana Explorador

Verificar Si Es Imagen Clase: Ubicación de diseño

Solicitar Guardar Diseño Producto Clase: Interfaz Añadir Diseño

Generar Código Clase: Gestor Añadir Diseño


Documento de la Arquitectura de Software

Clase: Gestor Modificar Diseño


RESPONSABILIDADES COLABORACIONES

Verificar Código Ingresado Clase: Interfaz Modificar Diseño

Solicitar Dirección Archivo Clase: Interfaz Ventana Explorador

Verificar Si Es Imagen Clase: Ubicación de diseño

Solicitar Guardar Diseño Producto Clase: Interfaz Modificar diseño

Clase: Gestor Eliminar Diseño


RESPONSABILIDADES COLABORACIONES

Verificar Código Ingresado Clase: Interfaz Eliminar Diseño

Solicitar Dirección Archivo Clase: Interfaz Eliminar Diseño

Solicitar Eliminar Diseño Clase: Interfaz Eliminar Diseño

Clase: Gestor Seleccionar Diseño del Catálogo


RESPONSABILIDADES COLABORACIONES

Solicitar Dirección Archivo Clase: Interfaz Seleccionar diseño de catálogo

Solicitar Guardar Diseño de Producto Clase: Interfaz Seleccionar diseño de catálogo

Clase : Gestor Registrar producto

RESPONSABILIDADES COLABORACIONES

Seleccionar algún diseño del catálogo Clase: Interfaz Registrar producto

Verificar que los campos no estén vacíos Clase: Interfaz Registrar producto

Agregar un nuevo registro de producto Clase: Gestor Registrar producto

Generar un código a un producto recién Clase: Gestor Registrar producto


registrado

Clase: Ubicación de Diseño


RESPONSABILIDADES COLABORACIONES
Documento de la Arquitectura de Software

Obtener Dirección Archivo Clase: Gestor Añadir Diseño


Clase: Gestor Modificar Diseño

Clase: Diseño de Producto


RESPONSABILIDADES COLABORACIONES

Guardar Diseño de Producto Clase: Gestor Añadir Diseño


Clase: Gestor Modificar Diseño

Buscar Código de diseño Clase: Gestor Modificar Diseño


Clase: Gestor Eliminar Diseño

Obtener Dirección Archivo Clase: Gestor Modificar Diseño


Clase: Gestor Eliminar Diseño

Eliminar Diseño Clase: Gestor Eliminar Diseño

Obtener Datos De Diseño Clase: Gestor Registrar Producto

Clase : Producto

RESPONSABILIDADES COLABORACIONES

Registra los datos de un producto Clase: Gestor Añadir cotización

Obtener el código y el nombre de un Clase: Gestor Modificar cotización


determinado producto
Clase: Gestor Eliminar cotización

Eliminar el registro de un producto Clase: Gestor Eliminar cotización

Agregar un nuevo registro de producto Clase: Gestor Registrar producto

Guardar el diseño de un producto Clase: Gestor Seleccionar Diseño del catálogo


Documento de la Arquitectura de Software

5.3.3.2.2 Diagrama de clases del diseño


Interfaz Menu Principal

Interfaz Mantener Informacion del Catalogo de diseños de productos Interfaz Seleccionar Diseño del Catalogo Interfaz Registrar Producto

LlamarInterazCatalogodeDiseñosDeProductos() LlamarInterfazDiseñoCatalogo() LlamarInterfazRegistrarProducto()

Interfaz Modificar Diseño Interfaz Añadir Diseño Interfaz Eliminar Diseño

LlamarInterfazModificarDiseño() LlamarInterfazAñadirDiseño()
... LlamarInterfazEliminarDiseño()

GestorModificarDiseño Gestor Añadir Diseño


GestorEliminarDiseño

VerificarCodigoIngresado(Coddiseño : Integer) SolicitarDireccionArchivo()


VerificarCodigoIngreso(CodDiseño : Integer)
SolicitaDireccionArchivo() VerificarSiEsImagen(URL : String)
SolicitarDireccion()
VerificarSiesiImagen(URL : String) SolicitarGuardarDiseñoProducto()
SolicitarEliminarDiseño()
SolicitarGuardarDiseñoProducto() GenerarCodigo(CodDiseño : Integer)

Gestor Seleccionar Diseño del Catalogo Gestor Registrar Producto

SolicitarDireccionArchivo() SeleccionarDiseñoCatalogo()
SolicitarGuardarDiseñoProducto() VerificarCamposVacios()
GenerarCodigodeProducto()

Producto
Codigo : Integer
Nombre : String Diseño de Producto
Material : String CodDiseño : Integer
TipoAcabado : String URL : String
Descripcion : String CodProducto : Integer
PrecioUnitario : Double
Cantidad : Integer GuardarDiseñoProducto(CodDiseño : Integer, URL : String)
...
1..* 1
BuscarCodigoDiseño(CodDiseño : Integer)
RegistrarProducto() ObtenerDireccionArchivo(URL : String)
ObtenerNombreCodigoProducto(CodProducto : Integer) EliminarDiseño(CodDiseño : Integer) : Int
elimiarDatosProducto(CodProducto : Integer) ObtenerDatosDelDiseño()
AgregarNuevoProducto(prod : Producto)
GuardarDiseñoProduto(CodDiseño : Integer, URL : String)

le corresponde

Ubicacion de diseño
URL : String

ObtenerDireccionArchivo(URL : String)
...
Documento de la Arquitectura de Software

6. Vista de despliegue

1. Capa de Presentación 2. Capa de Negocio 3. Capa de Datos


6.1 Se
rvidor de base de datos
 Características

PC Servidor de Base
de Datos
LAN Switch LAN
Documento de la Arquitectura de Software

 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 Switch
 Características
 Como mínimo 5 puertos
 Ancho de banda por ranura: 48 Gbps
 Terminación inalámbrica máxima: 20 Gb
Documento de la Arquitectura de Software

6.3 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.4 Switch
 Características
 Como mínimo 5 puertos
 Ancho de banda por ranura: 48 Gbps
 Terminación inalámbrica máxima: 20 Gb
6.5 Computadoras
 Características
 Intel Core i3
 Memoria Ram 512 MB
 Hd 100gb
 Sistema operativo: Windows XP/7/8

 Tipos:

- PC Jefe de producción
Computadora que será utilizada por cada uno de los usuarios de la empresa, en
este caso, el jefe de producción, para acceder al sistema. Está conectada
directamente al servidor principal vía LAN.
- PC Supervisor de tareas
Computadora que será utilizada por cada uno de los usuarios de la empresa, en
este caso, el supervisor de tareas, para acceder al sistema. Está conectada
directamente al servidor principal vía LAN.
- PC Encargado de despacho
Computadora que será utilizada por cada uno de los usuarios de la empresa, en
este caso, encargado de despacho, para acceder al sistema. Está conectada
directamente al servidor principal vía LAN.
Documento de la Arquitectura de Software

7. Vista de implementación
7.1 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 separar en tres módulos Servicio al cliente (abarca cada una de las actividades
del paquete servicio al cliente), Gestión de producto (abarca cada una de las actividades del
paquete de Gestión de producto) y Gestión de tareas de operario (abarca cada una de las
actividades del paquete Gestión de tareas de operario).
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.

7.2 Diagrama de componentes


7.2.1 Actividad implementar un subsistema

<<implementation subsystem>>
<<design subsystem>> Servicio_al_Cliente
Servicio al cliente
<<trace 1:1>>

<<implementation subsystem>>
<<design subsystem>> Gestion_de_producto
Gestion de producto
<<trace 1:1>>

<<implementation subsystem>>
<<design subsystem>> Gestion_de_tareas_de_operarios
Gestion de tareas de operarios
<<trace 1:1>>
Documento de la Arquitectura de Software

 Subsistema de Implementación: Servicio al cliente


 Componente Cotización
- Interfaz Mantener información de la cotización
- Interfaz Añadir cotización
- Interfaz Modificar cotización
- Interfaz Eliminar cotización
- Cotización
 Componente Gestor Cotización
- Gestor Añadir cotización
- Gestor Modificar cotización
- Gestor Eliminar cotización
 Componente Pedido
- Interfaz Registrar Pedido
- Pedido
 Componente Gestor Pedido
- Gestor Registrar Pedido
 Componente Producto
- Producto
 Componente Cliente
- Cliente

<<implementation subsystem>>
Servicio al cliente

<<file>> GestorCotizacion.java GestorPedido.java


Cotizacion.java

<<file>> <<file>> <<file>>


Pedido.java Producto.java Cliente.java
Documento de la Arquitectura de Software

 Subsistema de Implementación: Gestión de producto


 Componente Producto
- Producto
- Interfaz Registrar producto
 Componente Diseño de producto
- Diseño de producto
- Interfaz Mantener información del catálogo de diseños de productos
- Interfaz Seleccionar diseño del catalogo
- Interfaz Añadir diseño
- Interfaz Modificar diseño
- Interfaz Eliminar diseño
 Componente Gestor diseño de producto
- Gestor Añadir diseño
- Gestor Modificar diseño
- Gestor Eliminar diseño
 Componente Ubicación de diseño
- Ubicación de diseño
- Interfaz Ventana explorador
 Componente Gestor Seleccionar diseño del catalogo
- Gestor Seleccionar diseño del catalogo
 Componente Gestor Registrar producto
- Gestor Registrar producto

<<implementation subsystem>>
Gestion_de_producto

<<file>> <<file>> GestorDiseñoProducto.java


Producto.java DiseñoProducto.java

<<file>> GestorSeleccionarD GestorRegistrarProducto


UbicacionDiseño.java iseñoCatalogo.java .java
Documento de la Arquitectura de Software

7.2.2 Diagrama general de componentes

IniciarSesion

<<implementation subsystem>> <<implementation subsystem>>


Gestion_de_tareas_de_operarios Servicio al cliente <<implementation subsystem>>
Gestion_de_producto

<<file>> <<file>> <<file>> <<file>> GestorCotizacion.ja GestorPedido.jav


Operario.jav AvanceDeTarea.ja Tarea.java Cliente.jav va a <<file>> <<file>> GestorDiseñoProducto
Producto.java DiseñoProducto.ja
a va a .java
va

GestorOperario.ja GestorTareas.jav
va a
<<file>> <<file>> GestorSeleccionar GestorRegistrarProduc
Cotizacion.ja <<file>> to.java
Pedido.java UbicacionDiseño DiseñoCatalog...
va .java

Conexion a BD

Base de Datos
Documento de la Arquitectura de Software

8. Vista de Datos
8.1 Modelo Relacional
Documento de la Arquitectura de Software

8.2 Tipo de Base de datos: Base de datos centralizado.

Base de datos

Cotizacion Producto Tareas Asignadas Avance de tareas Pedido

Ubicación de diseño 0perario Diseño de Producto Tarea Cliente

También podría gustarte