Proyecto UML

Information System I
Ing. Manuel Rojas V - manuel.rojas28@inacapmail.cl
Análisis y Diseño de Sistemas
“Farmacia”
“Sistema de Farmacia”
UNIVERSIDAD TECNOLOGICA DE CHILE

Programa INGENIERIA EN INFORMATICA Número Documento N-01-2016
Materia TI1212-000 Sistema de Información I Versión V1.0 09-Junio/2016
Gustavo Ahumada, Javier
Profesores Manuel Rojas Autores
Polanco, Camilo Burgos
1
Tabla de contenido
1. INTRODUCCIÓN..................................................................................................................3
1.1. Propósito........................................................................................................................3
1.2. Alcance...........................................................................................................................3
1.3. Estructura del Documento.............................................................................................3
2. MODELO DE PROCESO DE NEGOCIOS................................................................................4
2.1. Descripción de Actores Involucrados en el Modelo de Negocio...................................4
2.2. Requerimientos del Modelo de Negocio......................................................................4
3. CASOS DE USO DE ALTO NIVEL...........................................................................................5
3.1. Casos de Uso de Alto Nivel............................................................................................5
3.2. Casos de Uso a Nivel Detallado.....................................................................................6
3.3. Descripción de Casos de Uso.........................................................................................7
3.4. Eventos.........................................................................................................................12
4. DIAGRAMA DE ESTRUCTURA ESTÁTICA...........................................................................15
4.1. Modelo Conceptual......................................................................................................15
4.2. Diagrama de Clases......................................................................................................16
5. DIAGRAMA DE INTERACCIÓN..........................................................................................17
5.1. Diagrama de Secuencia del Sistema............................................................................17
5.2. Diagrama de Colaboración del Sistema.......................................................................18
5.3. Contratos......................................................................................................................19
6. DIAGRAMA DE ACTIVIDADES Y ESTADO..........................................................................22
7. CONCLUSIONES................................................................................................................23
8. ANEXOS............................................................................................................................24
2
1. INTRODUCCIÓN
Se desea automatizar el sistema de atención al cliente y el sistema de para mejorar la coordinación. Para
esto, el proyecto consta de realizar un sistema de que maneje toda la parte relacionada con los clientes,
stock y que pueda interactuar de forma adecuada con otros sistemas sin problemas. El presente documento
refleja los estudios realizados para la implementación de la solución elegida en el estudio de factibilidad,
donde mostraremos los Modelos de Procesos de Negocios, Modelo Conceptual, Diagrama de Clases, y Casos
de Uso. Primero daremos una pequeña descripción del Sistema Actual, sus necesidades y objetivos
perseguidos en este proyecto. Luego mostramos el Modelo de Proceso de Negocios indicando sus objetivos
Estratégicos y el proceso realizado por la empresa para la captura de clientes. En forma gráfica y más
detallada el funcionamiento del sistema completo, mostrando los casos de uso de cada etapa del proyecto.
1.1. Propósito
El propósito de este trabajo es proporcionar un sistema en el cual se pueda obtener información de forma
oportuna y a su vez tener un control, para evitar pérdidas y maximizar las ganancias.
1.2. Alcance
El trabajo realizado tiene como alcance todo el Sistema llevado dentro de una Farmacia dirigido a lo que es
venta y productos, por lo cual, no tomamos en cuenta el sistema de Recursos humanos, ni administrativo.
1.3. Estructura del Documento

El documento está dividido en cinco secciones. La segunda sección presenta una descripción del proceso de
modelo de negocios, la tercera sección describe los actores y casos de uso contenidos en el modelo junto
con las relaciones existentes entre ellos, la tercera sección describe una representación de las estructuras
estáticas del análisis de requerimientos descrito con Casos de Uso. Por último, la cuarta sección presenta la
especificación del comportamiento de cada caso de uso descrito, la quinta y sexta sección son las
conclusiones sacadas por el equipo de análisis de proyecto como así también los anexos si corresponden.
A lo largo de este formato se encuentran comentarios y ejemplos acerca del contenido del documento a
elaborar a partir de ésta. Éstos se encuentran indicados, al igual que este párrafo, por una línea a lo largo de
su borde izquierdo. Estas secciones deben ser eliminadas de la versión final del documento.
3
2. MODELO DE PROCESO DE NEGOCIOS
Business Process Management es un conjunto de métodos, herramientas y tecnologías utilizados para

diseñar, representar, analizar y controlar procesos de negocio operacionales. A través de un enfoque
centrado en los procesos para mejorar el rendimiento que combina las tecnologías de la información con
metodologías de proceso basado en diagrama de CU. Determina también una colaboración entre personas
de negocio y tecnólogos para fomentar procesos de negocio efectivos, ágiles y transparentes. Abarca
personas, sistemas, funciones, negocios, clientes, proveedores y socios
2.1. Descripción de Actores Involucrados en el Modelo de Negocio
Es capaz de indicar cuáles son las decisiones que debe tomar cierto actor y/o en cuáles es capaz de colaborar
para que otro actor tome una decisión. Además, representa a aquellos actores (humanos o no) que no
participan en las decisiones, y que simplemente se limitan a realizar las actividades operacionales.
Se incluye una breve descripción de cada uno de los actores involucrados. Cada actor está descrito de la
siguiente manera:
Actor Cliente
Descripción En el contexto, el término es utilizado como sinónimo de comprador (la persona
que compra el producto) o consumidor (quien consume un producto o servicio).
Versión Proyecto versión 1.0
Actor Farmacéutico
Descripción Profesional con habilidades integrales en salud, fabricación de medicamentos,
control de calidad, desarrollo e investigación de los mismos, es aquel experto en
medicamentos, y en la utilización de los medicamentos con fines terapéuticos en el
ser humano. En el contexto es el encargado de realizar las ventas y verificar recetas
médicas.
Bodeguero Bodeguero
Descripción Es la Persona encargada de Recepcionar materiales de proveedores, chequear
estos de acuerdo a los requerimientos, mantener en resguardo los bienes
materiales adquiridos apoyando en labores de almacenaje, orden y limpieza.
Debe Utilizar el sistema para inventariar stock, a su vez realizar los ingresos de
mercadería directamente al sistema.
4
2.2. Requerimientos del Modelo de Negocio
Es capaz de indicar cuáles son las decisiones que debe tomar cierto actor y/o en cuáles es capaz de colaborar
para que otro actor tome una decisión. Además, representa a aquellos actores (humanos o no) que no
participan en las decisiones, y que simplemente se limitan a realizar las actividades operacionales.
Clave Descripción Tipo de

Requerimientos
R1 Ingreso de Credenciales (user and password) Funcional
R2 Color de Ventana No Funcional
R3 Hardware CPU XEON 7500 Hardware
5
3. CASOS DE USO DE ALTO NIVEL
Se presenta una descripción de los actores involucrados en el modelo de Casos de Uso y una descripción de
alto nivel de los casos de uso del sistema. Cada caso de uso incluye una sección con los actores involucrados
en él.
3.1. Casos de Uso de Alto Nivel
Este diagrama representa la funcionalidad completa del sistema mostrando su interacción con los agentes
externos. Esta representación se hace a través de las relaciones entre los actores y los casos de uso dentro
del sistema.
Figura 1.Representa el módulo de Ventas
6
3.2. Casos de Uso a Nivel Detallado
Hacen referencia a la descomposición de los casos de uso del punto anterior. Se dan cuando existe una
relación entre dos casos de uso. Dicha relación puede ser de extensión, que en términos de la Orientación a
Objetos es una relación de herencia, donde el “subcaso” especializa al caso. También puede ser una relación
de “uso”, donde el caso requiere que el subcaso se realice completamente para que él mismo se realice bien
y completamente (Ver Figura 2):
Figura 2.
7
3.3. Descripción de Casos de Uso
Este formato muestra una descripción para ayudar a comprender los Casos y SubCasos de Uso. También hace
referencia a los requerimientos consignados en el documento de Requerimientos, con los cuales tiene
relación. A causa de la limitación de espacio, solo se muestran algunos a continuación:
CATALOGO DESCRIPCION CASOS DE USO
Proyecto : Sistema de Farmacia ID Caso de Uso : CU-001
Nombre Caso de Uso : Administrar Stock
Creado por : Sección Ingeniería Última Actualización por : Sección de Ingeniería
Fecha de Última
Fecha de Creación : 01/07/2016 : 01/07/2016
Actualización
Versión : 1.1 Estado de Desarrollo : Propuesto
Sub Casos Uso Consultar Stock en Bodega, Reponer Stock en Vitrina, Solicitar Productos a Proveedores.
Contexto :
Estereotipo : Comercialización de Producto
Actores : Bodeguero
Propósito : Realizar Pedidos, Reponer Productos y Controlar Stocks.
Permite saber cantidad de productos en inventario, para generar pedidos de artículos

Resumen : faltantes, a su vez debe mantener productos Ordenados y a disposición de los
farmacéuticos.
Tipo : Secundario
Pre condición : Para generar un pedido se debe contar con Stock bajo.
Post condición : Se generan Inventarios Mensualmente, para evitar Perdidas.
8
Reglas de Negocio : [R1] Realizar Pedidos y Mantener Productos.
Escenario Normal de Eventos
Acción(Actor) Respuesta(Sistema)
[1.0] El Bodeguero revisa el stock por sistema. [2.0] El Sistema Muestra Faltantes.
[3.0] El Bodeguero genera Pedido. [4.0] El Sistema Genera Guía de Despacho.
Escenario Alternativo de Eventos
[2.0] El Sistema genera un mensaje #1 “Alerta Producto

[1.0] El Bodeguero Revisa Stock.
Faltante”
[3.0] El Bodeguero Genera Pedido. [4.0] El Proveedor tiene problemas de entrega.
[5.0] El Sistema genera un mensaje #2 “Alerta Proveedor

[6.0] Se ingresa Nuevo Proveedor.
con Problemas de despacho”.
[6.0] Se Genera Orden de Compra.
Incluido : ----
Escenario Excepciones
: El Producto tiene Sobre Stock.
de Eventos
Prioridad : 100% Frecuencia de Uso : Diaria
Requerimientos
: No posee
Especiales
Observaciones : el CU está en estado de aprobación
9
Nombre Caso de Uso : Confirmar Compra
Fecha de Última
Actualización
Sub Casos Uso Consultar Stock, Comprobar Pago Pendiente y Validar Receta.
Contexto :
Actores : Farmacéutico
Propósito : Generar la venta y realizar el Pago.
Permite Generar los pagos de los productos, realizar consulta de deudas y gestionar el
Resumen :
método de Pago.
Tipo : Primario
Pre condición : Para generar una Venta el Cliente debe generar un Detalle de Venta
Post condición : Se realiza el pago, se entrega la boleta y Medicamentos al Cliente.
10
Reglas de Negocio : [R2] Realizar Pago y Entregar Medicamentos.
[1.0] El Farmacéutico Revisa el detalle de Boleta. [2.0] Se Genera la Venta.
[3.0] El Farmacéutico Solicita el Pago de los Medicamentos. [4.0] Se Imprime la Boleta.
[5.0] Se descuenta del Stock los productos vendidos.
[2.0] El Sistema genera un mensaje #3 “Producto con

[1.0] El Farmacéutico Revisa el detalle de Boleta.
Restricción Medica.
[4.0] El Farmacéutico Solicita el Pago de los Medicamentos. [3.0] Se ingresa el Numero de Receta Médica.
[5.0] Se Imprime la Boleta.
[6.0] Se descuenta del Stock los productos vendidos.
Incluido : ----
: El Cliente no tiene saldo para realizar el pago.
de Eventos
Requerimientos
: No posee
Especiales
11
Nombre Caso de Uso : Buscar Medicamentos
Fecha de Última
Actualización
Contexto :
Actores : Cliente
Propósito : Selecciona los medicamentos a comprar.
El Cliente Busca los medicamentos los ingresa en una lista de medicamentos Generando un
Resumen :
Detalle de Boleta, para su posterior pago.
Tipo : Primario
Pre condición : Para generar una Venta el Cliente debe generar un Detalle de Boleta.
Post condición : Se Genera un Detalle de Boleta para su posterior Pago.
Reglas de Negocio : [R3] Buscar medicamento y Generar Detalle de Boleta.
12
[1.0] El Cliente Busca el Medicamento [2.0] Se Muestran los medicamentos con la descripción.
[3.0] El Cliente Selecciona el Medicamento que necesita. [4.0] Se Ingresa a Lista de Productos.
[6.0] El Cliente Acepta la Boleta [5.0] Se Realiza el Cálculo y se muestra los Valores.
[6.0] Se Genera un Detalle de Compra.
[2.0] El Sistema genera un mensaje #4 “Producto con
[1.0] El Cliente Busca el Medicamento Restricción Medica por favor entregue Receta Médica a
Farmacéutico”.
[4.0] El Cliente Acepta y Selecciona el Medicamento que
[4.0] Se Ingresa a Lista de Productos.
necesita.
[6.0] El Cliente Acepta la Boleta [5.0] Se Realiza el Cálculo y se muestra los Valores.
[6.0] Se Genera un Detalle de Compra.
Incluido : ----
: El Cliente no cuenta con receta médica para comprar sus Medicamentos con Receta Retenida.
de Eventos
Requerimientos
: No posee
Especiales
13
Nombre Caso de Uso : Efectuar Pago
Fecha de Última
Actualización
Contexto :
Actores : Cliente
Propósito : Realizar Pago de Boleta.
El Cliente Selecciona la Forma de Pago de sus Medicamentos, Realiza el Pago y se le

Resumen :
entregan los medicamento.
Tipo : Primario
Pre condición : Para realizar el pago el Farmacéutico debe Confirmar la Boleta.
Post condición : Se realiza el pago y se Imprime la Boleta.
Reglas de Negocio : [R4] Realizar Pago y Entregar Medicamentos.
14
[2.0] El Cliente acepta el Pago [1.0] Se Muestra Valor y Monto a Pagar.
[3.0] El Cliente Selecciona el Método de Pago (Efectivo) [5.0] Se Cambia el Estado de la Boleta a Pagado.
[4.0] Se entrega el dinero a Farmacéutico.
[2.0] El Cliente acepta el Pago [1.0] Se Muestra Valor y Monto a Pagar.

[4.0] El Sistema genera un mensaje #5 “Por favor deslice
[3.0] El Cliente Selecciona el Método de Pago (Debito)
Tarjeta de Débito”.
[6.0] El Sistema genera un mensaje #6 “Por favor ingrese
[5.0] El Cliente desliza la Tarjeta de débito por ranura.
contraseña”.
[6.0] El Cliente ingresa la contraseña [6.0] Se cambia el Estado de la Boleta a Pagado.
Incluido : ----
: El Cliente no cuenta con forma de Pago.
de Eventos
Requerimientos
: No posee
Especiales
15
4. DIAGRAMA DE ESTRUCTURA ESTÁTICA
4.1. Modelo Conceptual

Antes de definir el modelo estático o de clases, es necesario definir el Modelo Conceptual, el cual nos
muestra los conceptos presentes en el dominio del problema. Un concepto para este caso, en términos de la
Programación Orientada a Objetos, es un objeto del mundo real; es decir, es la representación de cosas del
mundo real y NO de componentes de software. En él no se definen operaciones (o métodos); en este
modelo se pueden mostrar los conceptos, los atributos de los conceptos (opcionalmente) y la relación o
asociación entre ellos. Informalmente podríamos decir que un concepto es una idea, cosa u objeto. Para
descubrirlos debemos analizar los sustantivos en las descripciones textuales del dominio del problema, es
decir, de la descripción del sistema, de los requerimientos y de los Casos de Uso (Ver Figura 3):
Figura 3.
16
4.2. Diagrama de Clases

Nos muestra una vista de la aplicación en un determinado momento, es decir, en un instante en que el
sistema está detenido. Las clases son la plantilla de los objetos, y aquí podemos ver representados a estos
con sus atributos o características y su comportamiento o métodos, así como la relación entre ellas
Figura 4.
17
Figura 5.
Figura 6.
5. DIAGRAMA DE INTERACCIÓN
Son aquellos que muestran las interacciones de un usuario con el sistema. Interacción es una cadena de
mensajes enviados entre los objetos en respuesta a un evento generado por el usuario sobre la aplicación.
Los diagramas de interacción pueden ser Diagramas de Secuencia y Diagramas de Colaboración. Estos
diagramas conforman la etapa del diseño de la aplicación, y se crean a partir de los diagramas de Casos de
Uso y el Conceptual.
5.1. Diagrama de Secuencia del Sistema
18
Los Diagramas de Secuencia representan una interacción entre objetos de manera secuencial en el tiempo.
Muestra la participación de objetos en la interacción entre sus “líneas de vida” (desde que se instancias) y los
mensajes que ellos organizadamente intercambian en el tiempo. El responsable o ACTOR es quien inicia el
ciclo interactuando inicialmente con la interfaz de usuario: GUI; en seguida se inician todos los objetos que
intervienen en el funcionamiento del aplicativo. En este diagrama se comienza a observar el
comportamiento del sistema a partir de los eventos generados por los actores. Aquí se interactúa con
instancias, no con clases
Figura 7.
19
Figura 8.
20
Figura 9.
21
5.2. Diagrama de Colaboración del Sistema

Los Diagramas de Colaboración dan todas las especificaciones de los métodos. Estos permiten describir una
operación específica incluyendo sus argumentos y variables locales creadas durante su ejecución. Se
muestran los objetos y mensajes que son necesarios para cumplir con un requerimiento o propósito, o con
un conjunto de ellos. Se puede elaborar para una operación o para un Caso de Uso, con el fin de describir el
contexto en el cual su comportamiento ocurre
Figura 10.
Figura 11.
22
23
Figura 12.
5.3. Contratos
Es un formato que describe lo que una operación debe satisfacer o lograr, en términos de lo que se hace, más
no de cómo se lo hace, y haciendo énfasis en los cambios de estado que ocurren en las precondiciones y
postcondiciones de la operación.
CONTRATO
Nombre: Buscar Medicamento
Busca en la base de datos los medicamentos necesarios,

Responsabilidades:
según Nombre, Id_Medicamento, descripción o laboratorio.
Referencias Cruzadas: [R1] Realizar Pedidos y Mantener Productos
24
CU Sistema de venta Farmacia.

A partir del movimiento reportado en las actividades de las
Notas:
etapas de ventas.
Si el producto no se encuentra en stock el sistema genera
Excepciones una alerta mensaje #1 “Alerta Producto Faltante”
El Producto tiene Sobre Stock.

Genera una lista de los productos con la descripción
Salida:
solicitada.
Precondiciones: Para generar un pedido se debe contar con Stock bajo.
Proporciona un listado con los medicamentos y alternativas

Postcondiciones:
genéricas de dichos medicamentos.
CONTRATO
Nombre: Efectuar Pago
Una vez el cliente encuentra su medicamento procede a
Responsabilidades:
Efectuar el pago
Notas:
etapas de ventas.
Cliente quiere pagar con una forma de pago no disponible
Excepciones
Cliente no tiene suficiente saldo
Salida: Genera una boleta con los productos solicitados
Precondiciones: Cliente debe haber seleccionado un producto disponible
Proporciona una boleta con los detalles de la compra del
Postcondiciones:
cliente
CONTRATO
Nombre: Confirmar Compra
Una vez el cliente selecciono sus productos el Farmacéutico
Responsabilidades:
debe proceder a confirmar la compra
Notas:
etapas de ventas.
Cliente selecciono un producto sin stock
Excepciones
la receta es invalida
Salida: se procede a realizar la compra
Precondiciones: cliente debe haber seleccionado un producto
25
Proporciona una boleta con los detalles de la compra del

Postcondiciones:
cliente
CONTRATO
Nombre: Comprobar pago pendiente
Responsabilidades: Comprobar pago pendiente
Notas:
etapas de ventas.
ningún pago pendiente
Excepciones
Salida: se realiza pago

Precondiciones: debe haber un pago pendiente
Postcondiciones: entrega una aprobación del pago entrante
CONTRATO
Nombre: Consultar Stock
Responsabilidades: Consultar Stock de un producto seleccionado por el cliente

Notas:
etapas de ventas.
producto inexistente
Excepciones
Salida: se confirma compra

Precondiciones: debe existir el producto
Postcondiciones: se procede a confirmar la compra
26
CONTRATO
Nombre: Validar Receta
Responsabilidades: Validar Receta presentada por cliente
Notas:
etapas de ventas.
Cliente presenta receta invalida
Excepciones
Salida: se procede confirma compra

cliente debe presentar una receta por un producto que la
Precondiciones: requiera
Postcondiciones: se procede a confirmar la compra
CONTRATO
Nombre: Administrar Stock
Responsabilidades: Administrar Stock de todos los productos
Notas:
etapas de ventas.
Producto con quiebre de compañía.
Excepciones
Salida: Se informa el Stock

Precondiciones: Ingresar al sistema.
Postcondiciones: Se Genera un informe.
27
CONTRATO
Nombre: Consultar Stock en bodega
Responsabilidades: Consultar el stock de bodega
Notas:
etapas de ventas.
No hay stock
Excepciones
aun no se hace inventario de stock
Salida: Se informa el Stock
Precondiciones: se debe hacer la consulta a bodega
Postcondiciones: se entrega un informe con el stock
CONTRATO
Nombre: Reponer Stock en vitrina
Responsabilidades: Reponer Stock en vitrina
Notas:
etapas de ventas.
No hay stock para reponer
Excepciones
no hay necesidad de reponer
Salida: Vitrina queda con stock
Precondiciones: Stock faltante en vitrina
Postcondiciones: Se informa que vitrina queda con stock
CONTRATO
28
Nombre: Solicitar Productos a proveedor

Responsabilidades: Solicitar Productos a proveedor
Notas: A partir del movimiento reportado en las actividades de las
etapas de ventas.
Excepciones No falta Stock
Salida: Nuevo Stock de productos

Precondiciones: Falta Stock de uno o varios productos
Postcondiciones: Se hace un informe con el nuevo stock
6. DIA
GRA
MA
DE
ACTIVIDADES Y ESTADO:
29
30
Figura 13.
31
Figura 14.
32
Figura 15.
33
Estado:
Figura 16.
34
Figura 17.
35
Figura 18.
36
7. CONCLUSIONES
Como resultado de este trabajo, podemos concluir que los diagramas son importantes a la hora de hacer un
sistema u programa, en este caso estamos con un sistema de ventas de una farmacia, en el cual hemos
desarrollado sus correspondientes diagramas, sin duda no fue un trabajo fácil, podemos concluir que un
sistema de ventas de una farmacia es complejo, ya que hay que tener en cuenta varios factores, uno de ellos
es el stock de todos los productos, por eso hay que saber administrarlo. Para finalizar esta conclusión
diremos que basándonos en una farmacia hemos conseguido hacer un sistema de ventas para una farmacia
independiente.
37
8. ANEXOS
38

Proyecto UML

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Proyecto UML

Uploaded by

Copyright:

Available Formats

Information System I

Ing. Manuel Rojas V - manuel.rojas28@inacapmail.cl

Análisis y Diseño de Sistemas

UNIVERSIDAD TECNOLOGICA DE CHILE

1.3. Estructura del Documento

2. MODELO DE PROCESO DE NEGOCIOS

Business Process Management es un conjunto de métodos, herramientas y tecnologías utilizados para

2.1. Descripción de Actores Involucrados en el Modelo de Negocio

2.2. Requerimientos del Modelo de Negocio

Clave Descripción Tipo de

3. CASOS DE USO DE ALTO NIVEL

3.1. Casos de Uso de Alto Nivel

Figura 1.Representa el módulo de Ventas

3.2. Casos de Uso a Nivel Detallado

3.3. Descripción de Casos de Uso

CATALOGO DESCRIPCION CASOS DE USO

Proyecto : Sistema de Farmacia ID Caso de Uso : CU-001

Nombre Caso de Uso : Administrar Stock

Creado por : Sección Ingeniería Última Actualización por : Sección de Ingeniería

Versión : 1.1 Estado de Desarrollo : Propuesto

Estereotipo : Comercialización de Producto

Propósito : Realizar Pedidos, Reponer Productos y Controlar Stocks.

Permite saber cantidad de productos en inventario, para generar pedidos de artículos

Post condición : Se generan Inventarios Mensualmente, para evitar Perdidas.

Reglas de Negocio : [R1] Realizar Pedidos y Mantener Productos.

Escenario Normal de Eventos

[3.0] El Bodeguero genera Pedido. [4.0] El Sistema Genera Guía de Despacho.

Escenario Alternativo de Eventos

[2.0] El Sistema genera un mensaje #1 “Alerta Producto

[5.0] El Sistema genera un mensaje #2 “Alerta Proveedor

[6.0] Se Genera Orden de Compra.

Observaciones : el CU está en estado de aprobación

CATALOGO DESCRIPCION CASOS DE USO

Proyecto : Sistema de Farmacia ID Caso de Uso : CU-002

Nombre Caso de Uso : Confirmar Compra

Creado por : Sección Ingeniería Última Actualización por : Sección de Ingeniería

Versión : 1.1 Estado de Desarrollo : Propuesto

Estereotipo : Comercialización de Producto

Propósito : Generar la venta y realizar el Pago.

Post condición : Se realiza el pago, se entrega la boleta y Medicamentos al Cliente.

Reglas de Negocio : [R2] Realizar Pago y Entregar Medicamentos.

Escenario Normal de Eventos

[1.0] El Farmacéutico Revisa el detalle de Boleta. [2.0] Se Genera la Venta.

[3.0] El Farmacéutico Solicita el Pago de los Medicamentos. [4.0] Se Imprime la Boleta.

[5.0] Se descuenta del Stock los productos vendidos.

Escenario Alternativo de Eventos

[2.0] El Sistema genera un mensaje #3 “Producto con

[5.0] Se Imprime la Boleta.

[6.0] Se descuenta del Stock los productos vendidos.

Observaciones : el CU está en estado de aprobación

CATALOGO DESCRIPCION CASOS DE USO

Proyecto : Sistema de Farmacia ID Caso de Uso : CU-003

Nombre Caso de Uso : Buscar Medicamentos

Creado por : Sección Ingeniería Última Actualización por : Sección de Ingeniería

Versión : 1.1 Estado de Desarrollo : Propuesto

Estereotipo : Comercialización de Producto

Propósito : Selecciona los medicamentos a comprar.

Post condición : Se Genera un Detalle de Boleta para su posterior Pago.

Reglas de Negocio : [R3] Buscar medicamento y Generar Detalle de Boleta.

Escenario Normal de Eventos

[6.0] Se Genera un Detalle de Compra.

Escenario Alternativo de Eventos

[6.0] Se Genera un Detalle de Compra.