Revisado Disenio y Arquitectura Final

Universidad Privada del Norte
Facultad de Ingeniería
Modelado y Diseño de un sistema de

información para la mejora de la gestión de
compra y Atencion en la clínica veterinaria
DR. VISE
Curso: Diseño y Arquitectura de Software

Profesor: José Luis Cuya Cámara
Integrantes:
 Claudia López Mego
 Juan Carlos Romero Farfán
 André Arturo Berrospi Villanera
 Brayan Alejandro Delgado Aliaga
 Ángelo Silvestre Ayquipa
 Jean Carlos Sánchez Martínez
 Eyner Torres Yactapuri
 Renzo Torrejón Fernández
2019
Tabla de contenido
1. INTRODUCCIÓN 2
1.1 Propósito........................................................................................................
1.2 Alcance...........................................................................................................
1.3 Definiciones, Acrónimos y Abreviaciones...........................................................
2. POSICIONAMIENTO 2
2.1 Oportunidad de Negocio..................................................................................
2.2 Objetivos........................................................................................................
2.3 Misión.............................................................................................................
2.4 Visión.............................................................................................................
2.5 Declaración de problema.................................................................................
2.6 Declaración de posición de producto.................................................................
3. LA SOLUCIÓN 4
3.1 Características Principales de la solución...........................................................
3.2 Restricciones...................................................................................................
3.3 Rasgos de calidad...........................................................................................
3.4 Precedencia y Prioridad...................................................................................
4. ANALISIS FUNCIONAL 6
4.1 MODELO DE CASO DE USO DE NEGOCIO.........................................................
4.3 MODELO DE CASO DE USO DE NEGOCIO.........................................................
4.4 MODELO DE ANALISIS DE NEGOCIO................................................................
4.5 MODELO DE CASO DE USO DE SISTEMA........................................................
5. MODELO DE BASE DE DATOS 14
MCVS-O1-102 Visión del Negocio
1. INTRODUCCIÓN
El propósito de este documento es recoger, analizar y definir las necesidades

de alto nivel y las características del sistema de gestión de una veterinaria,
tanto en la compra de productos como en los servicios brindados por la misma,
con el fin de identificar sus problemas relacionados con la información y sus
procesos de negocios.
El alcance de este documento se enfoca al proceso relacionado a la gestión de

compra, así como también la gestión de servicios brindados. Este proyecto no
contemplará la gestión de personal.
El sistema permitirá al encargado de la veterinaria Dr. Vise tener un mejor

control de las compras de productos para las mascotas, así como también las
órdenes de compra emitidas y así optimizar el manejo de información.
Por otro lado, el sistema permitirá registrar a los clientes para que sus
mascotas puedan servirse de los servicios de baño, ecografías, grooming y
campañas de vacuna.
1.3 Definiciones, Acrónimos y Abreviaciones

 Operador: Persona que utilizara el sistema.
 ERS: Especificación de requisitos software.
 RQF: Requerimientos funcionales.
 RQNF: Requerimiento no funcionales.
 Operaciones: Conjunto de transacciones que permiten llevar el control de los
eventos que suceden dentro del sistema.
 RUP: Son las siglas de Rational Unified Process. Metodología para describir el
proceso de desarrollo de software.
2. POSICIONAMIENTO
2.1.1 OPORTUNIDAD DE NEGOCIO
El sistema permitirá a la veterinaria Dr. Vise automatizar el proceso de gestión

de compra y servicios más eficiente, lo cual presentará un acceso rápido y
sencillo a los datos, gracias a interfaces gráficas, sencillas y amigable. También
podrá agilizar los procesos dado que existe un adecuado registro de productos
y su respectivo proveedor, además presentara datos actualizados y ordenados
de los servicios a los que son sometidos las mascotas, lo cual es un factor muy
importante para llevar un mejor control de la gestión compra y servicios de la
veterinaria Dr. Vise.
Fecha de Actualización: 07/04/2022 Versión: 1.0
Preparado por: Página : 2 de 121

 Automatizar los procesos de compra al 50%

 Ser reconocido a nivel distrital.
 Incrementar las ganancias en un 40% a diciembre 2019.
 Optimizar al 80% el control de los productos de las mascotas.
Ofrecer calidad en la atención que ofrecemos a nuestros pacientes,

satisfaciendo sus necesidades, además de la búsqueda de mejoras en el
tratamiento y prevención de la salud.
Ser un centro de Atención Médica Veterinaria que trascienda en la localidad y

sus fronteras por la calidad en los servicios que proporciona, con énfasis en
mascotas y proyección a otras especies, contando con equipos tecnológicos
modernos y con un equipo médico calificado.
2.5 Declaración de problema
Tabla1
Declaración de problema
El problema es La ineficiencia en los procesos de compra y servicios debido a

la falta de un sistema que permita una correcta gestión de los
procesos de la empresa y fallas en su modelo de negocio, tales
como lentitud en el proceso de atención al cliente y al
proveedor; falta de registro de documentación (clientes,
proveedores, ventas, compras, productos, cotizaciones,
facturas, etc.), redundancia y perdida de información; además
malestar institucional, debido a la exageración del uso de
papeles en sus proceso y registros manuales, todo ello provoca
cuellos de botellas en sus procesos.
Afecta a Usuarios, Proveedores, Personal Operador (Enfermera, Cajero),
Gerencia General, jefe de almacén, Médico Veterinario.
El impacto En los procesos manuales de compra, documentación, errores

asociado es de registro.
Una solución Automatizar los procesos manuales de la empresa mediante la
adecuada implementación de un sistema en la empresa Veterinaria Dr.
sería vise evitando la perdida de información y defraudación
tributaria.

2.6 Declaración de posición de producto
Tabla2
Declaración de posición de producto
Para Gerente General, Personal Operador.
Quienes Controlan los pedidos(proveedores), los almacenes (stock)
BICKY Es un Software de Gestión de Procesos de Compra y

Servicios.
Que Almacena y procesa la información necesaria para gestionar
los procesos compra y servicios tanto de pruebas médicas y
pruebas estéticos.
A diferencia El sistema manual actual.
de
Nuestro Permite gestionar las distintas actividades de la empresa
producto mediante una interfaz gráfica sencilla y amigable. Además,
proporciona un acceso rápido y actualizado a la información.

3. LA SOLUCIÓN
3.1 Características Principales de la solución

 Las fuentes de datos utilizadas por BICKY están sujetas constantemente
a revisiones por lo que los datos que ingresan al sistema son confiable y
seguros.
 BICKY será desarrollado utilizando la herramienta de Netbeans con el

entorno Java Web, lo que permitirá a los usuarios un fácil acceso y uso
a través de un browser.
 El sistema contará con un manejo vía Internet, permitiendo la seguridad

de los datos, estarán protegidos de manera que nadie pueda alterar los
contenidos de los mismos.
 Unos de los principales objetivos de BICKY es presentar de manera

oportuna la información concerniente al estado de la empresa como
reportes, información que se utiliza para la toma de decisiones.
3.2 Restricciones
 El sistema dependerá de una conexión a internet.
 El análisis efectuado para la realización del sistema abarca solo el Área

de Logística de la Empresa.
 El tiempo de desarrollo es limitado.
3.3 Rasgos de calidad

El desarrollo del Sistema BICKY se ajustará a la Metodología de Desarrollo de
Software RUP, contemplando los parámetros de calidad que la metodología
define.
3.4 Precedencia y Prioridad

 Carga de datos
 Verificación de Datos
 Cálculo de liquidaciones
 Emisión de Reportes
 Generación de pedidos
 Generación de ordenes
 Análisis de Productos

4. ANALISIS FUNCIONAL
4.1 MODELO DE CASO DE USO DE NEGOCIO
MATRIZ DE REQUERIMIENTOS
Proceso Actividades Responsable Automatizable? RF Requerimiento Funcional Caso de Uso Caso Uso Incluido Caso Uso extendido Actor
El Responsable de almacen revisa el stock actual de los productos Responsable de Almacen SI RF01 Permite consultar el stock disponible Consultar stock de Productos Responsable de Almacen
El Responsable de almacen elabora un orden de requerimientos Responsable de Almacen SI RF02 Permite el registro de la orden de requerimientos Registrar Orden de Requerimientos Responsable de Almacen
El Gerente evalua la orden de requerimientos Gerente NO

El Responsable de almacen envia la orden de requerimientos a los proveedores Responsable de Almacen NO
El Responsable de almacen recibe las proformas de los proveedores Responsable de Almacen NO
El Gerente evalua las proformas de los proveedores Gerente NO
El Responsable de almacen genera la orden de compra Responsable de Almacen SI RF03 Permite el registro de orden de compra Registrar Orden de Compra Responsable de Almacen
El Responsable de almacen envia la orden de compra al proveedor Responsable de Almacen NO

Gestion de compra
El Proveedor recibe la orden de compra Proveedor NO
El Proveedor procesa la orden de compra Proveedor NO
El Proveedor emite la factura de Orden de compra Proveedor NO
El Responsable de almacen recibe la factura de orden de compra Responsable de Almacen NO
El Responsable de almacen comunica al gerente la llegada de los productos Responsable de Almacen NO
El Responsable de almacen realiza el pago de la factura de orden de compra Responsable de Almacen NO
El Responsable de almacen registra la factura de orden de compra Responsable de Almacen SI RF04 Permite el registro de la factura de orden de compra Registrar Factura de Orden de Compra Responsable de Almacen
El Responsable de almacen registra los productos recibidos Responsable de Almacen SI RF05 Permite el registro de productos Registrar Producto Responsable de Almacen
El Cliente solicita atencion de Pruebas Medicas Cliente NO

El Medico solicita atencion Pruebas Medicas Medico NO
El Operador registra la atencion de prueba medica Operador SI RF06 Permite el registro de la atencion de prueba medica Registrar Atencion de Prueba Medica Operador
El Cajero busca la atencion de prueba medica a pagar Cajero SI RF07 Permite la consulta de la atencion solicitada por cliente Consultar Atencion de Prueba Medica Cajero
El Cliente efectúa el pago de la atencion de prueba medica Cliente NO

Gestion de
Atencion de El Cajero emite el comprobante de pago. Cajero SI RF08 Permite generar e imprimir comprobante de pago Emitir Comprobante de Pago Cajero
Pruebas Medicas
El Medico realiza la atencion de pruebas medicas Medico NO
El Medico genera un acta de resultados Medico NO
El Medico evalua el acta de resultados Medico NO
El Medico registra el acta de resultados Medico SI RF09 Permite registrar el acta de resultados Registrar Acta de Resultados Medico
El Medico entrega el acta de resultados al Cliente Medico NO

El Cliente solicita una atencion estetica Cliente NO
El Operador registra la atencion estetica Operador SI RF10 Permite el registro de la atencion estetica Registrar Atencion Estetico Operador
Gestión de El Cajero busca la atencion estetica a pagar Cajero SI RF11 Permite la consulta de la atencion solicitada por cliente Consultar Atencion Estetica Cajero
Atencion de
Estéticos El Cliente efectúa el pago de la atencion estetica Cliente NO
El Cajero emite el comprobante de pago. Cajero SI RF12 Permite generar e imprimir comprobante de pago Emitir Comprobante de Pago Cajero
La enfermera realiza la atencion estetica Enfermera NO
Figura 1 Matriz de Requerimientos.

4.2 MODELO DE CASO DE USO DE NEGOCIO
Figura 2 Modelo de caso de uso de negocio.
4.3.1 ACTORES DE NEGOCIO:
Figura 3 Actores de negocio.

4.3.2 OBJETIVOS DE NEGOCIO:
Figura 4 Objetivos de negocio.
4.3.3 CASO DE USO DE NEGOCIO VS OBJETIVOS DE NEGOCIO:
Figura 5 CUN vs ON.

4.3 MODELO DE ANALISIS DE NEGOCIO

4.4.1 REALIZACIONES DE NEGOCIO:
Figura 6 Realizaciones de negocio.

4.4.2 DIAGRAMA DE CLASES DE REALIZACION DE GESTION DE COMPRA:
Figura 7 Diagrama de clases de realización Gestión de Compra.
4.4.3 DIAGRAMA DE CLASES DE REALIZACION DE GESTION DE ATENCION DE

PRUEBAS MEDICAS:
Figura 8 Diagrama de clases de realización de Gestión de Atención de Pruebas Medicas.

4.4.4 DIAGRAMA DE CLASES DE REALIZACION DE GESTION DE ATENCION

ESTETICA:
Figura 9 Diagrama de clases de realización de Gestión de Atención Estética.

4.4.5 DIAGRAMA DE ACTIVIDADES DE GESTION DE COMPRA:
Figura 10 Diagrama de actividades de Gestión de Compra.

4.4.6 DIAGRAMA DE ACTIVIDADES DE GESTION DE ATENCION DE PRUEBAS MEDICAS:
Figura 11 Diagrama de actividades de Atención de Pruebas Médicas.

4.4.7 DIAGRAMA DE ACTIVIDADES DE GESTION DE ATENCION ESTETICA:
Figura 12 Diagrama de actividades de Gestión de Atención Estética.

4.4 MODELO DE CASO DE USO DE SISTEMA
4.5.1 ACTORES DE SISTEMA:
Figura 13 Actores de Sistema.

4.5.2 CASO DE USO DE SISTEMA DE GESTION DE COMPRA:
Figura 14 Caso de uso de sistema de gestión de compra.

4.5.3 CASO DE USO DE SISTEMA DE GESTION DE ATENCION DE PRUEBAS MEDICAS:
Figura 15 Caso de uso de sistema de gestión de atención de pruebas médicas.

4.5.4 CASO DE USO DE SISTEMA DE GESTION DE ATENCION ESTETICAS:
Figura 16 Caso de uso de sistema de gestión de atención estética

5. Modelo De Entidad Relación
Figura 17 Modelo de Base de Datos - Modelo Entidad Relación

6. Modelo De Base De Datos
Figura 18 Modelo de Base de Datos - Modelo Físico.

7. Especificación De Caso De Uso Sistema
7.1. Especificación De Caso De Uso: Registro De Orden De

Requerimientos
1. Descripción:
Este caso de uso permite registrar la orden de requerimientos de la clínica veterinaria
Doctor Vise, de acuerdo a este caso de uso podemos: registrar, modificar y eliminar
la orden de requerimientos dentro del sistema.
2. Actores:
Responsable de almacén
3. Flujo de Eventos:
3.1 Flujo básico:
a) El caso de uso inicia cuando el responsable de almacén seleccione la
opción de “Registrar Orden de Requerimientos” dentro de la interfaz
principal.
b) El sistema muestra una interfaz “Registrar Orden de
Requerimientos”, donde presentará los campos: código, cantidad y
fecha de emisión. Además, mostrará las opciones de Registrar,
Consultar stock del producto, aceptar y Salir.
c) El sistema captura los datos del Código de producto de la interfaz
Consultar Stock del producto.
d) El sistema muestra el código obtenido de la interfaz consultar stock en
el “Campo código”.
3.2 Subflujos:
3.2.1 Registrar OR
a) El sistema muestra la interfaz REGISTRO DE ORRDEN DE
REQUERIMIENTO con los siguientes campos: código (solo
lectura), fecha de emisión (solo lectura), Sede, Dirección de
Entrega. Además, muestra las opciones de Aceptar y
Cancelar.
b) El responsable de Almacén ingresa los datos del registro.
c) El responsable de Almacén selecciona la opción de Aceptar.
d) El sistema valida los datos ingresados.
e) El sistema genera un nuevo código de Registro y obtiene la
fecha del sistema para la fecha de emisión y la dirección de
entrega.
f) El sistema graba un nuevo registro de orden de requerimientos
y muestra el MSG “Se registro exitosamente la orden de
requerimientos”
g) El responsable de almacén cierra la interfaz REGISTRO DE
ORDEN DE REQUERIMIENTOS para su siguiente proceso y
el subflujo finaliza.
3.2.2 Modificar OR
a) El sistema muestra los datos del registro de OR en la interfaz
Registrar Orden de Requerimientos: código (solo lectura), fecha
de emisión (solo lectura), Sede, Dirección de Entrega. Además,

muestra las opciones de Aceptar y Cancelar.
b) El responsable de almacén modifica los datos del registro de
OR.
c) El responsable de almacén selecciona la opción Aceptar.
d) El sistema obtiene la fecha del sistema para la fecha de
actualización y de sus campos que se hayan modificado y
mostraran los datos actualizados en la tabla para el Registro de
Orden de Requerimientos.
3.2.3 Eliminar OR
a) El responsable le de almacén tendrá que escoger el campo
dentro del registro para su eliminación.
b) Tendrá que seleccionar la opción ELIMINAR en el sistema
para poder borrar los datos de la tabla que se hayan
seleccionado.
c) El sistema mostrara los datos actualizados que se hayan
eliminado de la tabla REGISTRO DE ORDEN DE
REQUERIMIENTOS.
3.3 Flujos Alternativos:
1. Datos de Registro Inválidos
Si los datos ingresados son nulos o inválidos, tanto en los Subflujos Registrar
como en Modificar Registro, el sistema no podrá registrar los datos que sean
nulos o vacíos
2. Orden de Requerimientos existentes
Si el sistema detecta que el registro ya existe un CODIGO igual el sistema no
podrá registrarlo.
3. No confirma la eliminación del registro
El responsable de almacén no elimina los datos el sistema si le da a cancelar y
mantendrá los datos correspondientes de la tabla y finaliza el subflujo.
4. Precondiciones
1.El responsable de almacén está identificado en el sistema.
5. Postcondiciones
1.El sistema quedara registrado la orden de requerimientos.
2.El sistema quedara modificado el registro de orden de requerimientos.
3.El sistema quedara eliminado del registro de orden de requerimientos.
6. Puntos de Extensión
1.Se le incluye de un caso de uso llamado CONSULTAR STOCK del producto.
7. Prototipo:
7.1. Subflujo REGISTRAR

Figura 19 Interfaz Registrar Orden de Requerimientos.

7.2 Subflujo MODIFICAR
Figura 20 Modificar Orden de Requerimientos.
7.2.1 Mensaje:

Figura 21 Mensaje "Registro Modificado".
7.3 Mostrar registro actualizado
Figura 22 Mostrar registro actualizado.

7.4 Subflujo ELIMINAR:
Figura 23 Eliminar orden de requerimientos.
7.4.1 Mensaje:
Figura 24 Mensaje "Eliminado exitosamente".
7.5 Mostrar tabla actualizada

Figura 25 Mostrar tabla actualizada.
7.6 Flujo Alternativo:

7.6.1 Mensaje: Datos nulos o Inválidos (subflujo registrar)
Figura 26 Mensaje "Datos no nulos o inválidos"
7.6.2 Mensaje: Datos Existentes (subflujo modificar)
Figura 27 Mensaje "Datos existentes"
7.6.3 Mensaje: Datos no Eliminados (subflujo eliminar)
Figura 28 Mensaje" Datos no Eliminados"

8. Diagrama de clases de análisis:
Figura 29 Diagrama de clase de Análisis

9. Diagrama de Comunicación:
9.1 Flujo Básico

9.1.1 Subflujo: Registrar
Figura 30 Subflujo: Registrar
9.1.2. Subflujo: Modificar

Figura 31 Subflujo: Modificar
9.1.3
Subflujo eliminar

9.2. Flujo Alternativo:

9.2.1 Datos Inválidos

Figura 33 Datos inválidos
9.2.2 Datos Existentes:

Figura 34 Datos Existentes
9.2.3 Datos no eliminados:

Figura 35 Datos no eliminados

7.2. ESPECIFICACION DE CASO DE USO: Registrar Factura de orden de
compra
1. Descripción:
El caso permite Registrar Factura de compra de la Veterinaria DR VISE. De acuerdo a
su necesidad su necesidad, el responsable de almacén de la Veterinaria DR VISE puede
agregar una factura en el sistema de información.
2. Actor(es):
Jefe de almacén.
3. Flujo de eventos
3.1. Flujo básico
1) El caso de uso se inicia cuando el jefe de almacén selecciona la opción de
Factura en la interfaz del menú principal.
2) El sistema muestra la interfaz “Registro de Facturas de orden de compra”, con la
lista de facturas, con los campos Numero de factura, fecha de emisión, total a pagar.
Además, muestra la opción de Agregar Nueva Factura, Consultar Orden de
compra.
3) Si el jefe de almacén elige una factura
a) Si elige “Consultar” ver subflujo consultar orden de compra.
b) Si elige “Agregar” ver subflujo Agregar Nueva Factura.
4)Si el jefe de almacén no elige una factura
a) Si elige Agregar ver subflujo Agregar Nueva Factura.
b) Si elige Consultar ver subflujo consultar orden de compra.
5) El jefe de almacén selecciona “Salir” y el caso de uso finaliza.
3.2. Subflujo:
3.2.1. Agregar Nueva Factura
1)El sistema muestra la interfaz Factura de compra con los siguientes campos:
Idfactura (solo lectura), idordendecompra(solo lectura) , Numero de factura (solo
lectura), fecha de emisión(ingresar), total a pagar(ingresar). Además, muestra la
opción Agregar y Cancelar.
2)El jefe de almacén ingresa los datos de Factura de compra.
3) El sistema genera un nuevo código de factura y obtiene la fecha del sistema
para la fecha de emisión.
4) El sistema valida los datos ingresados.
5)El sistema graba un nuevo registro de Factura y muestra el MSG “Factura
creado con código Nro. 6000001110”
6) El jefe de almacén cierra la interfaz “Registrar Factura de compra” con la lista
de Facturas, agregados y el subflujo finaliza.
3.2.2. Consultar Orden de compra

1)El sistema muestra la interfaz orden de compra con los siguientes campos:
Id compra (solo lectura) , NroOC(solo lectura),OCfechadeadmision (solo
lectura),fechadeentregaPos, Direcciondeentrega, idproveedor.Además, muestra la
opción Seleccionar.
2)El jefe de almacén consulta los datos de orden de compra.
3) El sistema consulta el orden de compra y obtiene el id compra.
4) El sistema valida los datos seleccionados
5)El sistema Selecciona y envía los datos a idordendecompra en la interfaz
agregar nueva factura.
6) El jefe de almacén cierra la interfaz “Consultar orden de compra” con la lista
de orden de compra seleccionada, el subflujo finaliza.
3.3Flujos alternativos
1. Datos de Facturas inválidos
Si los datos ingresados son nulos o inválidos, tanto en el Subflujo Agregar, el
sistema reporta un MSG “se ha encontrado datos no validos” y el subflujo continua
con el paso 2.
2. Factura ya existe
Si el sistema detecta que la factura en el paso 4 del subflujo Agregar Factura,
muestra un MSG “factura ya existe” y el subflujo finaliza.
4. Precondiciones
1. El jefe de almacén está identificado
2. Lista de Disponible de orden de compra.
5. Postcondiciones
1.En el sistema quedara registrado una nueva factura.
2. En el sistema quedara agregado en el registro de factura
6. Puntos de extensión
ninguno
7. Puntos especiales
ninguno
8. Prototipos

8.1. Diagrama de clases de Análisis
Figura 36 Diagrama de clases de Análisis
8.2. Flujo Básico-Diagrama de comunicación-Registrar Factura Orden de compra

Figura 37 Diagrama de comunicación - Registrar Factura Orden de compra
8.3. Diagrama de secuencia - Registrar Factura Orden de compra

Figura 38 Diagrama de Secuencia -Registrar Factura de Orden de compra
8.4. Subflujo-Diagrama de comunicación-Agregar

Figura 39 Subflujo-Diagrama de comunicación -Agregar
8.5. Diagrama de secuencia - Agregar

Figura 40 Diagrama de Secuencia-Agregar
8.6. Subflujo-Diagrama de comunicación-consultar orden de compra

Figura 41 Subflujo-Diagrama de comunicación-consultar orden de compra
8.7. Diagrama de secuencia – consultar orden de compra


Figura 42 Registrar Factura de orden
Figura 43 Consultar Orden de compra

7.3. ESPECIFICACION DE CASO DE USO: Mantener atención de pruebas
médicas
1.Descripción:
El caso de uso permite registrar la atención de una prueba médica. De acuerdo a la
necesidad el operador puede registrar una nueva atención.
2.Actor:
Operador.
3.Flujo de eventos
3.1. Flujo básico (cambiar paciente por cliente)
1. El caso de uso de uso se inicia cuando el operador selecciona la
opción registrar en la interfaz del menú de atención de pruebas
médicas.
2. El sistema muestra la interfaz “Registrar atención médica” con la lista
de todos los registros de atenciones, con los datos del paciente, id de
atención, fecha, estado de la atención. Además, muestra las opciones
de agregar un nuevo registro y eliminar un registro.
3. Si el operador selecciona “Agregar”, ver el subflujo agregar registro.
4. Si el operador selecciona “Eliminar”, ver el subflujo eliminar registro.
5. Si el operador selecciona “Regresar”, el caso de uso finaliza.
3.2. Subflujos
3.2.1. Agregar
1. El sistema muestra la interfaz de registro de atención con los campos:
id de atención, datos del paciente, fecha de registro, estado de
atención. Además, muestra las opciones: Aceptar y Cancelar.
2. El operador ingresa los datos del registro.
3.El operador selecciona “Aceptar”, validando los datos.
4.El sistema muestra la lista de todos los registros de atención.
3.2.2. Eliminar
1.El sistema muestra una alerta,” ¿Desea eliminar el registro
seleccionado?”.
2.El operador pulsa “Si” para confirmar la eliminación del registro.
3. El sistema muestra la lista de los registros de atención.
3.3. Flujos Alternativos

1. Campos del registro de atención inválidos, el sistema muestra:” Se
encontraron datos inválidos “, y se vuelve a mostrar el formulario de
registro.
2. Si el operador selecciona NO en el paso 2 del subflujo eliminar,
finaliza el subflujo.
4. Precondiciones
1. Lista de pacientes disponibles.
2. Operador identificado en el sistema.
5. Postcondiciones
1. En el sistema quedará registrada la nueva atención.
2. En el sistema quedará eliminado el registro de atención.
Ninguno.
7. Requisitos especiales
Ninguno.
7.4. ESPECIFICACION DE CASO DE USO: Mantener Cliente
1.Descripcion.
El caso permite mantener actualizado el registro de los clientes de la Veterinaria
“DR. Vise” De acuerdo con su necesidad, al operador de la veterinaria puede
agregar, actualizar y eliminar un cliente en el Sistema de información.
2.Actor(es)
Operador.
3.Flujo de eventos
3.1 Flujo básico
1)El caso de uso se inicia cuando el operador selecciona la opción “Cliente” en
la interfaz del menú principal.
2) El sistema muestra la interfaz “Mantenimiento de clientes”, con la lista de

clientes, con los campos: código, nombre, apellido, teléfono, correo,
dirección. Además, muestra la opción Agregar Cliente, Actualizar cliente y
Eliminar cliente.
3) Si el Operador elige un cliente

a) Si elige “Actualizar” ver subflujo Actualizar cliente
b) Si elige “Desactualizar” ver subflujo Actualizar cliente
4) Si el operador No elige un cliente

a) Si elige Agregar ver subflujo Agregar cliente
5) El operador selecciona “Salir” y el caso de uso finaliza.
3.2 Subflujo
3.2.1 Agregar Cliente
1) El sistema muestra la interfaz Cliente los siguientes campos: código
(solo
lectura),
nombre, apellido, teléfono, correo, dirección, fecha de registro (solo
lectura),
numero de RUC (opcional) Además, las opciones de Aceptar y Cancelar.
2)El operador ingresa los datos del cliente

3)El operador r selecciona la opción Aceptar
4)El sistema valida los datos ingresados.
5)El sistema genera un nuevo código de cliente y obtiene la fecha de sistema
para la fecha de registro y la fecha de actualización.
6)El sistema graba un nuevo registro de cliente y muestra el MSG “Cliente
Creado con Código Nro. “#CV1321312”.
7)El operador cierra la interfaz “Mantenimiento de cliente” con la lista de cliente
actualizado y subflujo finaliza.

3.2.2 Actualizar Cliente

1) El sistema muestra la interfaz Cliente los siguientes campos:
código (solo lectura),
nombre, apellido, teléfono, correo, dirección, fecha de registro (solo lectura),
fecha
de actualización (solo lectura) y numero de RUC (opcional). Además, las
opciones de Aceptar y Cancelar.
2) El operador actualiza los datos de cliente

3) El operador selecciona la opción Aceptar
4)El sistema valida los datos ingresados.
5)El sistema obtiene la fecha de sistema para la fecha de actualización.
6)El sistema actualiza y muestra el MSG “Cliente Actualizado
Satisfactoriamente”
7) El operador cierra la interfaz “Mantenimiento de cliente” con la lista de cliente
actualizado y subflujo finaliza.
3.2.3 Eliminar Cliente
1)El sistema muestra un MSG” ¿Esta seguro que desea Eliminar Cliente?”
2)El operador selecciona la opción SI para proceder a eliminar al cliente.
4)El sistema muestra la interfaz “Mantenimiento de cliente”, con la lista los
Clientes actualizados y termina el subflujo.
3.3 Flujos Alternativos

1.Datos del cliente inválidos
Si los datos ingresados son nulos o inválidos, tanto en los Subflujo Agregar
como en Actualizar Cliente, el sistema muestra el MSG “Se han encontrado
daos No validos” y lo Subflujos continua en el paso 2.
2.Cliente ya existe
Si el sistema detecta que el cliente ya existe en el paso 4 del subflujo Agregar
cliente, muestra un MSG “Cliente Ya existe” y el subflujo finaliza.
3. No confirma la eliminación
Si el operador selecciona NO en el paso 2 del subflujo Eliminar Cliente finaliza
el flujo.
4.Precondicones
1.El operador está identificado en el sistema.
2.Lista disponible de cliente.
5.Poscondicones
1. El operador está identificado en el sistema.
2.Lista disponible de cliente.
6.Punto de extensión
Ninguno
7.Requisitos Especiales
Ninguno

8.Prototipo
Figura 44 Registro de nuevo clientes

8.1. DIAGRAMA DE CLASES DE ANALISIS
Figura 45 Diagrama de clases de análisis

Figura 46 Registrar cliente

Figura 47 Mantener cliente Flujo básico

Figura 48 Mantener cliente subflujo

Figura 49 Mantener cliente

Figura 50 Mantener cliente diagrama de estado

ESPECIFICACION DE CASO DE USO: REGISTRO DE ACTA DE RESULTADOS
1. Descripción:
El caso de uso permite realizar el registro del acta de resultado correspondiente a cada
atención realizada. Contiene el resultado de su correspondiente prueba médica. En una
atención se puede realizar varias pruebas médicas por lo tanto una atención podrá
generar varias actas de resultado, dependiendo del número de pruebas por atención.
2. Actores:
Medico
3. Flujo de eventos:
3.1 Flujo básico:
1) El caso de uso se inicia cuando el medico selecciona la opción “Menú
Atención Pruebas Médicas” en la interfaz del menú principal.
2) El medico seleccionara “Mantenimiento de Acta de Resultado”, con la
lista de Actas de Resultado previamente registrados con los campos: código
(solo lectura), nombre de la prueba médica (solo lectura), medico responsable
(solo lectura), fecha del registro (solo lectura). Además, muestra la opción
Registrar Acta de Resultado y las opciones de Editar Acta de Resultado y
Eliminar Acta de Resultado por cada registro que se visualice.
3) Si el medico elige un Acta de Resultado
a) Si elige “Editar” ver subflujo Editar Acta de Resultados.
b) Si elige “Eliminar” ver subflujo Eliminar Acta de Resultados.
4) Si el medico NO elige un Acta de Resultado
a) Si elige “Registrar” ver subflujo Registrar Acta de Resultados.
5) El medico selecciona “Salir” o “Cancelar” y el caso de uso finaliza
3.2 Subflujos:
3.2.1 Registrar Acta de Resultados
1) El sistema muestra la interfaz Registrar Acta de resultados con un
buscador para buscar y elegir a que detalle de registro de atención se le
registrará su resultado, también se visualizará un formulario para
llenarlo con los datos del Acta de resultados con los siguientes campos:
código, nombre de la prueba médica (solo lectura), descripción del
resultado a registrar y opción para adjuntar archivos. Además, muestra
la opción Aceptar y Cancelar.
2) El medico busca la Prueba Medica a la cual le registrara su resultado.
3) El sistema valida los datos ingresados.
4) El sistema realiza la búsqueda de la Prueba Medica
5) El sistema muestra los resultados de la búsqueda.
6) El medico ingresa los datos de Acta de Resultados.
7) El medico selecciona la opción Aceptar.
8) El sistema valida los datos ingresados
9) El sistema genera un nuevo código de Acta de Resultados y obtiene
la fecha del sistema para la fecha de registro.
10) El sistema graba un nuevo registro de Acta de resultados en la base
de datos.
11) El medico cerra la interfaz “Registrar Resultado de Pruebas
Médicas” con la lista de Acta de resultados actualizados y el subflujo
finaliza.
3.2.2 Editar Acta de Resultados
1) El sistema muestra la interfaz Editar Acta de resultados con los

siguientes campos: código (solo lectura), nombre de la prueba médica
(solo lectura), fecha en la que se registró (solo lectura), descripción del
resultado y archivos adjuntos. Además, muestra la opción Aceptar y
Cancelar.
2) El medico edita los datos del Acta de resultados.
3) El medico selecciona la opción Aceptar.
4) El medico valida los datos ingresados.
5) El sistema obtiene la fecha del sistema para reemplazar la fecha de
registro.
6) El sistema actualiza y muestra una notificación “Acta de resultados
Editada satisfactoriamente”.
7) El administrador cierra la interfaz “Mantenimiento de Acta de
Resultado” con la lista de cajeros actualizados y el subflujo finaliza.
3.2.3 Eliminar Acta de Resultados
1) El sistema muestra la interfaz Eliminar Acta de resultados con los

siguientes campos: código (solo lectura), nombre de la prueba médica
(solo lectura), fecha en la que se registró (solo lectura), descripción del
resultado (solo lectura), archivos adjuntos (solo lectura) y el medico
responsable (solo lectura). Además, muestra la opción Aceptar y
Cancelar.
2) El administrador selecciona la opción Aceptar para confirmar la
eliminación del Acta de Resultado.
3) El sistema elimina el registro en la base de datos de Actas de
Resultado y muestra una notificación “Acta de resultados Eliminada
satisfactoriamente”.
4) El sistema muestra la interfaz “Mantenimiento de Acta de

Resultado”, con la lista de las Acta de resultados actualizadas y termina
el subflujo.

1. Datos de Acta de Resultados inválidos:

Si los datos ingresados son nulos o inválidos el sistema muestra una notificación
“Se han encontrado datos no validos”.
2. Acta de Resultados ya existe:
Si el sistema detecta que el Acta de Resultados ya existe mediante la validación
del código en el paso 8 del subflujo Registrar Acta de Resultados, muestra una
notificación “Acta de Resultados ya Existe” y el subflujo finaliza.
4. Precondiciones:
1. El medico está identificado en el sistema
2. Lista disponible de Atención de Pruebas Medicas
5. Postcondiciones:
1. En el sistema quedara registrado el Acta de Resultados de cada Prueba Medica.
2. En el sistema quedara actualizado la lista de Acta de Resultados.
Ninguno
7. Requisitos Especiales
1. El tipo de atención al que se le va a registrar sus resultados debe ser de Prueba
Medica.

Figura 52 Diagrama de clase de análisis
Figura 53 Flujo Basico de Registro de Acta de resultados

Figura 54 Diagrama de Registro de Acta de Resultados

Figura 55 subflujo Registrar

Figura 56 Diagrama de Secuencia Registrar

Figura 57 continuación del diagrama de secuencia Registrar

Figura 58 Continuación del diagrama de secuencia Registrar

Figura 59 Subflujo editar

Figura 60 Diagrama de secuencia de editar

Figura 61 Continuación del diagrama de secuencia editar

Figura 62 Subflujo eliminar

Figura 63 Diagrama de secuencia Eliminar

Figura 64 Continuación del diagrama de secuencia Eliminar

Figura 65 Flujo de acta de Resultados Inválidos
Figura 66 Diagrama de secuencia de Acta de resultados invalidos

Figura 67 Flujo de acta de resultados existentes

Figura 68 Diagrama de secuencia de acta de resultados existentes

8. Prototipo
Figura 69 Interfaz Registrar Acta de Resultados

Figura 70 Acta de resultados

Figura 71 Editar acta de resultados

Figura 72 Eliminar Acta de resultados

7.5. Especificación de caso de uso: Registrar orden de compra
1. Descripción
EL Caso permite registrar un orden de compra. De acuerdo con las
necesidades de la empresa. Al buscar la orden de requerimientos y buscar al
proveedor adecuado que cumpla con nuestros requerimientos.
2. Actor(es)
Responsable de almacén
3. Flujo de eventos
3.1. Flujo básico:

3.1.1. El caso de uso se inicia el Responsable de almacén puede
visualizar el registro del orden de requerimientos.
3.1.2. EL Sistema muestra la interfaz de orden de compra con la lista de
orden de compra que tiene la empresa por abastecer con los
campos de Id de la orden de compra, Nro., fecha de emisión, fecha
de entrega, dirección de entrega y con la lista de proveedores a
escoger, y además se muestra las opciones de registrar, actualizar y
cancelar.
3.1.3. Si el responsable de almacén elige orden de compra
3.1.3.1. Si elige “Registrar” ver subflujo de registrar orden de comprar
3.1.3.2. Si elige “Actualizar” ver subflujo de actualizar orden de compra
3.1.3.3. Si elige “Cancelar” ver subflujo de cancelación de orden de
comprar
3.1.4. El Responsable de almacén cierra la interfaz de orden de compra y
avanza a la registro de factura de orden de compra.
3.2. Subflujos
3.2.1. Registrar orden de comprar

3.2.1.1. EL sistema muestra la interfaz de orden de compra con los
siguientes campos de Id de la orden de compra (Es asignado
por el sistema), NroOC, fecha de emisión(es asignado por el
sistema), fecha de entrega posterior, y elección del proveedor
con la opción Aceptar y Cancelar.
3.2.1.2. El Responsable de almacén ingresa los datos que requiere la
orden de compra y selección el proveedor de acuerdo a los
beneficios.
3.2.1.3. El Responsable de almacén selección la opción aceptar.
3.2.1.4. El sistema valida los datos ingresados
3.2.1.5. El sistema genera un código que referencie la orden de compra
y la fecha de emisión es obtenida por el sistema.
3.2.1.6. El sistema registra la nueva orden de comprar y muestra un
MSG “Registro satisfactorio con el Nro.: 9999999”.
3.2.1.7. El Responsable de almacén cierra la interfaz de orden de
compra y avanza a la registro de factura de orden de compra.
3.2.2. Actualizar orden de compra

3.2.2.1. El sistema muestra la órdenes de compra con todos sus

campos:
Id de la orden de compra, NroOC, fecha de emisión, fecha de
entrega posterior, y proveedor y además muestra Aceptar y
Cancelar.
3.2.2.2. El Responsable de almacén actualizado los datos de orden de
compra.
3.2.2.3. El Responsable de almacén selección la opción de aceptar.
3.2.2.4. El sistema obtiene la fecha para la fecha de emisión.
3.2.2.5. El sistema registra la nueva orden de comprar y muestra un
MSG “Actualización satisfactorio con el Nro.: 9999999”.
3.2.2.6. El Responsable de almacén cierra la interfaz de orden de
compra y avanza a la registro de factura de orden de compra.
3.2.3. Cancelar orden de compra
3.2.3.1. EL sistema muestra la interfaz de orden de compra con los
siguientes campos de Id de la orden de compra (Es asignado
por el sistema), NroOC, fecha de emisión(es asignado por el
sistema), fecha de entrega posterior, y elección del proveedor.
3.2.3.2. El responsable de almacén selección una orden de compra y la
opción cancelarlo
3.2.3.3. El sistema muestra MSG “si está seguro de eliminar”
3.2.3.4. Selección la opción aceptar
3.2.3.5. El sistema muestra MSG ”Se eliminó satisfactoriamente”
3.2.3.6. El sistema actualizado los datos
3.2.3.7. Si el responsable de almacén selección salir sale de la interfaz y
el caso de uso finaliza
3.3.1.1. Dato de la orden de compra inválidos

Si los datos al ingresar son null o inválidos, tanto los Subflujos
registrar y actualizar el sistema muestra un MSG “Se
introdujeron datos inválidos”
3.3.1.2. Código existente
Sistema detecta si existe duplicidad en el código de orden de
compra por lo cual saltara un MSG” Duplicada encontrada en el
código 99999”.
3.3.1.3. Cuando el Responsable de almacén no confirma
El sistema no hará al siguiente sin la confirmación
Muestra MSG "No se emitió cambios"

4. Precondiciones
4.1. El Responsable de almacén está identificado en el sistema
4.2. Lista de Orden de requerimientos
5. Postcondiciones
5.1. En el sistema quedara registrado la orden de compra
5.2. En el sistema quedara actualizado la orden de compra
5.3. En el sistema quedara cancelado la orden de compra
5.4.
6.1. Se Incluye Consultar orden de requerimientos
6.2. Se incluye Asignar Proveedor
7. Requisitos Especiales
Ninguno

Figura 73 Diagrama de análisis
Figura 74 Flujo básico de Registrar orden de requerimientos

Figura 75 Diagrama de secuencia de registrar orden de Requerimientos

Figura 76 subflujo registrar


Figura 79 Subflujo Actualizar

Figura 80 Diagrama de secuencia de actualizar

Figura 81 continuación del diagrama de secuencia actualizar

Figura 82 Subflujo cancelar

Figura 83 Diagrama de secuencia cancelar

Figura 84 continuación del diagrama de secuencia del subflujo cancelar

Figura 85 Flujo alternativo de Datos inválidos

Figura 86 Diagrama de secuencia de datos inválidos

Figura 87 Flujo alternativo de código no existe


Figura 88 Diagrama de secuencia de código no existe

Figura 89 diagrama de secuencia de no confirma

Figura 90 flujo alternativo de no confirma

8. PROTOTIPO
1. PROTOTIPO
8.1. REGISTRAR ORDEN DE COMPRA
REGISTRAR ORDEN DE COMPRA
Registrar Orden de Compra
Código: Buscar Proveedor
Nro de Orden de Compra:
Fecha de Emisión:
Fecha de Entrega Posterior:
Código Nro de Orden C. Fecha de Emisión Fecha de Entrega P Proveedor
Registrar Actualizar Cancelar
Figura 91 Registrar orden de compra

8.2. ACTUALIZAR ORDEN DE COMPRA:
ACTUALIZAR ORDEN DE COMPRA
Código: Buscar Proveedor:
Nro de Orden de Compra:
Fecha de Emisión:
Fecha de Entrega Posterior:
ACTUALIZAR CANCELAR
Figura 92 Actualizar Orden de compra

1. BREVE DESCRIPCIÓN:
Este caso de uso permite al cajero Emitir un comprobante de pago para el
cliente que ha sido atendido en la clínica, detallando todos los servicios y
productos solicitados por parte del cliente y facilitando el pago de dicha
Atención mediante un medio de pago valido para la empresa.
2. ACTORES:
cajero
3. FLUJO DE EVENTOS:
3.1 Flujo Básico:
1. El caso de uso inicia cuando el cajero accede al Sistema y solicita
Emitir Comprobante de Pago en la interfaz “Menú Principal”.
2. El sistema muestra dos campos:
 ID. de Comprobante: deshabilitado. Sistema no muestra valor.
 Fecha de Emisión: deshabilitado. Sistema muestra fecha actual.
Además, muestra dos secciones: Datos Cliente y Detalle de
Comprobante.
Datos Cliente:
Muestra los siguientes campos:
 Nombre: deshabilitado
 Nro. Documento: deshabilitado
 Teléfono: deshabilitado
 Email: deshabilitado
 Dirección: deshabilitado
Datos de Comprobante:
Muestra los siguientes campos:
 Tabla con los siguientes campos:
o Nro. Atención
o Descripción
o Precio
 Sub Total: deshabilitado
 IGV: deshabilitado
 Total: deshabilitado
Además de las siguientes opciones:

 Guardar: deshabilitado
 Imprimir: deshabilitado
 Atrás: habilitado
3. El sistema muestra los datos del cliente en la sección “Datos del

cliente”.
 Cliente: Razón Social o Nombres y Apellidos del cliente.
 Tipo de Documento: RUC o DNI del cliente.
 Teléfono: Número telefónico del cliente.
 Dirección: Dirección del cliente.
 E-mail: Correo electrónico.
4. El cajero busca el cliente por medio del botón “Buscar Cliente”.

5. El sistema captura los datos de la interfaz “Consultar Atención”.
6. El sistema muestra el detalle en la sección Detalles del Comprobante.
7. De acuerdo con el detalle de la atención, el sistema muestra el Sub
Total, IGV y el Total.
8. El sistema habilita la opción registrar.
9. El cajero selecciona la opción Registrar.
10. El sistema obtiene el último ID de comprobante generado y autogenera
el nuevo ID de comprobante.
11. El sistema registra el comprobante de pago, con fecha y hora, además
del detalle del comprobante de pago.
12. El sistema muestra el numero de comprobante generado en el campo
“ID de Comprobante”.
13. El sistema muestra el mensaje “La boleta o Factura (de acuerdo al
caso) se generó satisfactoriamente con el Nro. XXXXXX”.
14. El sistema habilita el botón “Imprimir”.
15. El cajero selecciona la opción “Salir”.
16. El sistema cierra la interfaz y el caso de uso finaliza.

3.2 Sub-Flujo
3.2.1 IMPRIMIR COMPROBANTE
1. Luego del paso 16, el cajero presiona el botón “imprimir”, el sistema muestra el
mensaje “¿desea imprimir el comprobante?”.
2. El cajero selecciona la opción si para confirmar la impresión.
3. El sistema imprime el comprobante de pago.
3.3.1 SALIR SIN GUARDAR
1. Si el cajero selecciona “salir” sin antes generar el comprobante de pago, el sistema
muestra el mensaje “desea cancelar comprobante de pago”, si es selecciona si, el
caso de uso finaliza.
4. PRECONDICIONES
1. El cajero debe estar identificado en el sistema
2. La lista disponible de clientes
3.
5. POSTCONDICIONES
1. El sistema quedara registrado el comprobante de pago.
2. El sistema quedara actualizado con los registros de comprobantes
6. PUNTOS DE INCLUSIÓN
Ninguno
7. REQUISITOS ESPECIALES
Ninguno
8. PROTOTIPO

Figura 93 Emitir comprobante de pago
1. BREVE DESCRIPCIÓN:
Este caso de uso permite al cajero consultar la atención recibida del cliente por
parte de la clínica.
2. ACTORES:
cajero
3. FLUJO DE EVENTOS:
3.1 Flujo Básico:
17. El caso de uso inicia cuando el cajero selecciona la opción “Consulta
por Atención” del formulario “Emitir Comprobante de pago”.
18. El sistema muestra la interfaz “Consultar Atención”, donde realiza una
búsqueda por cliente.
19. El cajero filtra la búsqueda en el campo “Buscar” y selecciona el botón
“Buscar”.
20. El sistema filtra los resultados de la búsqueda.
21. El cajero selecciona el cliente, da doble clic para capturar los datos de
la atención del cliente.
22. El sistema recoge todo los datos de la Atención y los importa al caso de
uso “emitir Comprobante de Pago”.
23. Fin del caso de uso.
3.2 Sub-Flujo
3.2.1 AGREGAR CLIENTE
Luego del paso 4, si el cajero no encuentra el cliente consultado, lo puede
agregar.
2. DATOS INCORRECTOS
si el cajero, en el paso 3 ingresa mal algún dato, el sistema no

mostrara los resultados esperados.
4. PRECONDICIONES
4. El cajero debe estar identificado en el sistema
5. La lista debe contener Atenciones previamente registradas.
6. La lista debe contener Clientes previamente Registrados.
5. POSTCONDICIONES
3. El sistema mostrara los resultados de la búsqueda realizada
4. El sistema quedara actualizado en caso se haya agregado alguna Atención no
registrada a la hora de la consulta.
6. PUNTOS DE INCLUSIÓN
Ninguno
7. REQUISITOS ESPECIALES
Ninguno
8. PROTOTIPO

Figura 94 Consulta atención
ESPECIFICACION DE CASO DE USO: Registrar Producto
1. Descripción:
El caso permite registrar los productos nuevos en la clínica veterinaria
Doctor Vise. De acuerdo con su necesidad, el responsable de almacén
de la veterinaria puede Insertar, Modificar, Eliminar y guardar un
producto en el Sistema de Información.
2. Actor (es)
Responsable de Almacén
3. Flujo de eventos
3.1 Flujo básico

1) El caso inicial cuando el responsable de almacén selecciona la opción
“productos” en la interfaz del menú principal.
2) El sistema muestra la interfaz “Mantener producto”, con la lista de
productos, con los campos: id producto, tipo producto, nombre producto,
descripción de producto, precio de producto, stock de producto, mostrando las
opciones Insertar producto, Modificar productos, Eliminar producto, Guardar
producto.
3) Si responsable de almacén elige producto
a) Si elige “Insertar” ver subtitulo Insertar producto.
b) Si elige “Modificar” ver subtitulo Modificar producto.
c) Si elige “Eliminar” ver subtitulo eliminar producto.
d) Si elige “Guardar” ver subtitulo guardar producto.
4) Si responsable No elige un producto.
a) Si elige Agregar ver subflujo de agregar producto.
5) El responsable selecciona “salir” y el caso de uso finaliza.
3.2 Subflujos
3.2.1 Insertar producto
1- El encargado muestra la interfaz Mantener producto
con los campos: id producto, tipo producto, nombre
producto, descripción de producto, precio de producto,
stock de producto.
2.- El encargado ingresa los datos del producto.
3.- El encargado selecciona la opción aceptar.
4.- El sistema valida los datos ingresados.
5.- El sistema genera un nuevo código de producto y
obtiene la fecha del sistema para la fecha de registro y la
fecha de actualización.
6.- El sistema graba un nuevo registro de producto y
muestra el MSG “producto creado con Código Nro.
969696969”.
7.- El encargado guarda los datos del producto.
8.- El Sistema muestra el mensaje Producto registrado.
9.- El encargado cierra la interfaz.
10.- El sistema carga los datos del producto.
11.- El sistema obtiene los datos del producto.
12.- El sistema muestra los datos el producto.
3.2.2 Modificar producto

stock de producto.
2.- El encargado se dirige a la información del formulario
que desea editar, selecciona la opción editar producto.
3.- El encargado modificara los datos del producto.
4.- El encargado selecciona la opción guardar.
.- El sistema valida los datos ingresados.
5.- El sistema valida los datos ingresados.
6.- El sistema genera un nuevo código de producto y
obtiene la fecha del sistema para la fecha de registro y la
fecha de actualización.
7.- El sistema graba un nuevo registro de producto y
muestra el MSG “producto creado con Código Nro.
969696969”.
8.- El encargado guarda los datos del producto.
9.- El Sistema muestra el mensaje Producto registrado.
10.- El encargado cierra la interfaz.
11.- El sistema carga los datos del producto.
12.- El sistema obtiene los datos del producto.
13.- El sistema muestra los datos el producto.
3.2.3 Eliminar producto

stock de producto.
2.- El administrador selecciona la información del
producto que desea eliminar, selecciona la opción
eliminar producto.
3.- El sistema abre un pequeño cuadro de dialogo en
donde nos muestra mensaje indicando que si “está
seguro eliminar el producto”.
4.- El encargado selecciona la opción sí.
5.- El sistema elimina el producto de forma lógica
cambiando el estado de activo a inactivo.
6.- El encargado cierra la interfaz registrar producto con
la lista de productos actualizados y el subflujo finaliza.
3.3 Flujos alternativos
1.- Datos del producto inválidos
Si los datos ingresados son nulos o inválidos, tanto en los
subflujos Agregar como en Actualizar producto, el
sistema muestra el MSG “Se han encontrado datos NO
validos” y los subflujos continua en el paso 2.
2.- Producto ya registrado
Si el sistema detecta que el cajero ya existe en el paso 4
del subflujo Agregar cajero, muestra un MSG “producto
YA Existe” y el subflujo finaliza.
3.- No confirma desactivación
Si el administrador selecciona NO en el paso 2 el subflujo
Eliminar cajero finaliza el flujo.
4. Precondiciones
1.-El encargado de almacén esta identificado en el sistema.
2.-Lista disponibles de productos.

5. Postcondiciones
1.-En el sistema quedara registrado el nuevo producto.
2.-En el sistema quedara actualizado el registro de producto.
3.-En el sistema quedara desactivado el producto
Ninguno
7. Requisitos especiales
Ninguno
8. Prototipos:




Diagrama de clase:
Diagrama de Comunicación:
Principal:

Insertar producto:
Modificar:


Eliminar:

Revisado Disenio y Arquitectura Final

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

Revisado Disenio y Arquitectura Final

Cargado por

Copyright:

Formatos disponibles

Universidad Privada del Norte

Modelado y Diseño de un sistema de

Curso: Diseño y Arquitectura de Software

El propósito de este documento es recoger, analizar y definir las necesidades

El alcance de este documento se enfoca al proceso relacionado a la gestión de

El sistema permitirá al encargado de la veterinaria Dr. Vise tener un mejor

1.3 Definiciones, Acrónimos y Abreviaciones

2.1.1 OPORTUNIDAD DE NEGOCIO

El sistema permitirá a la veterinaria Dr. Vise automatizar el proceso de gestión

Fecha de Actualización: 07/04/2022 Versión: 1.0

Preparado por: Página : 2 de 121

 Automatizar los procesos de compra al 50%

Ofrecer calidad en la atención que ofrecemos a nuestros pacientes,

Ser un centro de Atención Médica Veterinaria que trascienda en la localidad y

2.5 Declaración de problema

El problema es La ineficiencia en los procesos de compra y servicios debido a

El impacto En los procesos manuales de compra, documentación, errores

Fecha de Actualización: 07/04/2022 Versión: 1.0

Preparado por: Página : 3 de 121

2.6 Declaración de posición de producto

Para Gerente General, Personal Operador.

Quienes Controlan los pedidos(proveedores), los almacenes (stock)

BICKY Es un Software de Gestión de Procesos de Compra y

Fecha de Actualización: 07/04/2022 Versión: 1.0

Preparado por: Página : 4 de 121

3.1 Características Principales de la solución

 BICKY será desarrollado utilizando la herramienta de Netbeans con el

 El sistema contará con un manejo vía Internet, permitiendo la seguridad

 Unos de los principales objetivos de BICKY es presentar de manera

 El análisis efectuado para la realización del sistema abarca solo el Área

 El tiempo de desarrollo es limitado.

3.3 Rasgos de calidad

3.4 Precedencia y Prioridad

Fecha de Actualización: 07/04/2022 Versión: 1.0

Preparado por: Página : 5 de 121

4.1 MODELO DE CASO DE USO DE NEGOCIO

El Gerente evalua la orden de requerimientos Gerente NO

El Responsable de almacen envia la orden de compra al proveedor Responsable de Almacen NO

El Cliente solicita atencion de Pruebas Medicas Cliente NO

El Cliente efectúa el pago de la atencion de prueba medica Cliente NO

El Medico entrega el acta de resultados al Cliente Medico NO

La enfermera realiza la atencion estetica Enfermera NO

Figura 1 Matriz de Requerimientos.

Figura 2 Modelo de caso de uso de negocio.

4.3.1 ACTORES DE NEGOCIO:

Figura 3 Actores de negocio.

4.3.2 OBJETIVOS DE NEGOCIO:

Figura 4 Objetivos de negocio.

4.3.3 CASO DE USO DE NEGOCIO VS OBJETIVOS DE NEGOCIO:

Figura 5 CUN vs ON.

Fecha de Actualización: 07/04/2022 Versión: 1.0

Preparado por: Página : 8 de 121

4.3 MODELO DE ANALISIS DE NEGOCIO

Figura 6 Realizaciones de negocio.

Fecha de Actualización: 07/04/2022 Versión: 1.0

Preparado por: Página : 9 de 121

4.4.2 DIAGRAMA DE CLASES DE REALIZACION DE GESTION DE COMPRA:

Figura 7 Diagrama de clases de realización Gestión de Compra.

4.4.3 DIAGRAMA DE CLASES DE REALIZACION DE GESTION DE ATENCION DE

Figura 8 Diagrama de clases de realización de Gestión de Atención de Pruebas Medicas.

Fecha de Actualización: 07/04/2022 Versión: 1.0

Preparado por: Página : 10 de 121

4.4.4 DIAGRAMA DE CLASES DE REALIZACION DE GESTION DE ATENCION